> Get back to me in a decade and ask the same question.
Hmm. Interesting idea. Just we need answer slightly earlier then in a decade :-((
> Broken behavior in one filesystem is not the "weight of years of
> accumulated cruft".
It's just application of "general principle": if cleanups will broke things
they must be postponed for next stable release of kernel. Not more. If thay
are ready and working that is :-)
>>It's good to clear out (some of the) cruft in a major revision; if you
>>don't like it then may I kindly point you at 2.2.10, or 2.0.37, or 1.2.13.
> Hey, if I could take 2.2.x device drivers and plug them into
> 1.2.13, I'd do that and get 220k back on my install floppies.
If you need it then you'll need some other OS. Not Linux.
> But, oddly enough, there have been 4 releases of the kernel since then
> with 4 different device driver interfaces (and nothing but paranoia
> and contempt for any attempts to publish a driver interface), so
> nothing will work without massive hackery.
To me it looks like just application of general principle, nothing more.
> But why the devil should I reward sloppy coding practices by taking
> all my toys and playing with a different crowd? Even if Linux
> wasn't Unix's only hope, there are massive benefits to making it
> easy to upgrade to new kernels.
So far noone suggested ANYTHING better then implement-try-and-reimplement
style of development. Of course you can (and SHOULD) try to avoid as much
uglyness as possible but in the end story is always the same: something was
not taked into account when API/driver interaface/cacheing sysbsystem/whatever
was developed. Better to have well-established way to eliminate obsoleted/ugly
things in planned fashion then try to keep all accumulated cruft... You MUST
expect breakage when upgrading from 1.2 to 2.0, from 2.0 to 2.2, from
2.2 to 2.4 and so on...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/