Ryan Gordon Ends FatELF Universal Binary Effort 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."
BS: "tip of the iceberg" (Score:5, Informative)
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:He needs thicker skin (Score:1, Informative)
Reading Slashdot is sufficient for achieving this result.
Re:BS: "tip of the iceberg" (Score:4, Informative)
The advantage is on the typical user side. As a Mac user over two architecture transitions, I've really appreciated just being able to pull down a single executable from a site and have it "just work". Disk space is cheap and my tolerance for pointless frustration decreases steadily with age. A distribution mechanism like fat binaries makes it so the user really has to go out of their way to get it wrong.
Re:BS: "tip of the iceberg" (Score:3, Informative)
Also useful in copying applications between Application folders on Macs with different platforms.
Re:He needs thicker skin (Score:5, Informative)
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.
Re:He needs thicker skin (Score:5, Informative)
> 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.
Re:He needs thicker skin (Score:2, Informative)
I had to screw around with MythTV for days just to get up and running, mostly because the features I wanted were off on a branch that never got merged in, the client-server protocol is not designed well enough to ensure compatibility across different versions, lirc is an abomination to get working with some of its drivers (and much of the process isn't well documented), the drivers were out of date, the new drivers weren't compatible with old versions of the code one level up, the channel guide data provider story was a train wreck (and again, not well documented), and so on.
Setting up MythTV is very much like taking people out into a forest, giving them some iron ore, and telling them to build a house. First, they have to forge a saw out of iron ore, then sharpen the teeth individually with rocks, then cut down the trees, then.... And most of the problems are just plain boneheaded architectural decisions involving lack of backwards protocol compatibility or binary compatibility---the sorts of things that commercial OSes and software generally do very well and open source tends to ignore because they mistakenly think it doesn't matter. It matters.
Re:BS: "tip of the iceberg" (Score:2, Informative)
While I appreciate your strawman, I'm typing this on a (64-bit) PPC machine. The idea that Aunt Millie might be running a 2005-vintage Mac Mini, for example, is hardly unrealistic.
Re:BS: "tip of the iceberg" (Score:1, Informative)
Yes... lots of Mac software comes in a single executable binary. And uninstalling it is also as simple as dragging the "file" from the applications folder to the trash and emptying the trash.
"Insightful"? (Score:4, Informative)
I've never used a package manager that forced you to upgrade all dependencies to the latest version to install a package. All of them allow not just required packages but required versions of packages, and only force upgrades of dependencies when you don't have a sufficiently recent version.
Some can do patches. I think RPM can. But unless you're using dialup, they're not really that much of advantage. And you also have the problem of having to provide patches from lots of versions to lots of versions. Or you can provide only patches from the last version to the current one, in which case they're useless for anyone who misses an upgrade.
I don't know any package manager that does this. For example, Pacman, the package manager of Arch (my current distro of choice), installs new versions of files with the suffix '.pacnew' if the old version was modified and doesn't clobber.
This is true on pretty much any OS. Multiple versions of the same package will install to the same paths, and your package manager would have to be pretty fucked up to do that. If you'd like to horribly violate widely adopted filesystem organization standards and patch your software a bunch to make it work properly with your new layout, you can do that, but there's no real gain.
They manage packages. Just because they don't implement every feature you'd like doesn't mean that's not true, though evidently they do implement many features you'd like, but you are too busy raging pointlessly to pay attention to the facts. In fact, the only feature they don't implement that you'd like is a major design decision that would require altering pretty much all software on the system for no benefit to the vast, vast majority of users.
Then you get it from elsewhere if the official repos don't provide it. You can even build your own package, something you certainly ought to be capable of if you're applying your own patches to software. You can even set up your own repos!
So basically what you're saying is, "you're not using the package manager except if you are". Gee, really?
Most of your post you've been toeing a fine line between being just wrong and bei
Re:He needs thicker skin (Score:3, Informative)
Yes, Mythbuntu.
The problem was not a security issue.
The problem was using the wrong port for the database server in the client configuration, a port that was open and listening, but not MySQL.
The MySQL client connects, MythTV says 'Okay, got the database!' and goes on to do other things as if everything is working properly. Then when it gets around to actually using the database it just locks up waiting for the DB to respond, but since its not actually talking to a database it doesn't respond, and the REAL problem is that it never times out either. It doesn't log any error.
I did eventually find the problem myself, using some good old debugging skills. I also informed the guy who was helping me since he spends a lot of time in the two mythtv channels I was asking in and may help someone in the future. I also logged the bug with copies of the config files, a detailed description of the error, and all the log files that the mythtv and mythbuntu devs asked for.
I'm not new to this game, it was a bug that no one had reported. Admittedly, it was a stupid configuration error that was my own fault. During my setup, I even checked the little 'check database connectivity' checkbox, to which it came back and said the database was working properly. As a user I went well beyond what you SHOULD expect out of an end user, because as a developer I realize how hard it can be to debug errors and how important to have the most complete picture possible. I even added step by step details for reproducing the problem in a default Mythbuntu install.
You are responding the exact same way as the initial response from the assholes I'm complaining about. You are arrogant and worthless for help because you think you know everything about a situation when you have no idea whats going on. You are the problem.