Stable kernel 2.6.16.8 released
Posted Apr 19, 2006 4:40 UTC (Wed)
by clump (subscriber, #27801)
[Link] (17 responses)
Posted Apr 19, 2006 9:32 UTC (Wed)
by nix (subscriber, #2304)
[Link] (14 responses)
Posted Apr 19, 2006 10:20 UTC (Wed)
by hawk (subscriber, #3195)
[Link] (5 responses)
Prompt fixes for found problems really is a good thing. Then of course, one might argue that the way the 2.6 series is being developed introduces an unnecessary amount of problems, but this at least handles that reasonably well.
Posted Apr 19, 2006 10:25 UTC (Wed)
by nix (subscriber, #2304)
[Link]
(Oh look another release, 2.6.16.9, working around an AMD FPU bug.)
I guess it's just that a *lot* of security problems are coming to light right now. The question, I suppose, is what's got everyone so eagle-eyed all of a sudden (perhaps it's simply that more people are asking 'what is the security impact of this bug I just fixed?'.)
Posted Apr 19, 2006 11:07 UTC (Wed)
by DG (subscriber, #16978)
[Link] (3 responses)
At least then it would be able to get to the point where a vanilla kernel.org kernel can be deemed stable, and used in a production environment. As it is, it's necessary to rely upon either a vendor's kernel, or use something that's a moving target (e.g. the need to upgrade udev between 2.6.14 and 2.6.15).
Without a true stable branch, will Linux be able to claim that it's reliable and robust in the future?
I'm happy to have to upgrade to fix security bugs (are some the result of the Coverity scan?), but I'm not happy when that upgrade results in the need to upgrade other non-kernel components.
Posted Apr 19, 2006 12:13 UTC (Wed)
by nix (subscriber, #2304)
[Link] (2 responses)
It's just that there's no point backporting drivers to it (yahay!) because the development process now moves so fast that a jump vaguely equivalent to that between 2.4 and 2.6 now happens every three months or so. Feel free to drop the .6 and think of 2.6.16.1 as 2.16.1 if you like. :)
Posted Apr 19, 2006 12:14 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Apr 19, 2006 13:34 UTC (Wed)
by DG (subscriber, #16978)
[Link]
Posted Apr 19, 2006 10:46 UTC (Wed)
by NAR (subscriber, #1313)
[Link] (7 responses)
I wonder when will we get to the point that people won't install 2.6.x.y, where y<5 because they're afraid that a remote security hole will be detected (and fixed) and their system will be exposed to the vulnerability between the detection and the installation of the new kernel. Then we will have just finished a new lap on the "users only install 'stable' kernel - kernel doesn't receive enough testing if it's not marked as 'stable' - let's mark the just finished kernel 'stable' and let the users test it - users will stay away from the 'stable' kernel, because it's not stable" circuit.
Posted Apr 19, 2006 12:19 UTC (Wed)
by nix (subscriber, #2304)
[Link] (6 responses)
There's little point not installing 2.6.x because a vulnerability might be found, because a good few of these vulnerabilities exist in older kernels too... but other vulnerabilities may exist in those older kernels that was fixed or removed as part of general code churn, and no kernel hacker's likely to spot that (auditing obsolete kernels doesn't seem very rewarding). So the only people who'll spot *those* holes are the crackers.
So it really is a good idea to use 2.6.recent, especially if you're not using a distro kernel. People still pop up on l-k from time to time using things like unpatched vanilla 2.6.8 kernels, which strikes me as complete lunacy from a security perspective.
Posted Apr 19, 2006 14:50 UTC (Wed)
by NAR (subscriber, #1313)
[Link] (5 responses)
The problem is that the so called stable kernel releases tend to break userspace tools, e.g. cdrecord was broken around 2.6.9, mplayer was broken after 2.6.14 (even though the bug is supposed to be in mplayer) and some hotplug-related(?) tool was mentioned here at LWN which was also broken. That's why some users are reluctant to upgrade to the latest kernel.
I think if this 2.6.16.x will be really maintained, there is a possibility that the users will stick to this, while the 2.6.y (y>16) will be development branch like 2.5.x used to be.
Posted Apr 19, 2006 15:15 UTC (Wed)
by Duncan (guest, #6647)
[Link] (2 responses)
Duncan
Posted Apr 19, 2006 15:26 UTC (Wed)
by NAR (subscriber, #1313)
[Link] (1 responses)
Posted Apr 20, 2006 1:37 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
Posted Apr 19, 2006 15:50 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
Yes, buggy userspace programs may get broken (e.g. mplayer); if the mplayer bug was what I think it was it was fixed swiftly. As for cdrecord getting broken, well, what do you think the chance of Joerg actually *fixing* problems in his code is? Unless it totally breaks, on past form, he'll claim his code is entirely spotless and faultless, ignore any deprecation warnings and just add more pointless moaning to cdrecord about how broken the Linux kernel is and how you should use OpenSolaris instead. (The 2.6.9 breakage was to some degree cdrecord's fault, and it tries to work around it with a fix that makes the problem worse, but that thankfully is so buggy that it only kicks in for 2.6.9 and not for 2.6.10+.)
IMNSHO the best fix to cdrecord problems is to switch to the dvdrtools instead: all the cdrecord goodness (with a different name, dvdrecord, but it still works with CD recorders), plus it's still free software and it has a developer who's actually rational.
The repeated udev breaks were mostly due to sysfs structure churn pricking bugs in udev; in most cases that sysfs structure churn was necessary (unless you like having e.g. multiple files with the same name in one directory). My understanding is that Linus has put his foot down and this will churn less from now on, too.
As I understand it, the intent is maintain 2.6.16.x until 2.6.18 is released. It's not long-term stable: it's a short-term critical fixes branch, so you can get security and stability fixes *immediately*. The intent is that you track 2.6.latest, and upgrade to -stable kernels if you need them. If you want 2.6.16.x fixes even after 2.6.18 is released, stick with a distro that's released 2.6.16, or backport them, or pay someone else to.
Posted Apr 20, 2006 13:23 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Apr 19, 2006 18:02 UTC (Wed)
by iabervon (subscriber, #722)
[Link] (1 responses)
Posted Apr 19, 2006 19:51 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Apr 19, 2006 13:17 UTC (Wed)
by ledow (guest, #11753)
[Link]
I know that they won't introduce major compatibility problems or require userspace updates etc. and can even usually safely remain on the 2.6.16 system without issues for quite a while (at least until 2.6.17 for instance).
And all that dodgy stuff that requires updates, changes and patches can wait until 2.6.17 actually comes out (usually only a few months apart).
The greatest part of it all is the timing - I get instant security updates without major changes occuring. I get to run a stable system for months at a time. I get to see new features every few months. And the speed of the updates and the numbering system should be encouraging more people to keep their kernel moving forward faster than before - already 2.6.15 is obsolete and patches/bugs/etc. are ignored if they don't apply to 2.6.16 as well.
The time between major kernels is also only just enough to generate a serious working and prevelant exploit for any of the problems fixed (so even those who choose to stay on 2.6.xx kernels instead of 2.6.xx.yy don't cause THAT many problems for others or themselves).
However, I sympathise with embedded developers etc. whose kernel dates much faster than before (even if only by a numbering illusion). But no matter WHEN you fix something onto a chip, you're always opening yourself up to whatever comes after it. It's the same as running a distro - the second you release Slackware 11, there will be at least one major security problem immediately afterwards that you'll have to patch for, even if there haven't been any for months beforehand.
This is overall a good thing for embedded developers - it means that the way to go is with updateable systems, not cast-in-iron ancient kernels.
I am glad they're releasing more instead of releasing less. Letting bugs and security vulerabilities wait until the next version is not to my preference.Stable kernel 2.6.16.8 released
Indeed so. It's not as if Greg's standing over us forcing us to install the latest -stable; we can do it whenever a problem we care about is fixed. And 'cos they're tiny and trivially checkable they're easy to release :) this was sort of the premise of -stable, and it's nice to see it panning out.Stable kernel 2.6.16.8 released
Yes, while some people complain about the numerous versions being released, this really is so much better than 2.6 started out!Stable kernel 2.6.16.8 released
Indeed. The -stable approach seems to be that security fixes go out *now*, while other stuff gets queued for a week or so. That seems reasonable.Stable kernel 2.6.16.8 released
<moan>Stable kernel 2.6.16.8 released
I just wish there was a real stable 2.6 branch, like 2.0, 2.2, 2.4 etc, where new versions are released which contain only fixes for known problems.
</moan>
There is a real stable 2.6 branch. Greg's maintaining it.Stable kernel 2.6.16.8 released
Er, the stable team's maintaining it, that is. I don't mean to play down the contributions of anyone on the team....Stable kernel 2.6.16.8 released
Aaah. I'd read somewhere (probably lwn) that someone was going to create a more stable branch, but hadn't realised that this was it. Thank you.Stable kernel 2.6.16.8 released
It's not as if Greg's standing over us forcing us to install the latest -stable; we can do it whenever a problem we care about is fixed.
Stable kernel 2.6.16.8 released
The difference here is that the -stable kernel patches, especially the quickie ones fixing one security hole (which are the only ones that ever come out with extreme frequency) are *so* small that it's fairly easy to audit them by eye and make sure that they don't make things *worse*. Hell, I can do that for the most part and I'm not much of a kernel hacker at all.Stable kernel 2.6.16.8 released
There's little point not installing 2.6.x because a vulnerability might be found, because a good few of these vulnerabilities exist in older kernels too...
Stable kernel 2.6.16.8 released
The CDRecord thing around 2.6.9 was a security issue (something to do with Stable kernel 2.6.16.8 released
SCSI commands that could hose your data enabled for non-root), so there
wasn't much choice /but/ to break it. Otherwise, it wouldn't have been
broken. I recall some of the (LWN coverage of) the debate at the time.
Yes, you're right, but on my single user home computer without SCSI disks I care more about being able to burn CDs than that security flaw.
Stable kernel 2.6.16.8 released
Then why would you upgrade?Stable kernel 2.6.16.8 released
The -stable releases I was talking about were releases of the -stable branch. Those releases won't break anything.Stable kernel 2.6.16.8 released
I said
Stable kernel 2.6.16.8 released
Those releases won't break anything.
Well, except for the Sun JVM it seems :/
It might be worth listing all of the quick release changes since the list slow cycle in the announcement, though, since it's easy to miss a couple of the quick ones. It might also be worth using lowercase letters at the end instead of incrementing the number, like (IIRC) OpenSSL does.Stable kernel 2.6.16.8 released
Oh, please keep it numeric. For the sake of packagers everywhere keep it numeric.Stable kernel 2.6.16.8 released
I definitely think this new release system is better. I can run a stable system using just, say, plain 2.6.16 and then MANUALLY check the changelog for any -stable updates that need to be fixed (most of them fix parts I don't use or issues I don't have) and only upgrade to that 2.6.16.x kernel if I need one of them.Stable kernel 2.6.16.8 released