Kernel bugs: out of control?

Posted May 18, 2006 6:48 UTC (Thu) by gowen (guest, #23914)
In reply to: Kernel bugs: out of control? by hazelsct
Parent article: Kernel bugs: out of control?

He's running Debian unstable. And he's complaining that it's unstable. Linus is not the only one struggling with nomenclature.

Kernel 2.6 has a stable branch. The stable branch of 2.6.x is called 2.6.x.y, for large values of y.

to post comments

Kernel bugs: out of control?

Posted May 18, 2006 9:16 UTC (Thu) by malor (guest, #2973) [Link] (1 responses)

You're not reading what I'm saying. I'm using THE KERNEL from Debian unstable, because the kernel from testing doesn't work at all (2.6.15 crashes within an hour in my 865 machines), and the kernel from stable doesn't support all my hardware. I use nothing else from unstable on production servers. I have exactly one machine running the actual unstable distribution in its entirety, because that one clues me in when there's (yet another) kernel patch.

Debian's kernel is pretty much vanilla 2.6.16. Linus et al call Linux 2.6.16 'stable'.

The kernel devs' expectation that 'the distros' will magically fix all their bugs amounts to simple handwaving, shirking of their fundamental responsibility: when they call it stable, it should BE STABLE.

Software that's supported for only two months is not, pretty much by definition, 'stable'.

Kernel bugs: out of control?

Posted May 21, 2006 17:00 UTC (Sun) by nix (subscriber, #2304) [Link]

Actually, stable means `we think it will work'. Length-of-support has nothing to do with it.

Kernel bugs: out of control?

Posted May 18, 2006 9:17 UTC (Thu) by malor (guest, #2973) [Link] (2 responses)

And which 'stable' 2.6 kernel do I choose? And define 'large value of Y'. Bu your definition, 2.6.16.15 should be 'stable', but it lasted THREE DAYS.

Kernel bugs: out of control?

Posted May 18, 2006 9:46 UTC (Thu) by arcticwolf (guest, #8341) [Link] (1 responses)

You're confusing (unintentionally, I assume) two distinct meanings of the word "stable" here. Stable can mean either:

1) Bug-free enough to not crash on most systems encountered in the wild (i.e., "stable" in the sense of "production-ready");
2) Not undergoing changes.

It's important to keep in mind that these are not related to each other. When you say "it lasted THREE DAYS", you apparently mean that it was replaced with a newer patch (.16) three days later - that's the second definition of stable. So, yes, in that sense, 2.6.16.x isn't stable, but that's just because the developers are actually fixing security issues that are found and releasing patches immediately.

Would you rather have them sit on those patches for weeks or months? Well, if you do, you can still have that; nobody's forcing you to apply those new patches.

But in any case, what Andrew Morton talked about was stability in the first sense, and that's a different beast. How long would it have taken for 2.6.16.15 to crash on your boxen? It's hard to say, but I'd guess that unless you'd have been rather unlucky, it would've been more than three days.

So, the answer to your question is: you choose the latest one that's available. Whether you continue to apply newer patches as they come out is your choice, not ours, and complaining that you have downtime when patching security issues in the *kernel* is pretty silly. That's how things are in the real world. (And it's still true that nobody's forcing you to apply anything, so if you'd rather avoid downtime than patch newly-found issues, just don't apply them.)

Kernel bugs: out of control?

Posted May 18, 2006 10:05 UTC (Thu) by malor (guest, #2973) [Link]

It feels like you've read about three sentences of what I've written here, and you're reacting just to that. Most other replies I've put in this thread address these issues. I'd suggest reading them... I'm not going to repeat all of them here.

The strongest objection I have to the current model is that we are forced to take new features with our bugfixes, because they will not support kernels for more than two months. New features = new bugs. New bugs = new patches. New patches = new features. New features = new bugs. And so on.

'Stability', as defined from the point of view of the Linux kernel, should mean:

1) It's maintained with security patches;
2) No fundamental new features are added;
3) Drivers are added, if possible, without violating #2.

In other words.... do it like 2.4 did it, after Marcelo took over. If a new network card comes out, of course you can add the driver to the source tree... it's not going to affect anyone else. If that new driver requires an update to the memory management model of the kernel, then you don't include it in the stable branch, but rather in the dev tree.

I think they might have retrofit the USB system in 2.4... it's been awhile, and I wasn't following it closely, because I didn't need to. I do know that their backports from 2.5 were done without large-scale overhauls of kernel subsystems; they kept the changes focused and very limited. And, by and large, the 2.4 kernel was very stable. It wasn't as solid as 2.2, but it was quite acceptable.

Basically, the kernel devs had the model NAILED during 2.4. This high-speed 2.6 development, on the other hand, is an absolute disaster. These guys are some of the smartest in the business, but they are still human, and they are running into the limitations of their own intelligence. The code has become too complex for them to maintain... it's hard and nasty and difficult work now, and instead of slowing down development, they're ignoring the bugs and SPEEDING UP instead, apparently because that's more fun.

It's significantly less fun for people trying to keep production machines running.

Andrew Morton is most unhappy about the quality of the kernel. That should tell you something.