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.
Is there any valid reason[s] to _NOT_ go with the >= 2.2.10 kernel and keep using 2.0 kernels?
Yeah, you're running an older distro (eg. Slack 3.6) and really don't want to bother upgrading all the necessary stuff to have full 2.2 kernel compatibility...
Right, but Slack 4.0 is out now. :-) What all is involved in upgrading a linux OS anyway? just install over or what? and what if you are switching distributions? (hypothetical questions, but I'd like to know)
ufdraco
Eh...FUD? Slack3.6 requires no updates to use a 2.2.X kernel
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
I'm running Debian Slink and 2.0.X series works with my hardware configuration the way it is just fine so what's the point? I'll upgrade when Potato is put into stable and released.
Some distros have upgrade scripts. AFAIK, Slackware does not, so you either have to reformat and reinstall, or upgrade each package/library separately (or write an upgrade script yourself).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Hell, 3.5 only needs one or two upgrades, and those aren't required by many (Ok, well for what I use Slack for I didn't need any upgrades)
Well, i know that on my machine, i randomly get stalls when ftping from my linux box to my win98 box under 2.2.9, but they happen much less often with 2.0.36. The difference is really apparent when transferring hundreds of megabytes over my lan - it is almost never successful with 2.2.9, without an auto-resuming ftp client. Its probably my crappy realtek network cards, but hey, 2.0.36 works a lot better.
For me, all that I had to upgrade was pppd, to 2.3.5.
If you want to use FreeS/WAN (an IPSEC implementation on top of Linux for building secure VPN's), you'll
have to grab 2.0.3x because the package hasn't been ported to Kernel 2.2.x yet.
Paulão
--------
Fighting the herd since 1985.
I do some hardware testing on a 486DX33 with 8M of RAM, Slackware 3.6, 2.0.36. I wouldn't put a 2.2.x on that.
It is a developing stable version, but it isn't there yet. I tend to recall 1.2.13 as a benchmark in terms of stability and 2.0.36 is there, now. 2.2.x isn't. I like multiyear uptimes and I have no real desire to switch out the 386 with 16MB, the monster linear power supply, the QIC drive, and the dead-stable serial setup to my several UPSen that runs the two Spellcaster BRI cards that I depend on for my connectivity off of a 100MB drive (and probably real soon off of an LRP floppy, if I can get the Spellcaster stuff working) and tells the network to shut down when the Lower Colorado River Authority and the idiots at the City of Austin do something ass-backwards and shut off the power for an hour or two, keeping the ISDN up even if nothing else is. I need the uptime and the rock solid reliability. I travel all over Texas and I like to be able to get back no matter what has happened. I don't have a genset, just a few 1.5KVA Best UPSen to make sure that this is never an issue. So yes, if you dislike surprises, 2.0.3x is still where it's at.
Yeah. I have seen a lot of instability with the 2.2.x stuff here at UT. I am still on 2.0.36, and my box, arguably crappier than most, is a lot more reliable. And yeah, I have noticed some odd FTP stuff with everyone else but me, too.
I've got a similar spec machine here, being used as a masquerading firewall. Compaq 486DX33 with 8MB and Debian potato.
:-/
I've been running the 2.2.x series on it since I set the machine up, so I don't have any comparison to go with. What are your reasons for not running 2.2.x on this spec machine?
Incidentally, I've got a spare 8MB SIMM sitting here, but it seems that the machine only takes 'Compaq' RAM or something, since I can't get it to accept the SIMM.
Also, if you want to use encrypted file systems, I think that you have to still use 2.0.36.
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).
Most packages of ipchains comes with an "ipfwadm" wrapper script which works very well. You could at least give the setup a try on a test machine and then route a few test hosts through it and see if it worked. Then just dump the ipchains stuff out for boot scripts.
Even less stable.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Then perhaps it should be called a beta series of kernels, as opposed to 2.3.x, which is the alpha or pre-alpha version. When all the bugs are ironed out, then call it stable. I personally consider 2.0.37 to be the latest stable kernel out, and I wouldn't recommend 2.1.x, 2.2.x, or 2.3.x to anybody who wanted to do serious work and needed a reliable system.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
2.0.36 works perfectly fine, I see no reason to go beyond, at least not at this point. There's nothing in 2.2.x that would make it more fit for its purpose.
If it was called a beta series of kernels, then who would use it. We would still have the same problem because the only way to show and remove all of the bugs is to get lots and lots of people using it.
Besides, very few people are bitten by the bugs found in 2.2.x. I have been running it since the pre's and have had no problems with it at all, I even run 2.2.8 for a little while, with no problems. It was exactly the same with the 2.0 series, which is now rock solid.
In development trees, they take the stance that if you use them, expect to be bitten by bugs.
I agree with you that for critical systems, it is best to stay with 2.0 kernels, but for anything less, use 2.2 so the bugs get found and removed.
Beau Kuiper
"The best way to improve the kernel is to try it and file bug reports."
Agreed, but there's no way I'm going to do that on a production system. For now, if you want a reliable system you have to go with 2.0.x - which means if you want an up-to-date distro you should stick with Debian or good old Slackware.
It would be honest. Right now lots of inocent newbies are told about Linux' stability. Then they go and buy the latest 2.2 based SuSE/Redhat/whatever. And it's indeed mor estable than Windows on the average, but I didn't need to turn the power off because the system was completely frozen for years (only time was long ago when I tried an ealry dosemu version) until I started using 2.2. It happened 3 times so far.
The problem is we can't really compare Linux to Windows, we have to compare it to other Unix'es, and most of them are a lot more stable than our beloved (irony) Linux.
--
Michael Hasenstein
http://www.csn.tu-chemnitz.de/~mha/
It would be honest. Right now lots of inocent newbies are told about Linux' stability. Then they go and buy the latest 2.2 based SuSE/Redhat/whatever. And it's indeed mor estable than Windows on the average, but I didn't need to turn the power off because the system was completely frozen for years (only time was long ago when I tried an ealry dosemu version) until I started using 2.2. It happened 3 times so far.
Yes, honesty is good. It's great to finally see some of that from the Linux rah-rah crowd. But lumping all of Windows in one group isn't honest either. Windows NT is far more stable than Windows 9x, and from the sound of things, is far more stable than Linux 2.2. I've been running NT 4.0 for years without ever having a single crash (no my uptime isn't that long, but only because I've had to move the machine and/or modify the hardware. It's never gone down except for when I've told it).
I found that when I transferred a large file from one linux box to another, with realtek network cards (that I scored cheaply), it consistantly stalled. However, changing the mtu of one of them to 576, while keeping the mtu the same on the other fixed the problem. Quite strange, but it fixed the problem...
Anyone planning on upgrading an older version of Slack but wishing to retain a 2.0x kernel might want to consider Slackware 3.9. This version was released in parallel with the 2.2x-based Slack 4.0, and comes with all the new features, but sticks with the 2.0x kernel.
S/WAN is another reason too, it's designed for the 2.0 series kernel, and is unlikely to work with the 2.2 series for a while yet.
In short though, the point with linux kernels is usually "do I *need* to upgrade?" rather than "why *shouldn't* I upgrade?"
--
Exigo spamos et dona ferentes
-rw-r--r-- 1 root root 666 Apr 12 1996 /usr/src/linux/Documentation/filesystems/smbfs.txt
Is this a hint?
To be real here it is only worth the effort of upgrading the kernel when it gives you something you need... I am going to upgrade my workstation because I need the improved soundcard support, but my firewall running 2.0.37 I will leave as it is because its working and I have no problems with it. Also the 2.0.x kernels work better with machines with less than 16Mb I am told and my firewall is a 486DX2/66 with 16Mb ram.
From what I read 2.2.x is perfectly OK for most users.. there are some issues with it but that has always been true (thats why the 2.0 series went up to release 36!!). Generally though dont waste time upgrading kernels unless you need something it has got in it....
*--BigMan--- Time flies like an arrow.. but personally I prefer a nice glass of wine!
Um... to upgrade Slackware 3.6 for 2.2.x, I compiled maybe two packages (and I think they may not have even been necessary). Everything else is from the original install.
But still, for full compatibility, yah still needs 'em...
From what I remember doing (that is, getting all the version numbers of various programs up to the minimum that the 2.2 FAQ on linuxhq suggested at the time), I had to upgrade 6 or 7 packages... This was before slack 4.0 was released, so it wasn't as easy as:
/cdrom/slackware/slakware/a1/???.tgz
cd /
tar -zxvf
Sure it'll work with the 2.2.x kernel... Sort of. There are required updates, and one day ld (and more) will bite you in the ass when they don't do as expected...
What's the diff between the pre10 release and this full release? I have pre10 going here, but uname reports it as just "2.0.37". Should I DL this, or is there a patch to bring it to current?
-> I dislike sigs...
I'm _not_ a MS supporter, but I would definitely agree that the stability of NT is far better than that of Win9x. I use NT 4.0 at work and have never restarted the machine since 3/98. My Win98 partition at home is torture.
I still think Linux and BeOS are a lot better than NT, but NT is definitely the best version of Windows.
If that's a compaq prolinea, I know your memory heartache. Had to upgrade one of these myself. If I remember right, it took 72-pin SIMMS. If you try anything but 70 ns FPM ram (eg. 60/50 ns "modern" EDO), it won't work. I don't remember if it required parity or not, but I think that beast was killed long ago... (I hope so!).
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.
Why bother ? The original poster obviously
has everything set up right - why fix what
isn't broken? I am just as guilty as the next
guy for wanting the newest and flashiest things,
but if you have a machine that works, just leave
it. There is no reason why this machine
shouldn't run 2.0.X indefinitely.
We installed 2.2.5 on our test system here. We started having random system hangs. There are also compatibility issues with the 2.2.x series and the 1.1.7 JDK which we use to run our transaction server. So we're still using the 2.0.x series on the production systems and most of our workstations. Not that we wont continue to beat on new 2.2.x versions as they come out, but they aren't stable enough for us to use on critical systems yet.
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.
I seem to remember reading that 2.2.X has better handling of TCP/IP, and better memory managment. But don't quote me on that.
On a side note, I have been having all sorts of trouble getting mpg123 to run properly after I upgraded to RH 6.0. It always worked great under 5.2. Now it will only play for a few minutes before cutting out. I don't know if this is a KDE thing or a 2.2.X thing...or what. I compiled both under 6.0, downloaded the latest versions, etc... no luck. Anybody have and suggestions or similar experience?
mpg123 comes with RedHat 6.0. Install the RPM, it worked fine for me.
I don't love RedHat packages, but if you use them in RedHat, it makes life easier. If you don't use them, use SlackWare, or just compile anything.
Foolish consistency is the hobgoblin of well-designed computers...
pb Reply or e-mail; don't vaguely moderate.
AC,
You probably haven't tried Linux, which means that you don't know about Linux's stability. 2.2 is rock-solid stable compared to NT, it's just not quite as stable as the late 2.0.x series yet, and there are people who are real sticklers for stability.
2.2.x runs GREAT on my machine, with the exception of stock RedHat kernels not liking my APM BIOS - They kernel panic on system halt. (Not serious, since the machine is down anyway, but weird.) RedHat's tech support says it's buggy BIOS - I'm inclined to believe them, because APM is generally screwy on my machine, Linux or Windows.
I used to run NT4 Workstation, it crashed all the time. Now I use Linux for reliability and Win95 for games. (No Win98, because it sucks and doesn't even boot on my machine. That's right, MS boy, your precious Windows 98 doesn't even BOOT on some machines that run Linux like a charm.) Given the release of CivCTP and Nvidia GL drivers, Win9x's days on my machine are very numbered. Now Cornell just has to convert Just The Facts from VB to Java. (They intend to.)
retrorocket.o not found, launch anyway?
I upgraded a dozen or more, a couple of which I had to do in stages, but then, I was coming from Slack 3.0... Still, downloading all the necessary tarballs over a 33.6 was the worst part.
When I'm at home from school, I've been running a
2.2 kernel on a 486/50 with 20 megs of RAM, doing
IP masquerading etc via a cable modem. I really
haven't noticed much of a speed difference from
when the box had a 2.0.35 kernel, but maybe thats
because I have more than 16MB of ram (though only
slightly more).
Other reasons that I could imagine someone wanting
to use 2.0 kernels is because they are tried and
tested, and while the 2.2 series is earmarked
as a stable series, it is still very new. For
people who are using their box as a server, it
might be preferable to have something tried and
true, that has been in use for a significant
period of time.
In the lab I work in, there is a mixture of dec
alphas, rh 5.1, and rh 6. These boxes are all
managed by a central admin group, only one person
in the lab has root on any of these. In this
situation it is just as easy not to upgrade the
older rh5.1 box(es) (not sure how many we have),
since there really is no critical need to upgrade,
and the one that I use at least is a critical
file server, so downtime on it would have
something of a negative impact on the fragile web
of nfs mounts in the lab.
...that when I read the patches for a new version I find too many horrible bugs that I get nervous if I don't upgrade.
Well, I am running two servers that are still based on the 2.0.3x kernels. I tried the .37 kernel and on one machine running a Pentium 200 with an ASUS board and get the reboot problem as described. On another machine, a Pentium 133, dunno what board its really got, the system simply freezes at the same point where the other machine will reboot. Both systems have been rock solid with .36. I just want the DoS fixes that are found in .37. Any suggestions?
Would the age of the distro effect things? Both of these boxes are RedHat 4.2. I have a 5.1 box running 2.0.37 just fine.
Jeff
I'm running 2.0.36 on RH4.2 on a 486 rock solid and have the reboot problem with 2.0.37...
Particularly annoying as the box has no monitor or keyboard, just net connection.
Codeine.
Both of my boxes are running RH4.2. Is anyone having this problem on other distributions?
Jeff