Results tagged “Puppy Linux” from CLICK

I've been meaning to do this for ages, and I finally installed Puppy Linux on a bootable USB drive.

I went whole hog and used a 128 MB stick. Yep, that's it. I have a huge 20 MB left for storage. Now that I know this works (at least on my Dell, the only box to which I have access that also allows booting via USB) I'll get a bigger stick and actually have some room to, as they say, maneuver.

Doing the install was easy. I booted Puppy 4.1.2 from a CD I had previously burned (I know Puppy is up to 4.2 ... I'll have to try it). Then I used the menu to install to USB. The only thing I did that wasn't a default was selecting mbr.bin as the boot method. It works.

Things I was pleased about in Puppy 4.1.2, which blazes on a 3 GHz Pentium 4 with 512 MB of RAM, include Abiword with working spell-check (never did get that together in OpenBSD; they should package it to work right ... but I digress), and the inclusion of apps that make this a great working environment.

I already loaded a couple of IMAP accounts into Seamonkey's mail client, and if I did have the disk space, I could use gFTP to load all my stuff onto the USB stick.

Considering that these sticks are pretty much laying around and can be had for free, this is a great way to put together a cloud-computing environment if you have all of your mail and files in something like Google Docs and Gmail. Who needs to wait for Chrome OS?

It's been many months since I last used Puppy Linux. I bet more than a year has passed since I seriously ran Puppy, still one of the best Unix-like distributions/projects for older, underpowered computers.

I decided tonight to break out the 1999 Compaq Armada 7770dmt (233 MHz Pentium II MMX processor, 144 MB RAM), which has OpenBSD 4.2 on the 3 GB hard drive (yes, I know 4.5 is out, and yes I do have the CD set, and yes, I'll probably reinstall) and two pup_save files in its 0.5 GB Linux partition.

During my extensive tests of operating systems on this platform, I ended up running the aforementioned OpenBSD 4.2 and Puppy 2.13, the latter from live CD.

I'm in Puppy 2.13 right now. I know it's old. I know Puppy 4.something is out now and that the project is in some sort of turmoil.

I decided to get deeper into Puppy 4.1.2 on my Toshiba Satellite 1100-S101 laptop.

I'm always looking for platforms on which I can do all my Daily News-related work, which means I need the Java runtime and Flash video.

Well, there is a Java package for Puppy. I'm surprised Java isn't part of the base install, but it appears not. I installed the package, and I even brought in the Opera Web browser to augment Seamonkey.

Both browsers are performing well, but for some reason Flash doesn't work in either. I distinctly remember Flash working in all of the Puppy 2 and 3 releases I've used previously, and now I'm left wondering what happened.

Also, Java did NOT work in either browser, so easy use of the LogMeIn remote-desktop service is not something happening in Puppy. I'm getting to the point where I'll need to bit the proverbial bullet and install Java from source in OpenBSD on this laptop so I can get that functionality. I can live without Flash (and the Flash I do have in i386 OpenBSD via Opera is marginal at best; it works in YouTube but not in Brightcove). I can sort of live without Java.

But it's better for the work that I do to have both of these things working well.

Also, I was surprised to see not Pidgin or Gaim as the IM client in Puppy but something I'd never heard of. Pidgin is available as a package, so that's not such a problem.

The end result is that while Puppy 4.1.2. runs quite well at first blush, I need to look closer at why I was so unsuccessful at getting Flash and Java to work. It should be easier than this.

And while Flash remains somewhat of a problem in OpenBSD (I probably need to be running an up-to-date Linux such as Ubuntu, Debian, Fedora, Slackware, Zenwalk ... take your pick) I'll probably stick with it for the time being as my primary OS.

I have my Self-Reliant Thin Client running Debian Etch turned on all of the time. I haven't been able to find power-usage specs for the Maxspeed Maxterm (it could be a 5300, but there are no model numbers on the box), but with no moving parts, a Mini-ITX-size motherboard, Mini-ITX-type fanless power supply and fanless VIA C3 Samuel CPU, as well as non-working case fan (except when tilting said case at a 45-degree angle) and a Compact Flash chip instead of a spinning hard drive and no optical drive, the thing is totally silent and must be fairly sparing on electricity use.

I don't think I even moved the mouse yesterday, but today when I brought it out of screen-saver mode, there were three updates to Debian Etch:

dbus
dbus-1-utils
libdbus-1-3

Thus far, the 8 GB Transcend Ultra Speed 133x Compact Flash is performing quite well, meaning it hasn't died.

The last time I killed a CF chip, a 1 GB Transcend, I think the premature death occurred due to inserting or removing the module while it was mounted.

Since in this case I have the Self-Reliant Thin Client sealed, that CF chip is staying in there and won't be plugged and unplugged all that often.

That might stay true, but I want to get more CF chips and load different OSes on them. Then I could remove the cover to the CF-to-IDE board in the thin client and pop in and out different CF cards with totally different configurations.

Some of the CFs I'd want to do:

• Puppy Linux (could be a much smaller CF due to the nature of the Puppy distro and its "frugal" install)
• OpenBSD (I'm anxious to see how easy/difficult it would be to install to CF)
• Wolvix (which also offers a "frugal" install, though I'd chose a "traditional" hard drive install so I could use slapt-get/Gslapt to update the box)

Not having an optical drive hooked up makes the "preparation" of CF cards on the Self-Reliant Thin Client difficult. To install a new OS, I'd have to:

• Remove eight screws to open the case
• Remove the CF card cover
• Remove current CF card and plug in new one
• Unplug the CF board's IDE cable from both the CF board and the motherboard
• Plug in a standard IDE hard-drive cable into the CF board on one end, the motherboard on the other
• Plug CD-ROM drive into "middle" of IDE cable
• Plug hard-drive-style power cable (the thin client has one, even though it doesn't need it for its intended purpose)
• Install new distro (and probably do more than one so I don't have to repeat this procedure)
• Test new distro
• Remove IDE hard drive cable
• Plug CF board's IDE cable into CF board and motherboard
• Replace case cover

I could leave the CF board/adapter's cover off if I wanted to do a lot of swapping of CF cards. It would be a very easy plug-and-play way to swap distros, that's for sure.

And I could keep the current 1 GB USB flash drive plugged in for backups of the various systems. That would also facilitate file-sharing between the OSes on the multiple CF cards.

I'm running what I call The Self-Reliant Thin Client on Debian Etch, a GNU/Linux distribution I haven't run intensively in quite some time. I also recently installed the PowerPC build of Etch on my Power Macintosh G4/466, but I've been using the converted thin client almost exclusively since I built it last week using an 8 GB Compact Flash module as the system's sole hard drive.

First a bit of background: The Self-Reliant Thin Client began its life with me more than a year ago as my test box for the various Linux distributions I was trying to run. It's VIA C3 Samuel processor couldn't run everything (no Red Hat/CentOS after version 3, no Fedora at all, no Suse, no Slackware 12.1) but could run a lot (Debian, Puppy, DSL, OpenBSD, Ubuntu, PCLinuxOS, Slackware 11 and 12.0, Vector, Wolvix). I got the thin client — a Maxspeed Maxterm, model number uncertain (but it looks to be a 5300, or close to it) — I bought with no CF card in the slot (it was configured to do its thin-client duties with a 64 MB card in the slot) and no RAM. I soon added a 256 MB SIMM (the largest it will take) and an extra-long IDE cable and daisy-chain of three power cables to hang a CD-RW drive and full-sized hard drive outside the small case.

Back to this project: I only wanted to spend $20 on the CF module, not $170 on a true solid-state hard drive (that's the going rate for 64 GB models, and I think the price is finally at a place where you'll start seeing them in more and more PCs). Since the wear-leveling algorithms for the CF card are probably not as friendly to regular PC use as is a dedicated flash-based hard drive, I'm backing up the /home folder from the CF to a USB flash drive with a script that uses rsync.

In Etch, I had to add the rsync package (I generally use aptitude or Synaptic to add apps, depending on how I'm feeling at any given moment).

To make the use of rsync and other maintenance apps easier, I implemented sudo. In Ubuntu, by the way, rsync is included in the default install, and sudo is automatically implemented — in fact, in Ubuntu, you are strongly encouraged to use sudo and not su to root.

Since I like sudo and use it often, when I do an install, one of the first things I do is su to root, run visudo and add my user to the sudoers list. Then I do as much as I can with sudo and not su.

I don't mind having to install rsync and give my user sudo privileges in Debian because it takes maybe a minute from start to finish.

What's different about these last two boxes I've built and/or configured is that they both have backup drives (and scripts) in place. My Power Mac G4/466 running Etch has a second hard drive dedicated to backups (and running rsync in the same manner).

One of the reasons I chose Debian Etch for this project is that since Etch went stable in April 2007, about a year and a half ago, there aren't that many software updates, and I didn't want to eat up time on the box (and add wear to the CF chip) with constant updates. Debian Lenny has dozens of updates per week. I might do an update every two weeks, and I often have 150 packages that need updating.

But with Etch, there are often no updates in a given week. Today seems unusual because there are six updates, all related to the Common UNIX Printing System:

cupsys
cups-bsd
cupsys-client
cupsys-common
libcupsimage2
libcupsys2

Flash reliability in PCs and solutions for extending the media's life

Right now there are quite a few laptops being sold that use flash-based memory. On the low end, many of the ASUS Eee PC laptops use flash modules from 2 GB to 16 GB in size. And on the high end, we have the MacBooks that have a $600 option for a 128 GB solid-state hard drive.

I haven't yet investigated building a custom kernel in Debian to allow me to pass the boot parameter ide=nodma (or if, in fact, that is the right parameter at all). Here is a discussion of the problem at debianHelp.org, and here is the portion of the thread that discusses compiling a custom kernel:

I think I solved the ide=nodma not being recognized problem by compiling and installing a custom kernel. I turned off the option CONFIG_IDEDMA_PCI_AUTO in the .config file. This option is set to "Y" in the standard Debian 4.0 kernel.

...

Once I installed my custom kernel, the system booted quickly without IDE DMA timeouts. I don't even think I need to pass the ide=nodma option anymore.

By the way, I recommend installing 'kernel-package' which installs the make-kpg tool. It creates a proper custom .deb package file you can use to install the kernel painlessly on the target system.

I haven't tried this yet, and aside from speeding up the boot process, I don't know what it does in terms of speed and wear on the flash device.

Indeed, it's a very open and unanswered question whether or not it's a good idea to run a CF module as a hard drive in a system not specifically configured to minimize wear on the flash memory.

That's why this is an experiment with full data backup at all times.

About the only system I know of which claims to be sensitive to excessive flash writes is Puppy Linux, which besides being designed to limit disk writes also allows users to pass the ide=nodma parameter during boot time.

One of the great things about the Puppy installer is that you can install Puppy on the CF card while it's plugged into a USB card reader and then move the CF card to a CF-to-IDE adapter and then have the system boot from it.

When I installed Debian Etch on the CF, I had to plug an IDE cable into the thin client's built-in CF-to-IDE adapter, then plug the end of the cable into the motherboard and the other input into the CD drive. Then, after the install was done, I pulled the CD drive and the cable and used the thin client's own IDE cable to connect the CF-to-IDE adapter to the motherboard (the way the thin client is meant to be used). If this method works, Puppy theoretically makes this a lot easier — if you have a CD-ROM drive in the system, that is. I was able to do this because the thin client's CF-to-IDE adapter has a male plug, which works great with a standard IDE cable between the adapter and the male IDE port on the motherboard.

But my "stand-alone" CF-to-IDE adapter has a female plug, and this would pose problems in terms of having the adapter and a CD-ROM drive plugged in at the same time (unless there are two IDE ports on the motherboard, which would make using this CF-to-IDE adapter no big deal).

Anyhow, my point, in case I didn't make it, is that Puppy tries to write to the drive as little as possible, and that will extend the life of any flash memory you're using for either booting and running the system, or as storage.

So The Self-Reliant Thin Client has been running Etch continuously for about a week now with no problems. I plan to keep it running until something breaks down. This isn't like the Thin Puppy Torture Test, which used this same converted thin client but with no drives whatsoever after booting from CD and therefore couldn't be rebooted without plugging in the optical drive.

This time I'm OK rebooting

More on The Self-Reliant Thin Client:

• Photo gallery of the assembly of The Self-Reliant Thin Client
• Daily News story about solid-state drives and The Self Reliant Thin Client

I've been trying to mount a Linux filesystem in OpenBSD 4.2 for awhile, and finally I figured out how to do it (and do it automatically at boot) without screwing up either my OpenBSD or Linux partitions.

I have a tutorial on this about 1/2 of the way done, but this was another situation where the excellent OpenBSD FAQ and man pages, as well as a couple of good general Linux/Unix online tutorials gave me all the help I needed. (I can never remember quite how to make chmod do what I want without looking it up.)

Since I installed OpenBSD on the Compaq Armada 7770dmt's hard drive without fully setting up the Linux partitions (all I have is swap and an ext2 partition for my live CD files), OpenBSD didn't know how to properly mount the ext2 partition.

Briefly, I needed to run fdisk in OpenBSD, transfer the Linux information to the OpenBSD disklabel, create a directory in which to mount the Linux filesystem, give the wheel group write access to that directory, then edit /etc/fstab to properly mount the ext2 filesystem at boot.

Once I was sure the Linux filesystem was properly mounting and was writable from OpenBSD, I booted Puppy Linux without mounting the partition and then ran e2fsck to clean up any errors (there were some).

Since then, the filesystem has been error-free, and I can easily exchange files between my OpenBSD and Linux installs on this laptop.

It's nice to solve a problem for a change.

There was a time when I was fascinated with the idea of using thin clients as actual computers.

My "first" Linux box, which spawned dozens of distro reviews and many hundreds of blog posts was a Maxspeed Maxterm thn client that worked so well as a stand-alone PC because it was basically a mini-ITX motherboard and small power supply crammed into a thin box.

I daisy-chained a few IDE data and power cables through a hole in the back of the thin client so I could hook up a CD-ROM and hard drive outside the small box. Adding a keyboard, mouse, monitor and 256MB stick of PC-133 RAM, I was ready to go.

At that point, the Maxspeed functioned pretty much like any other computer. Anything that could run on a VIA C3 Samuel processor could run on the box. That wasn't everything, mind you, but it was enough to get by.

I'm thinking about buying a new test box -- something cheap (I never want to spend more than $50 on any computer), probably in the Pentium III range, maybe a Pentium 4 if I get a deal.

That and the fact that the Daily News is moving a few blocks down the road to a new office, which has me throwing away massive amounts of paper and inventorying all the tech garbage I've accumulated over the past couple of years.

In one of my file drawers, I found an HP/Compaq t5300 533MHz 32/64 thin client that I got for about $10 on eBay.

I wanted to see if I could run Damn Small Linux or Puppy Linux on it, but once I got the thin client in the mail (hey, for $10 I didn't do a whole lot of research on it), I pulled it open and saw that replacing the flash memory with something programmable would be difficult. It wasn't made of off-the-shelf-parts like the Maxspeed.

But it did work. The 32MB RAM, 64MB flash, 533MHz box, with keyboard, mouse and monitor connected, booted to what looks like a Windows CE desktop. Included is a CE version of Internet Explorer (something from the IE4 era, I think), and enough utilities to enable me to set a static IP and get networking into the box.

Not every Web site looks pretty in a cutdown IE4, but surprisingly the thing can (almost but not quite) post an entry to Movable Type 4.1 with relative ease, even if it crashed repeatedly crashing the browser when I saved the entry.

At least it saved. And since the browser starts in about 2 seconds on this little, fanless and completely silent HP box, there are worse things than crashing the browser. I eventually crashed the entire thin client, but it does recover remarkably quickly.

I'd still like to get a thin client working with Linux, not as a quasi-PC with full hard drives but with nothing but solid-state memory. Once I finally get a new text box (I'm thinking something generically Dell or HP), I'll use the Maxspeed in the way it was intended — almost. It's flash memory is a CF card (and no, it didn't come with the original), and I plan to install Puppy Linux on that CF card and run it as a silent workstation, perhaps saving my files on a USB flash drive (or on the CF itself).

Let me just say that in the days before I got my hands on two nearly free laptops, I had a lot of fun with thin clients.

The HP has built-in terminal software in addition to RDP and Citrix capability (I hardly know what either of those means), so I could use it as a non-X terminal (not terribly exciting) or try to sell it for what I can get on eBay (likely).

As for my new test box, I've seen quite a few promising candidates in the Pentium III and 4 range. I'd like something that can run 1 GB of RAM, but I will take 512 MB if necessary. I did see one with 1.5 GB capability. I have a pretty good feeling that a nearly 2 GHz CPU with 1 GB of RAM will run things very, very well when it comes to Linux and the BSDs.

I've seen some nice things for $60, but I'd rather part with $25, or get something for free. The latter has happened before, and it could happen again.

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.

I tested quite a few versions of Puppy Linux in recent days on my 1999-era Compaq Armada 7770dmt. The bad news is that version 3.01 wouldn't configure X properly. Any attempts to do so and then start X crashed the box.

The other bad news is that while Puppy 4.00 loads fine and runs fine, for some reason the load time for Abiword went from 8 to 10 seconds in previous Puppy builds to 30 seconds. That's quite a rollback. On a more positive note, start times for Seamonkey were about the same.

I don't really use Abiword all that much, but that kind of performance hit is disturbing. It could be due to the new way packages are being compiled for Puppy but is more likely something specific to Abiword, since Seamonkey appears to be unaffected.

I tried Puppy 2.17 just to see how encryption worked. It did fine. And I discovered that in the case of multiple pup_save files on a single system, the ones not in use during the current boot can easily be opened in Puppy.

One bone (pun there, intended or not) I have to pick with newer versions of Puppy Linux is the lack of the Dillo browser. I use it quite a bit. I could still add it from packages, I suppose (and I definitely will), and if the slowness of Abiword wasn't bothering me so much in Puppy 4.00, I'd be using it right now.

As it is, I will continue testing, but for now Puppy 2.13 (hopefully with Firefox added for Google Gears compatibility) remains the front-running distro for the Compaq, especially if I'm able to remove the hard drive and replace it with a Compact Flash module and CF-to-IDE adapter card.

The fact that I can move files from one pup_save to another, providing that the non-mounted one is unencrypted, gives me more flexibility as far as upgrading from one Puppy system to another and creating a new, encrypted pup_save instead of using an old, unencrypted one.

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

Coming up:
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?")

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?")

I've been using OpenBSD 4.2 for a few months now on the $15 Laptop (Compaq Armada 7770dmt), and I'm leaving it on the hard drive for now. It does run better with 144 MB of RAM. I may even upgrade the OS to the current version 4.3.

OpenBSD with X is nowhere near as fast as the fastest Linux systems, but the added security and overall quality keeps me using it.

However, I'm considering swapping out the hard drive (to retain my OpenBSD installation) and trying Debian again.

Back when I ran Etch on this laptop, I remember it being slower than Puppy and Damn Small Linux, especially when it came to refreshing the screen. That was with 64MB, and I think Debian deserves another try in 144MB.

I have to gauge how important it is to have a traditional, easily updatable hard-drive installation vs. the live CD environment of Puppy and DSL. In many ways, live CDs are ideal for older machines like this one. The way they mostly run in RAM speeds things up considerably, and "upgrading" is as easy as using a new CD.

I have upgraded OpenBSD from 4.2 to 4.3 on another one of my boxes. It wasn't impossibly hard. Still, it was nowhere near as easy as using apt to upgrade a Debian install, and when it comes to binary-package updates to OpenBSD's stable releases, there aren't any between releases.

My feeling after using OpenBSD for six months is that daily updates a la Debian aren't as necessary as any of us might think, and updating the box every six months is a reasonable solution.

And here I am using Puppy 2.13, which is well over a year old but has nice-looking desktop wallpaper and a bunch of apps that work very well.

Previously:

• In search of the best OS for a 9-year-old laptop: Part I — Puppy or Damn Small Linux
  

Coming up:

• 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
  
• In search of the best OS for a 9-year-old laptop: Part VIII — Final thoughts (aka "Why?")

In the battle for which operating system runs best on the $15 Laptop, Puppy Linux has pulled out front as the fastest system with the most features I need and best functionality on this 1999-era Compaq Armada 7770dmt.

In case you're wondering, here are the specs of the Compaq:

233 MHz Pentium II MMX processor
144 MB RAM
3 GB hard drive

I recently bumped the RAM from 64MB to the maximum of 144MB. Before this increase, running Linux or OpenBSD (which I have installed on the hard drive) with the X Window System was difficult at best.

Smaller applications like the Dillo Web browser, the Abiword and Ted word processors, the Geany and Beaver text editors ran pretty well in 64MB of RAM.

But the 500-pound gorilla of graphical applications is Firefox.

It would be nice to get by with Dillo, but many — if not most — of the things I need to do with a computer these days require a fairly modern browser.

Whether it's blogging, working on Dailynews.com, or on the Movable Type back end, it all happens in the browser.

And for that I need, at a minimum, Firefox 1.5.

Now that Damn Small Linux offers Firefox 2 (under the name Bon Echo, but for all intents and purposes an early release in the FF 2 series), that system is more than fair game for use on this laptop.

Unfortunately, while the browser runs great, other things in DSL have not been working so well.

For some reason, the desktop wallpaper doesn't work. Instead, I have a plain, gray X Window background. And while JWM (Joe's Window Manager) is the default in Damn Small Linux like in Puppy, switching over to Fluxbox in DSL has been problematic. Some builds have allowed me to use the Fluxbox menu, but others don't seem to work at all.

I could live without desktop wallpaper (or I could figure out a solution to the problem), but with Puppy Linux (I'm currently using version 2.13 but could easily upgrade to the newer 4.00 at any time) I get a nice-looking desktop, the Mozilla-based Seamonkey Web suite, Abiword (about as fast as DSL's Ted word processor but with the added ability to read and write .doc files), the Geany text editor, the ROX filer and quite a few other applications I've grown to like very much over the year and a half I've been using Linux.

And as far as speed goes, Puppy and DSL are quite equal on this hardware.

Coming up:

• 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
• In search of the best OS for a 9-year-old laptop: Part VIII — Final thoughts (aka "Why?")

Since I shocked it back to life, the $15 Laptop (1999 Compaq 7770dmt with 233 MHz Pentium II MMX CPU, 144 MB RAM and 3 GB hard drive) has relied on an Orinoco WaveLAN Silver 802.11b wireless PCMCIA card for networking.

The WaveLAN is truly a wonder, working in both my 1996 Apple Macintosh Powerbook 1400, plus just about every damn thing made thereafter, and it has served me quite well in the years since I fought and scratched for it on eBay.

But I don't really have a lot of wireless networking in my life. My Netgear router used to pump out 802.11b, but the radio died about a year ago, and the router is now wired-only, where it continues to work wonderfully.

And at the Daily News offices, no WiFi penetrates the hallowed halls of Editorial, where all I have at my disposal is wired Ethernet.

The wide-open WiFi signals I sometimes "borrow" from my neighbors are weak at best and usually don't work. The best WiFi I've tried is at the Los Angeles Public Library's many branches, but I don't have time to linger.

And the now-free WiFi for Starbucks cardholders works great with the Compaq in Linux but not at all on OpenBSD (I know this because OpenBSD wireless on this very laptop does work at the library).

So I've been contemplating purchase of a PCMCIA/Cardbus Ethernet card for some time. They're cheap. But do they work on my ancient hardware and many and varied operating systems?

I picked up a TRENDnet TE100-PCBUSR 10/100Mbps 32-Bit CardBus Fast Ethernet Card last week and finally got a chance to remove the Orinoco WaveLAN card, insert the TRENDNet and give it a try.

It works!

The TRENDnet uses a tried, true and otherwise compatible Realtek chipset with the 8139too Linux driver.

I had no trouble loading the driver and configuring the card in Puppy Linux 2.13 (where I had to select the driver on my own) and Puppy 4.00 (where the system detected the card and correctly chose the driver for me).

So for the first time in the year or so that I've had the Compaq Armada 7770dmt, I have reliable networking for the aging but still sturdy laptop at both home and work.

The next thing I'm going to try is seeing if the laptop can physically accommodate the TRENDnet wired and Orinoco wireless cards at the same time, and if I can in turn configure both to work without having to pull one and plug in the other.

$15 Laptop note: The eight-part series on finding the right OS for the $1Compaq Armada 7770dmt is ready to run. All I need to do is get the entries into Movable Type and queue them up to run. I hope to do that in the next few days.

As soon as I'm able to begin posting them, my eight-part series on finding the best operating system for my circa-1999 Compaq Armada 7770dmt will begin unfolding, one part a day, on Click.

I've been working on this series for about a month, working with everything from Damn Small Linux and Puppy Linux to OpenBSD and Wolvix Cub, with a lot of thoughts about past use of Slackware, Debian, Ubuntu and more.

So starting — again, as soon as I can get the entries lined up — look for a long meditation on the best way to make old hardware work in the 21st century.

I hooked up my Starbucks card with AT&T today to draw on the free Wi-Fi now available at the coffee giant, and was pleasantly surprised to have good broadband speed in Puppy Linux 2.13 on the $15 Laptop (Compaq Armada 7770dmt).

I was even able to sign on using the Dillo browser. I started Seamonkey after that, but just being able to log in with Dillo was a surprise.

Even more of a surprise, however, was that the AT&T Wi-Fi didn't work in OpenBSD 4.2, which I have installed as the primary OS on the laptop.

Now I know that wireless works fine in OpenBSD, because I use it at home and at the Los Angeles Public Library. When OpenBSD booted, I got an IP, and I could ping that IP. I should've written down the location's IP and tried to ping that. Otherwise, I couldn't ping anything, and as a result could not get any services to work. That means I couldn't get data into or out of the laptop.

Why does AT&T Wi-Fi work in Linux but not OpenBSD? That's a good question

What I'm saying, basically is that if you're running anywhere near 64MB of RAM and you, say, want to run Firefox, you need more memory.

The $15 Laptop -- a Compaq Armada 7770dmt with 233 MHz Pentium II MMX CPU -- ran a Linux console with no problem and even did an X session, provided no "heavy" apps like Firefox were used.

But how can you get along with just Dillo as a Web browser?

It's not easy if you want to do any kind of blogging, which a) uses the more-memory-intense Firefox and b) demands much more out of Firefox and the whole system as well.

Well, I can safely say that a 233 MHz CPU and 144MB of RAM are enough to run Puppy Linux (currently version 2.13, for which I continue to have a soft spot), Damn Small Linux 4.3 and even OpenBSD 4.2.

I'm going to reboot into OpenBSD right now to see just how well the Compaq is doing with it.

(I'm now back with OpenBSD 4.2)

Things appear to work pretty well with OpenBSD as well. Though certainly more secure than almost every other operating system out there (though I miss Debian and now also Ubuntu's ability to encrypt an entire drive with LVM) and as stable as anything out there, OpenBSD is in no way faster than the fastest Linux distributions.

And speed is a bit of a problem on hardware this old.

I'd have to try Debian again. Puppy and DSL are quite a bit quicker when it comes to screen refresh time in Firefox (and generally in X). I don't remember Debian Etch as being all that sprightly in comparison.

(Changing to DSL 4.3)

There's no doubt that DSL runs the graphics in X faster than OpenBSD. The screen does a much better job of keeping up with my keystrokes in Movable Type, and if the main purpose of this laptop is to crank out blog entries, that is an important consideration.

Of course, before I pull OpenBSD off of this drive, I'll have to make sure I have the xorg.conf saved, as well as a number of other configuration files as well as the output of pkg_info so I can remember all the software I have in this install.

I should probably just get a few swappable hard drives for the Compaq. Maybe even something bigger than 3GB. Just a thought.

Other problems with using DSL as the sole distro: no Flash (but OpenBSD doesn't have it either).

... (two weeks later)

I've been running the $15 Laptop a bit more. Having a good wireless connection helps immensely. I've been most happy with Puppy 2.13 thus far, since it has Seamonkey — a very acceptable Mozilla-based browser — and all the graphics work as they should.

I still have OpenBSD 4.2 on the hard drive, and as I say above, I'm reluctant to remove it, even though I can and will save the various configuration files in case I want to do a reinstall.

I'd like to try Wolvix again, just to see if the additional memory makes any difference in loading it. I could — and probably should — try Debian again. I don't know if it'll be as fast as Puppy or DSL, but it is worth trying.

What I'll probably end up with: I might leave OpenBSD on the laptop for awhile, but I can see myself ending up with a hard drive or Compact Flash chip with IDE converter completely devoted to storage and either running Puppy Linux off of the Live CD or as a frugal install on the hard drive or CF card.

File this under "why didn't I think of it before?"

I've been complaining for at least a month about how I can't install Google Gears to gain offline functionality for Google Docs because Gears only supported Firefox 1.5 to 2.x, and I was running Ubuntu with FF3 and Debian with Iceweasel.

Sure, there are ways to make Gears work with Mozilla browsers that don't go by the name "Firefox," but it seemed a bit above my capability.

And just today, on the first day of Firefox 3's official release, I finally installed Gears in Ubuntu 8.04 with FF3.

But I could've done this weeks ago, had I only come up with this solution:

I could (and now am) running Google Gears with Docs in Puppy Linux.

I occasionally run Puppy 3.00 on the $0 Laptop, but since the Mozilla-based Seamonkey browser/suite isn't Firefox, Gears refuses to install.

But ... there's a PET package for Firefox, and I figured that if I install it, I can add Google Gears and gain the offline functionality for Google Docs that I need.

Know what? It works. Sure, the version of Firefox (2.0.0.4) is a bit old, but I'm pretty much going to be using it for this one purpose.

And I'm just so damn stoked that I can run Google Gears with Docs in both Ubuntu 8.04 and Puppy 3.00.

Note: This should work for just about every version of Puppy out there from the 2's to the 4's. If you can run the Mozilla-Firefox PET package, you can run Gears.

Now maybe I'll try that trick on getting Gears working with non-Firefox browsers based on Mozilla.

I wasn't able to boot Damn Small Linux 4.4 RC1 on the machine I really need it to run on — the $15 Laptop (aka Compaq Armada 7770dmt) — so I booted it on my VIA C3 Samuel test box, the machine that ran my two Puppy Linux torture tests.

I've already written about how the inclusion of Firefox 2 (renamed Bon Echo) in DSL 4.3 has breathed new life into the live-CD distribution as far as I'm concerned.

Two things I like:

Unlike in 4.3, Fluxbox seems to work. I can easily get a menu in the Fluxbox window manager, something I couldn't do running DSL 4.3 on the Compaq.

The DFM file manager is less confusing. It doesn't come up with a right-click, as it did in previous versions, but it is there when you use the folders on the desktop. This way, it should be less confusing to new users. The EmelFm file manager is still there, and since I've gotten used to it, I'm glad it has stuck in DSL.

One thing that was a bit surprising was the length of time it took for Firefox/Bon Echo to start for the first time, even when all of DSL was loaded in RAM. I expected it to be a little quicker, although the speed is more than adequate when reloading it.

I love running low-spec live-CD distros like Puppy and DSL in what I call "torture test" mode -- booting it, running it without any hard drives and leaving to to run for days or weeks at a time. Since I already had DSL 4.4 RC1 loaded entirely into RAM (done by entering dsl toram as a boot code), I decided to disconnect the hard drive that was spinning when I first booted.

I pulled the drive's power plug, then the IDE cable. The drive went silent, and DSL 4.4 continued to run.

Now the box was super quiet.

I had already set a static IP, which was extremely easy to do with DSL's built-in utility.

X was configured perfectly at 1024 x 768 with no intervention on my part.

Nothing new on that count, thankfully. On this hardware at least, DSL really does "just work," as they (and I) say.

My VIA-based converted thin client has, shall we say, "problems" with audio. Many audio applications skip their way through an mp3. Luckily XMMS, the default audio player in DSL, works very well with the shoddy sound chip on this ECS motherboard. I downloaded a few mp3 files, and they played with no problem whatsoever.

I tried to add the Flash plugin by going to a page with Flash on it and clicking the "install Missing Plugins" button that usually comes up in Firefox. Everything seemed to go OK, but Flash didn't work.

While I don't consider a lack of ability to run Flash to be a deal-breaker in a distro, it can be ... inconvenient. I realize all the problems with Flash in the open-source community (principally that it's not open-source), and while I agree in principal, in actuality we all need Flash at various times, and I consider it a necessary evil. And I wish DSL would consider adding it, even as a MyDSL extension.

Speaking of MyDSL, I opened it up to confirm that the Flash plugin was unavailable, and while that turned out to be the case (as far as I can tell), I'm quite impressed with MyDSL itself.

In the process of playing around with MyDSL, I killed the box. Disconnecting the hard drive during the session was what (eventually) did it.

I'll just have to run DSLnthe "normal" way, with the hard drive running. I can seem to boot Puppy from CD without a hard drive connected, but not DSL. Once again, this has no bearing on the actual running of DSL. It's just a point of comparison with Puppy Linux that I always seem to make in the course of these reviews.

But where I really need DSL 4.4 to run is the $15 Laptop, the Compaq Armada 7770dmt. I'm just about to boost the memory from 64 MB to 144 MB, and while I'm not sure whether or not the change will make Debian, OpenBSD or Puppy usable with X (really with Firefox some small X apps work well in all of the distros above), DSL is already quite usable -- with Firefox -- in a measly 64 MB, and it'll only get better with 144 MB.

So even if I have to stick with DSL 4.2, one distro -- and one distro alone -- is at the top of the heap when it comes to running X in low specs. And that distro is, and remains, Damn Small Linux.

One of the best live CD projects out there, Puppy Linux, has kicked it up a definite notch with the announcement of Puppy 4.00.

I began using Puppy with 2.13, and it has always performed extremely well. Here is one of the changes in 4.00:

Puppy 3.01 was built from Slackware-12 binary packages, however to reduce the size 4.00 has been totally compiled from source, using the T2-project. Thus, less dependencies (smaller size) and later versions of packages than 3.01.

The main 4.00 release uses the 2.6.21.7 kernel -- same as 3.01 -- but there's also a version with 2.6.25. One note in the announcement says that some older PCs boot better with the newer kernel, so it might be a good idea to try both.

Another thing I read in the announcement is that there's a new Puppy 2.14R, which is an update to the original Puppy 2.14 with "the latest features of Puppy." That's also good. I remember 2.14 as being a very good release, even though I still boot 2.13 on occasion.

And the Puppy team is committed to keeping the Puppy 3 series going, with version 3.02 of the Slackware 12-compatible distro on the way.

Again, Puppy is a great project that's just getting better with each new release. Aside from my affinity for 2.13, I use 3.00 all the time on the $0 Laptop (Gateway Solo 1450). I would've upgraded to 3.01, but I never had a problem with 3.00, so I've stuck with it.

Robert Shingledecker told me at the SCALE 6X show earlier this year that he planned to add version 2 of Firefox to Damn Small Linux, and it's finally here in DSL 4.3.

Damn Small Linux hasn't yet moved to a 2.6 kernel -- Robert said he would maintain versions with 2.4 and 2.6 eventually -- but I can wait for that. Just having Firefox 2 is enough to let me use Movable Type, Google Docs and the rest of the Web-based applications that I've come to rely heavily upon.

I just downloaded the ISO, and once I burn it and give it a try -- probably on the $15 Laptop (Compaq Armada 7770dmt, circa 1999, 64 MB of RAM, 233 MHz Pentium II MMX) -- I will report back.

DSL, like Puppy Linux, is one of those systems that has benefited from continual improvement. Both projects set the bar very high for others that want to play in the small-sized live CD space.

And I do use both -- often.

Update: While DSL has always run great on my VIA C3 Samuel test box and the $15 Laptop, it has barely run on the $0 Laptop (Gateway Solo 1450). That hasn't changed. Luckily Puppy runs great on the Gateway, even though I'm mostly running Debian Lenny (and will soon be testing Ubuntu 8.04 on it).