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."
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.
Cory Doctorow talking about cloud computing makes as much sense as George W Bush talking about electrical engineering.
I like my elves the way I like my tea: thin and exotic.. served while still hot.
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
Fat elves
The Navy Motto "IF it ain't broke Fix It" "A day is wasted if you don't learn something new"
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.
Finally! A year of moderation! Ready for 2019?
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.
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.
.
Oh well, so goes it with parts of the Linux culture.
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.
# cat
Damn, my RAM is full of llamas.
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
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.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
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.
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?
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.
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?
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
There you go, someone listened and gave you that troll point that you asked for!
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.
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
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.
Why bother
Commercial Games. That's who.
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.
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.
Especially since on a 64 bit distro pretty much everything, with very few exceptions is 64 bit. ... 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, ...).
You should look at ppc and sparc distro : pretty much everything is
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.
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$!
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.
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.
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.
Jumpstart the tartan drive.
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.
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. ... etc
2. a file "common.files", containing processed and massaged %files
3. a file "common.pre", containing %pre
4. a file "common.post", containing %post
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).
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.
www.eFax.com are spammers
Is it possible to have a single Windows executable with both x86-64 and i386 code?
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.
That would seem to point to that the idea wasn't really useful in that case
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.
Well, please explain, what benefit do you see coming out from this?
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?
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!".
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
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.
That happens from time to time when you are allowed to have separate brains. Pretty alien concept for Mac fanboys I'm sure.
I don't have a 64 bit system. I do have multiple ARM devices and 32 bit systems.
But the lack of universal binaries is not the reason why it's hard to release closed source software on Linux.
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.
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/
Dilbert RSS feed
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.
Ok, but what do you expect to come out of this?
For instance, suppose this patch goes in. But you won't get an i386/amd64/ARM binary from me, because I don't have an ARM system, so I won't compile for something I can't test. Some architectures have things like alignment requirements. Not all code will work everywhere even if a binary for the platform can be produced. Different byteorder will require writing code that will correctly read data files on all platforms.
And why would you want code for 8 different architectures on a low power device that has a much more limited amount of space than a desktop?
I agree. I never said universal binaries were the problem -- rather, it's the lack of binary compatibility. It's the whole "source compatibility" / "binary incompatibility" that gives the win to Windoze over Linux in the gamine world.
Don't even need the USB stick, the package manager will install the right version and correct architecture for him. All he has to do is tell it that he wants program X installed.
Simple, no?
Change is certain; progress is not obligatory.
Ryan Gordon does. He's ported a metric buttload of commercial apps for Linux. See Loki games & icculus.org for more information.
There is a war going on for your mind.
It's the same reason why Android is a user interface disaster compared to the iPhone and Palm Pre -- geeks thinking like geeks, instead of geeks thinking like users. The package management thing is a hack, a hack which is useful only on stand-alone servers or stand-alone workstations and utterly useless at getting workstation administrative costs down, which requires a networked software installation and where fat binaries mean you install *one* package rather than needing several different filesystem shares with multiple package installations that are largely identical. But workstation administration costs, while a concern for users of Linux, aren't a concern for core Linux developers because they don't know, understand, or care about the workstation other than their personal development machine at home. So it goes.
Send mail here if you want to reach me.
Don't forget one of the problems I've complained about Linux for ages, only to get told "researching your ass off" is actually a better "feature"...Driver Cds. Maybe if you had fat binaries it would finally give Linux a stable ABI and we would finally see a "fat penguin" on the box of devices at the local Walmart/Best Buy/Staples and retailers like me could finally carry your product.
As it is shopping for Linux devices at retail is a fricking nightmare, as by the time anything ends up on some approved list somewhere it usually isn't sold in stores anymore, or Deity help you if the approved device has firmware A and they have moved on to firmware G without changing the box (which of course they do all the time) as you can enjoy your new paperweight. It is just too damned hard to sell Linux when your customers are Joe Normals that shop at Walmrt. with Windows all I have to do is tell them to look for the logo and my after sale device support costs drop to zero.
So if fat binaries would have finally allowed devices to show up with a fat penguin on the box I would have been dancing in the streets, of course its dead now so we'll never know. But until Linux is as easy to shop for as Windows and OSX at retail, which I truly believe won't ever happen without a stable ABI and easy to place "Linux 32/64" drivers on driver discs, well then Linux will always be the OS for geeks with a single digit adoption rate. Because Joe Normal isn't gonna study his ass off doing research just to buy a device at the Wally World. Just ain't gonna happen, and without Joe there will NEVER be a "year of the Linux desktop".
ACs don't waste your time replying, your posts are never seen by me.
...except that guy only has to worry about ONE architecture because of the lock in nature of commercial desktop software.
So the moment he leaves the server room he needs only ONE option.
If he plugged in such a USB drive inside the server room he might get immediately walked out of the building.
A Pirate and a Puritan look the same on a balance sheet.
You mean like something along the lines of what Loki or WordPerfect used 10 and 15 years ago or what Oracle uses today?
We are comparing proper package managers against competitors that are essentially dressed up shell scripts.
The enemy emperor has no clothes. Never had.
A Pirate and a Puritan look the same on a balance sheet.
This is silly. Nobody even distributes Linux binaries. They distribute Linux packages. Hell, even on Windows, the number of distributed .exe's has gone down. Most things get packaged into MSI. This is fine.
Maybe what he wants is an easier way for developers to package their stuff for many distros.
While I won't disagree that commercial games is a potentially valid argument, let's take a step back for a minute. Most commercial games that would benefit from this (i.e., the ones that are flashy and have big advertising budgets) are likely to require certain hardware capabilities (processing speed, graphics capability, high-end sound) to operate well. You might be able to force a lower-end system to run it, but NO game developer spends time optimizing the experience on crappy hardware, it's just not cost-effective for them. So they have hardware requirements, and chances are that is going to mean running on an Intel CPU, with an ATI or Nvidia GPU and some sort of decent sound processor. Don't try to tell me you seriously think that the latest FPS or MMO should run on your ARM netbook - that's not what they're designed for and we all know it.
So that leaves the question of x86 vs. x64 binaries, and I just don't buy any argument that it's too much work to make companies build both (or just stick with 32-bit and be done with it). NO modern game comes without a comprehensive installer, and most have internal updaters as well, so having them pick 32 vs 64 bit as appropriate is a perfectly reasonable thing to do. Even with high-speed Internet do you really want to download files that are twice the size you need them to be just so they can run on hardware you don't have?
And if you're trying to make the case for small, indie game developers being able to supply a 'universal binary' so make it available on more platforms, I ask you this: If they can't afford to have all of the different architectures available for development, testing and troubleshooting, what makes you think they're going to want to provide an sort of binary to run on those architectures? I don't even want to think about the headaches (and karma losses) that devs would go through trying to support platforms that they can compile for but not actually run on...
Universal Fat Binaries have a single problem they are meant to solve: How to provide a single version of a close-source program for proprietary OS that is currently shifting from one hardware platform to another in a manner that is supposed to be transparent to the user. MacOS has done it twice - M68K->PPC, and PPC->x86 (I don't consider x86->x64 in the same way, because a proper x64 OS will run x86 32-bit binaries seamlessly anyway). I was off of Macs by the time they went Intel, but was right in the middle of the M68K->PPC shift and think it was handled pretty well. But that's because a) the hardware options for the platform were highly fixed to begin with, b) the development environments for the platform were fairly limited as well, and c) EVERYONE knew that while Fat Binaries were intended to make the transition easier, they were not a permanent thing and eventually M68K support would be dropped and everything would be PPC only.
In case you missed that, I'll repeat it on its own: Fat Binaries are designed to TEMPORARILY support a TRANSITION from one architecture to another, and after a time they STOP SUPPORTING THE OLD ONE and go back to being thin.
Linux already supports something like this, in that multiple major versions of shared libraries are supported on the system for when there's an ABI change. But there's no reason to support Fat Binaries for different hardware architectures because a) Since the OS is open one is not locked into vendor-specific hardware, and thus vendor specified architectures that can be changed AND enforced, and b) there is no major architectural hardware transition in process that is likely to affect the consumers who would be the likely targets of this change. People buy hardware these days because the software they want to use runs on it. Even if a company were to offer Fat Binaries for multiple architectures, people would buy the one that will run the most software they want to use, and unless EVERYONE produced Fat Binaries for Linux people would STILL buy Intel systems because that's what most of the so
If I remember correctly (and bear with me, the 90's are a blur for me), this is EXACTLY what happened, and early pthread libraries had to do a whole bunch of kludges using signals and timers to get user-space threading on Linux.
It took years (maybe an exaggeration, it sure felt it at the time) to get proper threading support in Linux because fork() was good enough. 1996-1998 timeframe perhaps.
Maybe not in so many words, but yes, this happened. And some of it's justified - don't go putting immature stuff into the mainline. Well seems like they (LKML) apply that rule very inconsistently.
I have built cross-distro binary-only applications before.
Some notes on doing so:
Make sure you compile, link against a old version of glibc, this prevents issues of running applications built against newer versions of glibc spitting out "undefined reference errors" on systems with older glibc (much like when you compile a windows program against the winvista platform sdk and try to run that program on XP).
If you must link against the C++ runtime library (libstdc++), then provide a custom version of it with your software. That's about all you need (much like how many Windows applications come with the msvc runtime dlls they were compiled against).
This is legal, no source requirement (outside of providing the source to libstdc++ when requested - which wouldn't reveal anything).
I honestly don't see how this is a substantial difference from Windows, could you explain it better, please?
Change is certain; progress is not obligatory.
What usefulness? Fat binaries take all the work of producing individual platform-specific binaries to create, and present little advantage in use compared to having an installer or packaging system that installs the right binary from the set for the given platform.
Even for the few environments (such as where you share a filesystem with executable binaries between systems with different architectures) where they might be useful, on any system where executable interpreted scripts can be made indistinguishable from the end-user perspective to actual binaries, they offer no advantage over having a set of installed binaries for the various architectures with an executable launcher script.
icebraining here brings up a very salient point -- if the whole reason for fat binaries is simply distributing multiple versions of application X, one for each target platform, all in one package, it seems to me that we already *have* such a mechanism...
Which leads me to ask, what am I missing here? Or is the FatELF project really a solution in search of a problem?
Cheers,
"What in the name of Fats Waller is that?"
"A four-foot prune."
No, it wouldn't.
The userspace ABI is stable. But that's not where drivers are. Drivers are in kernel space, and the stability or lack of it would remain unchanged by this development.
I have right now: a nice color laser printer, a very decent scanner, and an old webscam by brother can no longer use but that I can, because he upgraded to XP64, which comes with no drivers for any of those. Meanwhile, Linux supports all that perfectly fine.
In fact my brother bought a new scanner that looks near identical to the old one. As far as I can tell any improvements if they exist at all are insignificant.
So, Windows has a stable driver ABI, why doesn't all that stuff work? Because it works so much better for the manufacturer to make you buy a new product instead.
I disagree
For the most part, the game engine is quite separate from the game-script in modern game development and can be compiled independently for each system, and run the same scripts.
I understand what Ryan was trying to do, but, to be fair, is a low-level solution that a higher level solution could do instead... i.e. make it a desktop environment fix rather than a kernel fix.
closed-source software is viable on Linux from the hardware/software point of view.... it seems it is the user-end that is missing from the purchasing stream. I've purchased and played (many of) the games Ryan has helped port to Linux. I'm glad he did them.
As far as rudeness and smugness goes, there's no need for that. I think it is quite sad that there is so much disrespect floating around.
No, that major reason is publisher effort, and the inconsistency of video driver support. And the first will never happen without the latter. Oh, and most games being written in DirectX.
Kudos to anyone still writing in OpenGL.
I've often wondered about that -- what usefulness is there in trying to mv or cp a populated directory *without* the -r/-a flags? Is this some Unix appendix, a leftover with no remaining useful function? Or is there some residual utility in requiring the flags, that I'm simply unaware of? Seriously, if anyone has any insight, by all means please post it.
And being able to set a directory itself as executable (such that the contents are run) sounds an awful lot like what Apple's done with their .app packages -- but there I have to wonder if there might not be some security implications.
Cheers,
"What in the name of Fats Waller is that?"
"A four-foot prune."
There's a view the world according to father knows best. And I'm sure it's true much of the time or the project would have foundered long ago.
I'm also sure that worthwhile patches fall through the cracks, personalities matter in how the decisions are made, and the communication of the decisions made often falls far short of the ideal, wasting valuable time and energy of people who wished to make a positive contribution.
That said, Con is not my personal poster child for the unfairly rejected: he seems to understand neither software engineering nor macro economics in the large. For example, while Con's patches might improve things for the desktop user in the short term, if it comes at the cost of continued enterprise support for the people who continue to develop the kernel, the victory will be short lived; in this scenario, at the end of the day, *everyone* loses. Fair enough, one might say, at least it's equitable.
The moral of this story as I read it is that he should have chosen his battle better in the first place, such as becoming a founding developer for Haiku, who likely would have embraced his audio-glitch-free window dragging aspirations as a founding precept of digital justice. From the Linux perspective, that enterprise machine that didn't see Con's reported glitches now looks like next year's entry model (welcome to Westmere). As a software engineer, one must cast an extremely critical eye on the carrying cost of modifications designed to avert a problem where there is already a great deal of writing on the wall.
I'd say there's a good chance that same logic applies to fat binaries.
FWIW, the driver situation seems almost by choice to be designed such that it works more smoothly when you have the source code for the drivers.
Which as far as I'm concerned device manufacturers are crazy not to do... the best a driver can hope for is to simply not get in the way, yet hardware manufacturers seem to have a really hard time writing decent drivers that work correctly. It's not a competitive advantage, all it does is screw themselves over when I can't use their device. Why they want to turn down help from users who can fix their drivers for them is beyond me.
So fat binaries would be of limited help for drivers... it's less of an issue for an installer to pick the right architecture to copy into place, as it is an issue that the Linux design philosophy is simply better suited for open source drivers. (which could be transparently compiled by the installer during installation for the target system)
You missed half the argument. It's hard, and it's pointless.
The grandma who has a netbook running ARM and a desktop running x86 will install software by going into Add/Remove Programs and picking "Fun Times Photo Album for Grandmas" out of a list. The package manager will figure out what needs to be installed for her, on both her ARM and her x86 computers.
She's not going to go to some random website and download a random installer file and use it on both her computers - her kids have told her over and over again that that's not safe, and she may lose her knitting patterns if she does it.
Seriously, the people who advocate this junk seem to be entirely unaware of the joys of package management. All FatELF does is re-solve a problem that package management has had licked for a couple of years now, and it solves the problem in a less efficient way.
It's hard, yes - but it's not worth doing just because it's hard.
Commercial Games. That's who.
Exactly. Take Blizzard, who ships Windows and Mac versions of their games on the same media. Fat chance of getting an official Linux release in the absence of a universal binary solution. Blizzard tends to ignore platform-specific package formats in favor of their own installers, the better to control and customize the installation experience. By avoiding the standard MSI format on Windows, for instance, they avoid introducing a lot of unrelated dependencies and vastly simplify the post-release patching process.
If you don't mind hacking around on the command line to get a game to work, the current state of affairs probably suits you just fine. But there's no business reason for Blizzard to support Linux users with an official release, if the best they could provide is a different set of command line inputs to type in. This of course assumes they would not develop installers for every Linux distribution on every compatible architecture, along with the necessary documentation and technical support for each. I think that's a fair assumption.
you can just ship i386 and not bother with this at all
that assumes the i386 libraries are in place, which as my original parent was just saying, isn't necessarily the case because often you can get everything purely 64-bit. (and as a side-effect of the earlier strawman, that CDs don't have room for both architectures, so only one is installed)
Then no one wants to be that one 32-bit app which requires the user to install the whole set of 32-bit system libraries... especially as the whole point of a USB or net install is to avoid installing crap on every single machine you use.
And besides, who wants to have to maintain a shell script and two+ executables for every application? It doesn't scale well. FatELF would be a straightforward solution to some real issues, I'm disappointed people couldn't give constructive criticism instead of getting hung up on a single use case (native installation) where's it's not *really* needed. I'm sure FatELF won't make you coffee either, doesn't mean it isn't helpful in other areas. (non-"installed" software)
And most other commercial software too...
If you pay for it, you'll probably end up with a binary. In the best cases, you get binaries for a whole bunch of different architectures and systems, like with Matlab...
In the worst cases, you end up with a binary that will run on only one architecture.
/.Mattsson - My native language is not English, so please don't whine over linguistic errors. (That's lame anyway...)
"So one of the developers in the project tracked and found the issue online for free"
After many, MANY others failed to do ANYTHING useful.
Yes, 15 shitty support attempts are no negated by one semi-successful collaboration that finds a problem.
And just so we're clear, NO one of the developers DID NOT track and find the issue, try reading it again so you don't misstate what actually happened in support of your ridiculous attempt at a point.
I seriously wish people like you would stop supporting FOSS, you don't add anything with your constant whining about how our legitimate concerns aren't fair.
That still exists, even on x86-64 Intel executables. But that's not what I was asking about.
There's no need to assume, you make a package. If they're needed, it'll fetch them
This is a weak justification. It's what already happens for everything else. If you install KMail on a gnome system you're going to get lots of KDE packages pulled in. In fact pretty much any non-trivial application will have quite a few dependencies. For instance, for me to install blender right now would take downloading 7 other packages. I don't really see anything wrong with that.
No, it won't be. Because you can't just check "build for all 8 architectures" and leave it at that. You need to make your code portable, which involves endianess and alignment issues for a start. That's what will take the real work, the shell script is a tiny thing in comparison.
FatELF binaries don't avoid this issue any better than any other solution, seriously. You still have to build/bundle custom, vetted runtimes that reside in a similar bundle on the install- and for each architecture you support. Done right, you end up with a set of binaries that runs on any modern distribution without major glitches. Unfortunately, you have to do the same effort for FatELF binaries as you would for the other way- and with no better assurances of "getting it right" with it as with the other means.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Running 32-bit processes on a 64 bit OS makes sense, in order to save memory on "normal" software that doesn't have pointer optimizations in mind (e.g. all software that use pointers instead of indexes).
In my opinion, 32-bit processes it is not only a "must", but also having the tools build in 64-bit mode is a huge error. What's the problem of a 64-bit OS running most processes in 32-bit mode? In the end, there are just few processes that could need more than 2/3GB of memory, and the extra CPU registers doesn't make the difference, yet (1, 2).
Or...conversely, you can use something like apbuild from the AutoPackage project to do the same sort of pinning on most machines without the old version being needed.
The magic trick with all of this would be to do something within Scratchbox2 (to mitigate compiler issues and frame it in so you can do things like 32/64-bit easily, or ARM in the same manner...) and use apgcc/apg++ to pin glib version numbers.
"Lack of unified package management" is another good "excuse" they use- in the end, you don't need unified package management, you need something akin to MojoSetup (Something else that Ryan's come up with that's definitely a must-try for a game studio doing things on Linux...) to handle installing if you're not providing "universal" .deb's or .rpm's (which can be done as well...)- and it'll handle much of what you need of it, especially if you know what you're doing with things on the Linux side of things.
In the end, there's less issues than most people realize there are with making games for Linux. It's more due to unfamiliarity and ignorance of how to properly do things that the stuff doesn't get done- and the reasons for those are that the studios and publishers don't think there's enough money there to become educated on the subject. It's NOT due to the lack of "universal" binaries...
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
What he said is that on some other architectures 32bit is more efficient than 64bit. This is not true for x86, because they fixed some architecture shortcomings while implementing 64bit (more registers for example). Because of this on x86 64bit code is faster than 32bit code.
On architectures like MIPS for example 32bit code is faster than 64bit code. This has to do with pointer sizes, which are bigger in 64bit and use more memory and more cache and take more bandwidth on the bus. So the 64bit code is slower.
Usually the kernel is 64bit, but most of the libraries are compiled as both 32bit and 64bit. If you need more memory than 4GB, you compile as 64bit, otherwise you compile as 32bit. The increased memory size you can address is the only advantage of 64bit on systems like this.
Now teach grandma how to use it.
At our university for example, we have the AFS network file system. I can put stuff in my network home directory and run it from a variety of lab and cluster workstations where I don't have time or permission to install a bunch of dependancies. But it's a huge pain in the butt when I sit down at a 32 bit machine and I had previously compiled some tool or library as 64 bit or whatever.
So yes, FatELF doesn't really help dpkg or yum do their thing. That doesn't mean it isn't useful elsewhere.
For instance, for me to install blender right now would take downloading 7 other packages.
And on OS X I just download Blender directly from the website... very easy because it contains everything I need.
As much as I appreciate the linux package system handling dependencies and installation of shared resources, whenever you're doing something *outside* of the packaging system it's a pain in the butt. *This* is where FatELF is handy.
You need to make your code portable, which involves endianess and alignment issues for a start. That's what will take the real work, the shell script is a tiny thing in comparison.
That's a side issue, completely unrelated. Once you've taken the time to make your app portable, coding minutia have nothing to do with making it harder than it needs to be to make use of that portability.
Do you work in government ?
I want to delete my account but Slashdot doesn't allow it.
What do you get when you cross an Elephant, and a FAT ELF who takes his bat and ball and goes running home to mummy the first time someone gives him lip? Well, I have no idea. I was hoping someome here might know. But I bet it's one UGLY abomination of an animal. The kind that other animals laugh and poke fun at.
A troll with score -1?
My other account has a 3-digit UID.
That's not worse than the current situation. The fact you won't use the feature doesn't mean other developers won't, and that would offer the end user more options, not less than we have today.
In any case most of the people arguing against this feature do so because they don't think it's needed. But I fail to see the disadvantages in implementing FatELF in Linux. Nothing prevents a developer from building binaries for a single architecture, and ignore this feature. Nothing prevents a developer from releasing their software in source-code only. There are no technical disadvantages that I can think of, even after reading most criticism.
There are certainly going to be difficulties, but if you really think about it, nothing prevents solutions for these problems to be crafted. On top of that, this particular problem you mention is not specific to FatELF, and it needs to be handled properly in the source code regardless of FatELF (if you want to create a source code that can be cross-compiled). FatELF is about easier deployment in situations where it's needed. It's not about making it easier for the developer to program for different platforms (it would be interesting though to see variants of fread/fwrite that abstract you from endianness, but that's a different topic anyway).
Maybe you wouldn't... but FatELF would probably be targetted mostly at software for users that don't have a clue. Nothing would force software like "ls" or "man" to be compiled in a FatELF package. But I could easily see Open Office distributed like this, and it would be neat.
Anyway, this is not an attack on your stance. I just wanted to offer a different point of view. Sometimes I think people is too reluctant to change, and in this particular case I think there are no real disadvantages for this to be rejected so flatly.
diegoT
I understand, if that whats he meant if that is implementation specific.
(on the topic of ppc and sparc) Registers, and pointers aside, if 64bit code is even less computationally efficient because of deficiencies in the architecture, then there is almost no point in using it!
Binaries can be made PIE, and on >4gb can be addressed with PAE (though I understand that is an x86 technology). It sounds like sparc and ppc REALLY dropped the ball architecturally if people run 32bit binaries for speed reasons.
Your bold statement about the design behind FAT binaries ignores an important historical use case: an operating system that was 4-way FAT for 68040, x86, PA-RISC, and SPARC.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
OMG how do they ship two different binaries without a universal binary for mac & windows, oh that's right you have to pick the right one, hell on linux you could have a shell script do that for you. The problem is that FatELF doesn't solve anything a shell script and binary compression format can't, yet it needs kernel level tricks.
IranAir Flight 655 never forget!
The original story is worth +5 apparently. Maybe someone could mod this AC up for me: I think the other side of the story deserves to be heard as well.
Understanding the benefits of a multi-architecture binary depend on first accepting the purpose of pre-compiled binaries.
And, they'd have to start designing the programs to have run-time portability rather than depending on the make process to discover and tailor the program for the target machine.
FatELF doesn't magically recompile binaries to be multi-arch, it's just a fancy way of packaging multiple binaries together, and for some reason people want to keep the binaries as a big package instead of just picking the correct one at install time.
IranAir Flight 655 never forget!
Yes. It is a "solution" which adds costs in many, many places for a problem that doesn't exist. I don't see why people even spend a second thinking about this.
-- Ulrich Drepper (2009)
640K ought to be enough for anybody.
-- Bill Gates (unattributed)
Agreed. There is also the question of why the authors of a GNU licensed program are expected to show a passionate interest in a project whose central focus is the distribution of binaries. FatELF makes sense when the source is not available. When the source is available, package management, with a per architecture build, makes more sense.
Just an application to run? This is what I wrote on how to compile an application to work cross-distro.
If you're talking about cross-architecture, I could make a 'FAT' binary by essentially wrapping the executable binaries for each architecture inside a bash script (the same way Loki installers work) and have it execute the one for that architecture - Obviously not that simple for the person who has to do it, but then if you've ever made universal binaries for OS X, you'd know it isn't that much simpler either.
Change is certain; progress is not obligatory.
FatELF binaries don't avoid this issue any better than any other solution, seriously. You still have to build/bundle custom, vetted runtimes that reside in a similar bundle on the install- and for each architecture you support.
Well, it seems to me that this is the straightforward part - if it's not exactly easy, it's at least fully under your control as the publisher.
What you can't control is what happens when the user tries to install or run your game. How do you know they have picked the right installer or executable binary to double click?
Unfortunately, you have to do the same effort for FatELF binaries as you would for the other way- and with no better assurances of "getting it right" with it as with the other means.
Getting it right is what QA testing is for. The benefit of FatELF is that the end user only has a single program to run. By eliminating the choice between binaries, you eliminate the possibility that he will somehow make the wrong choice.
Thing is I fail to see any advantages either. Why spend time on something if it won't bring a benefit?
The way I see it, this is unnecessary because computing in general is getting divided in 3 rough groups:
1. Desktops. All modern hardware will run i386 code, macs included. All modern Linux distros will run 32 bit code. So if you feel a need to ship a tarred binary for some reson, ship 32 bit code, and no problem. No need to compile twice.
2. Special purpose devices. Those have special screens, small disk sizes, slow CPUs, and so on. It makes very little sense to provide a fat ELF for those, because even if OpenOffice came with a fat ELF with code that could technically work on my cell phone, it probably wouldn't work right anyway, if it managed to find enough memory to load. If the application does work fine, you're still wasting very limited resources.
3. Niche architectures like SPARC and Itanium. Nobody cares about these for "user friendliness" purposes.
Why would it? Linux users install openoffice as a package. I don't really know anybody who downloads it from a website, it's just not the standard way to install things on Linux. If you're doing that, you're not a typical user, but have a special need of some sort. If you're a third party provider, you provide a third party package server.
Attempting this in a world where even an x86 binary wouldn't work on all x86-linux-pc boxes (static linking, yeah...yeah)
Laugh it up, but my Quake 4 binaries I downloaded in 2007 work absolutely flawlessly on my mid-2009 Linux distro.
Pirate Party UK
I'm not assuming. It *is* the end-all of linux installation. You have a very specific and unusual setup, which doesn't apply to 99% of the userbase.
Using tar files with binaries under Linux is roughly equivalent to deploying software in Windows by copying files to directories by hand and running regsvr32 instead of providing an .msi. It's an ad-hoc, user unfriendly way of getting software on the system, generally reserved to advanced users and sysadmins.
It still won't help you, because the architecture problem is not even half the issue. A binary compiled in Ubuntu will link against Ubuntu versions of libraries and may fail to work under a Red Hat that ships older version libraries.
But it won't do that. All you'll get is a binary that works on both i386 and amd64 Ubuntu Karmic. And it'll still fail to work on an older release or another distro, because nothing about FatELF involves packaging dependencies.
I have a tool like that - it's called tar. I have distributed applications for 5 OSes with different architectures like this. The startup program is a script which works out what binaries to run. No messing around in kernels is required.
This is all just my personal opinion.
http://llvm.org/
This is all just my personal opinion.
Maybe Blizzard should go and beg iD Software for some advice, then. They've been shipping perfectly functioning universal Linux builds of their games for years now. Or perhaps 2D Boy? Or Introversion. If tiny indie studios and massive names in the industry can all manage it, Blizzard could too.
Pirate Party UK
Why not let Ryan spend his time on it? After all he was willing to take care of it himself... he wasn't asking for other developers to maintain it. I am not arguing that people should like the feature, or support it... just that if it comes at no cost, and it adds more options and more freedom, we should let it at least move forward.
What good is a "free" OS if features are rejected just because?
To me, something being good enough doesn't mean it can't improve. For example you may not want to provide a third party package server, or may not want to maintain it. Or maybe you want to make the most user friendly software available in Linux (a la Apple)... some game to deliver in a CD for Kids to play by just double clicking it. Who knows? The thing is there are reasons why this might be a good option to have, even if most developers could not need it at all.
I just feel this feature is being rejected because it's unnecessary for most tech-savy people. If we, as developers, forget to have our users in mind... we will fail in our job to deliver solutions.
diegoT
I don't think anybody was stopping him from spending time on it. He can spend all the time he wants, even if nobody else in the universe is interested.
Just like Ryan is free to code whatever he likes, other developers are free to care or not about what he codes.
That's not really a statement of user friendliness. I made installers for Windows. I didn't really *want* to because it's boring as heck, but it has to be done, because that's how software is distributed on Windows.
In the same way I don't really enjoy packaging on Linux, but I have to, because that's how it's done there.
Being unwilling to comply with the platform's normal way of doing things isn't doing it in a friendlier manner, it's generally just being lazy or having too much of an ego. For instance, you could shoehorn a Mac style menu bar into a Windows application, but I doubt it'd get a good reception, or be able to obtain the "Designed for Windows" certification.
I don't get why people keep bringing this up, when the whole FatELF thing has nothing to do with this style of application deployment. Doing a Mac style install system on Linux would be a different project entirely. Mac could lose fat binaries and still have applications installed in the same way, or switch to using a package manager and keep fat binaries. Both things are really separate.
Really you can do Mac style deployment on Linux if you really want to. You just have to package the binary, data, every library it uses, and add a script that sets LD_LIBRARY_PATH. Then you can really drop a folder in a random location, click the script, and have it work.
On Linux, non-tech-savy people use the package manager. They don't go download tar files to random websites, because on Linux, that's the unfriendly way of doing things.
What the hell, it's a setup shared by anyone who wants to run software from a networked file system. Even so, I suppose 99% of users don't use GDB either, so I guess we can just drop things like that from package management, right?
Seriously, just because *you* don't need a feature on your dinky home installation, doesn't mean it's not a very useful feature for others. 'raw' binaries on Linux are only ugly because people like you don't want to contemplate fixing it. That's fine if you want to ignore it, but if you're just going to complain about a partial solution, either demonstrate why it negatively effects you or shut up and get out of the way.
Programming languages are already far two high level which incurrs a performance hit. We should all be coding in assembler. Personally, for fast executing binaries I prefer to tap the bits into the hard drive platter with magnetized needle.
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
Binary compatibility is quite easy in my opinion and I speak from previous experience.
Change is certain; progress is not obligatory.
Right. Now install it on a network share and run it on a network of 10,000 workstations, some of which are 32-bit workstations and some of which are 64-bit workstations. I can do it in 5 minutes with fat binaries. You, on the other hand...
Send mail here if you want to reach me.
FatELF is a stupid implementation of a stupid idea. I.e., even if you want fat binaries, modifying the ELF format is the wrong way of doing it.
Yeah for the Linux kernel developers for keeping this kind of crap out of the kernel.
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'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
That is because IMHO Linux has been taken over by the "SCoN!" faction, which stands for "Source Code or Nothing!" and is of course led by the militant RMS. Unfortunately the real world has these things called "patent trolls" which is why you will NEVER see devices for home users releasing source code. look at which companies DO release source-IBM,Intel,AMD,HP Corporate, what do these companies have in common? Simple, a large "patent warchest" and a large interest in the server/HPC markets.
That in no way, shape, or form describes the critical home market, which is where Linux desperately needs to be if they want a chance in hell of being a real threat to windows adoption. Lets be honest here-all the geeks that want to run Linux already are. The growth in the geek market is virtually nil. What Linux needs is for retail mom&pop shops like mine to sell and support your product, and the simple fact is they can't. Why? I'll give you an example from Ubuntu 9.04, which is the last time I tried selling Linux-
I put a couple of off lease office machine with Linux on the floor next to Windows. Because I didn't have to pay for an XP license, the price was cheaper. The customer bought it, promptly went to Walmart and bought a camera and an all in one printer, and neither worked. So they brought it to me because it was "broken" and I needed to fix it. But Linux would barely support the cam, and that was after many hours of CLI BS, and the printer? I got told "LOL buy a new one!" So I ended up having to give the customer their money back on an XP PC, and I promptly wiped Ubuntu and put Win2K. My support costs dropped to zero for those after that.
But every time I point this problem out, what do I get? I get labeled a troll, I get told that I am supposed to tell customers with a straight face to rush home and trawl some forum before they can buy anything for their PC, or that I should bundle, which because my last name ain't Dell automatically raises the price higher than just putting XP Home on the damned thing!
So mark my words, and come back in 5 years to see how true they are. The "SCoN!" crowd will make damned sure that Linux stays ass backwards, with kernel developers having to maintain fricking drivers, Windows 7 and later 8 will continue the MSFT dominance on the desktop, and we'll still here "next year is the year of Linux on the desktop!" while Linux users just can't figure out why nobody wants to trawl forums and spend hours dealing with Bash bullshit for their "superior" OS. Yet you still won't be able to go into Walmart and buy a device without researching like it was a college entrance exam.
And folks wonder why MSFT and Apple keep stomping the dog crap out of their free OS. Well duh. It may be "free as in beer and freedom" but if they can't even shop at walmart without studying or spending hours in CLI then it is "free as in worthless" for my customers.
ACs don't waste your time replying, your posts are never seen by me.
It's all moot anyhow: the Software Freedom Law Center never replied to my
request about the software patent thing. I suppose they still might; it's
only been a few days, but for some reason, I fully expect to never hear from
them.
Other people have covered other points, so I'm just going to talk about the SFLC. It sounds like you haven't communicated with them before, so please cut them some slack. Just yesterday Bradley Kuhn dented:
FLOSS ppls: !sflc is a charity w/ limited resources. It can take up to a week for us to answer general contact email. Pls give us a break!
coding is life
This is so true and people don't seem to make the connection - in order to have high quality, you have to discriminate. All these people hear how wonderful Linux is, and they think, "I've got a great idea to make it better!". Then when they get turned away, they whine about it like they're the only ones it ever happened to. Perhaps their idea just wasn't well designed, or it's badly coded, or it doesn't solve a problem. Or maybe it does just plain suck. Sorry, but Linux didn't get to be good by accepting every hair-brained non-solution to a non-problem that came along. People who whine about having their submissions rejected from the Linux kernel are probably the same types that would try to start a business with a "great idea", then whine when no one buys it.
Nathan's blog
Linux means freedom and liberty to many. Its odd for linux to miss the boat on this one and even worse to ban the choice. "We don't ____ here" is something for Microsoft to say.
Democracy Now! - uncensored, anti-establishment news
Honestly, I can't understand why a fat ELF would be need. Just wrap a small shell script around two or more binaries. All it would have to do is detect the OS (uname anyone?) and unpack the right segment. It is messier, somewhat, but it works.
You realize that your last sentence basically describes what FatELF would appear as to the end user, right? Except in the case of using multiple binaries they don't share segments at all. A FatELF binary would share segments other than the .code segment. Separate binaries will use more space than FatELF.
You could always strip the extra segments out if you wanted to.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
First, Why? That's what package managers and directories are for. Just like having lib and lib64, just have multiple bin directories and link the correct ones while booting.
Or if you're just doing one package and not a whole system, just have a script detect the correct arch and run the appropriate binary.
Second, do we know for a fact that there are no Apple patents on this? [**crickets**]
So, not really needed and potentially dangerous legally. Two really good reasons not to do it.
That "file" is not a binary. It is an application package, which is the point I was trying to make.
Open that .app folder sometime and peek inside. See what I mean? It's a folder! There's no reason you couldn't have 2, 3, or 50 separate binaries in there, and a simple script to choose one.
Don't thank God, thank a doctor!
They killed the jolly old fatELF.
Never answer an anonymous letter. - Yogi Berra
much less from some random untrusted binary she downloaded from the internet.
And then people wonder why there are no good third party apps for Linux (games, video editing, sound editing, etc etc)...
If I wanted to port my commercial application to Linux, it would be easier for me to make it available as a "fat binary" in my webpage than trying to convince the 296 linux distributions to add my program to their repository.
Ubuntu is an African word meaning 'I can't configure Debian'
Rude linuxheads?! I find that hard to believe.
Btw, modding me down, as you most certainly will, only proves my sarcasm was justified.
Shut up, you tedious cocksucker.
I don't think it's THAT far fetched to say that a troll looks like a cross between an elephant and a fat elf, do you?
My other account has a 3-digit UID.
I mean despite the obvious bloat.
I think it's way simpler to just compile one version for each architecture and put it on the package mirror. Less download time, smaller installation media, less disk space used for no reason, faster startup times...
The idea of a multi-arch binary makes sense for closed source that does not allow re-compilation only. And even there, you can offer different binaries for different architectures.
Hell if you *have* to get a "universal binary, just bzip all the different binaries into one executable archive that runs whichever binary inside fits the architecture.
But I see not point in it, would just unpack all the binaries for my arch on the first run, and be done with it.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
I remember running old NFS setups. Almost the entire installation was running off the network, it was dead easy to add more applications for everyone. You would "sudo apt-get install " (on an account was was allowed to do so) and everyone gets access to said application.
Of course, if you wanted to block access for certain users, groups, you could use setfacl (POSIX ACLs) to block users access from it. Ensure you blocked the .desktop files from these users and it wouldn't even appear in their menus. Dead easy. =)
The interesting thing about this, is that it doesn't really matter what 'client' distribution you're using on these networks, since all the libraries for the 'host' distribution is included on the system. I don't believe there is really any major problems with networked applications from being ran on Linux at this time.
Change is certain; progress is not obligatory.
Getting someone to copy paste a string of text in an e-mail is actually not that difficult.
Now, trying to instruct them to do stuff via a GUI, oh God, no.
Change is certain; progress is not obligatory.
When I ran a large network, the workstations mounted [nfs share]/$(/bin/uname -m)/ as root.
It was quite trivial to add anything for any specific architecture on such a setup.
Change is certain; progress is not obligatory.
I don't believe there is really any major problems with networked applications from being ran on Linux at this time.
Except if you want to let 64-bit machines run natively but still support 32-bit machines... then you have to maintain two separate file shares. FatELF would have let you keep it all synchronized on one share.
Further, this only works if you're globally using a standard distribution and release revision. It's not clear if FatELF would have supported distribution tags, but that seems like something that could be added fairly easily. Then when you want to start upgrading some machines to a newer distribution, you could just do 'apt-get --add dist-upgrade' or such on the server drive and have it merge the binaries into those that are already installed... life would be beautiful for sys admins.
(Also, FYI we actually use AFS, which is a somewhat more advanced network file system in that it is distributed as well, has its own permissions system, etc. Not actually sure how it winds up comparing to NFS on performance, but probably on par.)
No, that major reason is publisher effort, and the inconsistency of video driver support. And the first will never happen without the latter. Oh, and most games being written in DirectX. Kudos to anyone still writing in OpenGL.
Most games are written on a Cross Platform Game Engine (like Unreal) nowdays. Underneath the hood is OpenGL or DirectX on a PC (or XBOX 360) but if you target PS3 or Wii, the game engine has to target a different rendering library.
I can't really think of an issue with two separate fileshares. For the most part everything is identical in setup and commands, running the command "sudo apt-get install" is the same for both and I can set certain architecture specific settings when needed.
But, let's consider your idea. So what happens when I need to add support for 128bit x86 or arm etc? I have to replace every single binary? Some proprietary ones may not even exist in that architecture at all and in which case I need to set it up to work with other things. Like using Gnash instead of Adobe Flash (which conflict with each other when installed together).
As a sysadmin, I find it a lot easier to maintain separate paths in a network fileshare for different architectures due to architecture specific issues, software requirements etc. Using FAT binaries would complicate the issue immensely for me as not every single piece of software, library is going to be available for every architecture. Some software is even written in such a way that it makes it extremely difficult to port over to other architectures (see the issues the Linux developers had getting 64bit working for the majority of applications and libraries initially) - so this is to be expected.
Change is certain; progress is not obligatory.
That said, Con is not my personal poster child for the unfairly rejected: he seems to understand neither software engineering nor macro economics in the large. For example, while Con's patches might improve things for the desktop user in the short term, if it comes at the cost of continued enterprise support for the people who continue to develop the kernel, the victory will be short lived;
Why do desktop users and server/enterprise users need to use the same scheduler? Why not just have different schedulers for different use cases? This seems rather trivial. They already set the HZ value to different values for desktop and server users, because servers don't need the low latency that desktop users do.
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.
You're not quite getting it. YOU may not have other arches around but I do. This isn't about 32-bit vs 64-bit. It's about SPARC vs ARM vs Intel vs MIPS, etc. I would love to be able to use the same binaries. This is especially useful when you don't have source and can't recompile.
This would also make it easier to have commercial software supported on more than 1 CPU architecture. I get REAL pissed about Intel-only Linux and BSD software. There's no reason for it. And now that ARM may catch some steam in netbooks, this is pretty important to me.
I don't want to hear that "well, just run RMS-approved free software" or the "comershul softwear iz teh evil" crap either.
Right, we did the same thing on our mixed networks, but you end up with multiple completely independent installs of the software at that point, including multiple complete versions of the Emacs .el and .elc files and so forth. This isn't such a PITA if you're compiling everything from source because you have to compile it on all those multiple platforms anyhow, but if you're talking about commercial software (gasp! The horror!) you're talking about multiple times the administrative overhead to keep the software up-to-date and functional. If you are in a school environment or in an R&D lab you probably don't notice any of this because schools don't purchase a lot of commercial software and R&D labs are typically self-administered by the zoo animals err developers :), but for corporate workstation deployments these are big issues. In any event I've wasted enough time on this. we're not talking about a huge gain with fat binaries but it does solve a real problem and it's sad that it was rejected as simply "not invented here" by people who have no (zero) clue of real-life IT, as vs. having a reasoned discussion of advantages and disadvantages. But that's how things work in Linux-land nowadays. Makes Theo and RMS look almost rational. Almost.
Send mail here if you want to reach me.
It's not that hard to do file links, honest.
Yes, in which case I prefer seperate, segregated paths for each architecture because you end up with one platform having adobe flash and the other having Gnash, or you'll need a extremely custom setup to get an 32bit-only application working correctly in a 64bit environment (and by custom, I don't mean just installing the 32bit libraries, but stupid issues with things like running into stuff that wants m86_old() and requires modifications all across the system to get working - I have ran into this) etc.
Running two "sudo apt-get install" processes simultaneously is not hard, linking various configuration paths between the 32bit and 64bit setups is dead simple.
Now, dealing with a system where both 32bit and 64bit binaries are one and you need to make special customizing for one is going to be more difficult and annoying.
I'm sure it has it's uses, but in my opinion, it produces more work with networked installations.
Change is certain; progress is not obligatory.