Linux creator Linus Torvalds announced the third release candidate for the upcoming 2.6.24 kernel summarizing, "hmmm.. Lots of small fixes, some cleanups, and a few things like the cris updates that aren't really either, but which won't affect any normal user, and will hopefully make it easier to sync up in the future. Network driver fixes, some IDE and infiniband updates, some late cpufreq updates, and a hwmon update." He continued:
"On the architecture side, in addition to the afore-mentioned cris updates, there are some sh, arm, powerpc and mips updates, and also one final x86 unification cleanup (and I really mean it - the rest can wait until after 2.6.24, but with this one the x86 configuration really is fairly merged, and both i386 and x86_64 are really just special cases of the 'x86' architecture in the configurator)."
From: Linus Torvalds
Subject: Linux 2.6.24-rc3
Date: Nov 16, 10:33 pm 2007
Hmmm.. Lots of small fixes, some cleanups, and a few things like the cris
updates that aren't really either, but which won't affect any normal user,
and will hopefully make it easier to sync up in the future.
Network driver fixes, some IDE and infiniband updates, some late cpufreq
updates, and a hwmon update.
On the architecture side, in addition to the afore-mentioned cris updates,
there are some sh, arm, powerpc and mips updates, and also one final x86
unification cleanup (and I really mean it - the rest can wait until after
2.6.24, but with this one the x86 configuration really is fairly merged,
and both i386 and x86_64 are really just special cases of the "x86"
architecture in the configurator).
And cifs and ocfs2 filesystem updates to round it all up.
Nothing really exciting. A few things got reverted due to regressions, and
in general hopefully the regression counts are starting to shrink.
Go get it, and test it.
Linus
-
Release Often
Perhaps it would be more manageable if less material was accepted in each revision. I'd rather see 2.6.X released about once per month than the debacle of 2.6.23 spread out over an eternity and a huge number of "rc" levels with "sloppy bugs don't matter for rc testers" attitude. It used to be that you could use rc levels on a real machine to help test, now it is good enough to say "we found a fatal bug, but since it is an rc level, who cares, we can wait a week or two to [even] report it, anyone stupid enough to run rc levels deserves blinking LED's!". My response: then test your own rc levels yourselves, by yourselves, your [extremely arrogant] attitude is a problem!
When I consult, I advise "from good coders, last night's code is the best". I can hardly say that about kernel.org anymore.
nah despite that, the amount
nah despite that, the amount of bugs fixed has improved too.
The only thing that will help more is to fix even more of the remaining bugs, the
rest of the design work is shaping up easily compared to that
from good coders, last
So you have actually met any of these mythical coders who don't make mistakes when adding new features?
"Good coders" are obviously
"Good coders" are obviously not willing to risk a regression to get better code in the end.
"Good coders" are pretty much useless, then...
2.6.23.2-8 out now
Just btw., maybe noone noticed but it's funny that within an hour, the kernel has been versioned from 2.6.23.2 to 8.
This is why [link].
This is why [link].