Recently in The $15 Laptop Category

(Image above from http://mike.kruckenberg.com)

We've pretty much reached the point at which it's probably cheaper to buy a laptop computer than it is to purchase a comparable desktop PC with the keyboard, mouse and monitor needed to make it all work.

Of course if you have all of those things — especially the monitor — you will still save money by buying just the desktop box and keeping as many of your old peripherals as will work.

But it seems like the graphs of "laptop cost" and "desktop cost" have finally intersected.

Laptops are convenient. You can carry them almost anywhere, use them almost anywhere ... you always have a keyboard, mouse (in the form of a touchpad) and monitor attached ...

Can you see where I'm headed?

Laptops break. And they're hard to fix. Often really hard.

And instructions on how to fix them are either really detailed (like those for Macs from ifixit.com) or, shall we say, "nonexistent."

I couldn't have replaced our 2003 Macintosh iBook G4's hard drive without the lengthy instructions from ifixit.com, and even with them, the procedure took three hours and had me cursing more than twice.

I thought that PC-based laptops put their hard drives in "civilized" places. On both my 1999 Compaq Armada 7770dmt and 2002 Gateway Solo 1450, I could swap out a hard drive by removing five screws, switching the drive and reversing the procedure. Five minutes from start to finish.

Now that I'm using this 2002 Toshiba 1100-S101 — hell, I've got TWO IDENTICAL MODELS — I find out little about how to replace their hard drives other than that "it's not easy."

There's no easily-accessible bay like in the Compaq and Gateway. The one forum post I found said that just about everything needs to be torn apart to get at the hard drive.

And now that the Toshiba on which I'm running OpenBSD seems to be slowly dying, the prospect of getting the drive out and trying it in the other Toshiba is looking to be way harder than I'd like it to be.

Clearly I should've spent more time with the other Toshiba before I decided which one I'd be using.

Here are the major parts of each laptop and their problems:

Case:

Toshiba 1 looked better from the outside
Toshiba 2 had a prominent crack that was somehow repaired

Keyboard:

Toshiba 1 has fairly worn keys. The space bar is a bit unresponsive toward the ends
Toshiba 2 seems fine

Touchpad:

Toshiba 1's has a tendency to stop working at all for short periods of time. After a certain length of time it also starts to become very erratic (a USB mouse always works fine).
Toshiba 2's touchpad seems fine, but I haven't used it enough to know for sure.

CD/DVD drive:

Both Toshiba 1 and 2 have very picky optical drives when it comes to reading CD-R discs. Each will only read/boot a few of my many CD-Rs. And each boots different ones.

Screen:

Toshiba 1 came to me with a sticker on it that said "bad screen." But since it seemed to work, I just went forward with my floppy/network install of OpenBSD 4.4. Today, though, the screen began blanking out intermittently. Squeezing the bottom plastic portion of the screen will often (but not always) fix it.
Toshiba 2's screen seems fine.

Sound:

Toshiba 1's sound is intermittent in both Windows and OpenBSD.
Toshiba 2's sound seems fine.

Hard drive:
Toshiba 1's hard drive runs fine.
Toshiba 2's drive seems a bit noisy

Floppy drive:
Both seem fine.

Battery:
I've learned to expect nothing from old laptop batteries. I haven't even tried using them.

CMOS battery:
Toshiba 1 powered up with the correct time and date. No problems since.
Toshiba 2 powered up with a 1999 time and date. I suspect that the CMOS battery is dead.

Ever try replacing a CMOS battery in a laptop? Some are easy to replace but super-expensive to buy (my Compaq), others are commonly found and inexpensive but seem impossible to extract (my Gateway).

The bottom line is that laptops are extremely convenient. But they are still quite expensive, and for the most part disposable. In the past few months, I've heard about plenty of bricked laptops — Macintosh and PC.

At my office, I have a Dell Optiplex GX520 that's now probably three or four years old. Actually, we've got quite a few dozen of them. I beat the hell out of the thing, and it just keeps working. I've spilled plenty of things into the keyboard. It still works.

Since it's a Dell and not a generic box assembled from off-the-shelf parts, it wouldn't be as easy to fix as something I put together from TigerDirect or Newegg-purchased components, but if the hard drive, optical drive, mouse, keyboard or monitor died, I'd have it fixed in a few minutes.

I'm as guilty as anybody of spending a lot of time (but in my case almost no money; all these dead and dying machines have been free or nearly so) using laptops. I don't have a "home office" that I actually work in (it's a sordid tale that I won't even begin to relate), so when I do work at home, it's pretty much on a laptop.

When, after suffering for over a year with the Gateway Solo 1450's not-to-be-tamed-by-any-BSD CPU fan, I found in the Toshiba 1100 a laptop with no CPU fan problem in OpenBSD.

Never mind that its optical drive, touchpad, keyboard, sound and display are not exactly ship-shape.

But I can run OpenBSD in peace. And for the past hour, the screen hasn't gone blank. The touchpad has even continued to work.

While the first Toshiba booted Debian Etch and a Half's netinstall CD (and nothing else, leaving me to install OpenBSD from a floppy — and damned glad that's an option), the second Toshiba booted Debian Lenny's business-card CD and Knoppix.

And I'm wondering how useful Windows XP is to me on either of these laptops. Even if I do manage to figure out the admin password and can bring them from Service Pack 1 to whatever it is XP is up to now. (Is it the SP3 that my Dell desktop for some reason refuses to install?)

If I get the time (and if Toshiba No. 1's screen doesn't continue to cooperate), I'll probably be running Debian Lenny from Toshiba No. 2 before the end of this week.

I did pull the memory door on one of the Toshiba's, and I was pleased to learn that the 256 MB is on a single SODIMM, meaning I could pull the module from one and have 512 MB in the other.

