To view parent comment, click here.
To read all comments associated with this story, please click here.
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
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?




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.