Ryan Gordon Is Fed Up, FatELF Is Likely Dead

[energyman]

FatELF reminds me of the meetings I go to with my manager where buzzwords are flying around. "Universal Binaries" must be good, right? It will help our synergy as we move forward in this web 2.0 world.

Seriously, FatELF takes something you can already do on Linux and makes it a little more elegant. Which would be nice if people were using that functionality a lot, but as it is you're talking about making deep changes across the system libraries for a very limited payoff.

Yes, I know the chicken vs egg problem. In this case, I respectfully argue that the egg from Ryan needs to come first.

no, it makes it a lot LESS elegant. The only thing it does:

increased loads on mirrors.

Fatelf is a failure. A stupid idea to begin with that does not solve any problems but creates a lot more.

[smitty3268]

no, it makes it a lot LESS elegant. The only thing it does:

increased loads on mirrors.

Fatelf is a failure. A stupid idea to begin with that does not solve any problems but creates a lot more.

I disagree. It removes a shell script and combines a couple different files into 1. That seems slightly more elegant to me, at least from a developers perspective. From the perspective of the kernel/glibc folks, perhaps it still seems like a giant hack.

[Kano]

FatELF seems for me like a very interesting technology demonstration but without much use as it comes too late. Even if new distros would adopt it now then it would not help at all for users with older systems. Then you do not only need a "uname -m" selection - which i use for years of course as it is needed from 3d driver install scripts and when there are some differences in other aspects. You would still have to carry the old binaries for commerical games in order to satisfy all customers. Of course it could help for future generations, but then maybe mainstream is 64 bit already. Currently adobe flash is only 2nd choice for 64 bit which should really change soon - a universal binary would not hurt but a more simple download selection would be enough. Currently the download is so hidden that i prefer providing an install script. For games you could simple only provide 32 bit apps and hope that 32 bit emulation is active, just provide more 32 bit libs that it would run with minimal ia32-libs packages. Maybe you gain speed for games with lots of memory use, but for small games it might be not needed - however providing a 64 bit binary is usually not that hard when the code is in good shape.

[energyman]

I disagree. It removes a shell script and combines a couple different files into 1. That seems slightly more elegant to me, at least from a developers perspective. From the perspective of the kernel/glibc folks, perhaps it still seems like a giant hack.

and instead of a simple shell script you get a multi megabyte overhead. No, that is not elegant. That is complete opposite of elegant.

It is a nightmare. It is a nightmare for mirrors, it is a nightmare for people who are space constrained (everybody with a SSD) it is a nightmare for testers.

It is not a solution, FATELF is a problem.

Why don't you go and read Alan Cox comment on the mess? Ryan was not able to refute any of the points. All he did afterwards was putting his fingers into his ears and singing 'but fatelf is still a good idea'

Hint: no, it isn't. It is crap.

[yogi_berra]

Thanks for proving my point. Ya that's really up to date isn't it? Hell opensuse's compression on it's rpm (or it's version of RPM) isn't even the same anymore. SuSE 10.2, wtf, really a version that was released in 2006. Heck not even a mandriva version. And of course you notice the "generic" is only 32-bit.

They could be douchebags like Autodesk and only compile on Redhat and tell their paying customers to use Redhat when alien fails to convert the rpm to deb, everyone else can obviously get stuffed.

The current system is FUBAR for third party software, which is really the problem isn't it? A few people not liking a development model and an innate unwillingness to do anything that benefits the desktop/workstation with that model.

[energyman]

and fatelf does nothing to change that. So what?

Would autodesk support more distros with fatelf?
No, because the architecture is not the problem, lib versions is the problem.

[yotambien]

Ryan has given a couple of examples about why he thinks that shell scripts glue are not the best approach:

I'll preface my answer with a note: I am an _idiot_ at shell scripting.
Here're two examples that prove it.

- I once shipped a game that used pushd in its shell script to choose the
correct binary's folder. Anyone that's running Ubuntu can tell you that
this fails when /bin/sh ceases to point to bash. That game now fails to
start up. Human error, but still avoidable had there been a better
solution.

- Many years ago, I shipped a game that ran on i686 and PowerPC Linux. I
could not have predicted that one day people would be running x86_64
systems that would be able to run the i686 version, so doing something
like: exec $(uname -m)/mygame would fail, and there's really no good way
to future-proof that sort of thing. As that game now fails to start on
x86_64 systems, it would have been better to just ship for i686 and not
try to select a CPU arch.

There are places where this sort of mentality is suboptimal anyhow: I
consider the symlinks to /lib64 and /lib32 that you see on various distros
to be a version of the shell script tactic. It works, but it's not
really the cleanest approach.

I can also envision places where shell scripts aren't useful: web browser
plugins, scripting language bindings, and other places where we want to
load a shared library into a process that runs the risk of being 64-bit
when the other thing is 32-bit. Were the shared library a FatELF that had
both architectures, it would work without concern.

All of these things could have a million incompatible, one-off solutions:
shell scripts and symlinks and a million human errors. Doing it simply and
cleanly in one central place makes sense. I prefer that over loading an
entire scripting language interpreter just to load the correct ELF file,
and praying nothing ever changes to jeopardize the delicate balance.

-ryan

I am not qualified to make an informed comment on this, all I know is that package managers--which is where most of Alan's arguments relied in--are not a silver bullet to distribute software. And I'm not thinking about games, I have installed a good chunk of packages that are simply not present in the repositories. Somebody said (here or in the lkml, I can't remember) that "if your package isn't available, perhaps it's because it's not good enough and nobody cares". That couldn't be more unfair, there are lots of useful programs that are extremelly especialised and will never make it into a big distribution; anything to make life easier to those developers and perhaps minimise the risk of them breaking would be welcome. Again, I don't know whether FatELF would help or not, but I see some bogus counterarguments over here, as if the mere existence of this system would force everybody to use it.




OT:

Quoting Barney Frank immediately disqualifies you from every further discussion you will ever consider having for the rest of your life... I truly hope you can one day master the ability to think critically again....Though quoting Barney Frank once usually results in permanent stupidity and unrecoverable memory erasure.....

I personally will -NEVER- respect you again..

You brought my attention there. I looked up the guy to find that he's been campaigning for the rights of homosexuals, right to abortion, freedom of expression, reduction of US military expenditure, tighter controls on the market, and pushed several acts that had as their objective to protect those with the short end of the stick, like the Credit Cardholders' Bill of Rights 2008 and the Housing and Economic Recovery Act 2008 (all this according to Wikipedia).

What am I missing?

[Vighy]

Diego gave another idea why FatELF is useless:

http://blog.flameeyes.eu/2009/11/05/distributions-are-the-strength-of-linux

[energyman]

well, besides Ryan and dejano everybody thinks that the idea is worthless or stupid. Hmm, I think I see a pattern there.

[Svartalf]

I disagree. It removes a shell script and combines a couple different files into 1. That seems slightly more elegant to me, at least from a developers perspective. From the perspective of the kernel/glibc folks, perhaps it still seems like a giant hack.

From the perspective of a developer (note my tag... ) it doesn't make it much more elegant than the current state of affairs. Seriously.

If it were not needing quite so many alterations to everything in creation in the infrastructure, I can see where it MIGHT make some things a "little cleaner" to some developers. But it doesn't resolve that you still have to MAKE those binaries for all the platforms and resolve inconsistencies between distributions- it changes a lot for no appreciable gain, contrary to the claims of others in this thread.