Stable kernel 2.0.40 released

Posted Feb 9, 2004 6:48 UTC (Mon) by wildpossum (guest, #17744) [Link]

You're assuming that those recalcitrants who stick to 2.0 kernels would move over and help you test the 2.6 kernels if you denied them access to 2.0. I don't think this is the case. I don't think the continued availability of 2.0 affects the developer pool much at all. In any case this is FOSS and you have no way of preventing people from continuing to use already released software.

Posted Feb 9, 2004 6:51 UTC (Mon) by eru (subscriber, #2753) [Link]

In regards to the first point, I thought 2.6 helped with scaling down, especially with non-MMU systems.

But the people interested in 2.0.40 are running systems *with* MMU (probably a 386 or 486). Would 2.6.x scale down to a 4Mb 386SX? If not, it is not a replacement.

For people with apps that only run on 2.0 - I think their apps must be pretty poorly written if this is the case. You'd think they'd at least have them ported and certified for 2.4 kernels.

I suspect part of the problem is libc support and libc size. Old libc5 probably does not support 2.6 kernels without porting work, and even if the current glibc would run the apps in question, it would not fit in the small systems. There are alternate modern "low-fat" libraries like ulibc and diet libc, but they might not be compatible enough with what the ancient apps expect.

It dissapoints me that there is still interest in these old kernels. It dilutes the user and testing base for the newer kernels, and we should be looking to the future, not be stuck in the past.

I am not actually involved with any project sticking to old kernels, but based on what I do see in my work I would say that this conservatism is not atypical in projects where developing platform software like the kernel is not the objective, but stability is, and can be summed by the familiar phrase "if it ain't broke, don't fix it". Even a theoretically compatible upgrade in lower level software platform usually causes some unexpected problems (= costs), so the upgrade is not done unless it brings demonstratable advantages.

So, as a developer of an in-house language, I sometimes get questions about problems in obsolete versions I released many years ago, but still used in projects because they want to avoid changing the foundation. As a software developer I find this rather annoying, but looking at it from the point of a software user, I can see their point.

Posted Feb 9, 2004 9:37 UTC (Mon) by JoeF (subscriber, #4486) [Link]

It dissapoints me that there is still interest in these old kernels. It dilutes the user and testing base for the newer kernels, and we should be looking to the future, not be stuck in the past.
We are not like M$, forcing people to upgrade to newer systems because there is no support for old stuff anymore...
I am running 2.0 on an old Pentium 1 with 32MB RAM. Runs a webserver, and that's about it. Had an uptime of over 1 year (until yesterday, when I installed 2.0.40.)
Now that doesn't mean that I don't run 2.6. In fact, I do, on my main firewall box.
But, why change a running system?