Kernel bugs: out of control?

Posted May 11, 2006 23:59 UTC (Thu) by malor (guest, #2973)
In reply to: Kernel bugs: out of control? by vmole
Parent article: Kernel bugs: out of control?

I'm running testing on production servers because testing is current enough to be useful and essentially never breaks things. I'm just using the kernel from unstable, becuase that's the only one that works in all cases. I actually had to use a Ubuntu kernel for awhile when things were really bad with 2.6.15.

Linux 2.4 always pushed security fixes out right away... I don't remember Marcelo sitting on security patches. He'd accumulate a bunch of non-security stuff and roll it out all at once, but security patches were immediate release. And in the 5.5 years of 2.4's existence, it's had 32 total releases... and 10 of those were when Linus was still tinkering with it. So 22 is more accurate.

22 patches in 5 years, I can handle, particularly since many of them were optional... just new drivers, not security fixes, which meant they could be deployed whenever there was time.

16 patches in five weeks, nearly all of them immediate must-install security fixes... that's not so good.

to post comments

Kernel bugs: out of control?

Posted May 12, 2006 13:51 UTC (Fri) by vmole (guest, #111) [Link] (7 responses)

I want a kernel that supports the latest hardware
I don't want the kernel to change, or have bugs

Pick one.

Kernel bugs: out of control?

Posted May 16, 2006 16:23 UTC (Tue) by hazelsct (guest, #3659) [Link] (6 responses)

No. It's more like, don't call it "stable" unless/until it is.

Kernel bugs: out of control?

Posted May 18, 2006 6:48 UTC (Thu) by gowen (guest, #23914) [Link] (5 responses)

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.

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.

Kernel bugs: out of control?

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

Most of the security fixes weren't `immediate must-install'. A goodly number related to single drivers or obscure new protocols: SMB/CIFS, SCTP...

... I mean, the SCTP code is, what, a kernel release old? Thus, it has bugs; some of which may be remotely exploitable (by the nature of network protocol code). How terribly shocking.