Ryan Gordon Is Fed Up, FatELF Is Likely Dead

[deanjo]

I don't care about patents in this case, only about the technical reasons why FatELF is not needed. I leave patents to the lawyers.

Then of course there is also the fact that steam is not available to linux or os x, so are we now using Windows as an example of proper package delivery and installation?

You may not care about patents but I assure you the GNU / FSF crowd does.

[admax88]

To those of you in this thread who think that FatELF will magically fix compatability issues in linux you are _wrong_.

FatELF just takes different ELF files and puts them together into one file. That's it. It doesn't address issues like packaging across different distro's, or dealing with different versions of differnt libraries on different distros.

The only reason universal binaries work on Mac OS X is because the OS X environment is very homogeneous. Sure it supports up to 4 different platforms, but Apple has very tight control and knowledge over what is installed on every OS X install. Its like only having to package for 1 distro that supports 4 different processors (PPC32 PPC64 x86 x86_64).

OS X has no where near the complexity of the hundreds of different linux distro's and environments. Any linux distro and install can have all kinds of different versions of libraries available, FatELF doesn't help this.

The only solution, besides a package manager (which is really your best option), is to bundle all the libraries with your program. Not only is this a monumental waste of space and bandwidth(you know how many compat libs you need for 32-bit on 64-bit? imagine that times every since FatELF application you have on your system), but it was also possible to do this _before_ FatELF came around.

FatELF doesn't fix any compatability problems in linux in any way shape or form. It's only use is to let a stupid user download 1 big file and run it, rather than download 2 half-size files till he finds the one that runs.

[misiu_mp]

You do realize a patent covering that is going to court right? Look up patent US2004093167. " ANALYTE DETECTION SYSTEM WITH SOFTWARE DOWNLOAD CAPABILITIES"

Here is the EU patent pdf: http://www.freepatentsonline.com/EP1565103.pdf

Could you shortly mention which part of that patent is relevant to the discussion?
Is it automatic software updates you mean?
Im naturally not a specialist in patent law, but doesnt the automatic software update part only apply to a computer controlling an 'analyte detection system' (claim 16, 37)? However we would like linux to control such systems, what does it have to do with FatElf?
For everyone: Claims start at page 56.

[Veerappan]

FatELF doesn't fix any compatability problems in linux in any way shape or form. It's only use is to let a stupid user download 1 big file and run it, rather than download 2 half-size files till he finds the one that runs.

Some people seem to be forgetting the proportions of code to data in the application space we're talking about here (primary commercial games).

Lets say you've got a universal binary that handles x86, x86_64, and PPC 32-bit. This binary is for World of Warcraft (a randomly picked example). The original release of WoW contained ~3.5GB of installed data, and a binary which was only several megabytes in size. Let's pick a (probably exaggerated) number of 50MB for the X86 executable. The main point here is that textures/models/sounds/scripts make up the bulk of the installed game, not the executable.

Now lets image that Blizzard wants to release a *nix WoW client. There's no way that they'll convince the maintainers of a dozen different distributions to include their closed-source application in the default repositories for each distibution, so they have to release it themselves. They could package it as rpm, deb, or several of a dozen different formats, but each of those would be something they'd have to support separately.

With this FatELF concept, they could compile the game on x86, x86_64, and PPC once, and create a single archive containing all 3 architectures. The total size of the archive (before compression) would be 3.5GB + 50MB*3 = 3.65GB, which is a far cry from the 3 * 3.5GB you seem to be fearing.

This archive could either contain copies of the libraries needed to run the game on each architecture (whose versions could explicitly be chosen for compatibility with the game code and known stability), or you could take the easy way out and just statically compile the executable. Either way, as pointed out before, by including only copies of required libraries, the need for a FULL set of 32-bit compatibility libraries is avoided, and only relevant libraries are included.

This method may lead to a larger installed application than including only a single architecture, but it's not the monumental waste of space that some people are making it out to be.

Personally, I like the idea of FatELF, but it seems that I'm in the minority with deanjo here.

[admax88]

Some people seem to be forgetting the proportions of code to data in the application space we're talking about here (primary commercial games).

I'm fully aware of the data-code ratio in commercial games.

Now lets image that Blizzard wants to release a *nix WoW client. There's no way that they'll convince the maintainers of a dozen different distributions to include their closed-source application in the default repositories for each distibution, so they have to release it themselves. They could package it as rpm, deb, or several of a dozen different formats, but each of those would be something they'd have to support separately.

Stitching the differnt platform binaries into FatELF won't save them the trouble of packaging for different distros. They will still have to deal with different versions of libraries and different packaging formats for each distro they wish to support.

3.5GB + 50MB*3 = 3.65GB, which is a far cry from the 3 * 3.5GB you seem to be fearing.

I think you may have mis-read my post, that or I wasn't as clear as I could have been. I realize that a FatELF for WoW3 or almost any application won't be that much larger since its only the executable data that needs to be duplicated.

