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."
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.
Could this technology also help binaries to link against multiple versions of standard libraries (glibc, libstdc++)?
Not really, it'll just make bigger binaries that'll run on a system you'll never use.
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...
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?)
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.
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.
Calm down. Gentoo has almost finished building. In a few hours, you'll be able to use your machine again.
And wasn't it called Java?
Are any of you guys old enough to remember CP/M running on the 8086? It was a solid, no-glitch way of running binaries from one OS to another. And Z80 code seemed as complex to most techs then, as protected-memory schemes do now.
But they *did* it, and did it well.
If we are *ever* going to actually have a 'universal binary' we need to make the hardware do the job: not software.
Case study: 1988, SCI Systems, Huntsville, Alabama.
Three software guys huddled over their 80186-based site-controller motherboard our company built. These guys were GODS, able to write compilers AND embedded control software, all interrupt-based, pre-emptive long before Linux. All three agreed it wasn't software, this *must* be something in the hardware. There'll be yelling and noise, but let's get a hardware tech here.
"Neil!" someone said. And this odd-looking, couldn't-be-nicer guy snagged an oscilloscope cart on his way over. He seemed to already know the question.
He clipped on the grounds, checked about 4-5 pins and dropped the probe. 'Software problem.' and walked out. I thought he had to be the most arrogant guy in the room, until I did the math:
He wrote the schematics. He laid out the parts, he did the prototype, he did the solder, and every other masks. He wouldn't have sent the device to production if the Chip Enable lines weren't working. Because of this, if they're trying to talk to the memory chips (using Intel's STUPID, 16-ways to describe-every-location scheme) then it was a software problem.
The point: hardware guys have more they can cross-check; they can't move on until one level of production checks. Based on that, future levels don't _tend_ to need a complete re-fit. You just can't get that in software: people don't work that way. Software is just too elusive. I've been saying this since 1978.
They were trying to work out a 'java' at that time, they're still trying today. But different 'runners' and different code, and we STILL AFTER ALL THESE YEARS HAVE NO REAL PROGRESS. If anything works at all in the customer's hands, it's a surprise.
Make all processors have unified code, or drop the project. There's SO much more we could be doing, please?
--- For a good time mail uce@ftc.gov
The problem is that disk space is NOT cheap at all, or plentiful. ARM-based Linux is used on a lot of embedded devices where there's only 16 or 32MB of flash space, total. This "fatELF" idea makes no sense, because adding in x86, x86_64, MIPS, Alpha, and SPARC binaries to your ARM binary will make everything take so much space that much more (expensive) flash memory would be needed.
This just isn't a very good idea. It makes sense for Apple, which only has to worry about 2 architectures on the desktop, and wants to make things easy for consumers, but that's it. It doesn't make sense for Linux. And I'll bet that Apple doesn't use this "universal binary" thing on their iPhone, either.
Kind of like Java then.
As a former Autopackage developer, no, it isn't what Autopackage is about.
Autopackage attempts to do more than just packaging: it also tries to fight the binary compatibility problem. Probably the most widely known example is this one: compile a binary on distro A, run it on distro B, and get "symbol foobar@GLIBC_2.8 not found" errors. (There are a lot more binary compatibility issues than that though.)
However, making cross-architecture binaries is not one of Autopackage's goals.
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.
-- listen to interesting music, support independent radio... WPRB
Disk space may be cheap but I wouldn't call bandwidth that cheap. When you aren't using super-fast internet and are using Dial-up or cell phone internet, the difference between a 2 MB file and a 10 MB file is huge. Even if you have enough disk space for that, its still going to be painfully slow to download the larger it is.
Taxation is legalized theft, no more, no less.
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.
I thought this was the whole point of Java. Why are we going back and trying to solve a problem that was solved FOURTEEN YEARS AGO