Slashdot Mirror
Last 2.5.x Linux Kernel Released
Kourino writes "Today on LKML,
Linus released 2.5.75, which he said will be "the last 2.5.x kernel from me", and that he and Andrew Morton are going to start a 2.6-pre series soon. While this certainly does mean things could get interesting soon, don't hold your breath about seeing the actual 2.6 for a while; there are still many areas that need work. This essentially means that the development branch is going into maintenance mode, and new features probably won't get in after this point. Changes of note in 2.5.75 include a merge of the anticipatory scheduler from Andrew Morton's -mm tree and updates from several architectures."
So why would they set the feature freeze for Halloween if new features wont be allowed in after mid July?? Or does the feature freeze have nothing to do with features being added? I'm highly confused.
All stable kernel series take a while to sort themselves out. Stable series doesn't mean bug-free, it means working toward such as a matter of priority instead of actively adding new bells, whistles and capabilities. Don't install and run 2.6.0 (or 2.4.0 for that matter), give it some time to stabilize. No kernel since 1.2.x has been particularly stable early on.
As for the eventual stability of 2.4.x, I have an SMP file/print/Web/DHCP/DNS server running in one of the labs that I volunteer to run that has been running 2.4.18 since it was released sometime in late February 2002... it has only had one reboot, to replace a UPS whose battery went dead. It runs 24/7 and has crashed/frozen exactly zero times. Average load is generally above 2-3 during open hours.
That's not bad for a "work in progress" kernel!
STOP . AMERICA . NOW
It seems to me that the problem is that the number of people who try to use 2.6.0 will be far greater than the number that try 2.5.x. Therefore, the probability that a whole new set of bugs will appear (probably not major ones, but a fair number of minor ones) is quite high, and there's nothing that the kernel developers can really do to prevent this happening. This is even more true than int the past because of the ever-increasing ratio of Linux users to Linux kernel developers.
I protested the release of 2.4, saying its inclusion in distros would cause users to unknowingly run a poor quality kernel, but Linus said the reason he wanted it released was so that it would get more widespread testing.
The "stable" branch of the kernel is perhaps misnamed. Linus gets to release a new kernel whenever he wants, and I imagine he does some testing, but I don't think he puts a stable release through any kind of rigourous qualification, I think it's more like when the complaints about his pre- versions die down a little.
I know it's common for Linus to release stable kernels that are actually quite broken on some non-x86 architectures. People who run Linux on PowerPC use a branch that's extensively patched from Linus' releases.
Both the 2.4 and 2.2 kernels went through a number of releases before they were really usable. I think the reason 2.2 became reliable was that it was smaller and simpler, and fewer people were working on it.
I'm pretty sure a good part of the reason behind the establishment of the Open Source Development Lab and their hiring of prominent kernel developers like Linus and Andrew Morton is to make sure that 2.6 actually does turn out to be enterprise quality. IBM is a big backer of OSDL, and I don't think they want the billion dollar investment in Linux in general to go to waste.
Request your free CD of my piano music.
o Faster CD recording that doesn't need ide-scsi;
It's about goddamn motherfucking time. God the IDE CD running SCSI emulation is the biggest piece of shit I've seen on Linux. I have a box that has run rh 7.2 and now runs rh 9 and the only thing that locks this box up is anything out of the ordinary having to do with the CD-r (such as the pathetic piece of SHIT that GNOME calls CD player software - who made this crap the default desktop in RH? [And yes, I know I can run KDE (in fact I use the CD player kscd from that environment) but having heard how RH mucked around with KDE to 'unify' it with gnome, I'm leery of that]). Last night, that junk locked my machine so solid I couldn't login over the network, the Xserver froze (except for the mouse) and I had to hardware-reset it, fsck all the filesystems on reboot [even though I'm using ext3] and then it spent all fucking night resyncing the raid mirrors.
I love Linux, I've been a fantic about it since 1999, but that ide-scsi was terrible fucking hack.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
Try Gentoo You'll have to compile the 2.5-kernel yourself, but the distro will prep the system for you, among other things ;)
"The only clear view is from atop the mountain of our dead selves." - Peter Carroll
Though we're bordering on offtopic here, because this discussion isn't as closely related to the kernel as it could be, I'm fairly convinced needs no focus as you imply.
First of all, the Linux kernel is and will be the most important readily available high performance computing platform. I cannot imagine a design decision with more than temporary character that will slow down the kernel. Through constant improvement it will lead on all 64bit platforms, Dec Alpha, PowerPC, IA-64 and x86-64. We all know, in the long run, open source isn't beatable in improvement. The kernel is already far on the right side of that curve.
Now, should Linux developers at large focus on scientific computing, or the desktop, on both? Actually this is a "no-question". The development force of open source will always distribute itself along its own best interests, not because of what anybody told them. Till now the technical gurus of programming turned the core of the GNU/Linux OS in what it is, but the evergrowing developer community is attracting more and more apps developers (they are simply more readily available). So while the kernel project is readily scaling to bigger and bigger feats, the app world will still aim for the desktop, the poweruser's desktop first. Simply because there are many people that want to provide apps and simply will do. This will not impair kernel development in any way, and anyhow those people have no different needs from the kernel as the scientists have: stable, efficient, robust.
Since the POSIX and other standards strongly decoupled OS internals from the apps developers (what's going on behind the scenes is no business of the apps developer) we have the power to do it both, in parallel, with no friction.
My car still, by default, requires a check-up every now and then. That just screams stability.
0x or or snor perron?!