At the place where I work they still have a number of machines running an ancient Linux distribution called "FT" with the 1.2.13 kernel. The machines work perfectly. In fact, they work a lot better than the Red Hat 6.0 machines in some respects: there are a number of things (xfs, lpr with Netware printer, ...) which seem to be broken in Red Hat 6.0, but they work fine on the old "FT" 1.2.13 machines.
Generally I prefer a high-quality and well-tested distribution to one that has the very latest version of everything. If there's a particular program that I need the latest version of, then I build that program from source. How many people will actually need a feature from the 2.4 kernel when it appears? Not many, I would guess. It's very easy to build the kernel from source, so let those people do it. At the same time, I can't say I'm totally happy with the Debian release policy. Perhaps there should be some kind of non-security upgrades to stable. The concept of a Debian release is really only important where complex dependencies between packages are concerned. Packages on which no other package depends could be upgraded independently of each other while the packages they depend on remain unchanged or receive only minor, security updates. To implement this you might have a separate Debian version called "stable-test" where such packages go for testing. When the package maintainer is confident that the version in stable-test is in every way superior to the version in stable, he asks the release manager to move it from stable-test into stable. Many users would dist-upgrade to "stable" from time to time and upgrade particular packages they are interesed in from stable-test. For real hackers there would still be "unstable" and "frozen", too. Edmund