Quotes of the week

[Posted November 4, 2009 by corbet]

Unfortunately, our biggest competitors are our previous kernels, and we (were?) really good at writing really fast kernels. And most of our users who are running the competition are completely satisfied with all the features it has, so an "upgrade" that causes a slowdown does not go down well. A feature that 0.01% of people might use but causes a 0.1% slowdown for everyone else... may not actually be a good idea. Performance is a feature too, and every time we do this, we trade off a little bit of that for things most people don't need.

-- Nick Piggin

The fact is, maintainership does _not_ mean ownership. It means that you should be _responsible_ for the code, and you get credit for it, but if problems happen you do NOT "own" it. Not at all.

If you don't understand that, you shouldn't be a maintainer.

-- Linus Torvalds

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.

I didn't really expect to be walking into the buzzsaw that I did. I imagined people would discuss the merits and flaws of the idea and we'd work towards an agreeable solution that improves Linux for everyone. It sure seemed to be going that way at first. Ultimately, I got hit over the head with package management, the bane of third-party development, as a panacea for everything.

-- Ryan Gordon

If anyone wants a choice quote from me about the recent Linux holes, this is what I have to say: Linus is too busy thinking about masturabating [sic] monkeys, he doesn't have time to care about Linux security.

-- Theo de Raadt

Quotes of the week

