Slashdot Mirror
Linux 2.0.37 Released
After many months of hacking, Alan Cox has released what is likely to be the last 2.0 kernel. He writes in his diary that we will only see 2.0.38 if there is some sort of security hole. For those who don't know the drill by now, you can download the kernel from any kernel.org mirror.
Well, I know of at least one actually. 2.2 was designed with the notion that everyone has at least 16megs of ram (or at least everyone that will want to upgrade), so there are all sorts of optimizations and such which make 2.2 slower on machines with around 16megs or less of ram (certain cases being exceptions of course). Not that this is bad, we shouldn't hold linux back so that we can always run it on a two meg 386 without a math coprocessor, we just have to be careful to not assume to high of a hardware configuration. I'm still running 2.0.36 on a 486 with 16megs of ram (100mhz fwiw) and it runs a bit faster than with 2.2, so it's staying with 2.0 unless something terible is found which can't really be fixed.
So, yes, there are technical reasons out there to stay with 2.0.
Hope that helped,
Chris Frost
Linux 2.0.x is stable. Linux 2.2.x, despite the fact that it's an even-numbered series, is not stable, and should really be considered a development kernel (note the numerous bugs - filesystem corruption and DoS attack vulnerability). If someone were planning to use Linux in a mission-critical situation, I would most certainly caution against using the 2.2.x series.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Many people have forgotten (weren't there) the problems that 2.0 had while it was the latest stable kernel. There were at least 3 DoS attacks that were fixed, and probably file corruption too.
You have to remember that it takes widespead testing by many people to find all the bugs in a software product. The kernel team can only test the software on their own computers and configurations, and need outside testing to detect the remaining bugs. They don't get this widespread testing until they declare a stable tree. We get a rush of bug fixes after that as widespread testing occurs.
The corruption issue in 2.2.8 was due to the correction of a long standing bug that exposed another one.
Don't just dismiss the 2.2 kernel without trying it. The best way to improve the kernel is to try it and file bug reports.
Beau Kuiper
I can tell you one right away. I used to be in charge of admining a firewall. It had tons of individual ipfwadm firewall rules. You generally don't touch a machine like that unless there is a known problem or security hole. Moving to ipchains would have required a few days of rule writing, some testing, bugs found from me mistyping one charachter for weeks on end, ect. Thus I had no intetnion to (and I doubt my successor did either) upgrade the machine to 2.2. If I had to make a similar configuration, I would certainly use ipchains, but ipfwadm did its job, and that was all that was important in that case.
Second, linux has moved towards optimizing for newer hardware (aka adding new features to make life faster and easier, but requiring more RAM). Thus on 386es, and some 486es, 2.0 may be better. Of course, nowadays, FreeBSD is so much better on a 386 if you ask me, but I prefer linux on my newer machines.
I'm running a 486/100 w/16mb as a masquerading and port-forwarding firewall, perfectly happy on 2.0.36, thank you. This machine has only a 1.2 gig or so HD so I'm not inclined to download and compile a 2.2 kernel on it unless some real problem comes up that I cant solve with a 2.0 kernel. But for now, it just happily sits in my kitchen closet with my cable modem and hub and trades packets back and forth all day with no complaints.
RH6 has a fairly painless install/upgrade thingy that brings you up to a 2.2.5 kernel without any suffering at all (at least in my case).
Anyone else out there having trouble getting 2.0.37 to boot? Especially on a machine with a Cyrix processor and/or VIA motherboard? The machine I tried it out on gets as far as decompressing the kernel... when it finishes that, it spontaneously reboots. It's getting as far as printing the first kernel message, but it doesn't stay on screen long enough to be seen.
The machine in question is known to be defective, so I'm not terribly concerned about it, but it's consistently rebooted 2.0.37 at the same spot every time, where 2.0.36 mostly works and only spontaneously reboots occasionally and erratically.
Time for the bullshit filter.
There are very few people who know enough about the internals of NT and linux simultaneously to make sweeping, or detailed statements about their relative stability. None of them post on slashdot. Everything above is pure conjecture and/or horseshit.