Hacker News Reader

Comment by thingie | Hacker News Reader

He could write the patch, he could try it and persuade mainline kernel (and glibc and gcc, and...) developers to include it. If the feature is really that useful, he can even maintain it separately, or some Linux distribution can. All of which would be impossible with closed software. Innovation in the oss way, sadly, means, that there are lots of ideas, and most of them thrown out.

Hostile reaction from kernel developers? Well, maybe it's little sad, they could trash the patch more politely or something, but eventually they have to. Fatelf adds stuff to kernel, glibc and few other parts of system without really solving much. He could try something with binfmt_misc and completely userspace, not add junk into kernel and glibc itself. (With junk I mean something unnecessary that can be done in userspace. (or not at all))

View on HN

> without really solving much

On a German Linux news site (prolinux.de), a commercial Linux game developer -- Ankh2, IIRC -- once commented that they could not get their game running on about 2-3% of their customers' Linux computers, despite their best efforts.

I dunno whether FatElf would have solved problems like this in the long run, but there are problems. You may not be affected but this doesn't mean others aren't.

No, I don't think it will solve this kind of problem. It can do the only thing: pack two different binaries into one file, which is also binary, and the kernel has some extra logic to choose, so it is 'transparent'. While this makes some thing easier (if you really don't know whether you want to download that strange 'i386' file or even stranger 'x86_64' file, you download one larger 'fatelf' containing both), it doesn't solve the real problems. Distributions spent quite a lot of effort to make both 32 and 64-bit binaries run on a single system. This is just a hack, nothing more. And it can make the mess even worse. Do I have x86_64 binary in this? Is there a correct elf packed somewhere? How do I know.

> it doesn't solve the real problems.

Well, it would sure make running software on a mixed cluster a lot easier.

But in any case - the proliferation of package "managers" is a bigger problem. I really hope a few Linux distributions die so that we can at least have standardization in an evolutionary manner.

This is just a hack, nothing more.

Well, it is the cornerstone of Apple's highly successful and entirely transparent transition from PPC to x86, including drag-and-drop application installation/uninstallation. Couple it with Apple's compiler drivers and well-designed multi-architecture SDKs, and it becomes dead-simple to support multiple architectures and OS releases. Just build your binaries with -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk

It also supports Apple's transparent selection of armv7/armv6 binaries on the iPhone 3GS.

I'd say it's pretty useful, and not really a hack at all.

The only arguments I've heard against it involve package managers and shell scripts, which demonstrates such a remarkable lack of understanding of ease of use and user behavior that I don't even know where to start, other than to say: This is why popular adoption of Linux on the desktop is not going to happen any time soon.

I'm not saying this is a hack, but just because it has proved a useful strategy in Apple's situation, doesn't mean that it is the right strategy for Linux.

Apple succeeded by going against the conventional wisdom; now, in many ways, Apple is the conventional wisdom. In the end, I think the most important thing is for people to do what feels right for them, not blindly copying what has worked for others.

Apple, on the other hand, doesn't have anything even close to a package manager, for example. Also, "transition". There is no transition for Linux. Nobody is really interested in completely phasing out an old platform and port everything to a completely different new one, which is what Apple did. Apple's Mac OS has rather limited hardware support, in fact you shouldn't even try to run it on anything that doesn't have Apple sticker. Linux is expected to run everywhere on everything.

I can't see any possible difference for the fatelf solution and the package manager and scripts solution for an end user. It's not about the ease of use, because there is no difference.

Also, "transition". There is no transition for Linux.

ARM netbooks? That said, part of why there's no 'transition' is that providing easy-to-use (for consumers) third-party application binaries is this side of impossible given the lack of stable APIs across distributions and releases.

I can't see any possible difference for the fatelf solution and the package manager and scripts solution for an end user. It's not about the ease of use, because there is no difference.

I can drag-install any third-party application I want to download, and I can expect it to work on any machine. The author doesn't have to wait to get it packaged by a distribution, set up a package repository, etc. I don't have to wait 3-12 months for the latest version.

I can drag it over to my PPC iMac, and it'll work there, too.

How is that not 'different'?

Yeah. I hear double clicking on an rpm/dpkg is really difficult.

ARM netbook with its limited SSD disk space is really a great usecase for something that makes binaries two (three, or even more) times larger, while I need only the binary for ARM. (Yeah, it's not that much for > 100G HDD, still, it can be quite a lot for 4 or 8G SSD. Especially when it is completely useless for the computer.)

It's not different, because fatelf doesn't help with this. You can still make some tiny wrapper, and have completely the same thing. Vendor still have to make a package fit for your system, for the set of libraries that you have, correct versions of them, and so on. Yes, Mac OS X system has two or three recent different versions, mostly mutually compatible. If you were trying to make a package for only one or two mostly compatible Linux distributions and one or two of their versions, then it would be also that easy. But it is not, and fatelf doesn't make any difference.

> He could try something with binfmt_misc...

Exactly! And that sounds like it would have been the smartest move from the start. Something like this doesn't need to be in the kernel. It doesn't need to be in glibc, and doesn't need to be in ld. There are probably performance advantages that you miss out on by using binfmt_misc, but that's the perfect way to get your solution working without any external dependencies. You create two userspace tools: 1) an app that stitches together multiple binaries into a FatELF file, and 2) a launcher program that, when given the path to a FatELF file, picks the correct embedded binary and runs it. #2 might need some fancy tricks with the dynamic loader, but it's certainly doable.

Assuming people do like it and use it, only then do you try to get it integrated into the system proper. Why try to push something into three pieces of software very core to Linux and Linux development when there's no evidence that there will be any developer, distro, or user adoption?

Reply on news.ycombinator.com