Ryan Gordon Brings Universal Binaries To Linux

[illissius]

Yeah, that's my main concern as well. Disk space is cheap, RAM less so.

[elanthis]

I'm not sure how shared library loading is implemented in Linux, but if it maps binary into memory, does that mean we'll get a major increase in memory usage once FatELF goes mainstream?

No.

Stuff that's used is loaded into memory. Stuff that's not is left on disk. Same way it always has.

[loonyphoenix]

This could be useful for "portable apps" and proprietary software. Do I understand it correctly that not only will these binaries work across different platforms, but also across different distributions? I don't care for the platforms very much, there are generally only two of them, but I do care that sometimes proprietary software is available as a package for only one or two distributions.

[Wyatt]

Sheesh, short-sighted cynics everywhere. I was more indignant that SDL switched to PulseAudio for its default sound, to be honest. Did any of you even read the rationale for this move? Really, I'd think at this point that at least Ryan Gordon, a well-known professional championing commercial games and development for our OS, has a good enough reputation in our circles that people would trust that he has good reasons for making a completely optional alternative specification for bundling multiple binaries together. Such as to ease development and user experience for people that don't know what arch they run.

Seriously, relying on web technology to reliably determine system architecture? Are you completely insane? Next thing, you'll be telling me that sidecar files are how semantic metadata should be transmitted.

FatELF is actually a good idea, and I hope it sticks.

[pvtcupcakes]

This could be useful for "portable apps" and proprietary software. Do I understand it correctly that not only will these binaries work across different platforms, but also across different distributions? I don't care for the platforms very much, there are generally only two of them, but I do care that sometimes proprietary software is available as a package for only one or two distributions.

It's not a package; it's a binary. .deb and .rpm files are like tarballs that contain binaries. And binaries have always been cross distribution. (ELF binaries) This doesn't address the packaging issue.

[Remco]

What's wrong with PulseAudio?

[#kyz]

I really like the idea of bringing Universal Binaries to Linux. At least it gives those pesky commercial developers one less thing to complain about, which I think is a good thing for now. And hey, it could make it easier on new Linux users, which I have absolutely no complaints about.

I can see in a way though how some of you may not like it, however, it is entirely optional, if you don't want it in your project, simply don't use it. However if I was developing a project I'd at least give it a shot since I can't really say something bad about something I haven't even tried.

A game/app that comes to mind that could maybe benefit from it immediately is Nexuiz, it has x86 and x64 binaries in the same directory which may confuse the newer user. Of course I could be wrong.

[loonyphoenix]

It's not a package; it's a binary. .deb and .rpm files are like tarballs that contain binaries. And binaries have always been cross distribution. (ELF binaries) This doesn't address the packaging issue.

That's a pity. So then it isn't like "universal binaries" after all. As far as I know, those contain needed libraries, etc, being a package and a binary at the same time, no? (I never actually used Mac OS X )

[droidhacker]

Why is this bloated? Sure it will give you more than you need, but I will gladly accept this if it also includes x86_64 binary.

Your assumption is that they would include both binaries even if they were in one package, which it could be anyways.

The actual reason why certain proprietary software is packaged as 32bit only is that 32bit binaries work perfectly well on 64bit hardware, so there is no perceived NEED to do so. They would STILL have to compile it for both, which means that they will STILL not include both.

In fact, proprietary software tends to be distributed as runnable/installable archives. These same "install scripts" (like the ones distributed by AMD and NVIDIA for graphics drivers) *already can* include BOTH sets of binaries -- and select which ones to install based on the detected architecture. There is no need to actually combine the binaries! In fact, *AMD ALREADY DOES THIS*!!!

but one thing I do know is that offering two sets of binaries for the same PC is confusing for everyone except technical people.

How? If the software vendors followed AMD's lead and packaged them both together in the same script, it could *automatically* select the correct architecture.

If we want the Linux-platform to be more popular, we simply can't expect people, i.e your grandma and grandpa, to know whether to download and install the 32bit binary or the 64bit binary, because they don't know the difference and they don't want to know it either. What such people want is a binary that "just works". Universal binaries is just that.

What THEY need is for their software to be distributed in a magical system that automatically selects the correct package for their system, and at the same time, automatically installs all of the dependencies. Wait! We already have this... Its called PACKAGEKIT!

I disagree. Unless you really expect people to know the difference between 32bit and 64bit, this has to be done one way or the other to push forward the adoption to x86_64. As I said above, it's confusing to offer two binaries for the same PC, and we all know which one will work in any case.

As I have explained already, NO. This is NOT necessary. It is either up to the package vendor for their installers to automatically select the appropriate binaries for the system, or to the PACKAGE MANAGEMENT SYSTEM. There is *NO NEED* to bloat the binaries.

[droidhacker]

Not that often, but that's not the point. The point is it does happen (games for instance), and you can't reliably discover the architecture via the browser. Sure, the most currently common browsers do provide it, but some (for instance Konqueror) don't, and what do you do then? Say "Hey! I don't know what CPU architecture you're running. It could be ARM, PowerPC, x86, x86_64 etc. Please download the appropriate version."? I don't think that's working too well.

And what do you mean by "The correct way to distribute software is by non-executable installer packages."? Do you mean the package manager? If so, you're only moving the problem to another area ("Which package manager does the user use?").

The package manager is up to the design principles of the DISTRIBUTION.

Do you want to know WHY game vendors won't use this...
Think of this;
If your game is 1GB and you have 1000 users, each of whom downloads it, you have 1000 GB of download.

Now you decide to support 5 architectures, suddenly, the game size goes up by 500 MB to add in all the extra binary data. Each of your 1000 users now downloads 1.5 GB, which means a total of 1500 GB. That means that your NETWORK (which you pay for) suddenly has to handle 50% more data!

But if you keep it down to 1 package per arch, then though you have 5 packages of 1 GB, each user STILL only downloads 1 GB.

Do YOU want to pay for the extra bandwidth? Do you want the game maker to pay for it? If they pay for it, then they WILL charge YOU the difference.

So to summarize, the effect of joined multi-arch binaries:
1) Wasted disk space.
2) Wasted network bandwidth.
And that is *ALL*.