Ryan Gordon Wants To Bring Universal Binaries To Linux

wisesifu writes "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. While Linux has lacked such support for fat binaries, Ryan Gordon has decided this should be changed."

Comments

Only useful for non-free applications

[dingen]

If you have access to the source, you can always compile a version for your platform. The 'fat binary' principle is only useful for non-free applications, where the end-user can't compile the application himself and has to use the binary provided by the vendor.

Since most apps for Linux are free and the source is available, this feature isn't as useful as it is on the Mac. Not that it shouldn't be created, but it makes sense to me why it took a while before someone started developing this for Linux.

Re:Only useful for non-free applications

[betterunixthanunix]

Not everyone is skilled enough to compile the source on their own, especially for packages that must be patched to run on certain architectures. Personally, I would think this might be useful for distro maintainers who do not want to maintain separate packages across multiple architectures, although the benefits may not outweigh the costs.

Re:Only useful for non-free applications

[turbidostato]

"Not everyone is skilled enough to compile the source on their own"

By "end user" we can understand here "distribution maintainer" which already has the skills to compile the source (and that's not but a part in the lot of things that have to be done in order to integrate some software in a distribution).

"I would think this might be useful for distro maintainers who do not want to maintain separate packages across multiple architectures"

But they have to: they still must build and integrate for their supported platforms, then rebuild when bugs are found or the software is upgraded, then test... It's just the last step (producing the very binary packages) that changes so instead of multiple packages you'd end up with a single multplatform package. The distributor still need (almost) as much disk space and infrastructures as before, but then each and every user will end up with spending much more space in their hard disks (imagine the fat binary for, say, Debian, supporting eleven platforms).

And then, please note that this will allow for single binaries for diferent hardware platforms but not for different version compilations (so it won't be useful to obtain binaries for, say, amd64 for Debian, Red Hat and SUSE).

It seems it will only benefit to those that want to publish their software in an only binary form outside the framework of stablished distributions and that means closed source software. Of course they can look for their bussiness the way they feel better, it's only they don't get my simpathy so I don't give a damn about them.

Re:Only useful for non-free applications

[koiransuklaa]

The whole Linux distribution and installation system (such as, with apt-get) is great for setting up a server, but it's very awkward and unnatural for desktop apps. Apple is far ahead in that respect, and I see no reason why Linux shouldn't follow their lead.

You've got to be kidding? Super-easy installation and automatic security updates for all applications is 'awkward'?

If I understood you correctly, your suggestion is that desktop software should be hard to find, it should be installed from whatever website I happen to ultimately find and it shouldn't automatically get security updates. Sounds fabulous.

Don't get me wrong, I agree that package management systems have their flaws (even inherent ones) but you just aren't making a good case against them... You could start with explaining what's unnatural about "Open 'Add applications', check what you want, click Install", and then continue with explaining what's awkward about totally automatic security updates.

Re:Only useful for non-free applications

[tyldis]

Please elaborate.

I too agree that this is pointless for the end user in Linux, at least when it comes to free software. Only closed binary blobs will benefit, which IMHO is not something worth putting effort towards helping. They did their design choices and accepted the reality in doing so.

As for the end user, she should just use the package manager of her distro and find whatever she needs. Not worrying about neither compiling nor platforms.
For example, in Debian/Ubuntu you could more easilly package your installer to simply drop a file in /etc/apt/sources.d. Not only will the user be able to use the package manager to install your app like any other, she will also get security updates you publish.

Let the package system handle these things, they do it well and does not bloat your boat.

Re:Only useful for non-free applications

[Teckla]

But... "compiling for your platform" is just another way to install software. You could wrap this in a little application (call it "setup"), where you click "Next >" several times, and as a result you have a binary for your platform.

Wow, the lack of grasp on reality around here really amazes me sometimes. But it looks like it worked for you. The open source fanatic fan boys shot your karma through the roof. Congratulations!

Compiling non-trivial applications from source can take a long time. That fact alone can make precompiled binaries a big win for most users.

I did the "compile from source" thing for a long time on FreeBSD before finally realizing the pointlessness of it all. Not only was I completely unnecessarily beating up on my hardware, but spending far too much time waiting for compiles to complete.

These days, I grab precompiled packages whenever possible, and you know what? It's a hell of a lot better.

Does Linux even need them?

[GreatBunzinni]

Some people may claim that Linux may have some shortcomings but certainly the way that distributions handle support for multiple platforms and also the availability of binaries targeted at a certain platform surely isn't one of them. Linux already runs on a long list of platforms and software distributions already handle themselves quite nicely by building platform-specific packages, which also include all sorts of platform-specific binaries the applications will ever need. So, besides the empty "but Apple has them" rational, exactly what drives the need for universal binaries on linux?

Re:Linking problems

[dkf]

Could this technology also help binaries to link against multiple versions of standard libraries (glibc, libstdc++)?

Probably not. Or not without getting headaches like you get with assemblies on Vista. Keying off the system architecture (32-bit x86 vs. 64-bit ia64) is much simpler than keying off library versions.

The fix with standard libraries is for the makers of them to stop screwing around and stick with ABI compatibility for a good number of years. OK, this does tend to codify some poor decisions but is enormously more supportive of application programmers. Note that I differentiate from API compat.; rebuilding against a later version of the API can result in a different - later - part of the ABI being used, and it's definitely possible to extend the ABI if structure and offset versioning is done right. But overall, it takes a lot of discipline (i.e., commitment to being a foundational library) from the part of the authors of the standard libs, and some languages make that hard (it's easier in C than in C++, for example).

Not scalable

[gdshaw]

To a first approximation, the size of the binary will increase in proportion to the number of architectures supported.

This is something you might decide to ignore if you are only supporting two architectures. Debian Lenny supports twelve architectures, and I've lost count of how many the Linux kernel itself has been ported to. I really don't think this idea makes sense.

(Besides, what's wrong with simply shipping two or more binaries in the same package or tarball?)

Re:convenient for _closed source_ software vendors

[turbidostato]

"Actually, having to maintain packages across several architectures can be tricky at times."

Of course yes. But let's see if the single fat binary reduces complexity.

"Some packages need to be patched to run correctly on different architectures"

And they still will need that. Or do you thing that the ability to produce a single binary will magically make those incompatibilities to disapear?

"the upstream maintainers can accidentally break those patches (e.g. if they are not personally testing on a given architecture)"

That can happen too with a single binary exactly the same way.

"It could even be the case that different architectures have different versions of the same packages, because the distro maintainers are busy trying to get everything to work."

Probably with a reason (like new version needs to be patched to work on this or that platform). How do you think going with a single binary will avoid that problem? It's arguably that in this situation you would end up worse. At least with different binaries you can take the decision of staying with foo 1.1 on arm but promote foo 1.2 on amd64 in the meantime; with a single binary it would mean foo 1.1 for everybody.

"I am not saying that this "universal binary" solution is the answer, but it might help streamline the build process at the distro level."

Still you didn't produce any argument about *how* it could help.

Re:Gee, just 14 years

[TheUser0x58]

And I'll bet that Apple doesn't use this "universal binary" thing on their iPhone, either.

You'd lose that bet. Apple provides complete support for universal binary on iPhone, allowing developers to compile for ARMv6 (compatible with every iDevice) and ARMv7 (newer ISA; works on iPhone 3GS + iPod Touch 3G).

It makes sense for Apple, which only has to worry about 2 architectures on the desktop

Actually, 4: PowerPC, PowerPC 64, x86, and x86 64. Though for the purposes of your argument its probably an immaterial difference.