Posted Nov 5, 2009 2:36 UTC (Thu) by MisterIO (guest, #36192) [Link] (8 responses)

About de Raadt citation, the post that seemed to make more sense was actually Torvalds' view on security.

About FatELF, to me it seems useless. It doesn't solve what it claims to solve and it creates a lot of problems for the rest of the user space software stack.

Quotes of the week

Posted Nov 5, 2009 12:27 UTC (Thu) by nye (subscriber, #51576) [Link] (5 responses)

What problems?

Quotes of the week

Posted Nov 5, 2009 13:30 UTC (Thu) by MisterIO (guest, #36192) [Link] (4 responses)

Well, you need to support it, don't you? So you need to support it on the kernel, the loader, the c library and many other things related to the elf format. All this to solve a non-existent problem(I agree with Ullrich) or at most to achieve something that could have been achieved at the packaging level with less problems. It'd also make executables(on disk) bloated for each case, instead of having many different normal executables.

Quotes of the week

Posted Nov 5, 2009 14:03 UTC (Thu) by farnz (subscriber, #17727) [Link]

Not only that, but if your critical components (mount etc, as needed to get your filesystems working) are in traditional ELF, FatELF can be implemented purely in userspace, using binfmt_misc, and a custom FatELF loader.

Quotes of the week

Posted Nov 5, 2009 17:44 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

As opposed to the existing biarch approach, where you need support in
every single app that ever loads plugins. Currently gtk and glib at least
are hardwired to load plugins out of "/.../lib/..." so fail in a biarch
world: lots of distros have to carry around patches for this.

And if gtk/glib can't get it right, why do we expect everyone else to?

Quotes of the week

Posted Nov 5, 2009 20:28 UTC (Thu) by bronson (subscriber, #4806) [Link] (1 responses)

So, because gtk/glib can't get it right, we need to scatter fixes throughout the world? This sounds like a cure that's worse than the disease, doesn't it?

Why not just fix gtk/glib?

Quotes of the week

Posted Nov 5, 2009 22:23 UTC (Thu) by nix (subscriber, #2304) [Link]

gtk, and glib, and every other package which ever wants to support plugins
or read things from $libdir, forever.

Does that really seem sane? Normally we have the dynamic linker handle
this stuff for us. Why can't it help here? ('Ulrich rejects everything
without looking at it on dubious personal taste grounds' is not a good
answer.)

Quotes of the week

Posted Nov 5, 2009 18:44 UTC (Thu) by iabervon (subscriber, #722) [Link] (1 responses)

I think it doesn't actually solve a lot of problems that it could be applied to, but I think it does solve a real problem: on a system that runs code in multiple architectures, what architecture's libraries are in the normal places for finding libraries? If, for example, you had a system that ran both x86 and ia64, you couldn't comply with the standards without using the same files for libraries on both, because the standards specify that each of these has its libraries in /lib. (Imagine a cluster which appears as a single system, but runs the supercomputer programs on ia64 nodes and postgres on x86 nodes, with processes being assigned to node types at exec time, but the dynamic linker and dlopen needing to be able to find the correct code in the normal location, which is the same for the two architectures.)

Of course, this would also clean up the common situation of having both x86 and x86_64 libraries on the same system, wanting to run some programs of each architecture (because different programs perform better on each architecture), and wanting to avoid the hassles of having libraries in places that not every developer has them.

Quotes of the week

Posted Nov 9, 2009 16:24 UTC (Mon) by gmaxwell (guest, #30048) [Link]

on a system that runs code in multiple architectures, what architecture's libraries are in the normal places for finding libraries?

So Lets assume that it can solve that problem, which could otherwise be solved with some intelligence in the dynamic linker (which it already has) and an environment variable for runtime loaded libraries, it really only replaces it with a different one in that no package manager can reasonably handle different parts of a file belonging to different packages. So distros would need to force bloated binaries on everyone, support yet another effective arch for bloatbins, or implement some crazy fatelf binary merging in their package management system.

Quotes of the week

Posted Nov 5, 2009 14:16 UTC (Thu) by clugstj (subscriber, #4020) [Link] (5 responses)

"FatELF"

The attitude of the originator of the patch seems to be that Mac OSX has it, therefore Linux needs it also. Fortunately, features for features sake isn't flying with many of the kernel maintainers.

Quotes of the week

Posted Nov 5, 2009 20:24 UTC (Thu) by bronson (subscriber, #4806) [Link]

Agreed, this is a complex solution searching for a simple problem.

FWIW I find if you read "blarch" instead of "biarch" it makes the conversations a lot more tolerable.

Quotes of the week

Posted Nov 6, 2009 16:58 UTC (Fri) by Tet (guest, #5433) [Link] (3 responses)

No, FatELF came about to solve some very real problems that can't be solved otherwise. It happens to also be an option for some other things that can be solved by other means (for example, package management). But it solved a problem, which now will remain unsolved due to the unwillingness of some kernel developers to actually think about the issue.

Quotes of the week

Posted Nov 6, 2009 17:33 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

So, what problems are there? Please, demonstrate them with a comparison using an existing user-space implementation of FatELF - you don't need kernel support for a binary format (binfmt_misc exists for a reason).

You only need kernel support for a binary format if your critical binaries you need to mount a filesystem and execute the dynamic loader are in that format - this is why ELF is in-kernel. Beyond that, a userspace dynamic loader can do what the in-kernel handling does, thus proving the value of FatELF in the real world. Once you've got that proof (e.g. every distro using ld.fatelf.so), then kernel inclusion is worth discussing.

Quotes of the week

Posted Nov 6, 2009 20:34 UTC (Fri) by Tet (guest, #5433) [Link] (1 responses)

Largely, I think we're agreeing. The specific example I was thinking of (and indeed, which I've been bitten by in the last few weeks) is ~/.mozilla/plugins. binfmt_misc won't help there, but ld.fatelf.so would. I was arguing for FatELF as a concept, not necessarily for the specific kernel implementation. Remember, there's more to FatELF than just the kernel patches. Ryan also provided patches for glibc, binutils and gdb. But Ulrich has refused to consider a FatELF ld.so, so we're basically screwed.

Quotes of the week

Posted Nov 6, 2009 22:29 UTC (Fri) by farnz (subscriber, #17727) [Link]

No, we're not agreeing at all. You appear to be under the impression that because I'm not savaging you, I agree - right now, I am undecided, but slightly biased against FatELF, after my limited experience of OS X "universal" binaries (which appear to not work properly, in as much as my experience of them is that the binaries don't work on PPC or x86, and the developers neither supply source, not support whichever architecture you have in hand beyond compiling the universal binary).

binfmt_misc is the kernel side of the support infrastructure you need to make an ld.fatelf.so work transparently to the end-user. Where's the implementation of ld.fatelf.so? Why do we need it in-kernel now? What problems does it solve that I've experienced, whether in using Linux distributions, in supporting them as part of an end-user product, or in supporting the use of Linux as the only OS on my wife's computer?

I'm seeing an awful lot of assumptions on the part of FatELF supporters that everyone has seen the problems they've seen, and, well, I haven't. I see a solution looking to create me the same problems I experienced trying to make binary-only software work on Mac OS X, and I don't like it, but I'd like someone to tell me what the positives are. Thus far, all I see is more code, less testing, and people telling me that I must accept it, because it solves a problem that is better solved elsewhere.

Quotes of the week

Posted Nov 5, 2009 15:17 UTC (Thu) by mattdm (subscriber, #18) [Link] (1 responses)

To be fair to Theo de Raadt, this message from Linussome important context.

(But I gotta say, my first thought was "Isn't that upcoming Ubuntu release?")

Quotes of the week

Posted Nov 8, 2009 18:33 UTC (Sun) by ikm (guest, #493) [Link]

> my first thought was "Isn't that upcoming Ubuntu release?"

Good one! :)

False sarcasm

Posted Nov 5, 2009 17:44 UTC (Thu) by proski (subscriber, #104) [Link]

The Linus quote about code ownership sounds sarcastic at the first glance. But in the context, Linus is serious. And he is right too.

Quotes of the week

Posted Nov 7, 2009 2:23 UTC (Sat) by leoc (guest, #39773) [Link]

"package management, the bane of third-party development"

It seems to me that Apple itself agrees with the kernel developers, as they have moved their most important platform over to a package management system (aka the "app store"), rather than rely on independent third party distributors pushing out universal binaries for ARM.