Slashdot Mirror
Linux v2.6 Begins Testing
xose quotes Linus from the kernel list: "the naming should be familiar - it's the same deal as with 2.4.0.
One difference is that while 2.4.0 took about 7 months from the pre1 to
the final release, I hope (and believe) that we have fewer issues facing
us in the current 2.6.0. But very obviously there are going to be a
few test-releases before the real thing.
The point of the test versions is to make more people realize that they
need testing and get some straggling developers realizing that it's too
late to worry about the next big feature. I'm hoping that Linux vendors
will start offering the test kernels as installation alternatives, and
do things like make upgrade internal machines, so that when the real
2.6.0 does happen, we're all set." You all know what to do ;) Update: 07/14 17:49 GMT by S : OverNeith writes "Joe Pranevich has done it again! He's written another summary document on what to expect in the new and upcoming 2.6 Kernel!"
All I see is badness coming from this. If someone is good enough with unix to want to use the 2.6 kernel to develop software, odds are they already know how to download and install the kernel themselves. If, on the other hand, we have someone new to Linux see 2.6 and think "that must be better than that old 2.4 kernel POS", and proceed to choose that one, odds are is that the 2.6 kernel is going to result in a less-than-stable system, and is going to look badly upon linux in the future.
Although to be fair, Gentoo does require you to do some configuration for your kernel, to select the network card drivers and such. It isn't effortless with the kernel.
It's not the driver, it's just that Linux Kernel 2.4.x is not preemptible. In other words, the kernel system calls, like read and write, are made to be interruptable in 2.6.x. Basically, it adds some code that allows something else in the kernel to run if one thing is waiting, say, for some sort of input, which improves latency for short periods of time. Linux Journal, May 2002 edition explained this and they had a latency graph of a system playing music under a load. Without the preemptible patch, there were huge spikes in latency (basically audible as gaps in the music) but with the patch, there were minimal changes in the latency. Just today, I noticed something similar to what you talked about. I was ripping CD's and then encoding them as Ogg. Apparently, cdparanoia does system calls that have high latency and since they can't be interrupted, working in X is slow. However, since Ogg encoding is mostly userspace, X was much faster even though more of my processor was being used. Recently, Slashdot linked to an article outlining the changes in 2.6. People have also been making patches for 2.4 for a long while to improve latency, and I think there is a backport of the low latency patch to 2.4.
I thought 2.6 was suppose to have crashdump support? If not, that's to bad, because often that is what is required to fix problems in the real world. Often the technical person isn't the same person who is using the machine. There needs to be a way for the technical person to figure out what went wrong after the fact. OOP's are about as useful as the BSOD data. Plus, unless its a repeatable problem usually by the time the machine crashes its a little to late to run out and hook up a serial console.
This quote may sound quite arrogant and that Linux isn't suited to the business world - but think about it for a minute - what he said was "We're going to do it our way, making sure it all works, rather than release it before testing properly". I'm glad someone has the sense to do this. How long was it before Microsoft Apps get patched? Something like hours after release? I'd prefer something stable (or as stable as possible) on release, and I thank Linus (and Alan, and Dave) for taking their time. I'm pretty sure we all can't wait until these new features come out - but I'd rather wait for them to become stable instead of risk my precious collection of... well... you catch my drift. =)
Though honestly, much of MS software is also sold shrinkwrapped. This gives a latency between the final build, documentation print run, CD pressing, packaging and distribution that doesn't exist with something like the linux kernel. During this time development continues, which is why you can have patches for a game or application avaliable before said product is even in wide distribution.
And again honestly, I don't think you can argue that the linux stable series are released as "full quality" and don't need patches right away. History does not support such claims.
Indeed, Linus knows this; he sees the problem that the unstable series doesn't get tested well enough and that only slapping a 2.even.0 number on it increase the testing crosssection several orders of magnitude.
In conclusion, I think you should read "it'll be released when it's done" not mainly as an assurance of release quality, but as a short form for "it'll be released when I think we'll have a good enough chance of getting people to test this without getting too badly burned".
Belief is the currency of delusion.