My point was that, FatELF won't fix the compatability issues between the available libraries on different distro's. Because of this the only solution outside of a package manager is to package all the required deps and compatability libraries along with the original executable for the game.

But if every game I'm installing on linux has to pacakge their own libcurl, libgl, libthis, libthat, libcompatx86, whatever whatever, that will be a huge amount of wasted space on my box. Every game that I install will have multiple copies of libcurl, libthis, libthat for every platform that was included in the FatELF.

The space hit to one package may only be 50-100 Megs depending on the amount of libraries required, but if I install 10 games on system, that's 500-1Gig I'm wasting on duplicated code.

This archive could either contain copies of the libraries needed to run the game on each architecture (whose versions could explicitly be chosen for compatibility with the game code and known stability), or you could take the easy way out and just statically compile the executable. Either way, as pointed out before, by including only copies of required libraries, the need for a FULL set of 32-bit compatibility libraries is avoided, and only relevant libraries are included.

You gave me a space estimate for duplicating the core game executable for 3 arch's, but you ignored that space of including all these libraries and then duplicating them for every platform.

Looking back at my post it seems my argument is mostly against packaging static libs with your download, than againt FatELF itself. However FatELF on its own doesn't address any compatability issues on package/distributing in linux.

[Milt]

Fatelf sounds like a good improvement for commercial software in my opinion.

It will not solve all problems, but it will make life easier for people that "just want to make it work".

It would be much better if we could all make a common package manager instead of course, but I do not expect it to happen realistically.
(Personaly I think that most common package managers today are more or less very limited and/or broken ....
Gobolinux seems nice though, but I have only done limited testing so far )
("worse is better" - imo fatelf is worth doing even if a perfect package manager would be a _better_ solution in theory)

[misiu_mp]

There seem to be two main reasons to have fatElf as advocated by its proponents:
1. distributing binaries for different architectures bundled together
2. distributing an executable and the libraries it depends on in a single package.

Both of these can be achieved today by simply putting all the binaries and all the libraries to one directory tree plus a simple script to choose the right version.

I hear cries about how difficult it is to deploy on linux because of all the distro incompatibilities. Well, lets take a look at a concrete example, such as WorldOfGoo.
It is distributed as a deb, rpm and a tar.gz. This is the relevant content of the tar.gz:

d icons
d libs32 \_ contains libogg, libvorbis, libSDL
d libs64 /
d res - game data
f readme.html
f WorldOfGoo
f WorldOfGoo.bin32
f WorldOfGoo.bin64

The WorldOfGoo shell script basically only does:

MACHINE=`uname -m`
if [ "$MACHINE" = x86_64 ]
then
	LIBS=./libs64
	BIN=./WorldOfGoo.bin64
else
	LIBS=./libs32
	BIN=./WorldOfGoo.bin32
fi

export LD_LIBRARY_PATH=$LIBS:"$LD_LIBRARY_PATH"
$BIN $@

The rpm and deb differs from the tarball only in that they put the above in /opt/WorldOfGoo and install some shortcuts and icons.

You cant say it takes a lot of effort to 'maintain' that?

Sure a shell script, however simple and posix-compatible it tries to be, is somewhat error-prone (its easy to use some non-standard-compliant features and make assumptions). Thats why I would rather see a project that factors out the operations usually done in such scripts (other common operation ive seen is locating certain directories) and provides them in a standardized way (some kind of an extended symlink framework maybe). This certainly doesn't look like a kernel problem at all.

Somebody asked why isnt it done? Maybe because status quo works as good as it does!

[Svartalf]

I hear cries about how difficult it is to deploy on linux because of all the distro incompatibilities. Well, lets take a look at a concrete example, such as WorldOfGoo.

And the cries are from people that don't know how to do the self-same. There's several differing ways to accomplish things in a way that doesn't have issues.

World Of Goo's a good example, by the by. Caster3D's another. (But then, I'm a bit biased there... )

We don't have the same situation as Apple does and "universal" binaries won't fix it any better than the current set of answers (seriously...)- and doesn't resolve the things I talked to earlier in this thread.

As one blogger elsewhere commented: "It's a nice proof of concept"

But, as they also observed: "It's not going anywhere"

As a PoC, I like it. As something practical, though, it doesn't resolve a raftload of things, it doesn't do it ANY different, really from what is already in place, and it majorly changes up a bunch of stuff in the process of doing all the aforementioned. Alan Cox and others summed up the issues with it (and there's legitimate commentary from all over the place showing why it ended the way it did.).

[Ant P.]

The more I read these posts, the less I'm convinced it solves an actual problem.

The hypothetical scenario of downloading a multi-GB game once per architecture is completely wrong to begin with - the right way to handle that is to install the data and the engine as separate packages so that security fixes don't require reinstalling the entire thing each time.

[Milt]

Somewhat agree somewhat disagree personaly...

Yes clearly the best situation would be a nice clean package manager that deals with the problem.
And yes I am aware that fatelf does not stand a chance of getting anywhere.

I still disagree that it is necessarily a bad solution.