downwards
Saturday, 28. April 2007, 08:58:17
Ever since I moved from the standard SUSE 9.3 kernel 2.6.11 to a custom built 2.6.14, upgrading was a joy: the first step on an upgrade to a minor version bump takes a while: it is a minor version increase, yet support for tons of new drivers and configuration options are added, you walk your way through the configuration, make and then make modules_install && make install - and ready you are.
When we talk versioning number, it is interesting to note that with the A.B.C[.D] scheme, or <version>.<major>.<minor>[.<patch>] scheme, a D number first occurred when a grave error, which required immediate fixing, was encountered in 2.6.8's NFS code - today D numbers are released every other day…
It was a joy, I said - until the upgrade came from 2.6.19 to 2.6.20. It took me a few days to fix some issues with proper loading of some modules, certainly due to an older udev I am using. I solved it by finally deciding to compile those modules into the kernel (fair enough, why didn't I do that earlier?).
And then came 2.6.21 - somebody even saw some connection to the disaster of the Chernobyl Nuclear Power Plant… It was followed by a patch release a few days later with two bugfixes for networking issues that should cause all users of ipv4 or ipv6 to upgrade to this version. Right. IPV4: Fix OOPS'er added to netlink fib. 2.6.21 died every half an hour on my machine.
Following this much less pleasant release, there was a long and interesting debate on the LKML about releasing with known regressions.
No kidding. The quality is really going down the drain - and this, notabene, is said by somebody who is certainly not stress-testing or cornering the kernel into odd cases. I am kernel's Joe Average who is just using his machine to accomplish some other tasks. I am fine with putting up with a few inconveniences, I know that can happen when you run "the latest" - but please, this is not the bleeding edge: I am not fond of running the bleeding edge development kernel! This is the latest stable version of the Linux kernel… Or rather: wannabe stable.
When we talk versioning number, it is interesting to note that with the A.B.C[.D] scheme, or <version>.<major>.<minor>[.<patch>] scheme, a D number first occurred when a grave error, which required immediate fixing, was encountered in 2.6.8's NFS code - today D numbers are released every other day…
It was a joy, I said - until the upgrade came from 2.6.19 to 2.6.20. It took me a few days to fix some issues with proper loading of some modules, certainly due to an older udev I am using. I solved it by finally deciding to compile those modules into the kernel (fair enough, why didn't I do that earlier?).
And then came 2.6.21 - somebody even saw some connection to the disaster of the Chernobyl Nuclear Power Plant… It was followed by a patch release a few days later with two bugfixes for networking issues that should cause all users of ipv4 or ipv6 to upgrade to this version. Right. IPV4: Fix OOPS'er added to netlink fib. 2.6.21 died every half an hour on my machine.
Following this much less pleasant release, there was a long and interesting debate on the LKML about releasing with known regressions.
0 regressions is never realistic (especially since many regressions
might not be reported during -rc), but IMHO we could do much better than
what happened in 2.6.20 and 2.6.21.
No kidding. The quality is really going down the drain - and this, notabene, is said by somebody who is certainly not stress-testing or cornering the kernel into odd cases. I am kernel's Joe Average who is just using his machine to accomplish some other tasks. I am fine with putting up with a few inconveniences, I know that can happen when you run "the latest" - but please, this is not the bleeding edge: I am not fond of running the bleeding edge development kernel! This is the latest stable version of the Linux kernel… Or rather: wannabe stable.
WIDGETIZE