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 393101
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: bah
by mckill on Thu 5th Nov 2009 23:28 UTC in reply to "bah"
mckill
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.

Reply Parent Score: 1

RE[2]: bah
by siride on Thu 5th Nov 2009 23:31 in reply to "RE: bah"
siride 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.

Reply Parent Score: 6

RE[2]: bah
by Redeeman on Thu 5th Nov 2009 23:52 in reply to "RE: bah"
Redeeman 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.

far from it, theres no real reason to want to distribute one big fat binary, its stupid, and serves no real purpose

Reply Parent Score: 1

RE[2]: bah
by collinm on Fri 6th Nov 2009 00:22 in reply to "RE: bah"
collinm 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?

Reply Parent Score: 3

RE[2]: bah
by sbenitezb on Fri 6th Nov 2009 01:16 in reply to "RE: bah"
sbenitezb 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.

Reply Parent Score: 3

RE[3]: bah
by Alex Forster on Fri 6th Nov 2009 02:49 in reply to "RE[2]: bah"
Alex Forster Member since:
2005-08-12

Christ, cry me a river about "disk accesses." The average Walmart PC comes with a terabyte of storage, and a staggering majority of the world has access to at minimum a four-megabit broadband connection. Go check out the size of your average executable. I'm on a Windows machine, so heading over to my System32 folder, I see the following:

* 9MB - mshtml.dll - The Trident rendering engine, the largest and most complicated part of Internet Explorer.
* 2MB - explorer.exe - Your start menu and file manager.
* 13MB - shell32.dll - All of the Windows UI control implementation
* 5MB - ntoskrnl.exe (!!!) - The Windows kernel, including all process and memory management, is five megabytes.

I can't believe anyone would spend the better part of an hour compiling from source to save 5 megabytes, not to mention that the source of any given application tends to be substantially larger than the binary it produces anyway!

Live and let live, though, I guess. I don't use Linux, so it doesn't affect me either way.

Reply Parent Score: 5

RE[2]: bah
by sbenitezb on Fri 6th Nov 2009 01:51 in reply to "RE: bah"
sbenitezb 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.

Reply Parent Score: 2

RE[3]: bah
by Shane on Fri 6th Nov 2009 03:52 in reply to "RE[2]: bah"
Shane Member since:
2005-07-06

Except when your distribution of choice has not packaged a piece of software that you need.

Reply Parent Score: 1