Ryan Gordon Is Fed Up, FatELF Is Likely Dead

[deanjo]

FATElf does not have anything to do with bundling libraries with applications. Regardless, such bundling trivial to do without FATElf -- the tar command can take multiple filenames when creating an archive, and the dynamic loader's search path is configurable at runtime.

The problem that FATElf purports to solve appears to be that some users are too stupid to download the correct binary for their architecture while also being unable or unwilling to use a package manager. Perhaps this is a problem worth solving, but let's keep the solution out of core system components.

You don't seem to be getting the whole picture of the goals of FatELF.

http://icculus.org/fatelf/

• Distributions no longer need to have separate downloads for various platforms. Given enough disc space, there's no reason you couldn't have one DVD .iso that installs an x86-64, x86, PowerPC, SPARC, and MIPS system, doing the right thing at boot time. You can remove all the confusing text from your website about "which installer is right for me?"
• You no longer need to have separate /lib, /lib32, and /lib64 trees.
• Third party packagers no longer have to publish multiple .deb/.rpm/etc for different architectures. Installers like MojoSetup benefit, too.
• A download that is largely data and not executable code, such as a large video game, doesn't need to use disproportionate amounts of disk space and bandwidth to supply builds for multiple architectures. Just supply one, with a slightly larger binary with the otherwise unchanged hundreds of megabytes of data.
• You no longer need to use shell scripts and flakey logic to pick the right binary and libraries to load. Just run it, the system chooses the best one to run.
• The ELF OSABI for your system changes someday? You can still support your legacy users.
• 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.
• Ship web browser plugins that work out of the box with multiple platforms.
• Ship kernel drivers for multiple processors in one file.
• Transition to a new architecture in incremental steps.
• Support 64-bit and 32-bit compatibility binaries in one file.
• 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.
• Have a CPU that can handle different byte orders? Ship one binary that satisfies all configurations!
• Ship one file that works across Linux and FreeBSD (without a platform compatibility layer on either of them).
• 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.
• Prepare your app on a USB stick for sneakernet, know it'll work on whatever Linux box you are likely to plug it into.
• Prepare your app on a network share, know it will work with all the workstations on your LAN.

[Draconx]

You don't seem to be getting the whole picture of the goals of FatELF.

http://icculus.org/fatelf/

<list of quoted bullets omitted>

Which of those bullets, specifically, has anything to do with bundling library dependencies?

[kraftman]

You don't seem to be getting the whole picture of the goals of FatELF.

http://icculus.org/fatelf/

Goals met with reality and project is probably dead Alan explained why FatElf isn't good:

http://lkml.org/lkml/2009/11/1/148

[energyman]

Sure and your friendly distro packager makes sure that most of those are so intertwined with dependencies on other NOT NEEDED libs that it slaps a bunch more code that is not needed. At least with a "Universal Binary" I can get rid of the whole item without worrying about breaking other apps and not having no longer needed libs on my system.

wrong. You still need all that 'unneeded crap'. Even worse - every fatelf binary consists of uneeded crap. Which means, more wasted space, longer load times. Everything worse.

[deanjo]

wrong. You still need all that 'unneeded crap'. Even worse - every fatelf binary consists of uneeded crap. Which means, more wasted space, longer load times. Everything worse.

Wrong, I've seen way to many compat 32-bit libs slapped up with the likes of cups-32 compat libs. Uhhuh ya, that is really needed now isn't it.

[deanjo]

Goals met with reality and project is probably dead Alan explained why FatElf isn't good:

http://lkml.org/lkml/2009/11/1/148

Most of which involves making sure that every damn distro out there AND the project are on the same page and in sync. This is NEVER the case. If the LSB was expanded and enforced then his arguments might have merit. Alan's comments are based in a "ideal" world scenario with is far from the real world. For christ sakes they can't even decide on what directory to put libs in.

[fabiank22]

This is exactly what Mac's Universal Binaries does do. Throw out the package to trash and your done.

Then why would we need Kernel-Level support and glibc-changes? After all it should be easily work on the level of a package-manager, and those don't need changes that invasive after all.

[deanjo]

Then why would we need Kernel-Level support and glibc-changes? After all it should be easily work on the level of a package-manager, and those don't need changes that invasive after all.

My response to that is why hasn't that happened already if the work is "easily" done?

[deanjo]

Sorry guys, but there is no way that you are going to convince me that making sure every damn distro and packager are playing by the same set of rules is easier then giving a "one-size-fits-all" solution. Ever think that there is good motivation behind Ryan's efforts? After all he is the leading porter of games for OS X and linux.

[kraftman]

Most of which involves making sure that every damn distro out there AND the project are on the same page and in sync. This is NEVER the case. If the LSB was expanded and enforced then his arguments might have merit. Alan's comments are based in a "ideal" world scenario with is far from the real world. For christ sakes they can't even decide on what directory to put libs in.

However, I prefer to install everything using package manager. If some third party member doesn't want to give me a package I consider it's their fault. :>

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

Why me or many other Linux user would want this? (except those who use bsd too) ;p