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

Re:Only useful for non-free applications

[eldavojohn]

Well, that's an important point but the author of this defends himself:

• 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?"
• You no longer need to have separate /lib, /lib32, and /lib64 trees.
• Third party packagers no longer have to publish multiple .deb/.rpm/etc for different architectures. Installers like MojoSetup benefit, too.
• A download that is largely data and not executable code, such as a large video game, doesn't need to use disproportionate amounts of disk space and bandwidth to supply builds for multiple architectures. Just supply one, with a slightly larger binary with the otherwise unchanged hundreds of megabytes of data.
• You no longer need to use shell scripts and flakey logic to pick the right binary and libraries to load. Just run it, the system chooses the best one to run.
• The ELF OSABI for your system changes someday? You can still support your legacy users.
• Ship a single shared library that provides bindings for a scripting language and not have to worry about whether the scripting language itself is built for the same architecture as your bindings.
• Ship web browser plugins that work out of the box with multiple platforms.
• Ship kernel drivers for multiple processors in one file.
• Transition to a new architecture in incremental steps.
• Support 64-bit and 32-bit compatibility binaries in one file.
• No more ia32 compatibility libraries! Even if your distro doesn't make a complete set of FatELF binaries available, they can still provide it for the handful of packages you need for 99% of 32-bit apps you want to run on a 64-bit system.
• Have a CPU that can handle different byte orders? Ship one binary that satisfies all configurations!
• Ship one file that works across Linux and FreeBSD (without a platform compatibility layer on either of them).
• One hard drive partition can be booted on different machines with different CPU architectures, for development and experimentation. Same root file system, different kernel and CPU architecture.
• Prepare your app on a USB stick for sneakernet, know it'll work on whatever Linux box you are likely to plug it into.

While you may be able to claim none of those points are overly compelling and target a very small part of the population, you have to recognize there's more than just satisfying non-free applications. Furthermore, I think you mean to say that it's "only useful for non-open source applications" as there are tons of free software applications out there that are not open source but are free (like Microsoft's Express editions of Visual Studio).

Re:Gee, just 14 years

[TheRaven64]

GNUstep has supported cross-platform app bundles for a long time. You can include Linux binaries for various architectures, FreeBSD, Windows, and even OS X-with-Cocoa binaries in the same .app, then drag it to your platform of choice and have it work. The down side of this approach is that it consumes a bit more disk space because you have a copy of all of the data (not just the code) in every binary. The advantage is that the same bundle will work on platforms that use ELF (Linux, *BSD, Solaris), Mach-O (OS X) and PE (Windows) binaries. Given how cheap disk space is, and how trivial it is to thin a bundle like this (NeXT's ditto tool could do it, but all you really need is to delete the folders for targets other than the one you want from the bundle) it's not really a big disadvantage. Fat binaries on Linux would mean you could run the same binary on Linux/x86 and Linux/ARM, for example, but that's not exactly a massive advantage.

Re:Apple dropped it

[PenguSven]

Ask PPC owners that want to get the latest version of OS X.

No, Apple didn't drop support for Universal Binaries. Most apps available for Mac today are universal binaries and work on PPC or Intel macs, and in some cases support PPC 32, PPC 64, Intel 32 and Intel 64. Just because a new OS doesn't support an older CPU architecture doesn't mean the functionality for Universal or "Fat" binaries is not supported.

Re:Apple Universal Binary is kinda of a joke.

[TheRaven64]

You are confusing NeXT and Apple's approaches, I think. Apple puts both all of the different architectures in the same file. Your code is compiled twice, but it's only linked once. The PowerPC {32,64} and x86 {32,64} code all goes in different segments in the binary, but data is shared between all of them, so it takes less space than having 2-4 independent binary files. To support this on Linux would not require any changes to the kernel, only to the loader (which is a GNU project, and not actually part of Linux).

Re:Gee, just 14 years

[Hal_Porter]

When did VMS take-over Windows? Which iteration? NT5 (2000/XP) or NT6 (Vista/Win7)? Or earlier?

Dave Cutler, the architect of VMS developed Windows NT. Lots of Windows NT kernel mode terminology - working sets, paged pools, IRQLs, IRPS and so come from VMS and were not present in 16 bit Windows (which didn't really have any architecture).

http://windowsitpro.com/Windows/Articles/ArticleID/4494/pg/2/2.html

If you take the next letter after V you get W, M you get N and S you get T, so W(indows)NT is a successor to VMS. The Windows NT kernel run on Dec's preferred Mips architecture (and later the Dec Alpha) before it run on x86. Much of the development of 64 bit Windows was done on Alpha.

Actually before Cutler worked on Windows NT at Microsoft he worked on a project to run Unix and VMS binaries on a single kernel in separate subsystems. Orignally Windows NT supported Win32, Posix, OS/2 and Win16+Dos subsystems, though Win32 obviously ended up being by far the most important. In fact Windows NT was originally so CPU agnostic that it run Win16 and Dos applications using a software emulator on Risc chips before it run them using V86 mode on x86.