Ryan Gordon Brings Universal Binaries To Linux

[droidhacker]

Who cares for PPC except from few old-fashion Apple users? This binary format can be useful for binaries that support x86, x86_64 and maybe future arm platforms since I believe they will be in handy in the near future if Android succeeds finally

If?
Finally?
Its already blowing the top off of palm, and making apple sweat bullets... AND, the fun has barely *just started*.

http://wiseandroid.com/NewsItem.aspx?category=News&path=October&itemid=14

Android: one year old today.

BTW: that list is *far* from accurate (its got a few dupes, a few DOA, and there's a slew of things missing), but does give the idea.

[Svartalf]

+1

PPC? Thanks, I don't use it and I probably never will.

Heh... Think X86/X86_64/ARM and you might be closer to what we're likely to see. Having said this, I'm unsure that he'll get people to sign off on them. It'd make delivery a bit easier for commercial devs- but it'd be a nightmare in terms of testing the whole mess.

[Svartalf]

If?
Finally?
Its already blowing the top off of palm, and making apple sweat bullets... AND, the fun has barely *just started*.

No kidding. The fun is about to begin in about one month's time.

It remains to be seen if Verizon ditched at least part of their control fetish or not, but if the ads are close to the truth on the Droid site, they will have ditched it enough to make it compelling to code for that platform- however, I doubt that FatELF binaries, if they did take off, would be something you'd find in the AppStore there...

[droidhacker]

for people that don't know what arch they run.

Huh? When all else fails, read the label on the front of the INSTALL DISK. DUH!

And this is linux,
You could always ask the user to run 'arch'.

For that matter, due to the propensity for downloadable installers, how about this; use a small installer frontend that does something like this;
#!/bin/bash
...
...
wget http://whatever/download/getfile?arch=`arch` -O installfile
...
#extract and install that file that was just downloaded.


Yeah, I know, you like it to download the WHOLE THING, so for *advanced* users, add in a "-d" parameter that just downloads the file, and a "-l installfile" parameter that installs a previously downloaded install file.

[Vadi]

Wonderful projects for the human Linux user.

Expert users compile everything on their own anyway.

[alazyworkaholic]

I'm happy to see this. Storage is cheap & the value of the convenience of having a single file can't be underestimated. I have a netbook (32 bit only) & will probably start using 64 on my desktop with karmic. This makes it necessary for me to keep two sets of files around when a package isn't available from the repositories. (acetone iso manager, frostwire, & a few others). lf I understood correctly & adding another arch multiplies the original size by ~1.2 or 1.3 rather than doubling it. It would be wonderful to be able to download files & updates to one computer to then pass them to another over a home nework instead of having to download two completely different sets. (I have a 100 kbps connection so you can imagine how much fun it is leaving the desktop on all night to update or download a few packages, then the netbook on all the next night! By the way, anyone seen a how to about downloading updates & packages first from one local computer & then look to the Internet repos to conserve my precious bandwidth?) Basically convenience is valuble & tar vs deb vs rpm vs run vs ... scares noobs.

[kraftman]

Heh... Think X86/X86_64/ARM and you might be closer to what we're likely to see.

This sounds much more interesting

[larva]

FatELF: There's Just More to Love

I don't understand what the fuss is. I've noticed that the size of most of my installed packages are not dominated by the size of the binary. Even multiplying it 2-3 times wouldn't change that.

The fact is the primary benefits aren't designed for distros. Many distros have long since figured out how to handle multiple archs. They don't need FatELF.

FatELF is for two kinds of people: Proprietary software developers and naieve end-users. Despite sentiments expressed by the ideological fringes, these are valuable people.

FatELF toolchains would simplify proprietary development. Small and large proprietary software developers simply cannot sustain funding for the resources to match what the community has. So they tend to focus, as Ryan explains, on infrequent releases for small numbers of architectures and distributions.

I'm sure end-users would love to be able download a single Flash/whatnot plugin binary rather than have to wander through confusing web UIs. Video codecs are also a pain. Also, with FatELF it may someday be possible to simply copy a program from one machine to another without having to care about the arch (needs OS X style bundles though).

If space is really a priority the "bloat" can be stripped thanks to the simplicity of the FatELF format. It doesn't matter if it's stripped before packaging or after package installation.

FatELF can benefit non-proprietary developers too, but the benefits aren't as compelling. Assuming toolchains evolve sufficiently, it may be possible to avoid crosstool and have a single toolchain capable of building FatELF binaries for all arches. Then there may be opportunities to consolidate formerly-separate build, package, and distribution mirroring systems.

Also, the binaries may compress very well. Given that they probably share most of their strings and, if the data layouts are the same or similar, then the data segments might also have alot of common byte sequences. Text sections probably wouldn't share the same byte sequence distribution so wouldn't compress as well. Unless inlining is overused or debugging has been selected, my impression is the text sections tend to be pretty small.

Finally, even uncompressed and with multiple archs, the ELF binary for a given arch looks like its contiguous and aligned to a page boundary. This means only one arch of the FatELF needs to be mapped and the rest can be ignored -- so the size of the binary read from disk is virtually the same. The biggest cost is the potential addition of a disk seek. To avoid that I suspect it's possible to reorder the FatELF binaries (if not strip them) when the package is installed.

So to me it doesn't make much sense to complain about FatELF. If you want to spend your time complaining why not stick to a.out?

[drag]

Yes... people complaining about bloat are just not understanding what is going on.

Having fat binaries means that you add a few megs onto major programs, at most. The bulk of modern software is going to be images, documentation, and other things like that. The actual machine code is going to be relatively small.

So the only thing that it affects is download time and disk usage.. and that is only going to be a fraction of the total size.

This means that if you download a game, browser, or plugin, it should "just run" regardless of the CPU your actually using...

[Ant P.]

90% of the replies here are from people who obviously didn't RTFA.