Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ryan Gordon Ends FatELF Universal Binary Effort

Soulskill posted more than 4 years ago | from the that-was-quick dept.

Software 549

recoiledsnake writes "A few years after the Con Kolivas fiasco, the FatELF project to implement the 'universal binaries' feature for Linux that allows a single binary file to run on multiple hardware platforms has been grounded. Ryan C. Gordon, who has ported a number of popular games and game servers to Linux, has this to say: 'It looks like the Linux kernel maintainers are frowning on the FatELF patches. Some got the idea and disagreed, some didn't seem to hear what I was saying, and some showed up just to be rude.' The launch of the project was recently discussed here. The FatELF project page and FAQ are still up."

cancel ×

549 comments

Sorry! There are no comments related to the filter you selected.

fp (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29997452)

first post

He needs thicker skin (4, Insightful)

harmonise (1484057) | more than 4 years ago | (#29997484)

He needs thicker skin if he's going to deal with the LKML crowd. I wouldn't give up just because it's not merged into the official tree.

Re:He needs thicker skin (4, Funny)

omuls are tasty (1321759) | more than 4 years ago | (#29997516)

Heck, an elephant needs a thicker skin if he's going to deal with the LKLM crowd.

Re:He needs thicker skin (1)

Tubal-Cain (1289912) | more than 4 years ago | (#29997538)

Should we start making body armor from the hides of kernel developers?

Re:He needs thicker skin (4, Funny)

Darinbob (1142669) | more than 4 years ago | (#29997720)

Not a good idea, that armor would attract flames.

Re:He needs thicker skin (3, Funny)

oldspewey (1303305) | more than 4 years ago | (#29998258)

... and repel mates

Re:He needs thicker skin (1)

pak9rabid (1011935) | more than 4 years ago | (#29997530)

Exactly...given enough time, if enough people find fatELF binaries useful, they may just rethink its usefulness in the kernel source tree.

Re:He needs thicker skin (1)

Mystra_x64 (1108487) | more than 4 years ago | (#29997548)

Hopefully this will never happen.

Re:He needs thicker skin (1)

jedidiah (1196) | more than 4 years ago | (#29997652)

The problem with fixating on something like ELF for fatness is that it's just the tip of the iceberg.

There's much more to the question of whether or not something will run on an arbitrary copy of Linux than the CPU arch.

Same goes for an Apple fat binary really...

BS: "tip of the iceberg" (5, Informative)

tlambert (566799) | more than 4 years ago | (#29997988)

The problem with fixating on something like ELF for fatness is that it's just the tip of the iceberg.

There's much more to the question of whether or not something will run on an arbitrary copy of Linux than the CPU arch.

Why do you think one of the discriminators in a fat binary can't be a distribution identifier, such that there are fat slices for supporting Debian, RedHat, Ubuntu, etc., all from the dame binary file?

Or that they can't have different slices in the fat binary for Gnome vs. KDE, or desktop vs. Android, and so on?

Also, the arguments about disk space are specious; at least in the Mac OS X world, there is a utility called "lipo" which will pull apart a fat bnary into only the pieces you need/want to install. Typically you only install the actually fat binary on server systems, where the software has to be able to run on multiple client machines, and otherwise you run scripts to reclaim disk space (or in the case of an embedded device, you run them over the install image before you install them).

Same goes for an Apple fat binary really...

Obligatory disclaimer: I am the person who maintains the fat binary loader in the Mac OS X kernel.

-- Terry

Re:BS: "tip of the iceberg" (1)

Mystra_x64 (1108487) | more than 4 years ago | (#29998154)

Simple script can do anything required. There is no need to modify kernel and/or ELF.

Besides: bandwidth for servers and users.

Re:BS: "tip of the iceberg" (1)

icebraining (1313345) | more than 4 years ago | (#29998162)

Can you remind me again of the advantages of such fat binaries over a tar/deb/rpm file with multiple binaries? Thank you.

Re:He needs thicker skin (2, Insightful)

nxtw (866177) | more than 4 years ago | (#29998286)

There's much more to the question of whether or not something will run on an arbitrary copy of Linux than the CPU arch.

This issue would limit the usefulness of a fat ELF feature, but it seems this is a problem that should be solved regardless of the existence of fat ELF support.

Re:He needs thicker skin (1)

morgauxo (974071) | more than 4 years ago | (#29998078)

That or write their own implementation of the concept, put that in the official tree and obsolete years of hard work.

Re:He needs thicker skin (0, Troll)

BitZtream (692029) | more than 4 years ago | (#29997728)

Not really, he can just go peddle his warez to someone who is more open to ideas.

Why should anyone subject themselves to dealing with a bunch of assholes to help them make their stuff better?

Reminds me of my recent MythTV experience ...

I join the IRC channel for it, ask a question, lay out whats wrong, and then was told repeatedly that I had configured the server wrong and it wasn't accepting connections, even though I said repeatedly that I was able to connect to it from one client but not another so it was unlikely to be a server problem.

After trying to explain that I had read the wiki, the mailing lists and done a fair amount of googling and already seen the 3 suggestions I kept getting over and over again, I got to the point where I told them to go fuck themselves basically. At which one guy, who hadn't been there earlier listened long enough to ask for the debug output.

Turns out, low and behold, it was a combination of client configuration error and a bug in the mysql libs that caused it to hang and never report an error.

A day later, I've dumped MythTV and went back to WMC under Win7. I've lost a few features in the process, but it works on all my hardware and has yet to require me to deal with a bunch of jackasses who are too arrogant to be useful. (With WMC you deal with to ignorant to be useful instead)

Does anyone care what I run? Of course not, but they've lost potential developer support. Instead of porting my custom extensions to WMC over to work in a MythTV setup and sharing them, I'll just continue to make them work in WMC. I filed the bug on the way out the door so someone else can fix it, but overall the total loss will be on the MythTV end.

You don't get help by being a jackass to people, regardless of how much better than them you think you are. You see a lot of this in OSS software (not just Linux, as anyone who has dealt with Theo knows). I partially understand, they aren't getting paid, they don't have any motivation to hide their true colors. Well, at least any instant motivation. Turning people away is never a good thing. I would have been happy to donate to the project instead of buying more XBox 360s to use as extenders. Now I'll just get a couple more rather than re-using my existing PCs and donating to the project.

He doesn't need thicker skin, they need an attitude adjustment. Its a safe bet that he doesn't really care that much. He's obviously not a cluebie, he has some knowledge, and now they won't benefit. The problem isn't his.

Re:He needs thicker skin (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#29997904)

Fuck you, we don't need you or people like you, and you'll come crawling back when MS inevitably screws up your box. YOU'RE the one with the attitude problem. Maybe if you had read the debug log by yourself rather than show up in IRC whining about how something doesn't work you would have solved your issue by yourself. It's not our fault you're stupid and lazy.

Re:He needs thicker skin (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29998120)

Yeah, because some of us have lives and we're out getting pussy while you arrogant assholes are willing to spend days just getting the same fucking application to work on 4 different distros.

That's fine with me, you can do all the legwork. People like myself will be out in the sun staying fit. You know, Windows ain't bad. It'll run safely and reliably if you keep Linux dweebs' grubby, porn-addicted hands off of it.

That's why Linux weenies switched in the first place - their porn addictions required a much higher level of security. Those ham-handed hackers are willing to work hard for their porn because they don't get any pussy in real life. Fuck you, you elitist little snot-nosed assholes. Enjoy your basements and your greased-up Yoda dolls and your barely-functioning, constantly deadlocking half-ass Linux.

Re:He needs thicker skin (2, Interesting)

morgauxo (974071) | more than 4 years ago | (#29998220)

Maybe he could have done so, he does seem to have some sort of programming background. Maybe not if it's been mostly Windows stuff. If getting a program to work normally involves combing through log files then it's really still just a programmer's toy. That's sad considering the alternative (WMC) respects the copy flag.

It sounds like he was just trying to make it work. If it takes digging to that level just to get it running then there is a problem. I though Myth was supposed to be in a working state at this point? Was he trying to build the latest right out of source control? If he was just installing a stable release with typical options then I think it's pretty reasonable to expect that anything which could go wrong would be too high level to need to go to a bug log.

I've given Myth a few tries myself (on Gentoo). It's the one thing I have yet to get to work. I see lots of people do have it working but it seems most have to resort to a live CD. I for one don't want to be stuck with a distro that was built with only Myth in mind. I want my machine I have already customized as I like it but with mythbackend running in the background.

Re:He needs thicker skin (0, Redundant)

Jaysyn (203771) | more than 4 years ago | (#29998394)

Way to prove his point.

I sympathize with you. (1)

Zombie Ryushu (803103) | more than 4 years ago | (#29998132)

That is a tragic experience. The thing is, MythTV is in shambles and I know it. Its not easy to configure or use. I still support MythTV. But there is room for improvement. There are other Linux competitors to Myth out there. Support them if need be. But the truth is the Linux movement needs every warm body it can to fight Microsoft.

Re:I sympathize with you. (4, Insightful)

ckaminski (82854) | more than 4 years ago | (#29998272)

<quote>
But the truth is the Linux movement needs every warm body it can to fight Microsoft.
</quote>

THAT is the problem. Stop trying to FIGHT Microsoft. Start making better software. Innovation, something so tremendously better they start copying YOU.

Vis-a-vis AMD and Intel and x86_64 and VT extensions.

Except software has zero marginal cost, so once you take the lead, it'll take a serious fuckup, and not just money to lose it.

Re:I sympathize with you. (0)

Anonymous Coward | more than 4 years ago | (#29998362)

But the truth is the Linux movement needs every warm body it can to fight Microsoft.

That's the part I hate about the OSS movement. Why does it have to be about fighting Microsoft? Why can't it be about developing good and useful software?

Re:He needs thicker skin (1)

flaming error (1041742) | more than 4 years ago | (#29998236)

> they need an attitude adjustment

Yup. I told them to fix their attitudes too.

Some got the idea but declined.
Some didn't seem to hear what I was saying.
Some appeared just to be rude.

Re:He needs thicker skin (1, Insightful)

cheesybagel (670288) | more than 4 years ago | (#29998262)

So one of the developers in the project tracked and found the issue online for free and you think their support sucks? I won't even share my issues with a certain piece of closed-source software here, which required going through many layers of corporate bureaucracy to fix.

I once found a bug in DOSBox which none of the developers cared about. l debugged and read the code myself, made a patch that "fixed" the bug (although my fix made bugs elsewhere), posted it and screenshots showing the game working when it didn't even boot before. This was enough for a couple of people to start talking about it. Next release of DOSBox came guess what, the bug was fixed. Properly.

With closed-source software you are truly stuck because whoever developed the software must necessarily fix it. You cannot fix it yourself even if you could and wanted to. How is that better?

Re:He needs thicker skin (1)

hairyfeet (841228) | more than 4 years ago | (#29998366)

Hey I might be able to point you in the right direction on the x360s, if you don't mind getting up early or going to Wally World. This Saturday Nov7 at 8AM they are having a deal on the x360 arcade as part of their "pre Black Friday" warmup, where you get the arcade for $200, but you get a $100 gift cert.

So anyway I hope this little info helps. If you are using the x360s as media extenders the arcade should be perfect, and you can get 2 for $300 with that deal. You'll have to look up the Walmart Black Friday pages to see if there is a limit, but I don't recall there being one. Even if there is you'll still get the $100 on the first, which you can use on the second.

Re:He needs thicker skin (0)

Anonymous Coward | more than 4 years ago | (#29998402)

Who the fuck wants either MythTV or Windows Media Center? What the hell is wrong with just opening your video files in a media player? Why the fuck would anyone want to make their computer work like a TV? What is a media center anyway?

FatELF could quite easily have been some attempt to make everyone's Linux take twice as long to download and use twice as much disk space. Or perhaps the person who developed it just can't accept that it's totally useless. Maybe there is no giant conspiracy to ruin Linux by stuffing it full of useless crap, actually people are just morons.

Re:He needs thicker skin (1)

Mikkeles (698461) | more than 4 years ago | (#29997870)

He should have sent Theo in ;^)

Good riddance (4, Funny)

hansraj (458504) | more than 4 years ago | (#29997540)

I like my elves the way I like my tea: thin and exotic.. served while still hot.

Re:Good riddance (1)

jbeaupre (752124) | more than 4 years ago | (#29997616)

I like my elves like I like my coffee, ground up and kept in the freezer.

Re:Good riddance (2, Insightful)

maxume (22995) | more than 4 years ago | (#29997838)

That's terrible! They will quickly become dehydrated and lose flavor.

Re:Good riddance (0)

Anonymous Coward | more than 4 years ago | (#29998006)

Exxxactyl!

Re:Good riddance (1)

Nadaka (224565) | more than 4 years ago | (#29998182)

I like my elves like I like everything else, finely minced, baked with mushrooms and served in a legendary obsidian dining hall.

*elf meat biscuit*

Loosing is fun. Dwarf Fortress.

I don't believe it! (5, Funny)

smooth wombat (796938) | more than 4 years ago | (#29997546)

and some showed up just to be rude.

I would never have believed that people in the Linux community would show up at an event just to be rude. I've always heard such glowing praise about the Linux community. They're always there to help the new guy, willing to mentor those learning the "So simple a caveman can do it" operating system and break the monopoly of Microsoft once and for all.

His comments can't be correct. Everyone knows what fine, upstanding individuals the Linux community is.~

Re: whatever (1, Troll)

colinnwn (677715) | more than 4 years ago | (#29997620)

I don't agree with how most of the LKML handled it, but they are a different audience from the rest of the community, perhaps out of necessity, or maybe for the protection of us all. I wish I had troll points for you. Say hi to Mr. Ballmer for me while you are at it.

Re: whatever (1, Funny)

Yvan256 (722131) | more than 4 years ago | (#29997974)

There you go, someone listened and gave you that troll point that you asked for!

Re:I don't believe it! (0)

Anonymous Coward | more than 4 years ago | (#29997642)

Not sure if serious.

Re:I don't believe it! (1, Funny)

Anonymous Coward | more than 4 years ago | (#29997758)

I agree. In fact, I'll even propose an improvement:
Lets split the fat binary into separate files, so you don't need to download code that you will never use. Maybe someone could invent a software manager that automatically downloads the version that best matches your operating system?

Re:I don't believe it! (1)

tokul (682258) | more than 4 years ago | (#29998252)

I would never have believed that people in the Linux community would show up at an event just to be rude.
..
His comments can't be correct. Everyone knows what fine, upstanding individuals the Linux community is.~

Programmers are arrogant. Comes with territory.
It does not depend on OS.

Whaaaaaaa ?? DISCONTENT IN THE RANKS ?? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29997566)

I thought freetards all just get along ?? What is the free as in beer and as in whatever else there is going to do without this fat, as in R.M.S., binary thing ?? Another case of, ain't gonna happen cause they pissed on my parade event in freetard country. And I am not a troll, I am a Mac !!

Re:Whaaaaaaa ?? DISCONTENT IN THE RANKS ?? (1)

morgauxo (974071) | more than 4 years ago | (#29998278)

That happens from time to time when you are allowed to have separate brains. Pretty alien concept for Mac fanboys I'm sure.

Here are a couple of fatelves (2, Funny)

captnbmoore (911895) | more than 4 years ago | (#29997582)

Fat elves [jojosagency.com.au]

Solution in search of a problem (4, Insightful)

amorsen (7485) | more than 4 years ago | (#29997606)

The 32-bit vs. 64-bit split is handled pretty well on Linux (well, Debian drug its heels a bit on multiarch handling in packages, but even they seem to be getting with the programme).

Real multi-arch could be useful, but the number of arches on Linux is just too overwhelming. To get somewhat decent coverage for Linux binaries, they'd have to run on x86, ARM, and PPC. Plus possibly MIPS, SPARC, and Itanium. Most of those in 32-bit and 64-bit flavours. Those elves are going to be very fat indeed.

Fat Elves Sue Keebler (2, Funny)

Dareth (47614) | more than 4 years ago | (#29998218)

It has been reported that a law suit was filed against Keebler corporation by a group of fat elves.

Their spokes person was quoted as saying,"It's *mmmm* their fault, these cookies *numnumnum* are just too good!".

Re:Solution in search of a problem (4, Insightful)

nxtw (866177) | more than 4 years ago | (#29998348)

The 32-bit vs. 64-bit split is handled pretty well on Linux (well, Debian drug its heels a bit on multiarch handling in packages, but even they seem to be getting with the programme).

I disagree. Solaris and Mac OS X are the only operating systems I would say handle it well.

OS X 10.6 includes i386 and x86_64 versions of almost everything. By default it runs the x86_64 versions on compatible CPUs and compiles software as x86_64. It runs the i386 kernel by default, but the OS X i386 kernel is capable of running 64 bit processes.

One can reuse the same OS X installation from a system with a 64-bit CPU on a system with a 32-bit CPU.

Solaris includes 32-bit binaries for most applications but includes 32- and 64-bit libraries. It includes 32- and 64-bit kernels as well, all in the same installation media.

Wait, what does Con Kolivas have to do with this? (4, Insightful)

vadim_t (324782) | more than 4 years ago | (#29997634)

I don't get the point in bringing it up.

Things get rejected from the kernel all the time -- because not all things are good, useful, well coded, or solve a problem that needs solving. It's not new in any way.

This in particular seems like a solution in search of a problem to me. Especially since on a 64 bit distro pretty much everything, with very few exceptions is 64 bit. In fact I don't think 64 bit distributions contain any 32 bit software except for closed source that can't be ported, and compatibility libraries for any applications the user would like to install manually. So to me there doesn't seem to be a point to try to solve a problem that exists less and less as the time passes and proprietary vendors make 64 bit versions of their programs.

Re:Wait, what does Con Kolivas have to do with thi (1, Insightful)

BitZtream (692029) | more than 4 years ago | (#29997832)

Things get rejected from the kernel all the time -- because not all things are good, useful, well coded, or solve a problem that needs solving. It's not new in any way.

Except this seems to be the only place that doesn't acknowledge the usefulness of fat binaries.

Windows has had them since DOS, although no one uses them. OS X has them, FBSD has talk about them and isn't flatly rejecting the idea.

I've seen many features in my career that seemed pointless, tabbed browsing for instance, my OS already supports tabs of sorts on task bar. Then ... once you have them and use them for a while you come back and say 'hey, thats a really good idea'.

People who are anti-closed source need to just go hide in a cave somewhere and talk about when the revolution is going to come. There will be a place for closed source and open source, side by side for the foreseeable feature. Trying to deny that is only hurting yourself.

Re:Wait, what does Con Kolivas have to do with thi (1)

nxtw (866177) | more than 4 years ago | (#29998196)

Windows has had them since DOS, although no one uses them.

Is it possible to have a single Windows executable with both x86-64 and i386 code?

Re:Wait, what does Con Kolivas have to do with thi (1)

vadim_t (324782) | more than 4 years ago | (#29998216)

Except this seems to be the only place that doesn't acknowledge the usefulness of fat binaries.

Well, please explain what would the usefulness be.

Especially when the two architectures most people care about is i386 and amd64, and the former works perfectly fine on the later.

Windows has had them since DOS, although no one uses them.

That would seem to point to that the idea wasn't really useful in that case

OS X has them

But it went through a considerable architecture shift from one CPU to another that was incompatible. It isn't the case with amd64, you can ship an i386 binary and it'll work.

Then ... once you have them and use them for a while you come back and say 'hey, thats a really good idea'.

Well, please explain, what benefit do you see coming out from this?

People who are anti-closed source need to just go hide in a cave somewhere and talk about when the revolution is going to come. There will be a place for closed source and open source, side by side for the foreseeable feature. Trying to deny that is only hurting yourself.

All distributions I know of ship 32 bit libraries. The developer can just ship an i386 binary, and it'll work. So what does this improve?

Re:Wait, what does Con Kolivas have to do with thi (1, Troll)

icebraining (1313345) | more than 4 years ago | (#29998396)

Tell me how an Apple developer can run a server allowing the client to select the program and it'll download and install the correct version, like Debian repositories. That problem has already been solved, and the solution is better (it also gives you plenty of other features).

Oh, and closed-source companies can have their own repositories too. Example: http://download.skype.com/linux/repos/debian/ [skype.com]

Re:Wait, what does Con Kolivas have to do with thi (4, Interesting)

Auroch (1403671) | more than 4 years ago | (#29997866)

This in particular seems like a solution in search of a problem to me. Especially since on a 64 bit distro pretty much everything, with very few exceptions is 64 bit. In fact I don't think 64 bit distributions contain any 32 bit software except for closed source that can't be ported, and compatibility libraries for any applications the user would like to install manually. So to me there doesn't seem to be a point to try to solve a problem that exists less and less as the time passes and proprietary vendors make 64 bit versions of their programs.

EXACTLY! We don't want choice, we want it to just work! Damnit, force people to do things the way they ought to do them, don't give them choice, they'll just screw it up.

Especially when that choice makes things EASY!

Re:Wait, what does Con Kolivas have to do with thi (0, Flamebait)

idontgno (624372) | more than 4 years ago | (#29998084)

Steve Jobs, is that you?

Re:Wait, what does Con Kolivas have to do with thi (3, Insightful)

cheesybagel (670288) | more than 4 years ago | (#29997878)

It just shows Ryan isn't used to contributing free software to someone else's project. I once had to wait months before I got my code accepted into a free software project and it wasn't the kernel. If the maintainers add every submission to a project, it will end up in an unstable, unmaintainable mess. Code can last a long time and someone will have to maintain the code even after he's lost interest in it. I am especially leery of code that touches a lot of difference places at the same time, as is undoubtedly the case here.

Re:Wait, what does Con Kolivas have to do with thi (1)

yupa (751893) | more than 4 years ago | (#29998066)

Especially since on a 64 bit distro pretty much everything, with very few exceptions is 64 bit.
You should look at ppc and sparc distro : pretty much everything is ... 32 bit. That because 32bit is more efficiant than 64 bits (less code/data size). But on x86 that's different because that's on the same arch at all (not the same register/feature, ...).

Re:Wait, what does Con Kolivas have to do with thi (1)

coolsnowmen (695297) | more than 4 years ago | (#29998416)

If what you said was correct (which it is not), then why would intel/amd stop making 32 bit chips, as they are concerned only with processor efficiencies (and not RAM).

32bit is only more memory efficient than 64bit. It is not computationally so.

Re:Wait, what does Con Kolivas have to do with thi (1)

ejtttje (673126) | more than 4 years ago | (#29998090)

There are places this would be very useful to have. Anytime we're distributing binaries to users, hosting binaries on a network file share, or carrying portable media, it's a big pain in the butt to maintain completely separate architecture trees. In some cases it wastes a lot of space too if there's significant data files along with the executables, because we generally wind up replicating that in each arch install tree.

I've definitely appreciated OS X's universal binaries in the past, it's a shame to lose an opportunity for having that on Linux. Guess I'm not going to see bundled, versioned libraries like OS X Frameworks anytime either, sigh.

Re:Wait, what does Con Kolivas have to do with thi (1)

vadim_t (324782) | more than 4 years ago | (#29998356)

There are places this would be very useful to have. Anytime we're distributing binaries to users, hosting binaries on a network file share, or carrying portable media, it's a big pain in the butt to maintain completely separate architecture trees. In some cases it wastes a lot of space too if there's significant data files along with the executables, because we generally wind up replicating that in each arch install tree.

If your architectures are i386 and amd64 then you can just ship i386 and not bother with this at all.

If you're shipping something like Linux PPC or Sparc binaries, you're very, very unusual. You could also ship a shell script that runs the right binary, which may not be as cool, but should work just as well.

Re:Wait, what does Con Kolivas have to do with thi (1)

morgauxo (974071) | more than 4 years ago | (#29998312)

I don't have a 64 bit system. I do have multiple ARM devices and 32 bit systems.

Rude? (-1, Troll)

Profane MuthaFucka (574406) | more than 4 years ago | (#29997648)

What a pussy. Those guys were tough, not rude.

You want an example of rude? If I wanted a fat executable I would put my COCK into it. Now fuck off.

See? The LKML guys did not say anything like that. Therefore, we're not impressed by your crying.

Re:Rude? (0, Offtopic)

Yvan256 (722131) | more than 4 years ago | (#29998028)

Wow, you're a really profane motherfu...

oh wait.

rude (2, Insightful)

QuietLagoon (813062) | more than 4 years ago | (#29997678)

...some showed up just to be rude...

.
Oh well, so goes it with parts of the Linux culture.

Re:rude (1)

Ritz_Just_Ritz (883997) | more than 4 years ago | (#29997858)

Oh well, so goes it with parts of the Linux culture.

Coulda been worse. He could have been trying to get something folded in to the OpenBSD kernel. Theo makes those surly Linux kernel developers look like Miss Congeniality. :)

Kind of broken by design (3, Insightful)

bcmm (768152) | more than 4 years ago | (#29997686)

This idea is kind of broken for Linux. On MacOS, with 2 architectures, it makes some sense, since the actual executable code is not huge compared to data. On Linux, withe a couple of dozen architectures, executable code *is* going to start to take relevant amounts of space, and the effort involved in preparing them will be nontrivial. If this system were adopted, virtually no binaries would be made to support all available architectures, meaning that anyone not on x86 (32 bit) would need to check what archs a binary supported before downloading it, which is about as difficult as choosing which one to download would've been.

Game's over, quit holding up the bus. (3, Insightful)

argent (18001) | more than 4 years ago | (#29997850)

On Linux, withe a couple of dozen architectures,

Kind of, but not really. No more than there are four architectures (PPC, ARM, X86, X86_64) for OS X. There's two architectures for Linux that actually matter, and they're the same two that run Snow Leopard. X86 and X86_64.

I can see why people are going to get up in arms about this. I've been as big a RISC booster as anyone, I think Apple gave up on PPC too soon, and I'm still bitter about Alpha, but that game's over. 32-bit and 64-bit Intel architectures are what matter, and those are the ones that almost all binaries will work for. I'm not running YDL any more, and neither are you. Game's over, instruction sets lost to marketing. The game's over, the fat lady's sung, picked up her paycheck, and gone home to watch House on her Tivo. Give it up and quit holding up the bus.

Re:Game's over, quit holding up the bus. (1)

FlyingBishop (1293238) | more than 4 years ago | (#29998060)

Palm WebOS, Google Android, and Maemo are three ready examples of mainstream products that run Linux on ARM. More are on the way. ARM is a big deal for Linux.

Isn't someone going to ask ... (0, Flamebait)

oGMo (379) | more than 4 years ago | (#29997856)

...who the hell distributes Linux binaries anyway? On OSX, most software you get is a binary. As you said, 2 platforms (one dying), universal binaries sortof make sense just so vendors can put things in a single box, use a single icon, and not care about writing detection code for something so fundamental.

On Linux the main binaries you get are either from your distribution (which already knows all about your architecture, so why bother), or maybe the occasional third party (nvidia? who already maintains all this separately). Maintaining N binaries is, as you said, difficult if not impossible for Linux. As is distributing binaries anyway.

As a poster above said: solution in search of a problem.

Re:Isn't someone going to ask ... (4, Interesting)

Joe Mucchiello (1030) | more than 4 years ago | (#29998012)

Commercial Games. That's who.

Re:Kind of broken by design (2, Interesting)

ceoyoyo (59147) | more than 4 years ago | (#29997982)

True, but the ability to handle such things can come in handy. As an example, suppose you've got a setup where you're running apps off a server. You've got several different hardware platforms going, but you want your users to be able to double click the server hosted apps without worrying about picking the right one for the computer they happen to be sitting at. A fat binary is pretty much the only way to solve that problem.

Re:Kind of broken by design (0)

Anonymous Coward | more than 4 years ago | (#29997998)

Back in the OpenStep day, some fat executables were 68000, x86, sparc, and pa-risc.

Also consider x64 is x64 (sure, there are amd/intel differences, but gcc doesn't go there). But a 386 is very different than a core 2 duo running in 32-bit mode. x86 binaries are often targetted at the 486, which eliminates a lot of new opcodes and goodies in the pentium and beyond.

Re:Kind of broken by design (1)

Daniel_Staal (609844) | more than 4 years ago | (#29998226)

Just wanted to say that MacOS for a while there supported 4 architectures: i386 and PPC, both in 32 and 64 bit. Very few apps actually shipped with all four, since there were also fallbacks in place. (A few high-end apps did, but only a few.)

And even then there were a half-dozen utilities out there for 'cleaning' the architectures you didn't need out of the files. Which could get back a fair amount of disk space.

Re:Kind of broken by design (1)

volsung (378) | more than 4 years ago | (#29998372)

Minor nit: Mac OS X (until Snow Leopard) had to deal with 4 architectures $ file /usr/lib/libbz2.dylib /usr/lib/libbz2.dylib: Mach-O universal binary with 4 architectures /usr/lib/libbz2.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/lib/libbz2.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64 /usr/lib/libbz2.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/lib/libbz2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

Re:Kind of broken by design (1)

volsung (378) | more than 4 years ago | (#29998406)

Gah, total format failure. Forgot I was in HTML mode. You get the idea, though.

Story of binary compatibility is short and tragic (5, Insightful)

Gopal.V (532678) | more than 4 years ago | (#29997696)

In the entire forked-up mess of the unix tree, there was only one thing that anybody & everybody cared about - source compatibilty. C99, POSIX, SuS v3, so many ways you could ensure that your code would compile everywhere, with whatever compiler was popular that week. For a good part of 4 years, I worked on portable.net, which had a support/ directory full of ifdefs and a configure script full of AC_DEFINEs. It worked nearly everywhere too.

Binary compatibility never took off because there is so little stuff that can be shared between binary platforms. Sure, the same file could run on multiple archs, but in reality that is no different from a zip file with six binaries in them. Indeed, it needed someone to build 'em all in one place to actually end up with one of these. Which is actually more effort than actually letting each distro arch-maintainer do a build whenever they please. OS X build tools ship with the right cross-compilers in XCode and they have more of a monoculture in library versions, looking backwards.

Attempting this in a world where even an x86 binary wouldn't work on all x86-linux-pc boxes (static linking, yeah...yeah), is somehow a solution with no real problem attached. Unless you can make the default build-package workflow do this automatically, this simple step means a hell of a lot of work for the guy doing the build.

And that's just the problems with getting a universal binary. Further problems await as you try to run the created binaries ... I like the idea and the fact that the guy is talking with his patches. But colour me uninterested in this particular problem he's trying to solve. If he manages to convince me that it's a real advantage over 4 binaries that I pick & choose to download, hell ... I'll change my opinion so quickly, it'll leave you spinning.

Re:Story of binary compatibility is short and trag (2, Insightful)

BitZtream (692029) | more than 4 years ago | (#29997952)

The problem isn't that its not possible, its that its hard. Your argument is that since its hard now, since the tools aren't ready for it, it shouldn't be done ...

Sounds pretty silly to me.

It would be hard to start from scratch and write a modern OS ... but that is indeed what Linux is.

If you never take the effort to make the hard easier it will remain hard. Changing from single threaded to multithreaded is hard, do you think we should not do that either, because the tools to do it don't make it a cake walk RIGHT NOW?

Seems a silly way to look at things to me. Fortunately other people made multithreading work on other platforms long before x86 could really do it properly, which made it easier to do on x86. Imagine if Linus said 'multithreading in an OS is hard on x86, you have to use timer interrupts and blah blah blah, I'm not doing it' back in the 90s ...

For you, it might not be any different, but you won't know until you give it a try.

For grandma who has a netbook running an ARM processor, and a desktop or laptop running a x86 processor, its probably a little different, don't you think? Do you want to remain in this hole forever, or do you want to get out and catch up to the rest of the world?

Re:Story of binary compatibility is short and trag (3, Insightful)

Anonymous Coward | more than 4 years ago | (#29998142)

For grandma who has a netbook running an ARM processor, and a desktop or laptop running a x86 processor, its probably a little different, don't you think?

No because a package manager makes it easy to install software for the current arch. Even grandma doesn't benefit from having x86, AMD64 and arm binaries in a single package, much less from some random untrusted binary she downloaded from the internet.

Re:Story of binary compatibility is short and trag (1)

adisakp (705706) | more than 4 years ago | (#29998114)

In the entire forked-up mess of the unix tree, there was only one thing that anybody & everybody cared about - source compatibilty. C99, POSIX, SuS v3, so many ways you could ensure that your code would compile everywhere, with whatever compiler was popular that week.

This guy worked in the closed-source world of video games where it's often not even legal to share your source code (due to middle-ware licensing and trade secrets) and even when it is legal, it's often not feasible for business or gameplay reasons (competitive coding advantage, preventing cheating hacks, disallowing "free content" mods, etc). It's exactly this reason that high-end cutting-edge games and other closed-source software will NEVER be viable on Linux unless there are major changes to the entire model of gaming development.

Re:Story of binary compatibility is short and trag (2, Insightful)

kill-1 (36256) | more than 4 years ago | (#29998338)

But the lack of universal binaries is not the reason why it's hard to release closed source software on Linux.

Re:Story of binary compatibility is short and trag (0)

Anonymous Coward | more than 4 years ago | (#29998124)

I understand the problem they are trying to solve. I ran into it myself. Downloaded a 64 bit x86 distro. For my 32 bit computer. However, if I had spent like 2 seconds reading the page I would have realized my error 4 hours earlier...

The reality is if you are distributing the source code 'fat' binaries do not make a lot of sense. A distro should be lowest common denominator. Then in the background automatically recompile the code for the current computer with optimizations cranked out for it. Now that is an interesting project... Or do like the apple/.net guys and JIT it.

Re:Story of binary compatibility is short and trag (0)

Anonymous Coward | more than 4 years ago | (#29998310)

Think IT guy who works on fifteen different architectures, has a "universal" USB stick, and walks up to a random guy in his office without having to figure out what platform the random guy is on in order to fix his problem. Do you think /he/ would like this?

If you Linux folks out there want broader acceptance, you have to recognize that your own forking across architecture, distribution, patch level, ABI compatibility, etc., just isn't cutting the mustard with many larger businesses. Those that do, you will notice, generally standardize on a single platform (distro, arch, etc.), and are just as subject to vendor lock-in as anyone running Microsoft is, if only because of support costs. Those minor differences in how various distros do package management are huge differences to IT departments who already don't have the bandwidth to meet their customer (business) needs.

That IT guy I mentioned above doesn't want to take the time to compile that source code or find the right USB stick for the guy's laptop, he just wants it to /work/.

Structure should be at the filesystem level (3, Interesting)

spitzak (4019) | more than 4 years ago | (#29997808)

My objection is that any such hierarchy of data could be stored as files.

Linux needs tools so that a directory can be manipulated as a file more easily. For instance cp/mv/etc should pretty much act like -r/-a is on all the time, and such recursive operations should be provided by libc and the kernel by default. Then programs are free to treat any point in the hierarchy as a "file". A fat binary would just be a bunch of binaries stuck in the same directory, and you would run it by exec of the directory itself. Also need filesystems designed for huge numbers of very small files and to make such manipulations efficient.

We need the tools to be advanced into the next century. Not use the workarounds of the previous ones as currently practiced on Unix and Windows.

a better idea.. (4, Interesting)

Eravnrekaree (467752) | more than 4 years ago | (#29997842)

Fatelf was never really a great idea in my opinion. Putting two binaries in a file is not a really good way to solve the problem as there are many more variations of CpU type including all of the x86 variation than one or two. it would be a better idea to do something similar to the AS/400, include, an intermediate form in the file, such as a syntax tree, convert it to native at runtime on the users system, and then store the native code inside the file next to the intermediate code. if the binary is moved to a new system, the native code can be regenerated again from the intermediate code. This does not even requite kernel support, the front of the file put shell code to call the code generator installed on the system, and generate the native code, and then run it. This way, things like various x86 extensions can also be supported and so on.

Re:a better idea.. (3, Insightful)

idontgno (624372) | more than 4 years ago | (#29998228)

So you're advocating Java?

Fat Elf? Nah, Porky Gnome is better.. (0, Offtopic)

phonewebcam (446772) | more than 4 years ago | (#29997864)

Oh sorry, thought were were talking funky distro names.

Re:Fat Elf? Nah, Porky Gnome is better.. (0)

Anonymous Coward | more than 4 years ago | (#29998204)

This post would be quite funny if it wasn't so actually feasible !

Isn't that what Java is supposed to do? (0, Redundant)

Anonymous Coward | more than 4 years ago | (#29997896)

Why have universal binaries when you have Java to do that? To do that at the binary level seems like it's pretty unnecessary. If you want performance, write it directly for that platform, and if you want universal accessibility, write it in Java. If he's doing it for his own personal enjoyment, that's cool, but if he thinks he's doing something useful, he's sorely wrong.

If I wanted to write in Java, I guess... (1)

argent (18001) | more than 4 years ago | (#29998016)

Why have universal binaries when you have Java to do that?

If I don't care about performance I can already write in Perl, Awk, Python, Tcl, or something. Why do I want to put up with Java?

I would LOVE to be able to remove all the "if `uname -cokebottle` matches "[xX]86" pick this RPM else pick that RPM" code from my installers. OK, that still leaves a fair amount of packaging hell unfixed but every little bit helps.

C Byte Code (2, Funny)

Midnight Thunder (17205) | more than 4 years ago | (#29998138)

If I don't care about performance I can already write in Perl, Awk, Python, Tcl, or something. Why do I want to put up with Java?

Well maybe what we could use instead in C byte code, or some other form of byte code, and then have on the JIT low-level compilations.

My first reaction to FatELF was that it is a good idea, since it works on the Mac. After listening to the issues people bring up with the large selection of CPU architectures I can understand this issue. On the other hand, why not allow ELF to support multiple architectures and let the 'market' decide if they want it? In a worst case scenario, it is just minor over-head that doesn't really impact anything.

The wrong Solution to the problem. (1)

Zombie Ryushu (803103) | more than 4 years ago | (#29997978)

FatELF was the wrong solution to the problem. In the Linux community, we do have a cross distribution application issue. But its one of pure stubbornness.

What do I mean? Suse has its way of setting up RPMs, Mandriva has its, RedHat (Fedora) has its. The three big names in RPM all fight each other over stupid things like RPM Macros, when RPMs are all 95% the same. We can't decide what to classify anything, so we fight over stuff like Amusements/Arcade vs. Games/Arcade. To some degree the same issue exists between mainline Ubuntu and Debian. Then we have the wonderful: I refuse to use DEB or RPM. e.g. Gentoo, Slackware.

We have propaganda circulating that RPM is proprietary. We have application makers who provide a binary installer for the Windows platform, yet hand Linux users a completely unpackaged BZ2 Type Tarball and say "Good luck!"

It should be policy that application makers UPSTREAM should provide an Source RPM AND a Source DEB.

It should be the case that I should be able to install any RedHat Fedora package, or any Suse Package on my Mandriva box. The people who make these decisions should be locked in a room together until they can come to a consensus how to solve this dispute. The same should be done on the DEB Side. I'm tired of having to take Suse or Fedora Packages and "converting" them by hand to make them acceptable and vice versa. This headache can be resolved if we all sit down and play nice together.

Re:The wrong Solution to the problem. (0)

Anonymous Coward | more than 4 years ago | (#29998158)

Not related to your point, but who says you can't use other package managers on Gentoo? Sure, its got its own better package manager, but it is the distro of choice for good reason.

You want people to quit whining about RPM? (1)

argent (18001) | more than 4 years ago | (#29998174)

We have application makers who provide a binary installer for the Windows platform, yet hand Linux users a completely unpackaged BZ2 Type Tarball and say "Good luck!"

That's because you don't have to descend into the hell that is rpmbuild, which was a pile of rotting dingo fetuses ten years ago and hasn't gotten one bit better since.

It's long past time that they gave up that ghastly binary blob and defined a new "rpmx" format, that would look kind of like this:

A gzipped or bzipped tarball, containing:

1. a directory "common", containing roughly what you currently get from rpm2cpio.
2. a file "common.files", containing processed and massaged %files
3. a file "common.pre", containing %pre
4. a file "common.post", containing %post ... etc
N. a directory "i386" and "i386.files" etc, containing the platform specific x86 stuff
N+1. same for "x86_64".

No weird binary format. No spec file full of a decade and a half of broken historical cruft. No requirement that you set up a chrooted environment to be sure you've got a clean environment for building the frigging RPM. Build it in perl or your scripting language of choice (even with a Makefile and shell scripts if you're old-school).

Re:You want people to quit whining about RPM? (0)

Anonymous Coward | more than 4 years ago | (#29998306)

(even with a Makefile and shell scripts if you're old-school).

Are makefiles and shell scripts considered "old school" nowadays? Oh dear...

Re:The wrong Solution to the problem. (1)

morgauxo (974071) | more than 4 years ago | (#29998400)

OK,

I really don't care as I use ebuilds. I wonder though, wouldn't the logical conclusion of your argument be to get rid of one of either rpm or deb and standardize on the other?

Actually come to think of it... if that happened, if binary packages were run-anywhere I MIGHT not even use ebuilds anymore. Hmm... Of course, there are so many choices to be made at compile time. I realize most of the optimization is not worth an adult's time but choosing optional features can be.

Petty fiefdoms and not invented here... (2, Interesting)

sbeckstead (555647) | more than 4 years ago | (#29998000)

Petty fiefdoms and not invented here syndrome will continue to torpedo any chance for a decent Linux on the desktop. Until Linux has a single binary and a universal installation strategy they will continue to be mostly harmless and largely irrelevant to the desktop market at large.

maybe the idea was just bad... (2, Insightful)

xianthax (963773) | more than 4 years ago | (#29998020)

maybe its just me but i see 0 advantages for an executable with multiple binaries.

shouldn't this all be handled by the package manager? isn't including all these binaries just jacking up download sizes for no gain?

a boot CD that can run on multiple archs is the only real use i see for this, but i would have to think there is a better way handle that than changing the fundamentals of executables and libraries.

maybe he received a less than warm reception from other devs because his idea provided virtually no benefit to the end user and required more work by the devs.

Universal binaries? How about universal installs (0)

Anonymous Coward | more than 4 years ago | (#29998082)

Instead of pushing for universal binaries (which means interpreted code across different CPU architectures), how about a universal installer (instead of RPM, DEB, .TAR.GZ)...and speeding up the install process instead of having to recompile every file?

Forget fat binaries for Linux (3, Funny)

Yvan256 (722131) | more than 4 years ago | (#29998092)

I want fat binaries for microcontrollers! Give me binaries that can run on PIC16F88, eZ80 and 68HC11!

There's nothing worst than having to replace a 0.50$ chip with another that cost 0.51$!

"That's a stupid idea" vs. "You are stupid" (2, Insightful)

wowbagger (69688) | more than 4 years ago | (#29998194)

The issue wasn't that there were lots of people saying "That's a stupid idea" or "That's a stupid implementation of an otherwise good idea."

The issue was lots of people saying "You are stupid."

There is a big difference.

I'd weighed in on this, because in the embedded systems I design this actually would have been useful - I have to support different processor types with what is, ideally, the same software load. (Just because MY embedded systems are much larger than some 4-bit microcontroller running 16K of code doesn't make them any less embedded.) People called ME stupid - not "That's a stupid design" or "That's a stupid reason to want FatELF", but "You are stupid."

Yes, developing a thick skin, so that when somebody says "That's a stupid idea" you realize that it is the IDEA, and not YOU, that they are criticizing, is important to any engineer.

But at the same time, saying to somebody "You are stupid" just because you don't like their idea, or don't see how it applies to your needs, is immature and unprofessional.

Why did he even talk to the kernel people? (2, Interesting)

pclminion (145572) | more than 4 years ago | (#29998232)

I don't understand what the kernel has to do with any of this. Fat binaries can be (almost) completely implemented at the userspace level by extending the dynamic loader (ld-linux.so). The way this would work is that the fat binary would have a boilerplate ELF header that contains just enough information to convince the kernel to load it and launch its interpreter program, which could piggyback on the standard dynamic loader. The fat binary interpretter would locate the correct architecture within the fat binary, map its ELF header into memory, then call out to the regular dynamic loader to finish the job. The only hitch is that a 64-bit kernel will refuse to load a 32-bit ELF, and vice-versa, so you would need an EXTREMELY minor patch to the kernel to allow it to happen. I mean like a one-liner.

You FAIL 1t... (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#29998314)

Bought the farm... To the original Achieve any of the Indecision and

Bloat-ELF (0)

Anonymous Coward | more than 4 years ago | (#29998330)

Someone should tell that guy to stop reinventing the wheel and use Java.
Virtual Machine? JIT? no... no... lets distribute EVERY architecture's native code in one big file instead.

His idea is idiotic and the kernel dev's had every right to call him out.
Having a thought-out idea doesn't entitle you to JACK CRAP

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?