LWN.net Weekly Edition for June 20, 2013

LWN.net Weekly Edition for June 13, 2013

A report from pgCon 2013

Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Quotes of the week

[Posted January 5, 2005 by corbet]

After 2.6.9-ac its clear that the long 2.6.9 process worked very badly. While 2.6.10 is looking much better its long period meant the allegedly "official" base kernel was a complete pile of insecure donkey turd for months. That doesn't hurt most vendor users but it does hurt those trying to do stuff on the base kernels very badly.

-- Alan Cox

Not all 2.6.x kernels will be good; but if we do releases every 1 or 2 weeks, some of them *will* be good. The problem with the -rc releases is that we try to predict in advance which releases in advance will be stable, and we don't seem to be able to do a good job of that. If we do a release every week, my guess is that at least 1 in 3 releases will turn out to be stable enough for most purposes. But we won't know until after 2 or 3 days which releases will be the good ones.

-- Ted Ts'o

(Log in to post comments)

Quotes of the week

Posted Jan 7, 2005 18:25 UTC (Fri) by mgalgoci (guest, #24168) [Link]

Perhaps what we need is to have packages for each major distribution
built with the virgin -rc kernels and made available for wider testing.

Many people like to avoid the download-compile-reboot cycle until there is
a final kernel for various reasons, eg, for some people it takes a good
hour or three to get things set up.

I am an active tester of fedora rawhide kernels simply because I am lazy
and I know that the fedora kernel team does a good job at keeping their
development kernels on the bleeding edge.

Quotes of the week

Posted Jan 8, 2005 4:54 UTC (Sat) by jd (guest, #26381) [Link]

I'm surprised the kernel is having so many security and other problems. Stanford has a cool program checker, which was used to great effect on the Linux kernel in the past. I'm sure they could be talked into either using it again, or supplying the key people (eg: Linus Torvalds, Alan Cox, Andrew Morton) with a copy so that they could validate the kernel and patches.

Then, there's the Linux Test Project. "2100+ tests", according to their website. That really aught to have picked up more than a few of the errors that have been subsequently discovered. If it did (or could have), then there is a problem with the development model, as the problems were NOT discovered in time. On the other hand, if it couldn't, the LTP group might want to re-examine those tests.

Problems are (almost) unavoidable. Unless you're willing to invest the resources into doing comprehensive auditing and code correctness proofs. That's unlikely to happen any time soon, though, so we're stuck with problems happening. However, they do seem to be happening a lot. Now, it's not without precedent - Linux 2.0 didn't "really" become stable until 2.0.20. That 2.6 is rough around the edges at .10 is within historic bounds. There have also been plenty of other "brown paper bag" releases amongst the stable kernels, in Linux' history. This is not something that has suddenly happened.

The question I would pose, though, is do we want it to continue like this? Or is it time Linus not only asked people to show him the code, but also insisted that they showed him a reason why the new code was better than what was already there. The tools for kernel developers to do their own QA are out there, and therefore the data could exist for Linus to visibly see that patch A fixed more bugs than it added. It wouldn'd solve everything, but if it reduced the number of needless bug additions by one per active developer, then every single component under development would have gained.

IMHO, that would be a worthwhile gain.

Quotes of the week

Posted Jan 9, 2005 8:09 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]

read the kernel mailing list for a while and you will see that Linus does demand justification as to why the new code is better then the old code before he accepts it.

there are two problems with the tests

the biggest one is that they test the things that broke in the past and so don't catch new types of breakage. when something new breaks the tests get updated to check for it as well

the second thing is that the testers get the new kernels at the same time as everyone else so they can't test them before they are released.

this second thing is actually a very good thing, it means that there aren't specific 'blessed' testers that people have to qualify as, it means that anyone who wants to can start testing and when they are useful people will pay attention to them

you have to watch out for the perfection trap. if you try to make absolutly no errors you can spend a LOOONG time trying to get everything right in a complex system (look at Debian trying to make an error free release for a perfect real-world example). at some point you need to accept that you're not going to be 100% perfect, try your best, and be prepared to fix things as problems are found