For those who like their kernels really stable: David Weinehall has
released 2.0.40. This release
("Moss-covered Tortoise") contains a number of security fixes; if you are
still using 2.0 somewhere, you may want to look at upgrading.
(Log in to post comments)
Stable kernel 2.0.40 released
Posted Feb 8, 2004 20:44 UTC (Sun) by Soruk (guest, #2722)
[Link]
When is 1.2.14 coming out? ;-)
Stable kernel 2.0.40 released
Posted Feb 8, 2004 22:15 UTC (Sun) by smoogen (subscriber, #97)
[Link]
When I last checked, there is no active maintainer for the 1.2.xx or 1.0.xx code bases. Alan Cox holds the keys for the 1.2.xx I think.. so if you want to take that over.. I would probably get a patch set together, and then let him look it over.
Stable kernel 2.0.40 released
Posted Feb 8, 2004 22:34 UTC (Sun) by Soruk (guest, #2722)
[Link]
Hee.. I wasn't expecting to be taken seriously with that one ;-) I haven't used 1.2.13 since late 1996! Still, I guess 1.2.13 could be useful for low-mem systems...
Stable kernel 2.0.40 released
Posted Feb 9, 2004 4:58 UTC (Mon) by rknop (guest, #66)
[Link]
Yikes. It's hard to imagine being able to do anything after the kernel was loaded in a system that was so low-mem that it helped to run 1.2.x rather than 2.0.x.
-Rob
Doing a lot with a little
Posted Feb 9, 2004 6:05 UTC (Mon) by allesfresser (subscriber, #216)
[Link]
I used to serve a whole office (back in 1995 or so) from a 386SX/16 box with 8M of RAM, running Netatalk (Mac filesharing), mail (SMTP/POP3 to/from 10 clients, UUCP to/from to smarthost over a 9600 bps dialup every three hours) and small intranet web server (Apache). That blessed thing was a faster Mac fileserver than my Power Mac 8500/120. And it ran on kernel 1.2.13 until the last three months when I upgraded it to 1.3.57. :-) It did, however, require almost 2.5 hours to recompile the kernel. :-(
Just to say you can do a lot with Linux (Slackware 3.0 in this case) and a just a dab of memory... :-)
Doing a lot with a little
Posted Feb 9, 2004 6:13 UTC (Mon) by allesfresser (subscriber, #216)
[Link]
Oh, and one more thing... that box would still be running today and plugging along just fine if somebody hadn't gone and knocked over a water bottle into its innards. (No, it wasn't me.) :-)
I understand the desire to have the latest stuff, and that's all well and good, but the needs of this particular office were such that you could have left that thing running to this day and they would have been fine. So I can see why someone would still want to use the 2.0.40 kernel, especially if there were incompatible changes made in forward versions or support for old devices (necessary for certain hardware) was dropped.
Who uses 2.0???
Posted Feb 9, 2004 1:48 UTC (Mon) by moxfyre (guest, #13847)
[Link]
Who uses old kernels like 2.0.x? And why are they still being maintained? I mean, if the requirements of your applications have changed so little that upgrading to a new kernel isn't worth it, then why is the kernel still being updated.
By the way, I'm not criticizing whoever uses 2.0.40, I'm just wondering who they are and what they're doing with it :-)
Re: Who uses 2.0???
Posted Feb 9, 2004 2:51 UTC (Mon) by macemoneta (guest, #2717)
[Link]
I know that a number of floppy-based recovery tools and firewall/routers (like tomsrtbt) use the 2.0.38 kernel to save space. I'm kind of surprised they haven't upgraded to 2.4 myself. There are 2.4 based single floppy systems (like FDlinux), so it will certainly fit on the media.
Re: Who uses 2.0???
Posted Feb 9, 2004 6:53 UTC (Mon) by wildpossum (guest, #17744)
[Link]
Well I'm involved in the floppyfw community and you will find that heroic efforts have to be made to squeeze new releases onto floppies. The most successful ploy is to use uClibc. tomsrtbt isn't even a firewall, it's a recovery floppy. It works fine for what it does and isn't developed much anymore. If I were the author I see no reason to start afresh with 2.4. Many rescue distros have gone to CDs or flash memory anyway.
Who uses 2.0???
Posted Feb 9, 2004 6:45 UTC (Mon) by wildpossum (guest, #17744)
[Link]
Well put yourself in the shoes of someone whose 2.0 based app still works fine. All you want to do is get rid of one or two irritating bugs and close a hole or two. Which is the easiest path? Try to rebuild your app on 2.2 or perhaps 2.4? Arrgh it runs like a slug because 2.2 requires more memory. In some situations you can't even put in more memory (think embedded systems). Or some other hitch. By contrast recompiling the 2.0.40 kernel is easy because you had no problems compiling 2.0.39 last time. So some people do need this release.
Stable kernel 2.0.40 released
Posted Feb 9, 2004 5:44 UTC (Mon) by gavino (guest, #16214)
[Link]
The reasons cited for this old kernel seem to be for low-memory usage and people with applications that only run on the older kernel.
In regards to the first point, I thought 2.6 helped with scaling down, especially with non-MMU systems.
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'm not expecting all apps to support 2.6 straight away, but they should all do at least 2.4 by now.
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.
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.
Stable kernel 2.0.40 released
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.
Stable kernel 2.0.40 released
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?
Stable kernel 2.0.40 released
Posted Feb 10, 2004 0:12 UTC (Tue) by alexboy8181 (guest, #19321)
[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.
The reason for having interest in older kernels is that you never know where they might turn up next. Ironically, I have to quote Dr. Andrew Tannenbaum, who used an example of memory management overlays in his latest book on OSes. He wrote that overlays, which used to be common in older OSes, became obsolete when memories grew. But now overlays are found in handhelds' OSes like PalmPilot. Obsolete one year, hot the next.
Besides, if you don't learn from past mistakes, you're bound to repeat them in the future. Likewise, if you don't learn from a truimph, you're gonna reinvent the wheel later.