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.