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.
We don't need the universal binary, so much as we need the "1-file install" idea that MacOS has. This would greatly simplify installing a standalone application.
For those of you who don't know, if you download an app for MacOSX (say, Firefox) you are presented with one icon to drag into your "Applications" folder. This is really a payload, a "Firefox.app" directory that contains the program and its [static?] libraries. But to the user, you have dragged a single "file" or "app" into your "Applications" folder - thus, installing it.
It's dead simple. We need something like this in Linux.
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'!"
Sofwtare vendors? This only makes life easier for _closed source_ software makers. For everyone else this is a solution looking for a problem as package management and repositories don't really have a problem with different arches and versions.
I'm not saying this is useless (people do want to run closed source software), but the kernel, glibc and other patches better be good and non-invasive if this guy wants them to land...
I think FatELF is too skinny for that. You want SantaELF, which links all those libraries statically in each binary...
Apple is still using it for x86/x86_64 fat binaries in Snow Leopard.
While your reply sounds a bit like flame-bait, I basically have to agree. The format isn't a universal binary that gets translated to each machine architecture when installed. Instead, it's basically an archive of pre-compiled binaries for each platform you support. So, for example, my stupid Qt application has to be compiled separately for Fedora and Ubuntu. This technology would in theory allow me to merge the binaries into a single FatELF binary. Personally, I'd rather just provide separate .deb and .rpm files.
However, the idea of a universal binary is cool. We could do something like the old p-Code, where we compile to a virtual architecture, and then translate it to the machine during installation. I liked the idea when they had it way back in the early 80's (late 70's?), and I was sad to see we didn't have the compute power back then to make it fly. I bet we do now.
Celebrate failure, and then learn from it - Nolan Bushnell
Read the fine website:
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
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%.
Why stop there? Just let each application carry with it a complete OS.
The Tao of math: The numbers you can count are not the real numbers.
Wouldn't surprise me if this is to encourage users to demand a native x86 version of software - once every significant application exists as x86 binaries, Apple can drop support for Rosetta altogether and that's another developer or two freed up to work on furthering their products rather than backward compatibility.
This is cool and everything, but I'd rather Ryan spent the time on whatever it takes to get Linux Unreal 3 published.
Apple does that. when 10.3 came out apple stopped installing OS 9 classic by default as well. Support backwards compatibility for 2-3 generations and then phase it out. First phase is simply not installing it by default. Second phase is not to supply it. Snow leopard is the 3rd generation of OS after Rosetta came out. installed by default in tiger, and Leopard, they stopped installing it by default for 10.6.
personally I wish MSFT would do the same thing. I get really pissed when my "new application" requires the same installer that win95 had, and in order to run it I have to reboot into safe mode as my antivirus won't let it run. Seriously why does an Application built in 2009 still require the win16 subsystem to run? Why aren't the coders moveing onto new toolkits? Apple nudges and then pushes programers forward. MSFT let's them stay in the previous century and use bare metal knife switches to turn on the lights.
i thought once I was found, but it was only a dream.
They already have, to a degree. In Snow Leopard, you have to choose to specifically install Rosetta. If you don't, you can't run PPC programs.
If you try, OS X will prompt you to install Rosetta (which it will do at the press of a button), but it's not there any more by default.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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.
What's the big benefit again? Instead of the package manager making the decision once at install time and all of the un-needed parts for platforms I'm not using stay on the install disk, now the decision is made each time I run the app and I get to clog my HD (or worse, my SSD) with all of them?
Now I can have the world's LARGEST hello world program with support for alpha, arm, avr32, blackfin, cris, frv, h8300, ia64, m32r, m68k, m68knommu, mips, parisc, powerpc, ppc, s390, sh, sh64, sparc, sparc64, um, v850, x86, and xtensa?
I'm guessing if this catches on, the most commonly used program will be 'diet' the program that slims down fat binaries by removing the architectures you will never encounter in a zillion years. (Just what are the odds that I will one day replace my workstation with an s390?)
If they want to do this, they should do it right and implement something like TIMI. Done well, it would mean that an app could run on a platform that didn't even exist when it was shipped (it worked for IBM).
Beyond the technical advantages of TIMI, it will provide us years of South Park references.
Linux doesn't need fat binaries because the package manager automatically installs the binaries that are appropriate for the machine.
OS X needs fat binaries because it doesn't have package management. I wish people would stop trying to bring OS X (mis)features over to Linux. If I wanted to use OS X, I'd already be using it.
Calm down. Gentoo has almost finished building. In a few hours, you'll be able to use your machine again.
And in fact, for large classes of interesting applications, installer and installed size is overwhelmingly data, not code. Games are going to be 95%+ data (check out how small the actual app is sometimes; often less than 1% the size of the data files). Microsoft Office has far, far more space allocated to fonts, clip art, all those multilingual spelling dictionaries, and templates than the actual *.exe files.
And even the self-contained .exe files in the above examples will also include a ton of bitmapped images for the GUI and such. Sure, command-line apps are going to have a lot more code, but even they will have the help text, tables, and other stuff that could be stored once in a platform-independent internal data structure.
Having behavior driven largely by data, not good is a good thing, of course. Data is a whole lot easier to debug than code, and bugs in data are generally much less catastrophic assuming the code itself does good validation.
My video compression blog
Somebody didn't read the article...
Q: Do you have to read the entire FatELF file to load it?
A: Nope! Just a few bytes at the start, and then the specific ELF object we want is read directly. The other ELF objects in the file are ignored, so the disk bandwidth overhead is almost non-existent.
Q: So this...adds PowerPC support to my Intel box?
A: No. FatELF is not an emulator, it just glues ELF binaries together. If you have a FatELF binary with PowerPC and Intel records, then PowerPC and Intel boxes will pick the right one and do the right thing, and other platforms will refuse to load the binary, like they would anyway.
Q: Does this let me run 32-bit code on a 64-bit system or vice versa?
A: No. This doesn't let 32-bit and 64-bit code coexist, it just lets them both reside in the file so the platform can choose 32 or 64 bits as necessary.
Q: Do I need to have PowerPC (MIPS, ARM, whatever) support in my FatELF file?
A: No. Put whatever you want in there. The most popular scenario will probably be x86 plus x86_64, to aid in transition to 64-bit systems.
Kind of like Java then.
Linux needs to become more like Mac OSX than Windows.
What I would like to see in Linux in the near future:
Universal file format for X86, X64, and PowerPC executiables that replaces the ELF format (WIZARD format, ELF needs food badly!)
GNOME and KDE merged into one GUI that emulates both of them, GNIGHT or something.
Ability for Linux to use Windows based drivers when Linux based drivers do not exist, something better than that NDISwrapper but under a GPL license and built into Linux.
GNUStep being developed into something that resembles Aqua, Aero, and other GUIs and is backward compatible with the Mac OSX API calls to recompile OSX programs for Linux. Maybe even in the near future run OSX Universal binaries somewhat like WINE runs Windows programs.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
I do not propose anything. Why should I?
You propose no solution for distribution of non-free software. You propose no solution for funding development of free video game software. Therefore, you appear to propose the elimination of the video game industry. A lot of Slashdot users who like to play video games disagree with your proposal.