Linked by Thom Holwerda on Thu 5th Nov 2009 23:05 UTC
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 393096
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Member since:2007-06-12
not really a big loss.. there appears to be basically no real benefit to doing this, certainly nothing that compares to the downsides, this appears to be one of the cases where the kernel devs and glibc people etc actually made a sane decision for once
that's because you're simple minded and lack seeing the 'bigger' picture.
this would make it a lot easier for devs to release a single binary that can actually reach quite a few different users, not just X86, PPC, but also 64bit versions.
this is also pretty big with ARM making a nice push.
Member since:2006-01-02
The problem can be solved more easily by other means. Simply including multiple binaries, one for each architecture, in the package. Then having a script or some other mechanism pick the right binary at launch time. Everything else, libs, text files, etc. can be more easily shared. Furthermore, these mechanisms are simple to understand and implement, and don't require massive changes to glibc and the kernel.
Member since:2006-03-23
that's because you're simple minded and lack seeing the 'bigger' picture.
this would make it a lot easier for devs to release a single binary that can actually reach quite a few different users, not just X86, PPC, but also 64bit versions.
this is also pretty big with ARM making a nice push.
this would make it a lot easier for devs to release a single binary that can actually reach quite a few different users, not just X86, PPC, but also 64bit versions.
this is also pretty big with ARM making a nice push.
far from it, theres no real reason to want to distribute one big fat binary, its stupid, and serves no real purpose
Member since:2005-07-15
"not really a big loss.. there appears to be basically no real benefit to doing this, certainly nothing that compares to the downsides, this appears to be one of the cases where the kernel devs and glibc people etc actually made a sane decision for once
that's because you're simple minded and lack seeing the 'bigger' picture.
this would make it a lot easier for devs to release a single binary that can actually reach quite a few different users, not just X86, PPC, but also 64bit versions.
this is also pretty big with ARM making a nice push. "
you want to support all arm architecture?
Member since:2005-07-22
that's because you're simple minded and lack seeing the 'bigger' picture.
I don't want tons of dead code living in my filesystem and gigabytes of updates. I don't know how the fat binaries and libraries work, but I assume they complicate the loading process even more and could require more disk accesses.
It is a stupid idea that only makes sense to Apple and third party developers. It may make the life of distributors simpler (or not), but also increase network usage with each update.
In the end, you are not solving a problem, just passing the ball to the end user.
Member since:2005-07-22
this would make it a lot easier for devs to release a single binary that can actually reach quite a few different users, not just X86, PPC, but also 64bit versions.
As commented already, the problem is that you need to compile first for different architectures and for different distributions. That means that you:
a) Have many computers with say Ubuntu x86, Ubuntu AMD64 and Ubuntu ARM, compile the source in the three and then what do you do with the resulting binaries to mix them into one fat binary? Too complicated.
b) Have one computer with cross compilers, then you compile the source with each compiler and then magically link all of them together to finally make dist in one single package.
c) Either a or b with single make $WHATEVER for every architecture.
In the end, the way it is now is simpler and works without doing anything. Distributing packages for different architectures is not a problem. Distribution sites usually check your browser ident to see which architecture to offer you by default. It works.
Member since:2006-01-22
not really a big loss.. there appears to be basically no real benefit to doing this, certainly nothing that compares to the downsides, this appears to be one of the cases where the kernel devs and glibc people etc actually made a sane decision for once
I totally agree with you. the idea of Linux is mainly source compatibility.
Member since:
2006-03-23
not really a big loss.. there appears to be basically no real benefit to doing this, certainly nothing that compares to the downsides, this appears to be one of the cases where the kernel devs and glibc people etc actually made a sane decision for once