Originally posted by deanjo
View Post
Announcement
Collapse
No announcement yet.
Ryan Gordon Is Fed Up, FatELF Is Likely Dead
Collapse
X
-
Originally posted by smitty3268 View PostSpecify 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.
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!
Comment
-
Originally posted by deanjo View PostWell 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
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).
As far as the "Once enough 3rd party programs start relying on that functionality" it's the chicken and egg thing.
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.
Comment
-
Originally posted by Veerappan View PostSome 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.
executable x86_64
executable x86_32
executable PPC64
data
pick data + one of the 3 and install them. Done.
Comment
-
Originally posted by droidhacker View PostThat 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.).
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.
Comment
-
Originally posted by droidhacker View Post... 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....
Whatever unforseen arch there may be is guaranteed not to be within your fatelf anyways, so this is a pointless argument.
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.
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!
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.
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.).
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.Last edited by deanjo; 05 November 2009, 05:44 PM.
Comment
-
Originally posted by deanjo View PostIf 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.
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.
Comment
-
Originally posted by Vighy View Postdon'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
Go figure (yes, this is the interwebs.)
Comment
Comment