Debian Etch on The Self-Reliant Thin Client

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