I'd probably be better off loading up the other Dell desktop I have waiting in the proverbial wings. It's not a server, but it uses this expensive PC800 Rambus ECC server memory. (What was Dell thinking, other than "mmmm ... expensive memory"?) Maybe it'll do OK with the 256 MB loaded in there now. And there's always my Power Mac G4/466, which runs Debian Etch fairly well in 384 MB of RAM (but without Flash video, since there's no Flash in the world of non-Mac-OS PowerPC). ...

I'll give Toshiba 1's hinky screen another week. Because I'm weak.

I feel like I'm booting children off a train.

Sure I've had my times when I installed a GNU/Linux distribution, used it for a couple of hours and then pulled it.

But for the past year or so, I've stuck with Debian, first with Etch and then Lenny since Etch went stable in April 2007. And when Ubuntu rolled out its new LTS distro in April of this year, I installed it and have been using it since. My older Compaq laptop has been running OpenBSD 4.2 for over a year, and I've done two very satisfactory Etch installs in the past month or so.

But on my main machine, a 2002-era Gateway Solo 1450 laptop, there's been trouble in GNU/Linux paradise.

After fighting with Debian Lenny for months over the Gateway's screen-refresh problems (which basically render much of that screen unreadable after a half-hour or so of use), I finally decided that I couldn't stick with the Testing branch of my favorite Linux distro on its road to becoming Stable. While many other problems cropped up and were mowed down either by me or the Debian Project itself, this last issue just wouldn't go away. And since I see not even one other person with this same problem, I fear the issue will never be resolved. I don't even know which package to file a bug against.

Remember when I thought I fixed my random-screen-freeze problem on this same laptop in Ubuntu 8.04 LTS? I thought that turning off automatic suspend in GNOME fixed the problem.

That didn't work. I still have random freezes. And I can't really blame it on the power plug because I've been in conditions where that plug does not move, and moreover these freezes never happened in Debian (when my screen image was not totally disintegrating, that is).

I was trying to get some pre-election work done on http://www.dailynews.com, and when I found that I didn't have the Java runtime installed (and needed it), I moved over to Ubuntu 8.04. In a half-hour, I had three unrecoverable crashes.

Again, I haven't heard of this happening to anybody but me.

I have TWO surplus laptops waiting in the wings. I'll see if any of them perform as well as or better than this Gateway. But whatever happens with those two machines, the Gateway will remain in service.

Once I decided to let go of Debian Lenny, I thought I would try Fedora 9, but when the live CD wouldn't let me install it, I turned to CentOS 5.2 — the free version of Red Hat Enterprise Linux — instead.

I first booted the live CD, then used the live CD to do a network install (NOT from the live environment but as a boot option). Once I determined that an http install wouldn't work but an ftp install would, I was off and running.

I've been testing CentOS 5.2 for about a week now. I've been slowly solving problems (adding things like Pidgin and Flash), and at this point I can say that CentOS 5.2 boots quickly, seems as snappy on this hardware as Ubuntu or Debian and runs extremely well.

I have yet to see a bug, and it has never crashed.

I have a full review and how-to for CentOS 5.2 in the works.

I hadn't anticipated replacing Ubuntu 8.04 LTS. I've had trouble with Ubuntu on this laptop since 7.04, and I've gone back and forth with it. Until I pulled it last week, I always had either Debian Etch or Lenny running on it. I've run Puppy 3.01 from live CD and the Slackware-based Wolvix Hunter — both with few problems.

The 2.6.18 kernel in CentOS 5 has always run better than any other on the Gateway. Other distros that share this kernel (albeit in slightly different versions) include PCLinuxOS 2007 and Debian Lenny.

And with support for RHEL/CentOS 5 slated to last a very, very long time, the fact that it runs so exceedingly well on this hardware gives me a true long-term solution.

I suspect that if I rolled the older Ubuntu 6.06 LTS — which has a little over seven months of support left before it EOLs — onto this laptop, it would run flawlessly. But it's packages are even older than Debian Etch's ...

As it stands right now, I'm going to stick with CentOS 5.2, and as much as I don't want to do it, I need to drop Ubuntu 8.04. I love Ubuntu — its philosophy and package mix, if not its brown color scheme. But I can't deal with the random freezes (after which ctrl-alt-backspace and ctrl-alt-delete are useless and only a hard reboot will work).

Aside from the screen-refresh problem, Debian Lenny was doing great. It improves on Etch in many, many ways.

I could see myself returning to Etch, which will have a full year of support as Debian's Old Stable distribution once Lenny is declared stable.

Whether I continue using this laptop or not, it has to run my daughter's educational games (GCompris, TuxPaint and Childsplay), and it has to be as stable as possible.

With Etch on the Gateway, I had trouble with the Alps touchpad, but since those problems were so easily solved in CentOS 5.2, perhaps I've learned enough to figure them out in Etch, where in addition to the touchpad-tapping issue the speed differences between the touchpad and a plugged-in USB mouse were more than a little incovenient.

I remember PCLinuxOS running as well as anything during the week or so I used it. I wonder how much support is left for the 2007 edition of that distro. The hype over PCLinuxOS has really slowed down over the past year, but I still think it's a very solid distro (based on Mandriva but with Debian-style apt and Synaptic package tools).

I've had trouble with X in Slackware on this platform, never seeming to get xorg.conf right, although Slack-based Wolvix runs perfectly for some reason. Slackware-based ZenWalk has all the packages I need and during the brief times I've run it has show itself to be extremely fast.

And since I'm running with separate /home partitions for both distros on this PC, switching those distros in and out should be less traumatic than in the past.

Even though I've taken great pains, after the fact (when it's harder to reconcile), to keep my user accounts' UID and GID numbers in Debian- and Red Hat- based distros compatible, I will probably dual-boot Fedora and CentOS for a while just to see how they match up on this hardware.

Depending on how things go with CentOS 5.2, I could eventually simplify things and do the unthinkable: not dual-boot anything.

CentOS seems terribly boring. But ever since Red Hat rolled a bunch of newer apps into its RHEL 5.2 (the base for CentOS), including Firefox 3 and OpenOffice 2.3, I've seen it as a very real alternative for the desktop.

And I neither expected it to run so well or for Debian and Ubuntu to run so comparatively poorly on this specific hunk of hardware.

If I had 10 test machines and Debian or Ubuntu ran flawlessly on them, I would be telling a different story, but from the perspective of this 6-year-old Gateway, RHEL/CentOS is pulling way out in front.

Here's the deal: I've been fighting with Debian Lenny for months on The $0 Laptop (Gateway Solo 1450), where I have everything running great except for my persistent problem with screen refresh in X. I've replaced the Intel i810 driver with the plain Intel driver, I've tweaked everything that can be tweaked in xorg.conf.

I can't really get work done while my display is slowly disintegrating during the course of a computing session.

I'm already running Ubuntu 8.04 LTS as the main distro on this system, and I've been thinking about what to do for the second distro. I'd go back to Debian Etch, but I had problems with the speed of the USB-connected mouse vs. the Alps touchpad, plus problems controlling the touchpad on its own.

In Lenny, the problems I've dealt with (and mostly solved) over the past six or more months have included suddenly disappearing sound (fixed with manually installed ESS Allegro modules), and an Epiphany browser that would always start in offline mode (fixed with a modification to Gconf2, if I have the name of the app right).

Nothing major — and nothing that couldn't be fixed with some help from either the bug reports themselves or other helpful people on the Web.

But this screen-refresh problem persists. I keep hoping that a routine software upgrade will take care of it, but that hasn't happened in countless xorg, driver and kernel updates. I don't think it's going to happen, either.

If you're running something that's very popular that catches the attention of developers (like the Asus Eee PC), chances are good that issues will be resolved. But I can't imagine any developers anywhere are paying any attention whatsoever to my 2002-era Gateway laptop. I'm no C hacker, so there's nothing much I can do, either.

I love Debian. I'm running two newish Etch installs right now (one PowerPC, one i386), and I could very well add a third with my $15 Laptop (Compaq Armada 7770dmt), or even more to a couple of testing desktops I have waiting in the wings. Whenever Lenny goes Stable, Etch will have another year's worth of patches as Old Stable before it reaches its end of life.

Etch has been great, and Lenny has made dozens of improvements. But this one regression has made it very hard to keep my favorite distro on my main laptop.

So I have been thinking for months about what to do, all the while hoping that I could fix the X problem in Lenny.

