Ryan Gordon Is Fed Up, FatELF Is Likely Dead

[snogglethorpe]

Good riddance. We shouldn't be copying Apple's stupider ideas.

[energyman]

Alan Cox gave a lot good reasons why fatelf is not needed in any way on lkml.

[M1AU]

I, for some reason, liked the idea of FatELF, especially for the main reason of multi-platform-binaries for commercial games. Well, I'm not sure if this would have addressed some core problems of building binaries for different platforms, but at least it could have addressed the way how they are distributed.

I also don't see the distribution package-managers as a viable option for installing big commercial games for various reasons. Maybe that's just me, but as I'm already having about 50+ GB of games installed on my home directory, I don't really want all of them to be installed through the package manager and therefor be installed somewhere in my system where I don't really know where it is (for the main reason of space, of course).

Well I'm sure many will disagree with me here since I'm talking about commercial software, though I see commercializing games as a viable option for game studios, even on Linux and FatELF could have helped them with easier package distribution.

[energyman]

so what? if you put the crap in your $HOME you are certainly able to download or copy the right binary package.

For everybody else there is a package manager. And distros with a good multilib setup don't even care if a bianry is 32 or 64bit.

FatELF is a non-solution in search of a problem.

[energyman]

Not dodging the questions at all, had old games such as loki games used such a approach I would still be able to use those games for example in a modern distro. Right now you try to run some of those old games and they *cough* *puke* and fart trying to find matching libs. In a "universal binary" approach this wouldn't be the case. Even in opensource projects such as Warsow this is a issue for example where it specifically looks for libcurl3 where as my distro has long gone and replaced that for libcurl4 (and doesn't even offer libcurl3 anymore). So what do you do you go and gripe to the game devs saying "hey my distro uses xyz lib though" to which the reply all to often today is "well it works on ubuntu". Then there is the issue as well that each distro's location of libs can vary some dump it in various places like /lib or /lib32 or /lib64 etc. BTW, Apple's universal libraries also handle more then just 2 arch, 4 by default PPC32 PPC64, x86 and x86-64. Your right, it can lead to a very big binary size but in reality how many ET:QW games are going to only need a recompile to play it on a arm arch? This is where common sense comes into play, but nice try at the "worst case" scenario play as unlikely as it is to ever come into reality.

Ryan is just trying to make a solution that would allow commercial developers to develop for linux without having to worry about each distro's "nuance" in order to get their product to run on each persons flavor of linux. This is a sore point that does hold linux back from being mainstream (as well, like it or not the lack of commercial apps).

a universal binary wouldn't help you in any way.

Stop that right there. You don't even know what you are talking about.

Btw, CivCTP still works:
just use the static binary
turn of HEAP RANDOMIZATION

and it runs. Without multilib, fatelf or whatever.

And Mac - well, what was the last version of MacOSX for PPC? PPC and PPC64 aren't that diffenrent and fatelf does not save you bacon when it comes to libs.

So. No. FATELF is a stupid idea. Solving no problems. Only creating new ones.

[yoshi314]

Who else here is sick of the constant UT3 remarks in every single icculus article?

i, for one, am sick of article full of self-referring links, that makes the text all green.

who cares about ut3 linux at this point, anyway?

[smitty3268]

Not dodging the questions at all, had old games such as loki games used such a approach I would still be able to use those games for example in a modern distro. Right now you try to run some of those old games and they *cough* *puke* and fart trying to find matching libs. In a "universal binary" approach this wouldn't be the case. Even in opensource projects such as Warsow this is a issue for example where it specifically looks for libcurl3 where as my distro has long gone and replaced that for libcurl4 (and doesn't even offer libcurl3 anymore). So what do you do you go and gripe to the game devs saying "hey my distro uses xyz lib though" to which the reply all to often today is "well it works on ubuntu". Then there is the issue as well that each distro's location of libs can vary some dump it in various places like /lib or /lib32 or /lib64 etc. BTW, Apple's universal libraries also handle more then just 2 arch, 4 by default PPC32 PPC64, x86 and x86-64. Your right, it can lead to a very big binary size but in reality how many ET:QW games are going to only need a recompile to play it on a arm arch? This is where common sense comes into play, but nice try at the "worst case" scenario play as unlikely as it is to ever come into reality.

Ryan is just trying to make a solution that would allow commercial developers to develop for linux without having to worry about each distro's "nuance" in order to get their product to run on each persons flavor of linux. This is a sore point that does hold linux back from being mainstream (as well, like it or not the lack of commercial apps).

