Re: starting with 2.7

[Adrian Bunk <bunk@stusta.de>]

On Sun, Jan 02, 2005 at 04:30:11PM -0800, William Lee Irwin III wrote:
> Adrian Bunk wrote:
> >> The main advantage with stable kernels in the good old days (tm) when 4 
> >> and 6 were even numbers was that you knew if something didn't work, and 
> >> upgrading to a new kernel inside this stable kernel series had a 
> >> relatively low risk of new breakages. This meant one big migration every 
> >> few years and relatively easy upgrades between stable series kernels.
> >> Nowadays in 2.6, every new 2.6 kernel has several regressions compared 
> >> to the previous one, and additionally obsolete but used code like 
> >> ipchains and devfs is scheduled for removal making upgrades even harder 
> >> for many users.
> 
> On Sun, Jan 02, 2005 at 05:49:08PM -0500, Bill Davidsen wrote:
> > And there you have my largest complaint with the new model. If 2.6 is 
> > stable, it should not have existing features removed just because 
> > someone has a new wet dream about a better but incompatible way to do 
> > things. I expect working programs to be deliberately broken in a 
> > development tree, but once existing features are removed there simply is 
> > no stable set of features.
> 
> The presumption is that these changes are frivolous. This is false.
> The removals of these features are motivated by their unsoundness,
> and those removals resolve real problems. If they did not do so, they
> would not pass peer review.

The netfilter people plan to remove ipfwadm and ipchains before 2.6.11 .

This is legacy code that makes their development sometimes a bit harder, 
but AFAIK ipchains in 2.6.10 doesn't suffer from any serious real 
problems.

> Adrian Bunk wrote:
> >> There's the point that most users should use distribution kernels, but 
> >> consider e.g. that there are poor souls with new hardware not supported 
> >> by the 3 years old 2.4.18 kernel in the stable part of your Debian 
> >> distribution.
> 
> On Sun, Jan 02, 2005 at 05:49:08PM -0500, Bill Davidsen wrote:
> > The stable and development kernel model worked for a decade, partly 
> > because people could build on a feature set and not have that feature 
> > just go away, leaving the choice of running without fixes or not 
> > running. Since we manage to support 2.2 and 2.4 (and perhaps even 2.0?) 
> > I don't see why the definition of "stable" can't simply mean "no 
> > deletions from the feature set" and let new features come in for those 
> > who want them. Absent that 2.4 will be the last stable kernel, in the 
> > sense that features won't be deliberately broken or removed.
> 
> I can't speak for anyone during the times of more ancient Linux history;
> however, developers' dissatisfaction with the development model has been
> aired numerous times in certain fora. It has not satisfactorily served
> developers or users. Users are locked into distro kernels for
> incompatible extensions, and developers are torn between multiple
> codebases.

At least on Debian, ftp.kernel.org kernels work fine.

> This fragmentation of programmer effort is trivially recognizable as
> counterproductive. A single focal point for programmer effort is far
> superior for a development model. If the standard of stability is not
> passed then the code is not ready to be included in any kernel. Then
> the distinction is lost, and each of the fragmented codebases gets a
> third-class effort, and a spurious expenditure of effort is wasted on
> porting fixes and features across numerous different codebases.
>...

My impression is that currently 2.4 doesn't take that much time of 
developers (except for Marcelo's), and that it's a quite usable and 
stable kernel.

> -- wli

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed