Ryan Gordon Is Fed Up, FatELF Is Likely Dead

[deanjo]

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.

Good for CivCTP, unfortunately, F.A.K.K, SoF, and another that I have somewhere don't. Same can be said with NWN. Sure you can get them running after fucking around with the libs and such.

[M1AU]

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?

Thanks for pointing that out.

[deanjo]

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.

Sure and your friendly distro packager makes sure that most of those are so intertwined with dependencies on other NOT NEEDED libs that it slaps a bunch more code that is not needed. At least with a "Universal Binary" I can get rid of the whole item without worrying about breaking other apps and not having no longer needed libs on my system.

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.

I pointed that out. You have to keep the target in mind. Nobody in their right mind is going to package a application for something that simply does not have the resources to run said application.

- 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.

Actually the later commercial games that have come out have been offered in 64-bit flavor as well. Compilers be bundled in a FatELF wouldn't be needed as the apps are already compiled.

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

All of this applies as it is already found in it's current state so I really fail to see your point here.

Ultimately all that Ryan was looking for was some input for working together to a common goal but instead he got and I quote:

I imagined
people would discuss the merits and flaws of the idea and we'd work towards
an agreeable solution that improves Linux for everyone. It sure seemed to
be going that way at first. Ultimately, I got hit over the head with package
management, the bane of third-party development, as a panacea for everything.

[kraftman]

Ultimately all that Ryan was looking for was some input for working together to a common goal but instead he got and I quote:

Like some people mentioned before it seems he looked from the bad side and bad ideas shouldn't affect Linux, just because someone wants to 'help' in his opinion. Afaik packagekit is a common goal.

[deanjo]

Like some people mentioned before it seems he looked from the bad side and bad ideas shouldn't affect Linux, just because someone wants to 'help' in his opinion. Afaik packagekit is a common goal.

Packagekit still relies on every distro to have all dependencies available that are needed for the application to run and packaged in a manner that is verified working with that application. It does not help at all for example in situations where a dependent library is not available by the distro or where the distro may have upgraded to a newer version that may not work with the application. Packagekit has the exact same flaws as distro specific packaging has where you are still at your distro's packagers mercy to keep it working with the various releases. You still need at least 1 maintainer of that package for each distro.

[droidhacker]

Packagekit still relies on every distro to have all dependencies available that are needed for the application to run and packaged in a manner that is verified working with that application. It does not help at all for example in situations where a dependent library is not available by the distro or where the distro may have upgraded to a newer version that may not work with the application. Packagekit has the exact same flaws as distro specific packaging has where you are still at your distro's packagers mercy to keep it working with the various releases. You still need at least 1 maintainer of that package for each distro.

You seem to miss the fact that fatelf *doesn't change that* -- it just makes it MORE COMPLICATED by forcing the package manager to try to figure out WHICH ARCH DEPENDENCIES to check for -- which in the case of x86_64, may not even be x86_64 -- could be x86_32 since that works as well.

I say good riddance to this pig. Adding more complexity to things doesn't make it any easier.

[fabiank22]

Sure and your friendly distro packager makes sure that most of those are so intertwined with dependencies on other NOT NEEDED libs that it slaps a bunch more code that is not needed. At least with a "Universal Binary" I can get rid of the whole item without worrying about breaking other apps and not having no longer needed libs on my system.

Number 1 is probably a fault of the distro you use. I've found (K)Ubuntu to be much worse than Fedora in that aspekt. But I won't consider it a problem that important. It's just a dead lib after all... we are probably talking about half a Megabyte here, unless you have many dead GCC-Versions.

I pointed that out. You have to keep the target in mind. Nobody in their right mind is going to package a application for something that simply does not have the resources to run said application.

It's not only resources, you have to also keep other things in mind: display, input methods,target audience(geeks vs n00bs)
However seeing how your main target for FatELFs would be games or consumer applications your target arch boils down to x86,x86_64 and slowly diing pre-Intel-Mac PPCs.

Actually the later commercial games that have come out have been offered in 64-bit flavor as well. Compilers be bundled in a FatELF wouldn't be needed as the apps are already compiled.

Okay, right. I don't need the compiler. I would still need to bundle Interpreters though. I still don't get why we should need a seperate fileformat for 2 archs instead of packaging whatever the app needs, one time as arch=x86 and on time=x64, and rename the libs to something like libmygamelibname.number.so and remove it when the package is removed.

[deanjo]

Number 1 is probably a fault of the distro you use. I've found (K)Ubuntu to be much worse than Fedora in that aspekt. But I won't consider it a problem that important. It's just a dead lib after all... we are probably talking about half a Megabyte here, unless you have many dead GCC-Versions.

At one time I would have probably agreed with you on it being the "distros" fault but more and more I'm seeing projects that respond to their app only guaranteed working on one specific distro, XBMC for example on the "free" side and Hulu desktop on the "non-free" side. There are many other examples out there as well and because of that I can't blame the distro at all. (PS XBMC for example doesn't even support your Fedora)

I still don't get why we should need a seperate fileformat for 2 archs instead of packaging whatever the app needs, one time as arch=x86 and on time=x64, and rename the libs to something like libmygamelibname.number.so and remove it when the package is removed.

This is exactly what Mac's Universal Binaries does do. Throw out the package to trash and your done.

[deanjo]

You seem to miss the fact that fatelf *doesn't change that* -- it just makes it MORE COMPLICATED by forcing the package manager to try to figure out WHICH ARCH DEPENDENCIES to check for -- which in the case of x86_64, may not even be x86_64 -- could be x86_32 since that works as well.

I say good riddance to this pig. Adding more complexity to things doesn't make it any easier.

With Ryan's proposed solution your deps would be with the package. You wouldn't have to worry about arch dependencies at the OS level as a FatELF package would have the required deps in it.

[Draconx]

With Ryan's proposed solution your deps would be with the package. You wouldn't have to worry about arch dependencies at the OS level as a FatELF package would have the required deps in it.

FATElf does not have anything to do with bundling libraries with applications. Regardless, such bundling trivial to do without FATElf -- the tar command can take multiple filenames when creating an archive, and the dynamic loader's search path is configurable at runtime.

The problem that FATElf purports to solve appears to be that some users are too stupid to download the correct binary for their architecture while also being unable or unwilling to use a package manager. Perhaps this is a problem worth solving, but let's keep the solution out of core system components.