Ryan Gordon Wants To Bring Universal Binaries To Linux 487
Posted
by
timothy
from the grossly-obese-binaries dept.
from the grossly-obese-binaries dept.
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."
Re:Only useful for non-free applications (Score:5, Informative)
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).
Apple is still using it (Score:3, Informative)
Apple is still using it for x86/x86_64 fat binaries in Snow Leopard.
Re:Gee, just 14 years (Score:5, Informative)
Re:Gee, just 14 years (Score:4, Informative)
Re:We really care (Score:4, Informative)
Read the fine website:
Re:Apple dropped it (Score:5, Informative)
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:We need 1-file installs (Score:4, Informative)
Re:Apple Universal Binary is kinda of a joke. (Score:5, Informative)
Re:Apple Universal Binary is kinda of a joke. (Score:1, Informative)
OS X' universal applications are ONE SINGLE application, but the executable file itself inside the app - and there is only ONE executable, not two or more - contains code for all architectures. Let me repeat: ONE executable file with all architectures, not several executables. So you're wrong. It's a quite smart solution.
That said, OS X' universal files are pretty much on their way out, as Snow Leopard (10.6) doesn't play ball with PPC. As time goes on and people realize that x86 is a dead horse running, we might however see universal executables again, but then as ARM and x86.
Re:We need 1-file installs (Score:1, Informative)
I think he meant a general solution to handle software that isn't in the repositories.
Re:Gee, just 14 years (Score:2, Informative)
Isn't that was http://autopackage.org/ [autopackage.org] is trying to do to?
I find it a benefit of Linux if there is only one instance of a XML library in my memory, though.
Re:Only useful for non-free applications (Score:3, Informative)
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).
I'm sorry, I should have been more clear. I mean free as in freedom. MS Visual Studio Express isn't free, it just doesn't cost any money to purchase.
Re:Only useful for non-free applications (Score:1, Informative)
Not everyone is skilled enough to compile the source on their own, especially for packages that must be patched to run on certain architectures.
That's ok as not everyone needs to compile the source on their own. If a distro supports a certain architecture then the user only needs to install the package and he doesn't even need to know what architecture he is running. This isn't 1996.
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.
Is that even a problem? I don't remember seeing anyone complain about that problem. I've heard complains about how the packaging process being complicated for newbies to tackle it but not about multiple platform support.
Re:Gee, just 14 years (Score:3, Informative)
The 68k/PPC binaries were referred to as Fat Binaries. As a marketing term, Universal was only ever applied to PPC/x86.
When you say that MacOS doesn't use universal binaries any more, that's not strictly true. It doesn't ship with many that use both PPC and x86, because as you say OS 10.6 won't run on PPC Macs. But it still fully supports them and many software vendors are still producing them. These days, the same tech is used to store a 32 bit and a 64 bit version of the same x86 executable.
Re:Apple dropped it (Score:3, Informative)
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.
Re:Only useful for non-free applications (Score:4, Informative)
It was... a joke. Thank god English is free of that stupid distinction?
Re:Gee, just 14 years (Score:5, Informative)
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 [windowsitpro.com]
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.
Re:Only useful for non-free applications (Score:1, Informative)
I'm a programmer, but I'd rather not have to compile everything myself. Experience has taught me that getting other people's projects to compile is a very frustrating and time consuming experience. The last time I made that mistake was when I wanted to make some trivial modification to the Chromium (aka Chrome, aka Iron) webbrowser; turned out it wasn't quite the same C++ as I had. After several days of fixing an error here, an erroneous cast there, and so forth, I finally gave up. I didn't even get it to compile, let alone run, let alone fix the problem.
Re:Only useful for non-free applications (Score:3, Informative)
"The last application I had trouble installing on Linux, due to glibc versioning problems, was a profiler for WebMethods Integration Server. Something like that is never going to get into the APT repository."
Why not? If it's free software it certainly can go in the "contrib" repo; if it's closed source but still redistributable it will go in "non-free". Being it "niche" doesn't preclude it from being in the repos: usually if it is license-compatible and there's at least one person willing to take the effort to package it, it will be accepted. Even if the packager is not a Debian developer, it will go with the support of the mentors list.
Of course it won't go in the repos if it's closed non-redistributable software but then we come back to square one since I already said that to be a "maybe" case for the fat binary case.
Re:Only useful for non-free applications (Score:4, Informative)
On my mac, I just download the app. Run it. If the app supports auto updating, it just hooks in on first run.
No package manager required. No dependency tracking, it just works. When I want to uninstall it, I just delete it and it cleans itself up on its own, sometimes not completely until next login.
A great example of this is CrossOver for Mac.
A package manager is nice for finding apps however, but trying to say that Apples system is bad in comparison is just silly. When you get a bunch of commercial vendor together, putting them all on the same 'repository' gets to be a bitch, they fight too much. This is why its rare for commercial software unless they can buy their way to the front of the display list.
No one is suggesting it be hard to find, not even Apple, which is why they have their own site with the common Mac software you can buy or download if its free or has a trial.
You can't compare Linux package managers which are practically designed to be anti-commercial to a commercial environment. Its just not the same ballgame.
Re:Only useful for non-free applications (Score:1, Informative)
> Free has meant 'no charge' for a lot longer than it has meant 'free (as in liberated) software'.
Hardly. 'Free' meaning 'gratis' is actually short for 'free of charge.'
Data Code (Score:3, Informative)
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.
Re:Linux is fine, but how about other platforms (Score:4, Informative)
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.
Re:Unix (OSF) tried it with ANDF (Score:3, Informative)
It was called P-code [wikipedia.org]
n the early 1980s, at least two operating systems achieved machine independence through extensive use of p-code. The Business Operating System (BOS) was a cross-platform operating system designed to run p-code programs exclusively. The UCSD p-System, developed at The University of California, San Diego, was a self-compiling and self-hosted operating system based on p-code optimized for generation by the Pascal programming language.
Re:Only useful for non-free applications (Score:1, Informative)
Thats why we have distributors who compiles applications binaries from source. We get competition to markets between distributors and enduser gets better results.
And then we still remember always the open source (and free software) that source code IS the software as well, not just on executable format.
And you can always find someway help to compile the code yourself. If not freely, just give $5 to someone to do that for you. That's it.
Re:Gee, just 14 years (Score:3, Informative)
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.
I'm not terribly familiar with GNUstep, but, in Mac OS X's implementation of application bundles, this is simply not true. Of course, architecture-dependent compiled executable code must necessarily be duplicated for each supported architecture, but the application data (which almost always is the most significant fraction of an application's size) is shared. The only reason data would have to be duplicated is if for some reason it is compiled into the binary. Though compiling data into the binary is common in many systems, application bundles render this practice unnecessary.
Re:Only useful for non-free applications (Score:3, Informative)
Re:Only useful for non-free applications (Score:4, Informative)
"Package managers are a necessary evil."
Your opinion. I've extensively managed software installations on Linux and Windows and even if package managers are a necessary evil, they are much better than the alternatives. By far.
"If I want software [...] I don't have to hope that the company I bought the operating system has put it in their database."
You forget that one thing is a package manager and a very different one a package source. Any company that cares can provide its own tigthly integrated package source for a distribution without permission or cooperation from the operating source vendor (yes: even closed source vendors can do that). And by using the package manager the end user gets for free centralized software inventory and upgrades without the need to go after each and every vendor's procedures as they reinvent the wheel.
"Package managers are only necessary because of the fragmented nature of the Linux universe."
Oh! that certainly explains why on the Windows side they have reinvented them (control panel's install/unistall app, install shield, windows update, msi files...) only worse.
Re:Gee, just 14 years (Score:3, Informative)
DEC did sue Microsoft, but they settled for royalties.
Re:Gee, just 14 years (Score:3, Informative)
> The way you express it, DEC would have a had a case
> against Microsoft for stealing their technology. Are
> you aware of any evidence that this happened?
As a matter of fact, yes. See http://www.roughlydrafted.com/2009/07/30/readers-write-how-microsoft-got-windows-nt/#more-3661 [roughlydrafted.com]
| "So, Cutler walked down the street to Microsoft and offered them
| Mica which became NT. Later DEC sued MS and, in an out of court
| settlement, got royalties for the filched technology. Part of the
| deal included targeting NT (back) onto the Alpha platform."