> } The general belief was that the stop-dead approach that was used with 1.2
> } wasn't too good, because 1.2.13 was starting to look very tired by the
> } time 2.0 was released.
>
> which makes it appear that we are being too ambitious in the changes made
> between major releases (by major I mean "stable" releases - ie 1.0, 1.2,
> 2.0).
I was thinking the same thing, but I don't see any easy solution. Things
like IPv6 support by their nature _do_ take a long time to get right. The
network code was being worked on well before 2.1 started, and it's still
nowhere near ready to be released.
> However the idea of having a fixed kernel and a load of
> feature/performance patches is also horrid. If you want a high
> performance news server you end up stacking something like a Buslogic SCSI
> upgrade, ISS network patches, no atime patches, tulip ethernet driver and
> maybe say a Cyrix CPU fix as well. Thats a whole load of individual
> patches which may not work at all well together!
I agree. It would be nice if things like drivers could be distributed as
standalone modules for older kernels. Then you could compile the BusLogic
and Tulip drivers without patching your kernel at all and just load them
in. Admittedly this doesn't help much if you need those devices to boot
your machine, but you always have the option of avoiding weird hardware to
some extent.
Things like noatime and ISS, yes that's a problem. Noatime is fairly
minor though, and ISS isn't the sort of thing I expect to happen often.
> However making this work in practice appears unlikely.
Quite. I think the best we can do is probably tune the system we have at
the moment so that we get a degree of stability in "stable" releases that
most people are happy with. IMHO we ought to err on the side of too
stable, rather than too unstable.
p.