OSNews

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.

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

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?

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.

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.

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.

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