Ryan Gordon Is Fed Up, FatELF Is Likely Dead

[droidhacker]

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.

How is it relevant if every distro and packager plays by the same rules? It is up to THAT PARTICULAR distro to be consistent with their OWN package manager, and it is up to the packager to ensure that THEIR PACKAGE meets the packaging specifications of the distro they are targeting.

[droidhacker]

Specify a package format that just stores everything into a zip file like that and try to get people to use it. Once enough 3rd party programs start relying on that functionality he can then make the argument that it would be better if integrated into the ELF specification.

Interesting thought...
You know, you could actually do this with RPM quite easily. Just use a "noarch" and set it to extract its files into /lib32, /bin32, /lib64, and /bin64 (and wherever else is needed), and in the post stage of the install, create a symlink from /bin/whatever -> /bin??/whatever. Or even better, create a script in /bin/whatever that does if (arch=whatever) run --/bin??/whatever. The functionality *already exists*, lets call it fatRPM!

[droidhacker]

Well first of all zip is a piss poor way of trying to preserve permissions and such so throw that idea out of the window as far as using zip. Of course you can check arch with a script again hoping that the script maintainer had enough foresight to see all possible reporting of the arch type

Whatever unforseen arch there may be is guaranteed not to be within your fatelf anyways, so this is a pointless argument.

and of course you hope like hell everybody is using the same shell and paths. Many present day installers already try that mojo sad fact is that they fail after a while. (For example many Loki installer games fail because of changing device names, old incompatible libs, etc).

In this regard, it doesn't make ANY difference if you are using elf or fatelf, since you STILL depend on the same device names, up to date libraries, etc.

As far as the "Once enough 3rd party programs start relying on that functionality" it's the chicken and egg thing.

Since the first chicken was born of some sub-chicken species that LAID EGGS, the egg came first. FACT.

Seeing that Ryan is the big porter for many of these commercial games, I would have to say he finds it desirable for his situation. He's carried the porting torch for linux for quite a while now, it would be a deep shame to lose his contributions. As it is he already ports more for the mac then linux, this gives him just another reason to discourage development for linux.

Huh? So you propose to let him spoil linux just to keep him HAPPY enough to keep porting games? Maybe if his games are so important to you, you should pull out your cheque book and buy him a new car or some hookers or something.

[droidhacker]

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.

Or you could package your files as...
executable x86_64
executable x86_32
executable PPC64
data

pick data + one of the 3 and install them. Done.

[Ant P.]

Since the first chicken was born of some sub-chicken species that LAID EGGS, the egg came first. FACT.

Chickensaur evolves into Chicken at level 25, actually

[duby229]

That would depend on how retarded your distro is behaving (i.e. how many unneeded 32bit libs they install just for the fun of it).

In other words, you can have an *entirely* 64bit system and it works just fine. If you need to run some specific 32bit program, you install ONLY the required dependencies instead of *ALL* 32bit packages provided by the platform, which is what fatelf would do (in addition to installing ALL of the packages for ALL platforms that *aren't even compatible* -- like ARM, SPARC, PPC, PPC64, etc.).

See that is exactly why I said it is a shame....

Fatelf solves the problem where you can have only the required 32bits libs needed and nothing else, and it stores them in a convenient way also abides traditional filesystem layout. It removes the need for a whole bunch of stupid symlinks and makes finding and linking libraries a hell of a lot easier.

The problem with it is that make doesnt really support crosscompiling in an efficiant elegant manner. Cross compiling on most distros is hackish at best, and on others is a collection of complicated scripts that need special sandboxed environments to run in. The fact is that fatelf is an excellent idea to solve amajor problem, but it doesnt address the massive deficiency in cross compiling support in linux as it exists today.

make needs to be completely rewritten or replaced.

[deanjo]

... so the goals are to make everybody need to download 5 or 10 DVDs to install from instead of just one that matches their architecture? That sure sounds simple to me....

LMAO you clearly don't get it at all, try a few extra meg.

Whatever unforseen arch there may be is guaranteed not to be within your fatelf anyways, so this is a pointless argument.

Script checks for x86-64, system reports back x86_64, fail

In this regard, it doesn't make ANY difference if you are using elf or fatelf, since you STILL depend on the same device names, up to date libraries, etc.

Which would be handled by the fatELF supporting libraries that are maintained by the distro.

A distro would only have to maintain their fatELF libraries this way not them having to maintain every single commercial application out there. Next

Interesting thought...
You know, you could actually do this with RPM quite easily. Just use a "noarch" and set it to extract its files into /lib32, /bin32, /lib64, and /bin64 (and wherever else is needed), and in the post stage of the install, create a symlink from /bin/whatever -> /bin??/whatever. Or even better, create a script in /bin/whatever that does if (arch=whatever) run --/bin??/whatever. The functionality *already exists*, lets call it fatRPM!

Again not every distro follows the same directory structure especially when it comes to /lib structure.

How is it relevant if every distro and packager plays by the same rules? It is up to THAT PARTICULAR distro to be consistent with their OWN package manager, and it is up to the packager to ensure that THEIR PACKAGE meets the packaging specifications of the distro they are targeting.

And how often does that happen? Extremely rare when dealing with commercial apps. If you can find me a commercial app that has a distro specific package for all the flavors of distros out there then you can start talking about reality of execution. To this date this has not happened. There is a reason why vendors like nvidia have stopped making distibution specific install packages the vender can't do it nor will all the distro's put the effort to make such packages let alone host them. Again reality check time.

That would depend on how retarded your distro is behaving (i.e. how many unneeded 32bit libs they install just for the fun of it).

In other words, you can have an *entirely* 64bit system and it works just fine. If you need to run some specific 32bit program, you install ONLY the required dependencies instead of *ALL* 32bit packages provided by the platform, which is what fatelf would do (in addition to installing ALL of the packages for ALL platforms that *aren't even compatible* -- like ARM, SPARC, PPC, PPC64, etc.).

I have yet to see any mainstream package system that does not install a bunch of unneeded linked libs for a application. You might of heard of this but it's called dependency hell.

As well, FatElf could only install what is needed and a situation such as it isntalling libs for "ARM, SPARC, PPC, PPC64, etc" is highly unlikely if the application isn't even supported in that architecture. Again keep this within the realm of reality and within context.

[yogi_berra]

If you can find me a commercial app that has a distro specific package for all the flavors of distros out there then you can start talking about reality of execution. To this date this has not happened.

http://www.sidefx.com/index.php?opti...ice&Itemid=277

Packages for Ubuntu 9.04 + 7.04 + 7.10, Debian Lenny + Etch, RHEL 4 + 5, OpenSuse 10.2, and a generic 32 bit for the weirdo's on arch, slackware, and gentoo.

[Vighy]

don't know if someone already linked it, but Diego Pettenò made an explanation why it was not accepted:
http://blog.flameeyes.eu/2009/11/04/...r-be-on-a-diet

[RealNC]

don't know if someone already linked it, but Diego Pettenò made an explanation why it was not accepted:
http://blog.flameeyes.eu/2009/11/04/...r-be-on-a-diet

Yeah, I already posted that but everyone in here just continues talking the same stuff all over again and totally ignoring that article.

Go figure (yes, this is the interwebs.)