Ryan Gordon Brings Universal Binaries To Linux

[phoronix]

Phoronix: Ryan Gordon Brings Universal Binaries To Linux

One of the interesting features of Mac OS X is its "universal binaries" feature that allows a single binary file to run natively on both PowerPC and Intel x86 platforms. While this comes at a cost of a larger binary file, it's convenient on the end-user and on software vendors for distributing their applications...

http://www.phoronix.com/vr.php?view=NzYyNQ

[droidhacker]

Wow. You mean that our binaries aren't already big enough? I don't need PPC junk floating around my AMD64. I sure hope that fat-elfs can be reduced to skinny-elfs.

And for that matter, if it is going to waste the space anyways, why not just produce separated binaries to begin with? You know that whoever produces these fat-elfs will first have to produce skinny-elfs and then glue them together...

Seems to me that this is just an exercise in BLOAT. No thanks.

[yoshi314]

now he "only" needs to battle toolchain (mostly binutils) developers to officially include support for this new format. i don't think they like breaking standards and introducing new stuff too well (although "gold" linker was a surprise - it's still broken and in mainline)

one executable for >5 platforms - doesn't sound that good. i hope it will be possible to strip unneeded platforms from resulting file (if needed) without breaking it.

[mdmadph]

Disk space is incredibly cheap today -- I would forgive a bit bigger file if it "just worked" in Linux, and I think a lot of common users like me would agree.

[pvtcupcakes]

I think it would be better if you could just combine x86 and amd64 since that's what 99% of users use. Instead of having to include PPC and other obscure archs.

I like to develop software in my free time for Linux, but I only distribute the source code because I don't have the desire to compile for two different architectures.

[RealNC]

Bloated crap. No thanks. I hope this project fails.

[lordmozilla]

please no.

This is not a bad idea in theory, but I don't want anythign more bloated than currently. And this seems like a really easy way to push back X86_64 adoption and keep all these old ix86 packets floating about.

[Ex-Cyber]

Distributions no longer need to have separate downloads for various platforms. Given enough disc space, there's no reason you couldn't have one DVD .iso that installs an x86-64, x86, PowerPC, SPARC, and MIPS system, doing the right thing at boot time. You can remove all the confusing text from your website about "which installer is right for me?"

Yeah, "given enough disc space". I'm sure that will be irresistible to Ubuntu, which fits a reasonably complete desktop install on one CD-ROM per arch/flavor by design. Or Fedora, whose install DVD images consume well over half of a DVD-5 per arch. Or Debian, which has multiple DVD-5 images per arch. Also, I could be mistaken (don't have time to look up the details right now) but I think that at least a couple of Debian's supported platforms have mutually incompatible requirements for bootable disc formatting.

I don't have any really strong feelings for or against this spec, but frankly that "benefit" seems pretty detached from reality.

I think it would be better if you could just combine x86 and amd64 since that's what 99% of users use. Instead of having to include PPC and other obscure archs.

I don't see any reason to arbitrarily limit the spec to only two architectures, particularly considering the possibilities of ARM-based netbooks. Arch support for a given binary is entirely at the discretion of the distributor in any case.

[AHSauge]

Why is this bloated? Sure it will give you more than you need, but I will gladly accept this if it also includes x86_64 binary. Both my PCs run x86_64, but only one of them is x86_64 only. The other one has tones of 32bit libraries installed because proprietary software. I'm not going to speculate as for why they don't deliver 64bit version of their apps, but one thing I do know is that offering two sets of binaries for the same PC is confusing for everyone except technical people. If we want the Linux-platform to be more popular, we simply can't expect people, i.e your grandma and grandpa, to know whether to download and install the 32bit binary or the 64bit binary, because they don't know the difference and they don't want to know it either. What such people want is a binary that "just works". Universal binaries is just that.

please no.

This is not a bad idea in theory, but I don't want anythign more bloated than currently. And this seems like a really easy way to push back X86_64 adoption and keep all these old ix86 packets floating about.

I disagree. Unless you really expect people to know the difference between 32bit and 64bit, this has to be done one way or the other to push forward the adoption to x86_64. As I said above, it's confusing to offer two binaries for the same PC, and we all know which one will work in any case.

[Remco]

Why is this bloated? Sure it will give you more than you need, but I will gladly accept this if it also includes x86_64 binary. Both my PCs run x86_64, but only one of them is x86_64 only. The other one has tones of 32bit libraries installed because proprietary software. I'm not going to speculate as for why they don't deliver 64bit version of their apps, but one thing I do know is that offering two sets of binaries for the same PC is confusing for everyone except technical people. If we want the Linux-platform to be more popular, we simply can't expect people, i.e your grandma and grandpa, to know whether to download and install the 32bit binary or the 64bit binary, because they don't know the difference and they don't want to know it either. What such people want is a binary that "just works". Universal binaries is just that.

How often do you install a plain binary for Linux apps? The correct way to distribute software is by non-executable installer packages. Those kinds of packages can provide any number of architectures in one single file. Or, if you don't like that bloat, discover the user's architecture from browser information and then offer the correct architecture-specific package by default.