Slashdot Mirror
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."
after the diminse of NeXTStep!
(c)Innovation!!(tm)(R)
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.
Pretty good is actually pretty bad.
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?
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
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).
"Little does he know, but there is no 'I' in 'Idiot'!"
> It's dead simple. We need something like this in Linux.
"aptitude install " (or the pointy-clicky equivalent) works for me.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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.
What is...?
you know, just trick the good ol' .DEB package format to include several archs, then let to dpkg decide wich binaries to extract.
is not that in linux the binaries are one big blob with binaries, libs, images, videos, heplfiles, etc. all ditributed in as a single "file" which is actualy a directory with metadata that the finder hides as being a "program file".
being able to copy a binary ELF from one box to another doesn't guarantee it'll work, specially if it's GUI apps that may require other support files, so fat binaries in linux would be simply a useless gimmick. either distribute fat .DEBs, or just do the Right Thing(tm): distribute the source.
What ? Me, worry ?
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?)
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).
I am TheRaven on Soylent News
"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.
It never really flew.
If someone wants to do this then something like Java would be good enough for many types of software. There will always be some things for which a binary tied to the specific target is all that would work; I think that it would be better to adopt something that works for most software rather than trying to achieve 100%.
Now why would I want to do anything that fucktarded, when I can just use the source? And if I needed cross-platform that badly, I can always ship ONE java app with ONE instance of data. The '90s called, they want their obsolete fat and universal binaries back.
The elusive (+1 Insightful, -1 Flamebait) post makes a brief appearance, flashing its brightly-colored plumage, before disappearing back into the brush.