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 393126
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: too bad
by hufman on Fri 6th Nov 2009 00:39 UTC in reply to "too bad"
hufman
Member since:
2008-10-11

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:
2009-07-16

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:
2005-08-28

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

RE[3]: too bad
by lemur2 on Fri 6th Nov 2009 04:43 in reply to "RE[2]: too bad"
lemur2 Member since:
2007-02-17

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.


Not really. The package manager works the same way (and therefore has the same source code) for any installation or architecture.

Different distributions and/or different targetted architectures simply "point" the package managers at different URLs.

The end user doesn't have to know the right URL. The URLs for the package manager repositories are normally set up when the OS is installed on the machine in the first place. If an OS is installed and the machine runs at all, it will already be set correctly.

Packager managers/repositories work. They are far better than anything that is available for Mac or Windows. Why mess with them?

Reply Parent Score: 3