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."
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.
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.
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!
Quartz Extreme and Core Image. Are there any other real reasons to spend all that money on generic hardware?
Commercial Games. That's who.
Another really big advantage is easier developer workflow. With multi-architecture binaries and libraries, you can test and debug the 32-bit and 64-bit versions of an application without rebooting into a separate OS, without building some weird chroot environment, without using a special linker that changes the paths of the libraries if it detects a 32-bit binary, etc. This means that your development system is essentially identical to the user systems (except for the kernel), and thus the likelihood of bizarre "Unable to reproduce" bugs goes way down.
Another big advantage is that if you build a universal install DVD, you have half as many binary packages. That means a less complex installer and thus reduced potential for bugs, reduced install testing overhead, etc.
Another big advantage is that when a user finds a 64-bit-specific bug in a tool, the user can do an "arch i386 grep 'blahblahblah' *" instead and work around it until somebody comes up with a fix. Without fat binaries, that's well beyond the ability of most typical computer users, including many IT people. You might as well tell them to fix the bug themselves. That doesn't do anybody any good....
But probably the most important reason for it is that Linux is late to the party. Many other operating systems support fat binaries---Mac OS X, Windows, NetBSD, etc. It's not like this is a new idea, nor is there a lack of a clear benefit. Obviously if there weren't clear benefits, there wouldn't be such broad support for this concept. And that's not just a bandwagon appeal; people judge operating systems by what they can do, and if there's an important, user-visible feature that one OS is missing, that's a win for operating systems that do have the feature....
Check out my sci-fi/humor trilogy at PatriotsBooks.
Regarding hard drive and network speed, in today's world of gigabit to the desktop and 10 gigabit backbones and 2 terabyte hard drives I don't know what you're talking about with "10 megabit" and "20 megabyte" cracks. You do realize that the primary expense in a networked workstation environment is administration, not hardware, right? The proper use for local hard drive in a networked workstation environment is for caching, not for software installation. We knew this truth about workstation management twenty years ago, but for some reason it has been forgotten in a world where Microsoft and their deranged horribly expensive and virtually impossible to manage workstation environment seems to be the model for how to do things. How many years of IT experience did you say you had, again? :).
Send mail here if you want to reach me.
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
So, remind me again: why exactly is it not possible to implement all that in a package manager and we need to have a Really Fat ELF?
Because Linux distributions can not agree on a single GUI technology, let alone a package manager.
-- Terry
I didn't smear MythTV, I pointed out how arrogant assholes can ruin someones experience and cause them to leave.
In the pastebin link you cited as being "less one-sided", you are barking orders to people and citing your credentials. What you say about arrogance turning potentially contributing members of a community away is sometimes true, commonly enough as to have become cliche, and quite unfortunate. However, you appear to have had a deep expectation that this is how you would be met. When you're convinced that you have good reason to "hate linux people", as you put it, you will tend to see what you believe. Especially after you have (admirably!) spent two frustrating days trying to find a solution.
It puts my teeth on edge to read the tone of your post here, and also of your linked IRC log. It came off -- and I say this not as an insult but as a barometer -- in a similar way to this guy. I'm not saying you're like that guy; but the heaviness with which you tried to control the conversation could have been perceived as a sense of entitlement. I certainly would have perceived it that way had I been present, and I likely would have reacted in a way that reinforced your dislike of the denizens of help channels.
It's only on multiple readings that I can see that you didn't actually have a chip on your shoulder, and did not actually possess the sense of entitlement that I attributed to you. Rather, you were venting frustration. Maybe you dreaded the trip you would have to make to #mythtv-users because you expected that you'd missed something obvious and would feel stupid when it was pointed out. If you are anything like me, this expectation will always render you very sensitive to being rubbed the wrong way by a rough sense of humor or an assumption that you are a noob (which, a priori, is the most likely hypothesis). If you're sensitive to it, then it doesn't matter how gently or politely they express this assumption; it will get your hackles up. And if the noob assumption is expressed less-than-gently because you opened with a statement that you intended to be humbly self-deprecating but which contained no mythtv-related query, you are likely to perceive it as a full-blown assault on your legitimacy.
If there is any personal advice I can offer, it is to maintain a sense of humor when entering any situation like this. You'll be encountering a lot of strong personalities. Maybe you expect them to respect your frustration, your intelligence, and the time you put into a solution so far (they may assume you're a noob). Maybe they expect you to ask your question first thing, all on one line (you didn't). Your sense of humor is a sort of shock-absorber to ride out the first few missed expectations and maintain your cool. It smooths over the beginning of the conversation. Small matters of etiquette can be allowed to slide on both sides. Thereafter, if someone's legitimatly an asshole, they're easy to spot and ignore.
As far as the nature of the community... hell, even if IRC were the most wretched hive of scum and villainy I'd still dread that support experience less than, say, Dell's.