Forgot your password?
typodupeerror
Software Linux

Ryan Gordon Wants To Bring Universal Binaries To Linux 487

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

Ryan Gordon Wants To Bring Universal Binaries To Linux

Comments Filter:
  • by Anonymous Coward on Sunday October 25, 2009 @08:15AM (#29863645)

    after the diminse of NeXTStep!

    (c)Innovation!!(tm)(R)

    • by TheRaven64 (641858) on Sunday October 25, 2009 @08:37AM (#29863763) Journal
      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: (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: (Score:3, Insightful)

          by FooBarWidget (556006)

          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.

      • by Grishnakh (216268) on Sunday October 25, 2009 @01:15PM (#29865419)

        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.

        • by TheUser0x58 (733947) on Sunday October 25, 2009 @02:18PM (#29865947) Homepage

          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.

      • Re: (Score:3, Informative)

        by TheUser0x58 (733947)

        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 com

      • Re: (Score:3, Insightful)

        by Darkness404 (1287218)
        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.
    • by BuR4N (512430) on Sunday October 25, 2009 @08:39AM (#29863777) Homepage Journal
      NextStep isnt dead, it just got a new name when Next told Apple to buy them....
    • Re: (Score:2, Interesting)

      by Hal_Porter (817932)

      Nextstep isn't really gone, it just possessed MacOS and now it walks around in its body, a bit like VMS did to Windows.

  • by dingen (958134) on Sunday October 25, 2009 @08:26AM (#29863679)

    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.

    • by betterunixthanunix (980855) on Sunday October 25, 2009 @08:32AM (#29863725)
      Not everyone is skilled enough to compile the source on their own, especially for packages that must be patched to run on certain architectures. 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.
      • Re: (Score:3, Interesting)

        by Sique (173459)

        But... "compiling for your platform" is just another way to install software. You could wrap this in a little application (call it "setup"), where you click "Next >" several times, and as a result you have a binary for your platform.
        For those who know what they are doing, there is always the "expert configuration" button.

        • by Yvan256 (722131)

          But then you need a fat binary for your little installation program.

        • Re: (Score:3, Insightful)

          by JackDW (904211)
          You're expecting the end user to have everything installed that he or she will need to build your application. End users probably don't have GCC and libc6-dev installed, not to mention the dozens of packages that are needed to compile a C++ program or a GUI program. Why should the end user have to install these things? He or she should just be able to install the libraries that are required, not the libraries and the headers and the C compiler and whatever else. And preferably, the library installation shou
        • by Teckla (630646) on Sunday October 25, 2009 @10:42AM (#29864521)

          But... "compiling for your platform" is just another way to install software. You could wrap this in a little application (call it "setup"), where you click "Next >" several times, and as a result you have a binary for your platform.

          Wow, the lack of grasp on reality around here really amazes me sometimes. But it looks like it worked for you. The open source fanatic fan boys shot your karma through the roof. Congratulations!

          Compiling non-trivial applications from source can take a long time. That fact alone can make precompiled binaries a big win for most users.

          I did the "compile from source" thing for a long time on FreeBSD before finally realizing the pointlessness of it all. Not only was I completely unnecessarily beating up on my hardware, but spending far too much time waiting for compiles to complete.

          These days, I grab precompiled packages whenever possible, and you know what? It's a hell of a lot better.

          • Re: (Score:3, Interesting)

            by Hurricane78 (562437)

            You have obviously no graps of software design principles.

            Look at how it's done on pretty much all Linux distributions: You choose your architecture when you choose the install medium. From then on, the package manager pulls your packages for the right arch. There is no need to re-compile it for every user, if it's the same. Just offer specially optimized binaries for every arch right on the package repository servers. That's the basic principle: Never do something twice. It's like caching.

            The other one is

      • by turbidostato (878842) on Sunday October 25, 2009 @08:49AM (#29863835)

        "Not everyone is skilled enough to compile the source on their own"

        By "end user" we can understand here "distribution maintainer" which already has the skills to compile the source (and that's not but a part in the lot of things that have to be done in order to integrate some software in a distribution).

        "I would think this might be useful for distro maintainers who do not want to maintain separate packages across multiple architectures"

        But they have to: they still must build and integrate for their supported platforms, then rebuild when bugs are found or the software is upgraded, then test... It's just the last step (producing the very binary packages) that changes so instead of multiple packages you'd end up with a single multplatform package. The distributor still need (almost) as much disk space and infrastructures as before, but then each and every user will end up with spending much more space in their hard disks (imagine the fat binary for, say, Debian, supporting eleven platforms).

        And then, please note that this will allow for single binaries for diferent hardware platforms but not for different version compilations (so it won't be useful to obtain binaries for, say, amd64 for Debian, Red Hat and SUSE).

        It seems it will only benefit to those that want to publish their software in an only binary form outside the framework of stablished distributions and that means closed source software. Of course they can look for their bussiness the way they feel better, it's only they don't get my simpathy so I don't give a damn about them.

        • by slim (1652) <`ten.puntrah' `ta' `nhoj'> on Sunday October 25, 2009 @09:42AM (#29864135) Homepage

          I agree that fat binaries are not appropriate for applications in the distribution's archive. And I agree that the first port of call for any user should be apt-get / up2date / etc.

          However there are many kinds of app that might not get into the distro archive, for all kinds or reasons. Maybe it's of really niche interest, maybe it's too new, maybe the distro-maintainer just interested in it. Or maybe it's proprietary. Some people are willing to compromise on freedom.

          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.

          • Re: (Score:3, Informative)

            by turbidostato (878842)

            "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 effo

    • by Monkey-Man2000 (603495) on Sunday October 25, 2009 @08:34AM (#29863737)
      While this is true, of course a lot of free software can run on OS X as well. Compiling this is nearly as easy as Linux, but it's still quite useful just to download a universal binary of the full application if it's available. Smaller apps aren't a big problem, but for bigger ones it can become an unnecessary hassle. For example, I just had to compile Inkscape from scratch on Snow Leopard and I spent an afternoon tracking down and compiling all the dependencies because the universal binary doesn't currently run on 10.6. I really would have benefited from the universal binary if I wasn't so bleeding edge.
    • by eldavojohn (898314) * <eldavojohn.gmail@com> on Sunday October 25, 2009 @08:34AM (#29863741) Journal
      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 [icculus.org] benefit, too.
      • A download that is largely data and not executable code, such as a large video game [icculus.org], 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).

    • by dkf (304284)

      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.

      On the other hand, it's a poor platform if it is too hostile to third party software (some of which will be sufficiently specialist to be effectively commercial-only, because you're really paying for detailed support). The big benefit is being able to say "this is a Linux program" as opposed to "this is a 32-bit x86 Linux program"; for most end users this is just a much easier statement to handle because they don't (and won't ever want to) understand the technical parts. (There's a smaller benefit to people

    • Actually, this can be good even for Ubuntu. Think of having i7, Atom and Phenom versions of executable alongside classic 586 version. Also, having one repository instead of several can also streamline few things. Downside is more data transferred on software updates, unless some create really smart update which transfers only part of fat binary that is actually used on client.
      • by Bert64 (520050)

        There are already smart update systems, there is a single source package which is compiled into multiple binary packages, your smart client only transfers the binaries which are appropriate for the architecture it uses. Because different architecture versions have different filenames, the packages themselves can already sit alongside each other inside a distribution repository... There is nothing currently stopping you creating a multi architecture install dvd. The reason it's not done is because it would b

    • Actually, there's one case where I can see this being useful. I was talking a while ago to some of the OpenBSD developers about the planned Dell laptops that had both ARM and x86 chips. Their idea was to have a /home partition shared between the two and let users boot OpenBSD on either. If you had fat binaries, you could share everything.

      The canonical use for fat binaries with NeXT was for applications on a file server. You would install the .app bundle on a central file server and then run it from wor

      • by Bert64 (520050)

        You could take that a step further actually...
        Boot the core OS on the ARM cpu, and use that for all your day to day tasks, but power up the x86 on demand for heavy computing workloads. Think of the early PPC amiga addon cards, the core system was still 68k based but you could use the PPC chip for certain power hungry apps or games.

        Not sure how hard it would be to engineer, at the very least you could boot the x86 system headless, and have a virtual network between the two so you could access it virtually re

    • by Zobeid (314469)

      Maybe "most apps for Linux are free and the source is available" partly due to difficulties of distributing and installing binaries?

      The whole Linux distribution and installation system (such as, with apt-get) is great for setting up a server, but it's very awkward and unnatural for desktop apps. Apple is far ahead in that respect, and I see no reason why Linux shouldn't follow their lead.

      I read an opinion somewhere, and it made sense to me, that Linux treats all software as system software -- as part of th

      • by koiransuklaa (1502579) on Sunday October 25, 2009 @09:12AM (#29863959)

        The whole Linux distribution and installation system (such as, with apt-get) is great for setting up a server, but it's very awkward and unnatural for desktop apps. Apple is far ahead in that respect, and I see no reason why Linux shouldn't follow their lead.

        You've got to be kidding? Super-easy installation and automatic security updates for all applications is 'awkward'?

        If I understood you correctly, your suggestion is that desktop software should be hard to find, it should be installed from whatever website I happen to ultimately find and it shouldn't automatically get security updates. Sounds fabulous.

        Don't get me wrong, I agree that package management systems have their flaws (even inherent ones) but you just aren't making a good case against them... You could start with explaining what's unnatural about "Open 'Add applications', check what you want, click Install", and then continue with explaining what's awkward about totally automatic security updates.

        • by 99BottlesOfBeerInMyF (813746) on Sunday October 25, 2009 @11:46AM (#29864893)

          The whole Linux distribution and installation system (such as, with apt-get) is great for setting up a server, but it's very awkward and unnatural for desktop apps. Apple is far ahead in that respect, and I see no reason why Linux shouldn't follow their lead.

          You've got to be kidding? Super-easy installation and automatic security updates for all applications is 'awkward'?

          Neither Linux on the desktop nor OS X is perfect when it comes to software installation and both should borrow from the other. Right now Ubuntu, probably the front runner for usability in desktop Linux, still has multiple programs used to manage packages and fails to handle installation from Web sites or disks well. It cannot run application off a flash drive easily and reliably, and frankly it sucks for installation of commercial software. A lot of commercial and noncommercial software is simply not in the repositories and I end up running a binary installer by hand or I have to resort to complex CLI copy and paste in order to get what I want running. But they're working on it and the new RC has a new package manager they eventually intend to solve some of these problems. Both OpenStep and multiple binaries would further the goal of having more usable application installation. For example, one could install an application on a flash drive then plug that drive into multiple computers with different architectures and run it without having to install it on the machines themselves (which is often not even an option).

          If I understood you correctly, your suggestion is that desktop software should be hard to find, it should be installed from whatever website I happen to ultimately find and it shouldn't automatically get security updates. Sounds fabulous.

          Like it or not, regardless of the platform I'm running, when I want new software I usually turn to Google. I read Web pages and reviews and comparisons and look at the developer's Web site. It follows then that an easier workflow is to directly install from a Web site by clicking a link in the Web browser. Ideally, this link should be a link to a software repository that will pull the application into my package manager and this is possible in some package managers but almost never used because there is not a single standard for package management on Linux. A less useful workflow is what I normally use. That is, I go through the process of deciding what software I want to use by looking at Web pages, then I open my package manager and copy and paste the name into the package manager. Then I sometimes find it and install from there with only on wasted step, but often I don't find it so I go back to my browser and install by hand using whatever method is necessary.

          In short, there's a lot of room for improvement and multiple binaries are one way to make an improvement for desktop use, but which may well never happen because Linux development is still dominated by the server role.

        • by BitZtream (692029) on Sunday October 25, 2009 @11:50AM (#29864915)

          You've got to be kidding? Super-easy installation and automatic security updates for all applications is 'awkward'?

          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: (Score:3, Interesting)

            by jedidiah (1196)

            ...and a great counterexample is MovieGate.

            It's right there on the Apple downloads page, and pretty prominent too.

            It doesn't do any of this "automatic dependency management". It could sorely use it.

    • If you have access to the source, you can always compile a version for your platform.

      . Yes ... you can.

      Let's use OpenOffice.org as an example, if for no other reason than I was looking into building it optimized specifically for my computer (Windows).

      Step 1) Getting the source [openoffice.org]

      The source tarballs linked here contain a snapshot from SVN:
      core source package
      system source package
      binfilter source package
      l10n source package
      extensions source package
      testautomation source package

      Okay, I probably don't need testautom

      • by dingen (958134) on Sunday October 25, 2009 @09:47AM (#29864177)

        No, my example wasn't a Linux one. Who cares. The main point is that it's not just that easy to build from source.

        Well, since TFA is about a fat binary system for Linux, it is kinda relevant to narrow your scope to just Linux. How stuff in Windows or any other operating system work has nothing to do with this new Linux-specific feature.

        That said, Windows is probably the worst platform for consumers wanting to compile their own applications. It doesn't provide any tools to do so by itself and if the source you want to compile doesn't include something like a Visual Studio project file, you're in for a very hard time. Linux doesn't suffer this fate at all. Compiling an application is in most cases nothing more complex than typing "./configure && make" and you're good to go.

        Besides, what is so horrible about having fat binaries on Linux?

        Nothing. I'm not saying it is. In fact, I'm saying it isn't. It just doesn't surprise me that it took a long time before someone started to develop something like this, while other platforms had this feature for quite a few years, because the need for this on Linux isn't on the same level as it was for Mac OS X back when Universal Binaries made their entry.

  • by GreatBunzinni (642500) on Sunday October 25, 2009 @08:27AM (#29863691)
    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?
    • Well, the effort of packaging a application (a) to different platforms and (b) to different distributions is quite a duplicate one, involving a lot of people (and time).

      • by PeterBrett (780946) on Sunday October 25, 2009 @09:48AM (#29864183) Homepage

        Well, the effort of packaging a application (a) to different platforms and (b) to different distributions is quite a duplicate one, involving a lot of people (and time).

        Firstly, this proposal has absolutely no relevance to the difficulty of packaging to different distributions.

        Secondly, packaging to different platforms has been solved. Most distributions now have compile farms where you submit a package specification (usually a very simple compilation script and a set of distribution-specific patches) and packages for all the various architectures get spat out automatically.

        This proposal is a solution looking for a problem, as far as Free software is concerned. The only utility is where the application is closed-source and can't go through a Linux distribution's normal package compilation and distribution workflow.

  • by Jim Hall (2985) on Sunday October 25, 2009 @08:27AM (#29863695) Homepage

    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.

    • by John Hasler (414242) on Sunday October 25, 2009 @08:34AM (#29863739) Homepage

      > It's dead simple. We need something like this in Linux.

      "aptitude install " (or the pointy-clicky equivalent) works for me.

      • Re: (Score:3, Funny)

        This is /., if it is not as pretty as Aqua, it does not count.
      • by teg (97890)

        "aptitude install " (or the pointy-clicky equivalent) works for me.

        No, it doesn't. "yum install firefox" and similar things like apt install something called firefox. In many cases this will be ok, but in many others it won't. E.g. when new releases of openoffice.org or firefox arrives. This often won't show up in normal repositories for a while, if it shows up at all before a later release of the distribution they are running.

      • by jonbryce (703250) on Sunday October 25, 2009 @09:40AM (#29864123) Homepage

        That is great for software supplied by your distro's repository, and most distros have lots of software available in their "contrib" or equivalent repository. Firefox of course usually comes installed out of the box, so it isn't an issue.

        Where this could be beneficial is for software that isn't popular enough for the distros to package. At the moment, you have to publish different packages for each distro and for each architecture, and you probably won't bother about much beyond i386 and amd64.

    • apt-get install firefox

      or synaptic (click) firefox (check) apply (click)

      A lot easier than finding/going to the website, clicking the download icon, waiting, draging an icon... Mozilla does this wonderfully (agent string used to present the download for your OS/language), most other downloads require you to look for the download you need.

    • by TheRaven64 (641858) on Sunday October 25, 2009 @08:45AM (#29863817) Journal
      As I get tired of repeating, GNUstep has had this on Linux (and *BSD, and Solaris, and Windows) for many years. It supports NeXT-style bundles with different binaries (and, optionally, different resources) for different systems, so you can easily store Linux, Mac, FreeBSD, and Windows binaries in the same bundle.
    • Linux' way of saying "NO NEVER NEVER DO THIS! Also, it doesn't work." to installing stuff by downloading it yourself has beauty where Apples concept is malware-prone.

      The only way I can see your suggestion implemented is by providing a file format that just contains what package you would like to install (for each possible distribution).

      e.g. for Firefox.app:
      Gentoo: ensure_installed(www-client/mozilla-firefox)
      Debian: ensure_installed(firefox)
      Fedora: ensure_installed(firefox) ... etc

      Declarative, that is. Then

  • by koiransuklaa (1502579) on Sunday October 25, 2009 @08:30AM (#29863715)

    ...it's convenient on the end-user and on software vendors for distributing their applications.

    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...

    • Re: (Score:3, Insightful)

      "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."

      Actually, having to maintain packages across several architectures can be tricky at times. Some packages need to be patched to run correctly on different architectures, and the upstream maintainers can accidentally break those patches (e.g. if they are not personally testing on a given architecture). It could even be the case that different a
      • Oh yes, maintaining packages for several archs is real work, I'm not claiming otherwise. I just don't see how universal binaries makes things easier. Coding, compiling, testing, patching -- all of those need to be done with all supported archs in mind in any case.

      • by turbidostato (878842) on Sunday October 25, 2009 @08:59AM (#29863869)

        "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.

      • by Bert64 (520050)

        Another option is for distributors to have compile farms, whereby they have an example of each architecture available to them, and it's a simple case of submitting a source package and it gets built automatically for each available architecture.
        Also most patch breakage is changes which prevent the patch from applying, most build systems will apply arch specific patches even if you aren't building for that arch so breakage will be quickly noticed... A well written patch to fix a specific arch should not have

  • Most package manager can automatically create a binary package out of a source package. In many cases this resolves even problems with otherwise incompatible libraries. So for whom is such a fat binary advantageous? I'd assume mostly for closed source vendors. I have nothing against closed source in general, but if I pay for a software I expect at least a minimum of support. Such a fat binary does not look too userfriendly for me. Even if I can strip it down to my architecture. I suppose it does not solve t
  • by C0vardeAn0nim0 (232451) on Sunday October 25, 2009 @08:44AM (#29863811) Journal

    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.

  • Not scalable (Score:5, Insightful)

    by gdshaw (1015745) on Sunday October 25, 2009 @08:45AM (#29863815) Homepage

    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?)

  • by Alain Williams (2972) <addw@phcomp.co.uk> on Sunday October 25, 2009 @09:40AM (#29864121) Homepage
    Architecture Neutral Distribution Format [wikipedia.org] was tried some 20 years ago. The idea was to have a binary that could be installed on any machine. From what I can remember it involved compiling to some intermediate form and when installed compilation to the target machine code was done.

    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%.

  • by iamspews (714559) on Sunday October 25, 2009 @10:24AM (#29864415)
    This is cool and everything, but I'd rather Ryan spent the time on whatever it takes to get Linux Unreal 3 published.
  • by sjames (1099) on Sunday October 25, 2009 @11:00AM (#29864615) Homepage

    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 [wikipedia.org]. 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.

  • by jipn4 (1367823) on Sunday October 25, 2009 @11:54AM (#29864939)

    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.

  • 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.

HELP!!!! I'm being held prisoner in /usr/games/lib!

Working...