Re: [tlug] Just curious... how much impact does a kernel update make?

["Stephen J. Turnbull" <stephen@example.com>]

Dave M G writes:

 > But then I considered other open source or free software projects, and 
 > they use version numbers all the time. For example, KDE has been working 
 > toward a version 4 (or 4.1? not sure... I'm not a KDE user) which was 
 > signified by certain milestones of development they wanted to achieve. 
 > Whereas Adobe wants to create a version number and then make it appear 
 > to have value, a free software developer decides what would have value 
 > and then assigns a version number to work toward.

That's unlikely.  Adobe does exactly the same thing: they decide what
would have value and work toward it.

The big difference between Linux and Adobe software, as far as I can
see, is that Linux generally asks more of those who make the decision
to use a new kernel (I mean the distros and the vendors, as well as
those of us who upgrade kernels on our own schedule which may be
faster or slower than our distro), and therefore has a more
sophisticated user base.  Those people generally aren't going to be
pay attention to version number bumps, rather, they ask "is my bug
fixed? will performance improve?"  Adobe users, on the other hand,
want to delegate those decisions to Adobe.  It's not surprising that
Adobe charges them for that, or that if the new feature turns out to
be more fuzzy kitten than man-eating tiger, they release and tout it
anyway.

Also, I offer some hearsay for your consideration (I can't confirm it
and don't have a cite).  That is, the current way the kernel is stuck
on 2.6 is partly due to vendor politics.  In the 2.4->2.6 transition
they had a lot of trouble getting customers to upgrade because a minor
version bump was considered too risky.  By pushing the activity back
to the micro version, they had a lot more luck, even though some of
the changes were big enough that (together) they probably would have
justified a minor bump.  Also, this made the kernel developers happy,
because more people were trying their new features earlier, thus
giving them more timely feedback.  The only people who aren't so happy
are module developers, who see more frequent API changes than they
were used to (Ian Wells commented on this).  AFAIK the end users are
genuinely happy, they're not perceiving more trouble than they had
under the old system.

For the cognoscenti: this may be one that Fred Brooks got wrong in the
20th Anniversary edition, where he said (something equivalent to) the
quanta of version bumps should be big or small, but not medium-sized,
and he personally thought that "small" would create too much
instability.  The Linux kernel currently seems to be doing very well
with frequent releases with small quanta of change.

 > Of course, different developers all have differing motivations for
 > using version numbers. But if my above analysis is generally
 > applicable, then it would seem to me that the Linux kernel
 > developers pretty much think that the kernel does exactly what it
 > needs to do, and only needs maintenance in the form of minor
 > adjustments for new hardware and the like.
 > 
 > Does that sound like a reasonable take on it?

I would disagree.  In upgrading from 2.6.20.7 to 2.6.27.1, I saw about
two dozen new kernel, not driver, features.  Mostly they were small,
such as variations on how NUMA architectures are handled, but others
offered changes in how scheduling etc is done.  As Ian Wells said,
this kind of complexity-increasing change carries risk of regressions.
They're not minor maintenance.