Ok, so it sounds like you are less concerned with the ability to have a binary run on multiple architectures and more impressed by the ability for it to embed libraries directly into it? I wasn't aware that it could do that, and I'm still not sure why that's such an awesome thing - couldn't Warsaw just stick libcurl3 next to the executable and load the locally provided copy rather than going to the system lib? It seems like it's exactly what you're looking for anyway, just seperated into a 2nd file, or am I missing your point?

BTW, there was another technology around a year or two ago that did something similar, without requiring massive changes to ELF. I think it mounted the file as a filesystem and everything that was needed to run was present there and automatically handled for you, so that no system libs were required. I can't remember what it was called, though.

I understand what Ryan is trying to do here, it just seems like a really fundamentally large change to the system in exchange for supporting a group that isn't exactly a priority on linux, or very large right now. Not making judgements myself there, I'm just saying the problems he is having selling this to the rest of the projects it would affect were pretty forseeable. And it seems to me like there are less intrusive ways to solve the issues that his system is meant to, if he had thought about the best way to do this within Linux rather than starting with a solution from Apple and trying to port it over to Linux.

[M1AU]

so what? if you put the crap in your $HOME you are certainly able to download or copy the right binary package.

For everybody else there is a package manager. And distros with a good multilib setup don't even care if a bianry is 32 or 64bit.

FatELF is a non-solution in search of a problem.

Well that's true, no big deal for me. I more thought about devs of Mac games hesitate to make a Linux port of there games, because of to the lack of multi-lib binaries. But well, as I see that you don't care at all about this "crap", lets end this here. I may also just be wrong if I thought this could have helped them in any way, as I'm just a humble user and not a coder at all.

i, for one, am sick of article full of self-referring links, that makes the text all green.

who cares about ut3 linux at this point, anyway?

Put me on the list of "sick of article full of self-referring links" and I also don't care about UT3 anymore.

[fabiank22]

Then there is the issue as well that each distro's location of libs can vary some dump it in various places like /lib or /lib32 or /lib64 etc. BTW, Apple's universal libraries also handle more then just 2 arch, 4 by default PPC32 PPC64, x86 and x86-64. Your right, it can lead to a very big binary size but in reality how many ET:QW games are going to only need a recompile to play it on a arm arch? This is where common sense comes into play, but nice try at the "worst case" scenario play as unlikely as it is to ever come into reality.

Ryan is just trying to make a solution that would allow commercial developers to develop for linux without having to worry about each distro's "nuance" in order to get their product to run on each persons flavor of linux. This is a sore point that does hold linux back from being mainstream (as well, like it or not the lack of commercial apps).

Okay, a few problems with your approach here:

- Why do you even need to be able to install the same package on many different archs?
If you choose a x64-arch you can still install x86-packages just fine, and with x86 you can't work with x64 either way. If you say "using x86 on x64 causes a shitload of deps", well big surprise, FatELF still has those deps and duplicate libs, just packaged differently and without providing bugfixes and security patches to it.
If have an exotic or mobile arch like say, Arm or PPC or something you will most like need a customized distro/kernel either way, and thus most of your programms will only be specialized/ported either way. FatELF doesn't make stuff magically run on your Freerunner.

- Which programs benefit from FatELF?
Most stuff won't have any advantage with FatELF - basically all open-source projects can be easily installed AND updated from the distro repository, and if not they most likely will provide either debs or rpms, which can be converted if nothing to ditro-level is included. OSS that doesn't include packages will likely not give a f*** about FatELF!
Games... well guess what, most closed-source games don't bother with other archs than x86 at all, and have real problems with space already. They will build for x64 the same moment THEY NEED TO!, which means when they start needing more than 4Gb-Ram.
After that there is only one way FatELF could do what you want it to: bundling all needed libs, compilers,runtimes, and whatnot with the ELF and installing it.

Guess where that ends:
- you will have at least 4 version of GCC and it's libs installed
- none of the packages included will have security patches and none of the companies will bother maintaining half the Linux-Desktop
- this won't help you the slightest if the kernel-Api breaks or FatELF releases new versions

[fabiank22]

Well that's true, no big deal for me. I more thought about devs of Mac games hesitate to make a Linux port of there games, because of to the lack of multi-lib binaries.

not a coder at all

not a coder

The problem with Mac games not being ported are many:
- Really bad drivers and driver support for graphics
- Compilers not having stable APIs, making it fun to port everytime gcc releases something new
- different distros behaving differently
- No established content architectures like steam
- Wine already providing "fair enough"-support for some stuff
- too little commercial potential(Yes, you CAN argue about that one)
- and so on

FatELFs are Multi-Arch-Binaries, thus not solving anything, Multi-Lib-Binaries have their own problems, for example: have fun maintainig this.
Windows sidesteps this with having multiple DLLs of fucking everything, but thats referred to as "DDL-hell" for a reason. For examlple: whatever happens if a security update or a third party changes the dll?