Ryan Gordon Is Fed Up, FatELF Is Likely Dead

[energyman]

no, it hasn't.

Apple only ships one system with tight specs and fixed hardware. Every idiot can write a working system for that. Apple users also seem to be happy to waste disk space for crap. Well, there isn't much to install anyway. Photoshop, itunes. And you are done.
Also MAcOSX is pretty fragile and a security nightmare.

No, there is no 'working' system.

Package managers have solved all that problems a long time ago. Fatelf is just an infestion of Job's RDF.

Think about that.

[deanjo]

no, it hasn't.

Apple only ships one system with tight specs and fixed hardware. Every idiot can write a working system for that. Apple users also seem to be happy to waste disk space for crap. Well, there isn't much to install anyway. Photoshop, itunes. And you are done.
Also MAcOSX is pretty fragile and a security nightmare.

No, there is no 'working' system.

Package managers have solved all that problems a long time ago. Fatelf is just an infestion of Job's RDF.

Think about that.

Hmmm Universals can be done for four different Archs and have been very successfully done and of those various arches the hardware configs have been plentiful enough. As far as "fragile" goes I have to laugh as well especially when a non primary harddrive fails in linux and because it can't mount it it greets you with a nice command prompt. At least a OS X system can handle such situations. Apple has been doing universal libraries for a long long time. They previously used a similar technique when transitioning from 68k procs to the PowerPC's. When they didn't have a Universal Binary solution available then the system could run it through emulation with Rosetta or having a solution such as OS 9 in OS X compatibility. Linux has never had that kind of freedom or execution in maintaining compatibility. Ask any user of OS X and linux (especially Mac geared distro's Yellow dog) and when you ask them about installing software on either they will pretty much all tell you YUM sucks ass comparitively speaking.

[deanjo]

Oh BTW the "disk space" arguement is funny given the day and age of Tb capacity harddrives and executables would account for maybe a couple of meg per app extra.

[energyman]

wron, wrong and wrong.

harddsik failure: if an harddisk fails that does not include system files, the system will boot just fine. You won't have your user data, or /var is shockingly empty or /tmp back on root, but that does not hinder the system.

next wrong, you don't know anything about linux it seems. You also don't understand why fat binaries are a really stupid idea. Just look behind x86/x86-64 and you see that sparc or ppc64 systems run 32bit code just fine.

another wrong, you are confusing emulation with the problem of package managing. Completly unrelated.

and another wrong, you think that something done on a closed, tightly speced plattform (Apple crap) is a workable solution for everybody else. Apple only supports MacOSX on selected hardware. And has problems even to do that right.

Fatelf gets you NOTHING. It solves NO PROBLEMS that haven't been solved ALREADY by package managers with A LOT LESS wasted space.

You also don't seem to grasp the many downsides of huge binaries.

Maybe you should stay with MacOS.

[smitty3268]

deanjo, please just tell me what the benefits of this system are over a simple zip file with multiple executables inside it. The only difference is that double-clicking would automatically run the correct program, but that can easily be fixed by running a script to determine what platform you are on.

This kind of stuff has been possible forever, and the fact that no one actually does it should tell you something. Not that FATelf is required, but that no one would use it even if it existed.

In fact, if Ryan really wants to push this idea then that is exactly what he should do. 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.

[deanjo]

wron, wrong and wrong.

harddsik failure: if an harddisk fails that does not include system files, the system will boot just fine. You won't have your user data, or /var is shockingly empty or /tmp back on root, but that does not hinder the system.

I beg to differ, having quite a few seagate drives fail that are pure data drives upon not being to mount them with fstab you are greeted with a command prompt to "fix the issue" which involves removing the line of the effected drive from the fstab.

next wrong, you don't know anything about linux it seems. You also don't understand why fat binaries are a really stupid idea. Just look behind x86/x86-64 and you see that sparc or ppc64 systems run 32bit code just fine.

Where the hell did I imply otherwise? Of course it can run 32-bit code fine when the compatibility libs are installed.

another wrong, you are confusing emulation with the problem of package managing. Completly unrelated.

Sorry I am not confusing the two, I was pointing out that Apple's track record of maintaining backwards compatibility far exceeds any effort linux has yet put in so far.

and another wrong, you think that something done on a closed, tightly speced plattform (Apple crap) is a workable solution for everybody else. Apple only supports MacOSX on selected hardware. And has problems even to do that right.

Yet it is easily ran on hackintoshes and darwin has no issue running many archs. Hell it's easier to get a AC97 card on a hackintosh running then it is in linux usually despite it never being designed to do so. Your argument completely fails here.

Fatelf gets you NOTHING. It solves NO PROBLEMS that haven't been solved ALREADY by package managers with A LOT LESS wasted space.

What don't you get about having to worry that your distro packagers have to maintain that package as well as the app your trying to run. That's a shitload of fingers in the pie compared to a universal binary approach.

You also don't seem to grasp the many downsides of huge binaries.

Maybe you should stay with MacOS.

You don't seem to grasp the advantages of making it simpler for the end user for adoption.

[deanjo]

deanjo, please just tell me what the benefits of this system are over a simple zip file with multiple executables inside it. The only difference is that double-clicking would automatically run the correct program, but that can easily be fixed by running a script to determine what platform you are on.

This kind of stuff has been possible forever, and the fact that no one actually does it should tell you something. Not that FATelf is required, but that no one would use it even if it existed.

In fact, if Ryan really wants to push this idea then that is exactly what he should do. 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.

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

[RealNC]

Here's a good explanation of why FatELF is useless on Linux:

http://blog.flameeyes.eu/2009/11/04/elf-should-rather-be-on-a-diet

Probably the best user-visible point in this is that OS X uses application bundles that work "out of the box" and therefore universal binaries can help. Linux does not use app bundles.

Another good point is that you don't need FatELF to support multiple architectures. You can do it with a simple script. Valve's game servers (hlds, srcds, etc) work out of the box for multiple archs from the same package. No one needs FatELF to solve a problem that already has solutions and therefore is no problem at all.

[deanjo]

Another good point is that you don't need FatELF to support multiple architectures. You can do it with a simple script. Valve's game servers (hlds, srcds, etc) work out of the box for multiple archs from the same package. No one needs FatELF to solve a problem that already has solutions and therefore is no problem at all.

You do realize a patent covering that is going to court right? Look up patent US2004093167. " ANALYTE DETECTION SYSTEM WITH SOFTWARE DOWNLOAD CAPABILITIES"

Here is the EU patent pdf: http://www.freepatentsonline.com/EP1565103.pdf

[RealNC]

I don't care about patents in this case, only about the technical reasons why FatELF is not needed. I leave patents to the lawyers.