Re: FatELF patches...

From: Alan Cox
Date: Sun Nov 01 2009 - 19:00:28 EST

Lets go down the list of "benefits"

- Separate downloads
- Doesn't work. The network usage would increase dramatically
pulling all sorts of unneeded crap.
- Already solved by having a packaging system (in fact FatELF is
basically obsoleted by packaging tools)

- Separate lib, lib32, lib64
- So you have one file with 3 files in it rather than three files
with one file in them. Directories were invented for a reason
- Makes updates bigger
- Stops users only having 32bit libs for some packages

- Third party packagers no longer have to publish multiple rpm/deb etc
- By vastly increasing download size
- By making updates vastly bigger
- Assumes data files are not dependant on binary (often not true)
- And is irrelevant really because 90% or more of the cost is

- You no longer need to use shell scripts and flakey logic to pick the
right binary ...
- Since the 1990s we've used package managers to do that instead.
I just type "yum install bzflag", the rest is done for me.

- The ELF OSABI for your system changes someday?
- We already handle that

- Ship a single shared library that provides bindings for a scripting
language and not have to worry about whether the scripting language
itself is built for the same architecture as your bindings.
- Except if they don't overlap it won't run

- Ship web browser plugins that work out of the box with multiple
- yum install just works, and there is a search path in firefox

- Ship kernel drivers for multiple processors in one file.
- Not useful see separate downloads

- Transition to a new architecture in incremental steps.
- IFF the CPU supports both old and new
- and we can already do that

- Support 64-bit and 32-bit compatibility binaries in one file.
- Not useful as we've already seen

- No more ia32 compatibility libraries! Even if your distro
doesn't make a complete set of FatELF binaries available, they can
still provide it for the handful of packages you need for 99% of 32-bit
apps you want to run on a 64-bit system.

- Argument against FatELF - why waste the disk space if its rare ?

- Have a CPU that can handle different byte orders? Ship one binary that
satisfies all configurations!

- Variant of the distribution "advantage" - same problem - its
better to have two files, its all about testing anyway

- Ship one file that works across Linux and FreeBSD (without a platform
compatibility layer on either of them).

- Ditto

- One hard drive partition can be booted on different machines with
different CPU architectures, for development and experimentation. Same
root file system, different kernel and CPU architecture.

- Now we are getting desperate.

- Prepare your app on a USB stick for sneakernet, know it'll work on
whatever Linux box you are likely to plug it into.

- No I don't because of the dependancies, architecture ordering
of data files, lack of testing on each platform and the fact
architecture isn't sufficient to define a platform

- Prepare your app on a network share, know it will work with all
the workstations on your LAN.

- Variant of the distribution idea, again better to have multiple
files for updating and management, need to deal with
dependancies etc. Waste of storage space.
- We have search paths, multiple mount points etc.

So why exactly do we want FatELF. It was obsoleted in the early 1990s
when architecture handling was introduced into package managers.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at