Slashdot Mirror
Ryan Gordon Ends FatELF Universal Binary Effort
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."
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.~
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
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.
Quidquid latine dictum sit, altum videtur
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
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.
It's a shame you have to lie about this to make your "point". The person you claim wasn't there earlier actually was and had been asking for a debug dump the entire time. Bot logs are bad for liars.
> 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.
Woah woah woah. Back up here. I was there for those 2 IRC coonversations and you kept complaining when you were asked for details or to check your settings and the wiki. Repeatedly getting upset that someone was "assuming" you wear a newbie, refused to even consider the problem was with your configuration. You were hardly an innocent angel who was being picked on by some bullies.
And later you owned up that it was YOUR configuration issue and apologized and thanked the people in the channel.... and now days later you are using that to smere them and MythTV and OSS projects in general?
Really classy.
FYI for those reading this:
At the top of the following log is him admitting it was his mistake and saying thank you for the help.
http://mythtv.beirdo.ca/ircLog/channel/1/2009-10-28
Unfortunately I don't have the rest logged and the log bot was down for part of that day.
1. Ability: There is no guarantee that the people that kept giving you the same suggestions over and over know enough about the project to look into it more deeply, but you assume that they just weren't interested in helping. It's more likely that they know little more than you do about the project, but have a short list of the most commonly encountered problems and likely solutions. (kind of like tier 1 tech support, but free)
2. Affiliation: There is no guarantee that any of the people you talked to even have anything to do with the project other than lurking in their IRC channel. In my experience quite a few users lurk in channels of software they like, regardless of how capable they are of helping other people.
3. Incentive: I'm sure your problem was YOUR top priority at the time, but quite a few people on IRC lurk most of the time while they are doing other things, some of which are more important to them than trying to fix your problem. Also they have almost zero direct incentive to try to be nice to you.
4. Price: You mention this only to dismiss it, but seriously, this is a very valuable service that you are receiving for free, and you even had your quite obscure sounding problem diagnosed.
For-pay tech support either eliminates or hides these problems from the end-user, volunteer tech support doesn't have the resources to do this.
1. Ability is handled by tiering, if this were commercial software, you would have had to wait days to weeks in order to reach a level of tech support that would have been able to diagnose a bug in a sub-library not maintained by the business in question, and that's assuming you had paid enough for support to go that far for you (a hint, just buying a device will NOT get you this level of support). Instead you had an answer in under a day, and even a chance that the bug will get fixed based on your input.
2. Affiliation: This is the easy one, even if you do get support from someone outside a company you've purchased something from, you aren't going to blame the experience on the company, but rather on the individual. With open source however, if you find some random jerk that claims to be part of the project that proceeds to piss you off, you blame the project, not the individual. And regardless, unless you have a support contract with someone, it's just one person helping another.
3. Incentive: Paid services have a lockdown on this one too, tech support that doesn't maintain at least the barest facade of civility won't be working in tech support for much longer. (there are exceptions, but in general they will be more highly incentivized to pretend to like you, however as someone who worked in tech support for a while, I can guarantee you there is approximately zero chance that they will actually like you or care about your problem, which you have a pretty decent chance of with open source volunteers.)
At the end of the day, your problem was solved at no cost to yourself. Additionally I don't see any mention of your helpers even being rude, is this just an omission, or did you really just go into a roomful of random people and end up screaming at them (figuratively of course) because they couldn't help you with no direct provocation? If so, holy crap, you're a jerk.
Here's the log of the full conversation. We was hardly abused, and got persistent help over several hours which was patient and helpful, ultimately culminating in him realizing what he had done wrong and admitting to it.
Clearly, the myth IRC folk are at fault.
http://pastebin.com/m2cfd19dd