Linux 2.1.131


It’s a long time since I used a development kernel. In fact, I don’t think I’ve ever just downloaded the source and built it myself. The last time I was on the cutting edge, it came as part of an installation of Slackware. I think it was 1.1.59, and seemed to be no less stable than the real thing. So maybe it’s a little surprising that since I moved up to a Pentium I’ve always stuck with the stable 2.0.x series?

Not really. I’m a coward, firmly fitting into the ‘if it ain’t broke, don’t fit it’ mould. Not only was I on a faster machine, but 2.0 was faster than 1.2. Why would I risk breaking things for a few extra percent?

In a sense, I think I was right. But I’m getting ahead of myself, let’s get the thing installed…

Quick Aside

I expect that most people reading this will already know about Linux’s version numbering conventions. If you fall into this category, you may as well jump to the next section.

If you’re still with me you may be wondering what all the fuss about Linux 2.2 is and why there aren’t any Linux 2.2 betas.

The reason is simple: way back when Linux 1.0 was released, Linus Torvalds decided that all stable, ‘release’ versions would have even version numbers. In the case of release 1.0.9, ‘1’ is the major version number, ‘0’ is the version and ‘9’ is the patch number. Since ‘0’ is even it is considered a stable, usable by ‘normal’ people version.

The version I tested was 2.1.131. ‘1’ is odd so this is a development kernel, usable by people that are prepared to accept the occasional glitch. Note, however, that the kernel is now in a ‘feature freeze’ which means that only bug-fixes are being added. Put another way, even this development version should be, and is, fairly stable.


Linux sits very much at the heart of your system, and any upgrade to it shouldn’t be taken lightly. That’s why, for pretty much the first time in history, I took a look at the documentation.

make config ; make dep ; make clean ; make zdisk ; make modules ; make modules_install

What could be easier?

Well, after being cushioned by using RedHat for a number of years it was a little confusing to be expected know which options I needed to set. Nothing I couldn’t deal with — and nothing unexpected — but I just want to make it even clearer that this isn’t something that someone who has difficulty installing a Windows 95 application would want to do.

I must confess, however, that it wasn’t as difficult as I’d expected. It only made me happier when I rebooted my machine and it started, apparently, without problem.

In Use

In use it doesn’t feel at all different to 2.0. Running some unscientific benchmarks I find that it is, indeed, slightly faster and it does use slightly less memory, but I don’t think that’s the point. The point is that it now runs on even more machines, from i386’s to Acorn Archimedes, in even more configurations, from SMP to X.25. The point is that it now optimizes for many of the Intel compatible CPUs and handles many of their bugs.

However, it’s not all rosy. The PPP daemon from RedHat 5.0 doesn’t work out of the box. You need to download and compile a new version. I found this more difficult than building the kernel! (The problem was that it expected to be built at /usr/src and failed anywhere else with screens of not very obvious errors.)

And I’ve not managed to get my 64AWE Gold working yet, either. This is more laziness than anything else, the instructions look fairly straight-forward.

More seriously, one of the main new features seems not to work on my machine: the graphical console drivers. Normally this wouldn’t matter too much. I spend almost all the time in X anyway, so some memory uselessly set aside just for the sake of being cutting-edge is not really worth it. However, one main benefit of the graphical console is the Tux logo when Linux is booting…

Actually, it is useful. It means that there’s a standard interface across all Linux platforms, from i386 to SPARC. But not, apparently, if your video card doesn’t support the VESA 2.0 standard. I would have thought that this is relatively rare. My machine is less than three years old but only supports VESA 1.2.

Other bits and pieces

Looking at Joseph Pranevich’s excellent “The Wonderful World of Linux 2.2” in this months Linux Journal (December 1998), it would seem that my ‘aging’ hardware is unable to take advantage of most of the fancy new stuff.

For example, if you have a multi-processor box, 2.2 will work much better. There’s improved support for non-x86 architecture machines and there are optimizations for non-Intel x86 machines, too.


The new development kernel is smaller and faster than the current stable version and still appears to be rock solid. I’m not sure how the development team keep managing it when the millions of dollars that Microsoft invest seems only to increase bloat.

However, the features that have been added seem to be there to please ever more niche markets.

In summary: the best has managed to get even better.

One thought on “Linux 2.1.131”

  1. Hi! I’m just starting to learn about Linux. I’m researching the compatibilty of my hardware right now. I heard Red Hat was good for beginners so I’m looking on their website. Just a couple questions..

    1. I’m not finding anything about HD’s. Are they all supported then?

    2. I did see some compatible motherboards.. Does that mean that certain motherboards aren’t going to work?

    3. What ways (short of writing my own drivers) are available to work around incompatibilites with a particular Linux distribution? In other words, can you download drivers etc or is it not that simple?

    4. I want to put it on its own excusive HD, and sometime after Christmas build a whole new computer for it from scratch. Am I going to have a lot of trouble with newer motherboards?(533MHz/Rambus/ATA 133)


Comments are closed.