Linked by Thom Holwerda on Thu 5th Nov 2009 23:05 UTC
Linux As we all know, Mac OS X has support for what is called 'fat binaries'. These are binaries that can carry code for for instance multiple architectures - in the case of the Mac, PowerPC and x86. Ryan Gordon was working on an implementation of fat binaries for Linux - but due to the conduct of the Linux maintainers, Gordon has halted the effort.
Thread beginning with comment 393113
To read all comments associated with this story, please click here.
too bad
by viator on Thu 5th Nov 2009 23:56 UTC
Member since:

I thought this was a good idea. It may have led to people, who because of maintenance reasons decided in the past not to release a linux version of an app to do so.
Who wants to have mantain a binary for each distros packaging system etc etc

Reply Score: 6

RE: too bad
by Redeeman on Fri 6th Nov 2009 00:01 in reply to "too bad"
Redeeman Member since:

I thought this was a good idea. It may have led to people, who because of maintenance reasons decided in the past not to release a linux version of an app to do so.
Who wants to have mantain a binary for each distros packaging system etc etc

stop posting about things you know nothing of.... NOTHING prevents vendors from distributing a package that works on all distributions _AND_ architectures today... and for that matter, 10 years ago either, its simply blatent incompetence on the part of "ISVs"

Reply Parent Score: -1

nt_jerkface Member since:

In theory ISVs could also build their own live cd in asm and distribute their program that way, but would it be worth the effort?

Until there is an msi equivalent that can be installed across Linux distros without worry of some random library update breaking your program expect the current situation of Linux getting the shaft from ISVs to continue.

Telling ISVs that they're stoopid heads for not wanting to write a bunch of scripts for not only multiple distros but also multiple versions of those distros is insane. Don't forget they also have to support all those multiple distros and versions as well. It isn't like open source where you can just dump the program and then have all the distros figure it out. When customers ask why program whizbang doesn't work in distro version combination xyz you can't tell them to fix if themselves if they don't like it (which really means f off since very few can actually fix such problems).

You win ISVs over by creating an appealing and stable platform for them, not by telling them to figure it out a chaotic mess on their own.

The real problem is at the end of the day Linux is designed around open source applications. Most Linux advocates have no idea as to how many headaches you run into when you try to distribute proprietary GUI applications in Linux, especially compared to Windows or OSX. Until the distros get together and acknowledge that more needs to be done to bring in ISVs expect the Linux desktop to continue to flatline.

I don't expect much to change however, given the entrenched FOSS ideology, the ongoing window manager war and failure of the LSB.

Reply Parent Score: 1

RE: too bad
by hufman on Fri 6th Nov 2009 00:39 in reply to "too bad"
hufman Member since:

During the Slashdot discussion of the announcement of the project, a point was brought up that this makes it easier for small programmers to distribute programs for multiple architectures.
The problem still arises, that the programmers must still compile their program for every architecture they want to release on.
The only improvement that a fat binary provides for a programmer is that their personal project website can list one raw package for their various programs, with a 3x bigger executable file sharing the same data, instead of releasing 3 separate packages with their own copy of the data. That's it.
Programmers still need to package their program for all of the different distributions, because fat binaries doesn't fix that at all. If a programmer wants to distribute a DEB and an RPM, they still need to create those manually. Fat binaries would only help for making one DEB and one RPM for all supported architectures, instead of one DEB and one RPM per architecture.

Reply Parent Score: 6

RE[2]: too bad
by i92guboj on Fri 6th Nov 2009 00:47 in reply to "RE: too bad"
i92guboj Member since:

Big packages ship the data separately, so that'd be one binary for each arch, and one data package. That's why there are noarch rpm's and such stuff as well.

That's assuming that the data is not arch-specific, which is almost always, but not always. In such rare cases fat elf would be even fatter hehe

Reply Parent Score: 1

RE[2]: too bad
by DigitalAxis on Fri 6th Nov 2009 03:17 in reply to "RE: too bad"
DigitalAxis Member since:

I can see a substantial benefit if we left the package manager behind... no longer would users be required to know whether they have an 386, 686, x86_64, ARM, or PPC installation: download and it'll work... at least, provided it was distributed as one. Right now, we have the package manager handling all of those distinctions; this would remove the vital dependencies on a specific package manager... at least, provided you have all the right versions of the libraries installed.

Reply Parent Score: 5