Is the kernel development process broken?

Posted Mar 10, 2005 9:28 UTC (Thu) by Duncan (guest, #6647) [Link]

Well, I think not. <g> For the most part, people who want ultra-stable
kernels to run year-plus uptimes on are running distribution kernels,
which are literally what you are asking for, six-month "out-dated" kernels
that they picked and stabilized for six months, backporting a few drivers,
features, and security fixes, as needed. That's actually what the current
kernel development process was designed to encourage -- faster development
in the mainline kernel so less stuff had to be backported from the
development kernel to something /years/ outdated, so distribution kernels
stuck closer to mainline, and only had to freeze and stabilize it. Those
wanting ultra-stable kernels aren't /supposed/ to be running the
kernel.org kernel, with the current 2.6 arrangement.

You don't see any reason to switch from 2.4? Why aren't you still on 2.2
then, or even 2.0. Talk about wanting and getting outdated stability.
No, I'm not joking. It's a serious question. Actually, that has often
been pointed out as one of the benefits of the open source development
method. There's nothing forcing you to run on that upgrade treadmill
unless you /want/ to run on it. You can continue to backport security
fixes and what-not as necessary.

Just as 2.4 had certain improvements over 2.2, so 2.6 has improvements
over 2.4. The improved scheduling is one I like. Another is the
data=ordered and data=journal options for reiserfs, which happens to be my
chosen file system, altho it's possible that has been backported to 2.4 by
now (I know it was in the 2.4 SuSE kernels for some time b4 it was added
to 2.6 but don't know if it ever hit 2.4 mainline), I haven't kept track.
Another is the increased flexibility of UDEV as compared to devfs or a
static /dev. Still another is the IDE rewrite, including the simpler and
less confusing (from a user perspective) ATAPI burner drivers (yes I know
that ATAPI is a reduced functionality SCSI, but it still doesn't make
sense to an ordinary user, even or especially a semi-technical one that
actually cares about such things, why SCSI drivers were required for an
IDE/ATAPI CDR/RW. Yet another is the /far/ simpler mouse driver, with the
ability to set up a /dev/input/mice that looks the same from user mode no
matter /what/ sort of pointing device (or how many) are in use. One more
is the built-in ALSA sound drivers. Any one of these are IMO worth
switching to 2.6 for. However, there's nothing forcing you to upgrade if
you don't find those or other features useful, and you are comfortable
with 2.4. Again, that's considered one of the benefits of open source --
no forced upgrade treadmill. Comfortable where you are? You are welcome
to stay there, and don't have to worry about your license expiring, or the
only people that know the code deciding it's not worth supporting any
more.

As for the the nano-version numbers, no, the same thing is /not/ going to
happen all over again. It's simply the micro-release with a few very
limited fixes. The whole point is to only have fixes to anything found by
the wider testing of full release, no "development" at all in the
nano-versions.

Finally, keep in mind that despite the popularity of open source and Linux
in particular, development is still done because the developers find it
fun and challenging to do. Linux existed long before it became popular,
long before people ran or even could run "mission critical" systems on it,
and it will continue to develop and change regardless of whether people
continue to do so, as long as there remains at least one person with the
ability and interest to continue that work. You may wish it to stagnate
because you don't like the methods being used, and as far as you are
concerned, if you /want/ to continue to use an old stagnant version, you
are certainly free to do so, because that's one of the things open source
lets you do. However, the rest of the Linux world will continue to change
and evolve as it's going to, in any case. Again, that's the way open
source works. Since the developers are in a very real way volunteering
(paid or unpaid) to continue development in whatever way they find
rewarding (fun, interest, or money-wise), they will continue development
as they find best suits their wishes. Others who disagree are of course
free to stay where they are, or fork the code and develop it in a
different direction, just as recently happened with xfree/xorg. Success
isn't defined as continuing to gain market share, tho that happens to be a
nice side benefit when it occurs, but as continuing development in a way
that continues to be rewarding to those participating. Linus and the
others find the current system better matches their style and is therefore
more efficiently rewarding with the less hassle, than the old odd/even
minor version thing, and they are the ones driving the development, so
that's the way it's going to be, unless someone else decides they want to
try it a different way, and can get enough to agree with them to make the
fork.

My thoughts, no personal attacks intended, just that I found your post an
appropriate place to tack on mine, taking as it does the opposite
viewpoint.

Duncan