First of all, I need to rewire the power supply plug. I think that is what is responsible for my intermittent freezes in Ubuntu (which don't seem to happen in Lenny, for reasons unknown). When I have the laptop on a desk, it never freezes, but when it's on my actual lap, as it was when I was trying to work on last-minute election programming yesterday morning, those freezes can really throw me off. I moved over to Debian, but I needed the Java runtime, didn't have it installed and didn't have the time to do that.

And then there's the video issue.

So I've been thinking, what should I install in place of Debian Lenny? I'm a big fan of long-term support releases, especially for older hardware, so I strongly considered CentOS 5, a clone of Red Hat Enterprise Linux 5. But the relative lack of consumer-oriented software had me worried. I could add the Dag Wieers repositories to deal with that issue, but even that repository doesn't cover everything I need.

Mandriva is also on the table, as is one of my favorite distros, Wolvix. The Slackware 11-based Wolvix is due for a new version soon. While its package mix addresses most of my issues, there are a few things that I can't easily find for it. And I worry in Wolvix's case (as well as Slackware's in general) about how long the kernel goes without getting patched.

I almost never see new kernels for older Slackware releases. I don't know if that's because they are unnecessary, but with patched kernels rolling into Debian and Ubuntu fairly regularly, I wonder why Slackware does things differently.

I'd run "regular" Slackware, but I had quite a bit of trouble getting X configured, and I'd rather use GNOME than KDE. I know there are GNOME projects for Slackware, but what I'm trying to do is install something that works well, comes together easily and has lots of available packages.

Given all the Mandriva fans on LXer, I considered it. I've used the Mandriva-derived PCLinuxOS and thought highly of it — and I may in fact go that way. The 2.6.18 kernel in PCLinuxOS 2007 (Debian Etch is also built on that kernel) is perhaps the best ever for the Gateway in that it controls the CPU fan with no intervention. The intervention needed in other kernels is slight (a single line in /etc/rc.local usually does it), but it's nice to have it done automatically.

Again, I'm not a huge fan of KDE, and I find that distros that are either KDE- or GNOME-centric tend to treat the other desktop environment as something of a second-class citizen.

I've had Fedora in the back of my mind for a while. Seeing all the packages available is very encouraging. And the Fedora community looks like a very good resource in terms of getting things working. I imagine that quite a bit of RHEL information would apply to Fedora as well, giving the distro an even deeper bench.

I'm not crazy about the length of support for a given Fedora release, which looks to be 12 to 13 months. I'd feel better with the 18 months that Ubuntu's non-LTS releases get, or even a full 2 years. Compromising on length of support is something I'm willing to do at this time for something that potentially gives me all the packages I want and that runs well besides.

As far as the availability of packages goes, Fedora acquits itself well. I have run it from the live CD before, and it seemed to do well on the Gateway.

In a slightly related matter, my install of Fedora 9 on my Power Mac G4/466 didn't go so well. The X configuration was horrible, and the distro ran much slower than Debian Etch on the same hardware. And Debian did a perfect X configuration for the internal graphics card and huge LaCie electron22blue monitor. Sure I could've used the information from the xorg.conf in Debian to properly modify the same config file in Fedora, but with such a performance hit, it didn't seem worth it.

Since the 1.3 GHz CPU and 1 GB of RAM in the Gateway offers much more power than the 466 MHz and 384 MB in the G4, Fedora seems to run fine on the faster machine.

And now that I have the Ubuntu LTS as my main distro (and hopefully a trouble-free one once I replace that shaky power plug), it's time to try something else.

First I need to keep copies of the xorg.conf, my CPU-fan script and rc.local from Debian Lenny in case I do a reinstall. Then I need to back up the /home files and consider adding a separate /home partition for the secondary distro (Ubuntu already has a separate /home partition).

Again, I'm not happy about the 13-month life cycle of any given Fedora release, and I really don't need a cutting-edge kernel for my not-cutting-edge hardware (unless, of course, it makes a cheap wireless adapter work), but with /home on its own partition, and Fedora installing GRUB on the root partition instead of the master boot record, with the GRUB on the MBR chainloading to the Fedora partition, it shouldn't be hard to roll Fedora out and something else in.

I could change my mind ... or not.

Update: OpenSUSE offers about two years of support per release, and that is enough to get me interested.

I'm downloading new OpenSUSE 11 and Fedora 9 ISOs now, and I'll burn them in the morning.

As of today, here are all the machines I use and what they run:

At the office:

Work box:
Dell Optiplex GX520
Pentium 4 (3 GHz)
512 MB RAM
Windows XP SP2

The Debian Mac:
Power Macintosh G4
466MHz single PowerPC processor
384 MB RAM
Debian Etch

The Self-Reliant Thin Client:
Maxspeed Maxterm 5300(??) thin client
VIA C3 Samuel (1 GHz, running at 500 MHz for some reason)
256 MB RAM
8 GB Transcend Compact Flash module as boot drive
1 GB USB flash drive for backup
Debian Etch

At home:

iBook G4
1 GHz CPU
384 MB RAM
120 GB Fujitsu hard drive (replaced by me in a 3-hour odyssey)
OS X 10.3

This Old PC:
Pentium II MMX (333 MHz)
256 MB RAM
10 GB hard drive
Windows 2000 (I haven't booted this or connected it to the Internet in over a year)

The $0 Laptop:
Gateway Solo 1450
Mobile Celeron (1.3 GHz)
1 GB RAM
30 GB Toshiba hard drive
Ubuntu 8.04 LTS, Debian Lenny, Puppy 3.01

The $15 Laptop:
Compaq Armada 7770dmt
Pentium II MMX (233 MHz)
144 MB RAM
3 GB IBM hard drive
OpenBSD 4.2

I have quite a few machines in various states of repair that I might resurrect over the next year if and when I get the time, but this is what I have right now. With the exception of the white-box This Old PC, all of these get fairly regular use.

Every time I write about Ubuntu 8.04 LTS, which I've been running on my Gateway Solo 1450 laptop since its release in April, I mention that it's the only GNU/Linux distribution I've used that successfully suspends and resume the computer.

And I've made that feature — suspend and resume — the bar over which other distros must jump to "beat" 8.04 on this platform.

Make no mistake, I've "enjoyed" a working suspend/resume capability. But I haven't enjoyed returning to the laptop after a while to find the screen looking normal but the keyboard and mouse completely dead. CTRL-ALT-backspace won't kill X. CTRL-ALT-delete won't reboot the machine. I need to do a hard boot with the power button to get things working again.

I've had X issues in many distros, most severely with Debian Lenny, my preferred distro for this PC, which has serious problems with refreshing the screen, leaving the upper panel in GNOME and many graphical elements of various applications virtually unrecognizable after about a half-hour of use.

I appeared to have a similar X issue in Slackware 12, which I installed only briefly (and too briefly to make a determination, especially since I never got a "perfect" X configuration), but other systems, including CentOS 5, Fedora 9, and Puppy 3.00 had none of these issues.

Nor did Ubuntu 8.04, which automatically wrote an xorg.conf that was much different — being way more spares — than any other I'd seen before. But X performs flawlessly.

Even though suspend/resume works in Ubuntu, I'm now about 80 percent sure my intermittent keyboard/mouse freezesare caused by whatever daemon is responsible for automatically checking whether or not to suspend the system.

I pretty much arrived at this point through the process of elimination with the addition of a little bit of logic. Since no other distro appeared to be freezing like this, and since I only have automatic suspend/resume set on Ubuntu, that seemed to be the most likely cause.

So I went into the GNOME Power Manager utility and turned off the "put the computer to sleep after XX minutes" feature.

Since then, I've had no freezing whatsoever in Ubuntu 8.04. A month from now, I'll be sure.

Unfortunately, I haven't been able to figure out the problem with screen refresh in Debian Lenny. I'm considering wiping it from the laptop and trying another secondary distro, maybe CentOS or Fedora. Even Sidux — a more "tame" version Debian Sid — is something to try just to see if I continue to have the screen issues.

Or I could just stick with Ubuntu 8.04. I'm not thinking about upgrading to 8.10, which not coincidentally is available for download today.

Click that last link to see the major new features in Ubuntu 8.10. I'm very unlikely to need 3G wireless, but if I find that 8.10 supports my Airlink 101 AWLL 3028 USB wireless adapter, I would strongly consider doing the upgrade.

I'm sure all of the Ubuntu mirrors are straining mightily with everybody trying to download the whole 8.10 image or upgrading their current installations. I'll be waiting at least a couple of weeks before I try to download the ISO and burn a live CD. If that loads and then the wireless works out of the box (I won't be holding my breath), I'll go forward.

Otherwise, I'll stick with 8.04 LTS — the long-term-support edition of Ubuntu that will be supported until 2011 on the desktop.

But with suspend/resume off the table, Ubuntu has lost its edge over every other GNU/Linux distribution (and even FreeBSD/PC-BSD) on this laptop.

I've been sticking with my installs much longer than usual — I'm still using a now-year-old installation of OpenBSD 4.2 on my $15 Laptop (and OpenBSD 4.4 will be released on Nov. 1).

See tomorrow's post for a breakdown on what I'm running on every machine.

My inability to do more-than-simple mathematics at times has really put a cramp in my computing style.

In the case of OpenBSD and the $15 Laptop — the Compaq Armada 7770dmt — it has cost me 32 MB of RAM ever since I upgraded from 64 MB to the maximum 144 MB.

The reason is that in some Compaq's OpenBSD will not address more than 16 MB of RAM without some intervention on the part of the user.

This intervention is described in OpenBSD's installation FAQ. In order to have the system recognize the additional memory in the affected Compaqs, you must create a file called /etc/boot.conf containing one line, which tells the OS about your additional memory.

The example in the OpenBSD FAQ is for a system with 64 MB of RAM but with the aforementioned 16 MB being recognized.

To get the additional 48 MB recognized by the system, the following line should be in your new /etc/boot.conf file:

machine mem +0x3000000@0x1000000

That worked perfectly when I, also had 64 MB of RAM.

But when I added 128 MB to the 16 MB on the motherboard (removing the 48 MB of RAM that the laptop had when I originally got it working), I had to change the value in /etc/boot.conf.

And I didn't do my math correctly. This is what I had:

machine mem +0x6000000@0x1000000

I suspected that the machine wasn't using the entire 144 MB, but I'm not conversant enough in OpenBSD as opposed to Linux to a) figure out exactly how much memory the system was recognizing (a number available in the dmesg output) and how much the system was using and how much was still "free" (which can be seen in the output of the top utility.

I've been looking at OpenBSD's installation FAQ again recently because I'm eager to try the OS on my new/old Power Macintosh G4/466, and I looked at the section on Compaq memory again and realized my error.

I realized that if 48 MB is recognized with +0x3000000, then each +0x1000000 represents 16 MB of additional memory. And following that logic, 48 MB is 16 MB times three, yielding the FAQ example of +0x3000000.

And since I was adding 128 MB, that was 16 MB times ... how many? Eight is the answer. So instead of the +0x6000000, I needed the following line in /etc/boot.conf:

machine mem +0x8000000@0x1000000

I booted OpenBSD 4.2 (I don't have enough space in /usr to upgrade to 4.3 — such is the problem with making that partition only 1 GB in size when it needs to be, as the FAQ says, 5 GB). Then I changed the value in /etc/boot.conf, rebooted and saw the dmesg roll by during the reboot with the entire 144 MB being recognized.

Missing 32 MB all this time represents a very large performance hit, and I'll be anxious to see how gaining access to that memory changes performance under X.

For those keeping score, here's the relevant part of my OpenBSD dmesg AFTER doing the /etc/boot.conf fix:

real mem = 150564864 (143MB)
avail mem = 137732096 (131MB)

(This post was originally written on April 24, 2008. In the days following, I was able to tweak xorg.conf and run Wolvix on the $15 Laptop (Compaq Armada 7770dmt, on which it runs quite well.)

Finding my long-lost Wolvix post got me itching to run it again. I haven't had it on the $0 Laptop (Gateway Solo 1450) in some time. It did a good job there, but I wasn't able to turn off the annoying tap-to-click feature on the laptop's Alps touchpad, and I've been pretty happy with how Debian Lenny is doing that and more, so my use of Wolvix has dropped quite a bit.

If I could manage to get X configured properly on the $15 Laptop (Compaq Armada 7770dmt) now running OpenBSD 4.2, I'd be running the smaller Wolvix Cub (smaller than Wolvix Hunter, which I run otherwise) on the aging PC right now. The combination of the Xfce and Fluxbox window managers, plus the excellent choice of apps (it has pretty much everything I use day to day) makes the Slackware 11-based Wolvix Cub and Hunter two of the best choices out there — for me anyway.

Adding to Wolvix's flexibility, it can run as a live CD, or be installed in a traditional or "frugal" manner. I've chosen traditional installs, and the install process in Wolvix is excellent. It's easy to create as many partitions as you need, you get a choice of GRUB or LILO bootloaders, and once you do have it installed, slapt-get and Gslapt are ready to bring all the apps up to date from both the Wolvix and Slackware repositories. And the Slackware team continues to update version 11, which was first released in October 2006. Even Slackware 8 (circa 2002) seems to get an update every once in awhile.

All of this makes me very comfortable running Slackware and ... well ... Wolvix, because the two "big" Slackware-derived distros, Zenwalk and Vector, use their own repositories, and they don't support a given release for very long before moving on to the next one. This burned me pretty good one time; I was running Zenwalk 4.4.1, and it was working great, but an unfortunate invocation of the distro's update manager completely broke the thing after 4.6 came out. My machine wouldn't boot the 4.6 CD, so it was the end of Zenwalk for me.

I like Vector, but I like Wolvix even more. And I really like having Slackware's security team watching out and sending patches that flow right into my Wolvix installs with a few easy clicks.

I also like a Slackware-based setup that doesn't depend on KDE. If you have a fast-enough box, KDE is great. My Gateway laptop handles KDE very well, even though I prefer to use GNOME on it. But on my older, slower, less-memory-rich boxes, KDE is a bit too sluggish, and I like a well-appointed Xfce or Fluxbox setup much better. (Note on 9/15/08: My most recent Slackware 12.1 install on the Gateway, though not without problems related to X configuration, again showed KDE to be quite spry and Slack's default lineup of applications to be more than adequate.)

Ever try installing Slackware without KDE? It's easy to do. In fact, the excellent Slackware installer offers complete control, on a package by package basis, over what gets put on your box during the intallation. If you elect to leave out all of KDE, you can run Fluxbox or Xfce, but you get very few apps. And the install still takes up over 2 GB of space. No Abiword, no OpenOffice. I guess that would be a good time to add one of the many GNOME-for-Slackware packages out there, like Dropline GNOME (which wouldn't work on this non-686 CPU, I think, but one of the others will).

But again, Slackware's KDE-centricity doesn't leave the Xfce or Fluxbox user with a whole lot of applications. Sure you can build the system you want with Slackbuilds, Linux Packages or Robby Workman's packages, but I don't think it's a coincidence that there are three major Slackware-based distros (Wolvix, Vector and Zenwalk) that use Xfce as the primary desktop environment.

And being able to use a Wolvix CD to get literally dozens of applications I know and love makes things that much easier. Add to that my seeming inability to get GRUB to boot Slackware 12 (I'm sure using Slack's own GRUB package and script would solve my problem), and Wolvix has solved quite a few problems for me.

(Note on 09/15/08: While Wolvix does an excellent job setting up the LILO or GRUB bootloaders, I've since adopted a policy for dual- and triple-booting in which one distro, using GRUB, controls the Master Boot Record and chainloads into all the other bootable partitions on the drive, with every one of those OSes using their own bootloaders — whatever they may be — on their own root partitions. It makes swapping OSes easier and makes automatic updates of the various /boot/grub/menu.lst files work every time — not always the case with everything stuffed into the /boot/grub/menu.lst controlling the MBR.)

(This post was originally written on April 24, 2008; since then, I've bumped the system up to 144 MB. This entry should set the scene for how much better things are working with the additional memory).

When you're not running X, 64 MB of RAM is plenty. In OpenBSD, or just about any version of Linux for that matter, you just don't need a lot of memory to use the console. Of course, you can't do a whole lot either.

I know, I KNOW, that real geeks use the command line as much as possible. E-mail with Mutt or Pine (and fetchmail, procmail, sendmail, procmail ... did I miss anything (maybe msmtp, which I prefer, or esmtp, exim, postfix ...), text entry with vi (or nano, joe, emacs), text-only Web browsing with Lynx or Elinks.

OK, I do all this stuff, though I did give up on Mutt; it just didn't work for me as well as I needed, and while I put in plenty of time on the configuration, I needed to be way more of an expert than I'll probably ever be). But I really prefer to run X. I get the apps I want, real Web browsing, and a whole lot more overall productivity.

But X takes memory, and while OpenBSD with the Fvwm window manager can run in 64 MB, things take forever and a day due to all the swapping. Unfortunately, my 1999-era laptop -- a Compaq Armada 7770dmt -- maxes out at 144 MB. That's 16 MB on the motherboard, plus two 64 MB EDO SODIMMs.

The memory is on the way (I hope). Right now I have two smaller SODIMMs, a 16 MB and a 32 MB, in the laptop. And yes, I had to do the Compaq memory fix from the OpenBSD FAQ to make the OS recognize the "extra" memory. But it does work.

Anyway, I'm hopeful that OpenBSD will perform dramatically better in X with 144 MB. Since this is a pre-ACPI laptop, I don't have the problems that plague me with my Gateway Solo 1450, on which only Linux, it seems, will turn the fan on and off in response to CPU temperature. In OpenBSD, it's all on. In FreeBSD, it works for a day, and then that's the end of it. Can't figure out that one.

But I'd love to have a laptop devoted to OpenBSD (I'm using vi now ... but I miss Geany, Firefox and the rest of the junk I've got loaded on here). And if OpenBSD can work well on the desktop with only 144 MB, that will be a significant achievement for all of us with hardware in the 10-year-old range.

I'd love to roll OpenBSD onto my 10-year old PC that now runs Windows 2000. It would Do OK with Linux, for sure, but getting OpenBSD on there would be really great. And I have a full 256 MB of RAM on that box. I'm already running that much memory on my test box in the office, and I have no complaints there when it comes to running X apps in OpenBSD.

I started X to finish this post. First I ran Firefox, even though this laptop has only wireless 802.11b networking (and no wired Ethernet, although I've been meaning to get a PCMCIA Ethernet card). Yep, still takes a dog's age to start Firefox, and it's not all that responsive when it's running.

Again, I would love for that NOT to be the case after the memory upgrade.

I started Geany to continue writing. Geany runs pretty well with this 233 MHz processor and 64 MB of RAM.

So does the Dillo browser. And everytime I write about Dillo in OpenBSD, I like to mention that, for some reason, the Dillo menus and buttons look way better in the OpenBSD version of the app (I'm using the package, not the port) than they do in any other operating system in which I've tried it. And I've tried many.

I've been able to have OpenBSD's /etc/fstab automatically mount the ext2 filesystem on my Compaq Armada 7770dmt's hard drive with no difficulty lately, but every couple of days or so I get a message while booting OpenBSD that says the Linux filesystem is not clean and that I should run fsck on it.

I then boot Puppy Linux 2.13, run e2fsck on the partition, the errors are cleared up, and all is well until a few more days pass.

I haven't lost any data, but I'm going to do a few experiments.

First, I added noauto to the /etc/fstab line so the Linux filesystem will not be automatically mounted. Then I'm going to run Puppy for a few days and check the filesystem with e2fsck.

It could be that the errors are coming from Puppy alone. I think that's unlikely, but it is a possibility.

Then I'll experiment with manually mounting (with mount) and unmounting (with umount) the Linux filesystem while in OpenBSD.

That way I can see whether or not automounting and unmounting the ext2 filesystem in OpenBSD is what's causing the problem.

Hours later: Looks like OpenBSD is NOT responsible. I ran Puppy totally in RAM (using the puppy pfix=ram boot parameter), than ran e2fsck to clean up the filesystem on my ext2 partition. Then I ran Puppy the "normal" way, in which the system mounts the partition to access the pup_save file. I then rebooted and once again ran Puppy without mounting the partition. At no time did I boot OpenBSD or mount the filesystem in that OS.

Once I was back in Puppy, running pfix=ram to keep the partition unmounted, I ran e2fsck and got this message:

/dev/hda3 was not cleanly unmounted, check forced.

I had one more test to do.

Now that I had run e2fsck on the ext2 filesystem, I needed to boot OpenBSD, mount the filesystem, write a file to it, then unmount it. After that, it would be time to boot Puppy Linux again, using the pfix=ram boot parameter again so as not to mount the filesystem in Linux, and then run e2fsck again to check the filesystem and see if mounting, writing to and then unmounting it caused any errors.

So I booted into OpenBSD 4.2, mounted the ext2 filesystem, modified a few files, added a few, then unmounted it. I rebooted and did the same thing again.

Then I booted into Puppy, again with the pfix=ram boot parameter so as not to mount the Linux partition.

I ran e2fsck. After two boots of OpenBSD, during which I modified files in the Linux filesystem both times, there were no errors in the ext2 filesystem.

I said it was "unlikely," but in fact it's Puppy Linux, NOT OpenBSD that is not "cleanly" unmounting the Linux filesystem. I truly expected it to be the other way around.

I'll have to test this with Damn Small Linux, Wolvix and maybe even Slitaz to see if this is a Linux problem, or just a Puppy (or Puppy 2.13, to be more specific) problem. But right now, OpenBSD has absolutely nothing to do with it.

Mounting the filesystem in:

Damn Small Linux 4.3 caused no errors

I've had a bit of a difficult time with my OpenBSD 4.2 installation on the $15 Laptop — a Compaq Armada 7770dmt with 144 MB RAM, a 233 MHz Pentium II CPU and 3 GB hard drive. I use PCMCIA cards for networking, an Orinoco WaveLAN Silver for 802.11b wireless and a TRENDnet TE-100PCBUSR 10/100mbps for wired Ethernet.

Since I upgraded the memory from 64 MB to the 144 MB maximum for this machine, things are running much, much better.

But I'm running out of room in the /usr partition. I'm not sure whether or not OpenBSD can be installed in a single partition, but since the install FAQ tells you to set up separate partitions for everything, that's what I did.

On this drive, I set aside about 600 MB for Linux filesystems to create swap and a place to store files for Puppy Linux, leaving 2.4 GB for OpenBSD.

At the end of the OpenBSD partitioning, I had 1 GB for /usr, which is where applications are stored in the system.

For awhile things were going fine. I had our daughter's Gcompris, TuxPaint and Childsplay games on here, Firefox, the Geany text editor, plus a few console apps like nano, mc and mutt.

But it's not console apps that are taking up all the space.

I pulled the games and their libraries in order to fit the Opera Web browser and the Linux compatibility package needed to run it. That was the best thing I've done for this install since I did it. On this old hardware, the Linux build of Opera runs much faster than Firefox.

That speed really shows up when blogging with Movable Type. For some reason, even in Linux, scripts keep timing out in Firefox and the Mozilla-based Seamonkey. Now that I have Opera installed in both OpenBSD and Puppy 2.13, I'm a lot happier on this old laptop, which is about as challenged as it gets when it comes to old hardware working with modern operating systems and applications.

Anyhow, I needed to do some more "formatted" writing, and I did have the Ted word processor installed. But Ted isn't great when it comes to centering type, print previews or generating PDF output.

I needed Abiword. But I didn't have enough space.

The only thing big enough: Firefox.

Yep, I got rid of Firefox. One thing about the OpenBSD package manager that isn't helping me out here is that when you install a package, all the dependencies are checked, and the additional packages needed are downloaded and installed. But when you remove a package, the system doesn't check its dependencies for whether or not they're still needed by other applications in the system.

I'm sure there's a reason for this, and there's probably even a way around it (like the great deborphan app that I use in Debian), but I know nothing about it.

Anyhow, I managed to get Abiword installed, and I have 500 MB left in my /usr partition. Unfortunately, the spell-check in Abiword doesn't work in the OpenBSD build. Abiword spell-check doesn't work in Puppy either.
The spell-check installs and works most of the time in Debian (especially when you install it with Aptitude and get all the packages you need, rather than with apt-get, where at least sometimes you don't).

I found an old OpenBSD mailing-list hack about how to fix Abiword's spell-checking capability, but it didn't have enough information, and it didn't look like it would work anyway.

But the good news is that with this amount of memory, Abiword 2.4.5 runs extremely well in OpenBSD 4.2. Additionally, for some reason the fonts in Abiword look better in OpenBSD than then do in most other Linux/Unix systems.

So now I have Abiword, Geany, Opera and the Dillo browser as my "main" applications on this system. I don't want to forget the Rox-filer file manager. I put that on the box awhile ago. I still need space to add the Flash plugin for Abiword, and Rox is a prime target for removal so I can get that space ... or the space to install Gaim/Pidgin for IM.

But I just can't do it. I've loved the Rox-filer ever since I first used it in Puppy, and I just can't give it up.

I probably should. I removed mc (Midnight Commander) for space reasons, even though it probably doesn't take up all that much space, and since I had Rox. If mc didn't have problems with the function keys in the console (it misreads the keys for some reason), I'd be able to fit one more app in. (Note: mc works perfectly in an xterm window, just not in the console).

What I'm going to have to do eventually is reinstall OpenBSD. I need a bigger drive so I can have a big /usr partition, install everything I want on it, as well as have room for a full Linux install as well, something I could use in addition to Puppy.

So the OpenBSD install is really tight, in terms of space for applications, but it's working extremely well. I now have the ability to share files between OpenBSD and Linux via an ext2 partition, and that has added tremendous value to this laptop.

I could be using my Gateway laptop a lot more. It's got way better specs (1 GB RAM, 1.3 GHz CPU) and runs Linux way faster. But it isn't so hot with OpenBSD due to the noisy, uncontrollable-by-BSD CPU fan. And its PCMCIA slot still isn't fixed, so I can't run wireless with it.

The Compaq may be underpowered, but it has a very clear, very bright screen, an excellent keyboard, working wireless, no ACPI issues (since it has no ACPI), and there's just something about getting it to work and keeping it working that I find compelling.

And there's also something about OpenBSD that keeps me coming back to it, even on the desktop.

The OpenBSD system on the $15 Laptop (Compaq Armada 7770dmt) has a 3 GB hard drive mostly devoted to OpenBSD, with about 600 MB set aside for Linux, about 130 MB as Linux swap and the rest an ext2 filesystem on which I have my pup_save file for Puppy Linux and any other Linux files I've generated with other live CDs (Wolvix and Slitaz at the moment).

As I recall, I created the Linux partitions at one end of the drive and reserved the front for OpenBSD.

As a result, OpenBSD wrote its disklabel -- the system's guide to how the drive is partitioned -- to include one big Linux partition and not the separate swap and ext2 partitions I later created.

Check your disklabel this way (as root) (and with the name of your drive, mine being wd0):

# disklabel wd0

You should see any non-OpenBSD partitions at the end of the list.

You can edit the disklabel this way:

# disklabel -e wd0

This opens a file in vi (the default editor in OpenBSD, or whatever the $Editor variable is set to; I'd reset it to Nano if only I knew how).

I tried to modify the disklabel to recognize BOTH Linux partitions, but all I got were errors in both OpenBSD and when booting Puppy 2.13.

To figure out how to edit the disklabel, I ran the following command in OpenBSD:

# fdisk wd0

I figured that copying the "start" and "size" info into the disklabel would make my Linux partitions mountable in OpenBSD.

Nope.

I got some fsck errors when I booted Puppy. I fixed them by a) deleting and re-creating the Linux swap file and b) running Puppy in RAM (boot parameter: Puppy pfix=ram) and running e2fsck on my ext2 partition.

I still don't have my Linux filesystem mountable in OpenBSD, but I didn't lose any files or filesystems either.

Clearly I need to figure out how to take the information from fdisk and properly write it in the disklabel.

I'm just glad (and very much amazed) that I didn't lose anything. It's a tribute of sorts to the OpenBSD system and documentation that I managed not to totally kill the whole installation.

You might ask why I'm spending so much time figuring out how to best configure a Compaq Armada 7770dmt — a laptop with an ancient 233MHz Pentium II MMX processor, feeble 144MB of RAM and smallish 3GB hard drive.

For one thing, I almost never abandon a machine that can be used. And this one definitely can be.

Plus, I like the Compaq. It has a nice screen and keyboard, I like the fact that its power supply is totally contained in the laptop case. The thing's pretty solid.

And I remember my long search for a laptop. Just about everything I saw on the used market was overpriced and lacking essential parts (hard drive, power brick, CD drive, memory ...) but still selling for too much.

When I found this laptop for $15 and only had to add a CD-ROM drive that cost an additional $10 and a WiFi card I already had, I was hooked.

The build quality of this 1999 Compaq is much better than my 2002 Gateway, and I expect the Gateway to die long before the Compaq.

And with Linux, I've learned that a nearly 10-year-old PC can be quite usable. That means This Old PC, with a faster Pentium II processor (333MHz), more RAM (256MB) and which uses cheaper desktop IDE drives — and which at 11 years old is even longer in the tooth than the Compaq — is also still quite usable.

The fact that I searched long and hard for one laptop, came up with nothing from Craigslist and eBay, but then ended up with two laptops within months, getting each for next to nothing, was an opportunity to learn about hardware, software and what it takes to get things done in a variety of operating systems (I've run many versions of Linux, plus FreeBSD — including offshoots DesktopBSD and PC-BSD, NetBSD, OpenBSD, a couple of projects based on OpenSolaris, and yes, even Windows).

Even if I had $500 or so to buy new laptops every couple of years — and believe me, I don't, there's a lot of nobility, fun and plain old value in keeping these PCs running. And running well.

I guess you could call it a hobby.

I could do a lot worse, no?

Previously:
In search of the best OS for a 9-year-old laptop: Part I — Puppy or Damn Small Linux
In search of the best OS for a 9-year-old laptop: Part II — OpenBSD or Debian?
In search of the best OS for a 9-year-old laptop: Part III — Browsers and wireless
In search of the best OS for a 9-year-old laptop: Part IV — Wolvix Cub is surprisingly strong
In search of the best OS for a 9-year-old laptop: Part V — Where I'm headed
In search of the best OS for a 9-year-old laptop: Part VI — Younger Puppies
In search of the best OS for a 9-year-old laptop: Part VII — Debian with Xfce and Fluxbox calls

I've never had to configure a network interface in OpenBSD. In all of my installs, I set it up and just left it the way it was.

I've done plenty of configuration-file hacking to get interfaces working in various incarnations of FreeBSD and NetBSD, so I didn't think I'd run into any trouble.

And yet another time, the excellent OpenBSD documentation carried me through.

The information on how to configure a network interface can be found here.

Basically, I used the ifconfig command to figure out what the system was calling my new TrendNET PCMCIA Ethernet card. That would be rl0.

Working as the super user, I created the following file:

/etc/hostname.rl0

I needed a static IP and used vi to write in the following line:

inet 10.0.0.38 255.255.255.0 10.0.0.255

In this case, 10.0.0.38 is my IP address, 255.255.255.0 is the subnet and 10.0.0.255 is the broadcast address. Use your own static IP info to fill in these values.

Create the file /etc/mygate and put your gateway address in it (again, this number is an example; so use your own):

10.0.0.254

Edit the /etc/resolv.conf file (adding your own search domain and nameservers):

search example.com
nameserver 125.2.3.4
nameserver 125.2.3.5
lookup file bind

Then restart the network:

# sh /etc/netstart

The OpenBSD FAQ explains it better than I do, and configuring a network interface for DHCP is even easier.

In my exhaustive and exhausting series on finding an OS for the $15 Laptop, I made extensive mention of the fact that I found OpenBSD under X quite a bit slower than Linux. I can't explain it other than to say that speed is very important on extremely old hardware, and I don't envision myself sticking with OpenBSD, although I'd really like to do so.

And if I could get ACPI fan control working for the $0 Laptop (Gateway Solo 1450), I'd definitely be running OpenBSD on it as well, but I'm afraid that might never happen.

Again, for the umpteenth time, OpenBSD is very fun to play with. The documentation makes it easy to learn, and the packages — of which there are many — are of very high quality.

I know I said in a previous entry that Debian's Xfce installation didn't exactly provide what I wanted, but looking at what I need, Debian rises to the top of the pack.

Top of my list: Installing Debian with encrypted LVM. Especially in a laptop, encryption is a must to secure your data from prying eyes, should the laptop be lost or stolen.

And any little utility that Wolvix has can probably be added in Debian. And Aptitude is very good. It's not graphical, but it represents the best of Debian.

And I still trust the security team for Debian more than I do most others — this despite the OpenSSL problem that has recently plagued every Debian-based distro in recent weeks. (At least somebody figured it out, and the whole incident should tighten up things considerably in the Debian Project).

And in Debian, I can easily install all of our little girl's educational programs, although she is fairly vocal about preferring to use the newer, faster $0 Laptop, a 1.3GHz Celeron-based Gateway laptop with 1GB of RAM.

The only "stopper" is Google's lack of willingness to easily let users install Google Gears in Mozilla-derived browsers not named Firefox. That means it's a pain in the ass to install Gears with Iceweasel, the Debian-derived, noncopyrighted equivalent to Firefox.

And I haven't tried Debian on the Compaq Armada 7770dmt since I boosted the RAM from 64MB to 144MB. Responsiveness in X could be a lot better with such a relative overabundance of RAM.

So as far as the Compaq goes, I'm down to running Debian or Wolvix on the hard drive and Puppy as a live CD. Like I said previously, I don't want to kill out OpenBSD just yet, so I'll need either a second hard drive or a 4GB Compact Flash card with CF-to-IDE laptop adapter (the latter available for a quite-reasonable $10 at LogicSupply.com). I might even spring for a second hard-drive caddy for the Compaq, should I be able to find one, to make swapping the drives that much easier.

Or I could bite the bullet, get rid of OpenBSD for the time being, try out Debian and Wolvix on the hard drive, and narrow things down. I'll continue to run Puppy, with a separate partition for its encrypted pup_save file.

I've taken to using the Leafpad text editor in Puppy (I'm using it now), and the Leafpad-derived Mousepad editor in Xfce is just as fast, if spartan. Xfce's Terminal app has similar attributes. And I have no problem running xterm or rxvt.

It's really about the text editors and browsers I use, the software my daughter likes to run, stability, security, encryption and ease of maintenance.

Moreover, it's about speed on old hardware. These things look very different on newer computers. My 2002-era Gateway laptop runs Ubuntu very well. I doubt I could even boot Ubuntu on this Compaq. Even the Xubuntu live CD won't boot. With Debian, I have no problem.

On the Gateway, Ubuntu's polish as compared to Debian makes Ubuntu a better choice. But on this older Compaq, Debian's flexibility and added speed (don't ask me why it's faster, it just is) are much needed.

Next moves: I need to get a PCMCIA Ethernet card since I don't have regular access to WiFi. While I'm at it, a PCMCIA card for USB is something I should also look into. Sure, I could transfer files over the network, but USB is ... easier. (Note: Since this post was originally written, I have gotten an Ethernet card for the Compaq).

Previously:
In search of the best OS for a 9-year-old laptop: Part I — Puppy or Damn Small Linux
In search of the best OS for a 9-year-old laptop: Part II — OpenBSD or Debian?
In search of the best OS for a 9-year-old laptop: Part III — Browsers and wireless
In search of the best OS for a 9-year-old laptop: Part IV — Wolvix Cub is surprisingly strong
In search of the best OS for a 9-year-old laptop: Part V — Where I'm headed
In search of the best OS for a 9-year-old laptop: Part VI — Younger Puppies

Coming up:
In search of the best OS for a 9-year-old laptop: Part VIII — Final thoughts (aka "Why?")

As I say in a previous post on this very topic, there are many reasons to choose Puppy Linux as the primary OS on the nearly 10-year-old Compaq Armada 7770dmt laptop.

For one thing, Puppy is ideal — and explicitely designed — to run as a live CD or easily upgraded frugal install, the latter either on a traditional hard-disk drive or a Compact Flash memory card mounted in a CF-to-IDE adapter inside the Compaq's hard-drive caddy.

With recent versions of Puppy (2.17 onward, I believe) the ability to encrypt the pup_save file that holds all of the user's files and configurations adds both a needed measure of security to a laptop installation as well as providing an equally easy way to back up the entire system by copying a single large file to just about any storage medium, from USB flash drive to CD-RW to hard disks in formats ranging from old-school FAT to NTFS to Linux's many types of filesystems.

Also in Puppy's favor is that recent versions have heightened compatibility with Slackware 12 packages, promising a greater number of sources for additional applications, should I ever want or need to add anything beyond what Puppy and its own repositories already provide.

To recap, in the time I've had the 1999-era Compaq Armada 7770dmt laptop (again, with a 233MHz Pentium II MMX processor), I've taken it's RAM from 64MB to the maximum of 144MB, kept the original IBM-made 3GB hard drive, and run the following operating systems:

• Debian Etch "standard," with X and Fluxbox added
• Debian Etch Xfce desktop install
• Slackware 12 without KDE
• Puppy Linux 2.13
• Damn Small Linux 4.0, 4.3 and 4.4
• OpenBSD 4.2
• Wolvix Cub 1.1.0

Truth be told, I liked every one of these installs to one degree or another. While Slackware (installing without KDE but with everything else) took up too much space and offered too few applications I wanted, it still ran great.

Rolling my own X installation into Debian's "standard" install was an excellent exercise, but I just didn't have the expertise to really build it out. The Debian Xfce install was nice, but somewhat curious; all of the Debian desktop installs, even KDE, feature OpenOffice. Surprisingly, OO ran fairly well in 64MB of RAM and 233MHz of CPU. Strange, however, was the lack of GUI package management in the Xfce install. It did get me using Aptitude, so there was nothing lost there, but I got the feeling that Debian's Xfce just didn't offer what I wanted.

However, with Aptitude, Abiword actually installs the dictionary that makes spell-check work. At last look, neither Puppy nor OpenBSD do that.

I continue to enjoy Damn Small Linux, but the most recent versions just don't run as well as they should on this laptop. And little things like having Firefox renamed Bon Echo (why??) made it difficult to use Google Docs with Gears, which is one of the things I want to be doing fairly intensively, made DSL fall behind Puppy in the running.

Puppy has a great selection of apps, is fairly easy to configure, extremely familiar to me and runs great on this hardware. I find myself using this live CD more and more of the time.

Much of my feeling for 2.13 over other versions of Puppy is nostalgic. I first encountered Puppy with this very release, and most likely a simple move of the cute 2.13 desktop wallpaper to a newer version of Puppy would make me extremely happy. The fact that everything in 2.13 continues to work flawlessly, however, is a strong testament to how very well Puppy is put together. I probably will test and subsequently adopt a much newer version of Puppy for use on this laptop, if for no other reason than to use the encrypted-pup_save feature that will greatly add to the security of my data, since laptops — even ones well past their prime — have a way of falling into the wrong hands.

OpenBSD doesn't install with as anywhere near as many GUI features as ... any Linux distribution. Not that any of the BSD projects can't be configured to be as full-featured as any equivalent Linux distribution. It just takes time and effort. With a faster processor and a bit more memory, I'd really consider running OpenBSD as the primary distro on this laptop. On the other hand, hardware detection in OpenBSD excellent. It remains the only operating system to correctly auto-configure sound on this Compaq.

OpenBSD has well over 4,000 precompiled binary packages for i386 and even more software available through ports. It offers fewer packages than Debian or Ubuntu but way more than Slackware. And with the quality of the packages being so high and the tools used to manage them equally high in quality, OpenBSD remains an attractive alternative.

But again, Linux is just that much easier to use on the desktop. OpenBSD is no speed demon in X, and speed is more important when you're running ancient hardware than it is when you have, say, a PC from the past five years at your disposal.

And with OpenBSD, things like Adobe Flash are hard to deal with. And I don't think Google Gears will ever run in OpenBSD. I could be wrong on both counts (since OpenBSD can run Linux apps), but I do know that both are easier to do in Linux.

A bigger drive that could multiboot Debian, Wolvix and OpenBSD, with Puppy running either in a frugal install or as a live CD, is one way to go.

But running only one or two of these systems at a time seems to be more realistic, manageable and ... sane. Using multiple hard drives, like I do with my test box, is another way to go. That way the pain of dual-booting is avoided, as is the tedium of continual reinstalls.

Since OpenBSD offers much of the software I want and is an intriguing diversion from Linux, I could 'll probably leave it on the drive for the near future. In my 500MB or so Linux partition, I will probably grow my pup_save file and update Puppy. Now that I have Firefox 2 running on one of my other Puppy installs, I'll probably begin doing the same with this laptop, and that way I'll be able to use Google Docs with Gears. I can probably even figure out how to make Gears work with Seamonkey, but it's not imperative.

Previously:
In search of the best OS for a 9-year-old laptop: Part I — Puppy or Damn Small Linux
In search of the best OS for a 9-year-old laptop: Part II — OpenBSD or Debian?
In search of the best OS for a 9-year-old laptop: Part III — Browsers and wireless
In search of the best OS for a 9-year-old laptop: Part IV — Wolvix Cub is surprisingly strong

Coming up:
In search of the best OS for a 9-year-old laptop: Part VI — Younger Puppies
In search of the best OS for a 9-year-old laptop: Part VII — Debian with Xfce and Fluxbox calls
In search of the best OS for a 9-year-old laptop: Part VIII — Final thoughts (aka "Why?")