Slashdot Mirror
Kernel 2.2 - It Lives!
Build6 writes "For those of us still using 2.2 (how's that for "conservatism" eh?) -- 2.2.24 is out (and has been since last week) - see kernel.org for downloads. I see networking code tweaks, but no changelog. Time to give our old RH 6.2 machines one last kernel-recompile before Red Hat's end-of-life date arrives for 6.2? :-) What I'd like to know is - who else (besides me) out there still has machines running 2.2 and intends to keep it that way?"
All of us are still using 2.2 kernels, whether we like it or not.
...that run 2.0... And of course, Debian stable is still 2.2.
My current gateway is a AST 486SX/33 with 16 megs of RAM.
I was able to install RH 6.2 on it and wittle the RPMs I didn't need to get it down to under 200 megs.
While on many of my other servers I run 2.4.x, on this type of box I think 2.2.x suits my needs perfectly.
Really, I know what I'm doing...Ohhhh, look at the shiny buttons!
Debian use tried and tested software, their kernel sources contain quite a few bugfixes too.
Running the vanilla sources from www.kernel.org means you sometimes miss out on some bugfixes, unless you follow kernel development.
Found the changelog here. It reads:
Linux 2.2.24-rc5
* Fix n_hdlc globals pollution (Paul Fulghum)
* Fix initialisation of sk->sleep (Holger Smolinksi)
* Handle init_ethdev returning null in tulip (Neale Banks)
* Backport rtc wildcard fix to 2.2 (Paul Gortmaker)
* Correct wireless config help (Neale Banks)
* Fix smc9194 build (me)
I had a machine (on its 3rd motherboard, last 2 died, 1 of which had been purchased specificly for it) that is running 2.2.10 because I couldn't get the ppp stuff upgraded to work with 2.2.12 (clue to the last time I played with it). It is doing a firewall between home network and ISP (over 56K modem) and routing between the 10 Mb/s and 100 Mb/s networks at home (got some 10 only cards and a 100 only hub about 3.5-4 years ago).
Dude why are you running a development kernel on a firewall?
Not all conservatives are stupid,
but it is true that most stupid people are conservative.
- Hume
Distributions provide well-tested, patched kernels. Compulsively updating kernels is a fine hobby if it makes you happy, but unless there's a new feature you need, the potential for breaking something exceeds any practical benefit. The experience of the 2.4 series, where half the kernels substantially degraded performance because of some new half-assed VM only underscores that lesson.
No, if you don't know why you need to upgrade your kernel, you almost certainly don't.
What I'm listening to now on Pandora...
I use 2.4.20 on debian stable on a SparcClassic and s SparcStation 5 and it works very well. I never had any problem with it.. And with the speed of the disk on that thing, I really need ext3, because when my roomate pulls the plug I can't really wait 3 hours before my firewall is back up.. SparcClassics make really nice firewall especially if you find a scsi-1 hardware that's not too noisy..
> Why would you keep 2.2?
/proc/version
% uptime
9:19pm up 470 days, 12:17, 1 user, load average: 9.33, 4.13, 4.07
% cat
Linux version 2.2.16-3 (root@porky.devel.redhat.com)
That's why. It handles about 5 million hits per day on weekdays. Each hit runs a PHP program and has several database accesses. If it works so well, why change?
> What is there in 2.4 that makes it so bad?
On the 45 servers we have, I have never once gotten 2.4 or 2.5 to boot. Either the video doesn't work or it locks-up after printing "Loading Linux..." I'd like to upgrade to 2.4 so I could use our gigabyte Ethernet cards, but if 2.4 won't boot, what good is it?
2.4 is also harder to get to fit in standard boot images. Most of our servers won't boot bzImages. Linus has threatened several times to remove support for normal images. If he does that, we'll either have to stick with old kernels indefinitely or buy Sun's.
It does not need X, it is a PII-400, and it does not do anything that is so intensive it needs 2.4
Err, I hope you aren't implying that 2.4 is either bloaty or slow or both on older hardware.
I used 2.4.18 just fine for over a year on a Pentium 166 (no MMX) and had absolutely zero problems. This box was my broadband firewall and also served 60 GB of NFS, as well as SMB, ssh, mail, and apache 2.x web pages, both static and generated. (I know you're not supposed to combine your firewall and other stuff, but I had no choice at the time.) Anyway, this box did its job(s) flawlessly without a single complaint and though building a kernel took on the order of 50 minutes, most things happened instantaneously.
I decided to upgrade it to a Celeron 366 only after I started using a python-based wiki on a daily basis for note-taking. If I really wanted to, I could have hacked up my own program in C that would have been 10x faster but I had the spare hardware and figured I might as well retire the 166. Given all of the improvements of the 2.4 kernel series, I highly doubt that 2.2 is significantly faster than 2.4 (for the same tasks) on all but the very oldest hardware.
The only places that I think would want 2.2 over 2.4 are organizations that have mission-critical stuff running on 2.2 and aren't keen to fix that which isn't broken (if you'll pardon the cliche). Other than that, using 2.4 for most tasks is simply NOT going to cause armageddon. And also remember too that just because some piece of software is OLD doesn't automatically mean it's more STABLE.
If you run a firewall, all the more reason to upgrade to 2.4. Netfilter is far superior to ipchains, in my opinion.
Of course, you may not currently need stateful inspection, but you don't even have the option with 2.2. If you come to a point where you do, you're out of luck. (unless there is a current reliable backport out there, which is possible)
I used to use LRP on my router. Using such a stripped-down system was a great way to learn things. But eventually I switched to a minimal Debian install (once I got a hard drive for that old box).
Chmarr--
...
Try this:
int immediate = 1;
ioctl(pcap_fileno(pcap), BIOCIMMEDIATE, &immediate);
Does screw with some nonblocking modes, though.
Another quick tip: __attribute__ ((packed)); after your structure declarations will make structs vastly nicer to apply against raw packets in a cross platform manner.
Whatcha trying to write?
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Have you tried stripping the kernel?
It turned out my only serious problem with getting it to run on my SS-20 UP machine was that it's nearly impossible to get a kernel compiled for it that's below the one meg limit for booting that still has all the comment tag junk in it.
I have a Classic running RHL 6.2 because that was the last supported release on SPARC. It's been extremely stable (KDE/GNOME apps run like dying dogs though). However, my new SS5 will run Aurora Linux 1.0, which is based on RHL 7.3 and has a 2.4 kernel.
Ade_
/
Big Bubbles (no troubles) - what sucks, who sucks and you suck
It's better to rewrite everything to use iptables, though this does require some effort since the syntax is not quite the same. The biggest hurdle is figuring out how to log and drop a packet. In ipchains it is one command, in iptables you must create a new chain that does both actions and redirect packets to that.
I'm not trying to knock you, I'm just plugging a cool product (although I'm just a user, myself).