Recently in The Self-Reliant Thin Client Category

Since the CF card serving as the sole disk drive in the Self-Reliant Thin Client (Maxspeed Maxtor converted to use as a full desktop PC) checked out with fsck via a card reader on another PC, I decided to do a reinstall of Debian, this time Lenny instead of Etch.

I can't seem to use a Debian network mirror on this particular local network. Even though this particular LAN offers DHCP, it doesn't send DNS information, and my supplying the nameserver addresses doesn't jump-start the process. I used to install from this network with a static IP and have no trouble, and I'd like the choice between a dynamic and static IP in the Debian installer. I've been using my Debian Lenny DVD for installs recently, but I don't have a DVD drive pull to connect with the maze of IDE and power cables snaking out of the thin client's box. I did have a recent CD image of Lenny with Xfce and LXDE, so I burned that to a CD-R and used that to do the install on the thin client.

The Xfce desktop installation of Lenny, after the base install, is only 487 files (I believe the GNOME desktop version is some 700 files). So it shouldn't take as long as a network install. Having a CF card as the system's hard drive does lengthen the process. Commercial SSD's might be faster than traditional spinning magnetic hard drives, but garden-variety CF cards meant for digital cameras are definitely not as fast as regular disk drives.

Once the installation is done, I can pull those cables, remove the CD drive from the IDE cable Frankenstein "chain," reconnect the CF-to-IDE adapter that's built into the Maxspeed (using a VIA C3 Samuel CPU spec'd for 1 GHz but running at 500 MHz for some reason, with 256 MB RAM, the maximum for the ECS EVEm motherboard) and have a very portable PC with no spinning hard drives.

I generally install the standard Debian desktop with GNOME, but I have used the Xfce desktop installation, which unlike Ubuntu's Xfce variant Xubuntu doesn't include a whole lot of GNOME utilities.

That means no Synaptic, NetworkManager, Update Manager, etc. I might try managing the network interfaces with Wicd, which I don't think is even in Lenny but is probably available as a .deb package, or will certainly be available in Debian's Testing release, Squeeze.

Memory management: I have a limited number of PC133/PC100 memory sticks, and I had two 256 MB and one 128 MB stuffed into the Debian Mac (G4/466), which is running Debian Etch. (I have to update that box at some point; I hope I don't run into the same problems as I did with the thin client.) I had to pull one of the 256 MB modules to put into the thin client. What I really need to do is find a few cheap 512 MB PC133 memory sticks for the Mac. Not that Debian doesn't run great in 640 MB, but I'm always more comfortable with 1 GB, and the G4/466 maxes out at 1.5 GB. And I always recommend maxing out the RAM on any given computer (and usually do just that).

CF memory card as hard drive: I did most of my early experimenting with Linux and BSD on the Self-Reliant Thin Client using the aforementioned long IDE and hard-drive-power cables, into which I plugged any number of regular hard drives, switching them out at will. But I wanted to try running off the CF card (the thin client, back when it was an actual thin client, used just such a card for its own OS) and see just how long it will last in semi-regular use.

I could've used Puppy Linux as the OS, which is deliberately sparing of write cycles on the flash memory, and I still could. All I need is another CF card and I could easily swap them in and out of the thin client to run as many different OSes as I have cards. In fact, I just might leave the CD drive connected and the thin client case open, get a handful of CF cards and do those installations.

With a frugal install of Puppy Linux, I should be able to update the card without pulling the thin client apart and inserting a CD drive into the IDE chain (there's only one IDE header on the motherboard, otherwise this would be a lot easier).

Instead, I could pop the CF card out of the back of the thin client's CF-to-IDE adapter, replace the relevant files in the Puppy frugal install on another PC with a card reader, reinsert the CF card into the thin client and then have a fully updated Puppy box without needing to burn CDs and get the drive hooked up.

Later that day: I now am running Debian Lenny on the Self-Reliant Thin Client. Since I wasn't able to access a Debian mirror during the install, I used the Debian CD #1 image with Xfce and LXDE, choosing to install the Xfce desktop.

I've run the Xfce installation of Debian many times before, and while I at times appreciate all the GNOME tools in the standard Debian desktop (most of which are included in Ubuntu's Xubuntu variant, which is a lot more GNOMEish than not), I've been using Linux and BSD for about two years and have done my share of manual network configurations.

I'm also comfortable updating installations in the terminal and have gravitated toward Aptitude rather than apt because I tend to get more packages with Aptitude that make the given applications run better. Plus Aptitude keeps records of everything you've done with it — not that I know how to access said records, but I still use Aptitude because it works.

So I can get away without NetworkManager (although I've said I will try Wicd to manage the network interfaces in this installation) and Synaptic, and Xfce has plenty of GUI tools of its own to control the desktop.

Right now the first Aptitude upgrade is still running, and I'm enjoying 1280x1024 video (from an S3 Virage chip) on a LaCie 22-inch CRT monitor (the Daily News is swimming in these boat anchors). The graphics were never lightning-quick on this hardware, and no Linux kernel, Xorg implementation or other magic will change that. I've never been able to watch YouTube video on this box, even in Puppy Linux; and sound is similarly terrible. As a thin client with 2001-era hardware, the Maxspeed was never meant to be a fully functioning PC, even though I've been using it as such since 2007.

At first glance, I can tell you that Debian Lenny boots at least twice as quickly on the thin client with the CF flash card as hard drive than Etch did. That's a performance improvement I can live with.

I said before in this entry that I might keep the thin-client box torn apart in order to get another CF card, install Puppy Linux on it and be able to switch OSes by popping out one CF card and inserting another.

However, after a morning and afternoon screwing around with this in between doing my regular work, I'm ready to seal up the box and let Debian Lenny ride.

I just tried to update a Debian Etch box that hasn't seen any action in about a year, and I got this message when using the Update Manager:

W: GPG error: ... The following signatures couldn't be verified because the public key is not available: NO_PUBKEY xxxxxxxxxxxxxxxxxxxxxxxxxx
W: You may want to run apt-get update to correct these problems

(Note: I don't have the exact error message because I'm not using the box in question to write this post ... but it looks just like this, except with a bit more information and the full

I do have a few Debian Etch boxes hanging around, and today I wanted to update one — the Self-Reliant Thin Client (Maxspeed Maxterm thin client with 8 GB CF card as the hard drive) — and I ran into some PGP key issues.

I already dealt with how to fix the Opera key (if you're using the Opera repository for the free but not-open source browser, and I am), but I'll repeat what you should run, in this case specifically for Debian and using a root terminal (instead of sudo).

Open a root terminal (or su to root) and do the following:

# gpg --keyserver subkeys.pgp.net --recv-key F9A2F76A9D1A0061
# gpg --fingerprint F9A2F76A9D1A0061
# gpg --armor --export F9A2F76A9D1A0061 | apt-key add -

That takes care of the Opera key.

On this Etch box, my Debian key was bad as well. I can see that happening. I probably haven't booted this box in over a year, and since then the whole SSL problem with Debian happened, caused hair-rending, and then was resolved, so that might have caused the problem ... or maybe not.

At any rate, I did get errors when trying to update the box with Synaptic (I eventually used Aptitude in the console, my preferred method at least some of the time), so I needed to get a new Debian key. Here's how I did that one (thanks to Stackoverflow.com for the recipe):

# apt-get install debian-keyring
# gpg --keyserver pgp.mit.edu --recv-keys 1F41B907
# gpg --armor --export 1F41B907 | apt-key add -

Then I still had a problem with libc6. when trying to upgrade/update with:

# aptitude update
# aptitude upgrade

... I kept getting a message about libc6 being a corrupted package.

I got around this problem by first clearing the cache and then installing libc6 (and its dependency, libc6-i686) individually:

# aptitude clean
# aptitude install libc6

That worked. My "corrupted" package was gone, replaced by the presumably uncorrupted libc6, and I was able to then proceed with the update/upgrade:

# aptitude update
# aptitude upgrade

Update: I'm getting checksum errors in the downloaded packages. Could this be the CF card going bad? I cleaned out the packages and am trying another upgrade.

Further update: The box is dead. That half-upgrade made it so I can't even log in ... Guess I'll have to do a reinstall after all.

Even further update: I pulled the CF card and ran fsck on it from another box. It checks out. Why did I keep getting packages with bad checksums?

I'll have to hook up the CD drive and do a reinstall. I can't remember whether or not this particular box will boot Lenny. I could always reinstall Etch and upgrade from there. Since the CF card checks out with fsck, I can hopefully keep the same partitions when doing the reinstall.

Final word on 2.16.18 nostalgia: Before I close this out, the 2.6.18 kernel used in Etch and Red Hat Enterprise Linux (and CentOS) 5, PCLinuxOS 2007 and probably a few other distros I've forgotten, has been a very good kernel to me, for my hardware (especially the $0 Laptop, a Gateway Solo 1450). I'll miss it. I welcome all the new hardware drivers, especially wireless networking drivers, in the newer kernels. I don't welcome the regressions in Xorg, but since the Self-Reliant Thin Client uses an S3 video chip rather than Intel, maybe I can blissfully move to Lenny without trouble ...

Distrowatch guru Ladislav Bodner has been rolling more than a few operating systems onto his ASUS Eee PC 900 netbook — probably the most popular netbook out there at this point (they even sell them at Target now).

In this week's Distrowatch (which I recommend as a must-read for anybody who wants to follow what's happening in Linux and the BSDs), Ladislav writes about how a mouse-over problem that tends to freeze the screen in Ubuntu Netbook Remix on the ASUS Eee was solved in the Linux kernel but almost immediately returned due to the relevant patch being pulled from the kernel because it began causing other problems.

Ladislav goes over how you can go backward from Linux kernel 2.6.28-11.41 to 2.6.28-11.40 and get your ASUS working again under Ubuntu Netbook Remix.

He also provides a tip for those using SSD (solid-state drive) disks on how not to wear them out:

Finally, a quick reminder for those who are about to install Ubuntu Netbook Remix (or any other Linux distribution) on a netbook with solid state drives. Since these drives have a limited life span that depends on the frequency of write access to the drives, you can greatly prolong their life span if you follow these two rules while installing your preferred distribution (here is the source of this information, although there are those who dispute this):

* choose a non-journalling file system (e.g. ext2)

* don't create a swap partition

As Ladislav says, there is some dispute about the life of flash media in everything from those mini USB drives and SD camera memory cards to devices designed to replace traditional IDE and (mostly these days) SATA .

Some people have said that the MTBF (mean time between failures) for SSDs is so low when compared to spinning hard drives that the devices will last much longer than traditional spinning hard drives due to the lack of moving parts in an SSD. They say that worry about killing the flash memory with repeated write cycles is overblown.

But others are worried about killing their flash memory too quickly and take precautions such as the recommendation above not to have swap space on the drive.

For those who might not know, most operating systems do use swap space on the hard drive in the event that your computer's RAM (memory) fills up. I won't go into just how much space you need for swap because that's a whole new topic that's been discussed countless times in countless places. (I generally set aside 300 MB for swap on my systems).

Even Windows uses swap (that's one of the reasons your box tends to slow down after it's been running all day [or week/month/year]) — you've got a lot of critical stuff that the OS has written to the swap area of the drive.

Back to flash/SSD memory: As I say, some people think that worrying about excessive writes to flash is unwarranted. While I'm tempted to say that you shouldn't use an SSD on a server, Sun Microsystems (yep, the company bought recently by Oracle) is offering SSD-equipped servers and storage arrays. Sun thinks SSDs are the (near) future in servers since performance gains are too large to be ignored.

Sun is using single-level cell (SLC) flash memory, which has a much longer life than the cheaper multilevel cell (MLC) devices that pack more memory into the same space but have shorter write/erase lives.

We're a bit far away from the ASUS Eee PC and Ubuntu at this point in the post, aren't we?

Maybe. But here's what I want to say about flash-based storage: I'm all for it. I'd like to start moving everything I have to SSDs as soon as fiscally possible.

One thing I really like is a silent PC: no fans, and no spinning hard drives. If you've ever worked on a system with drives snaking out of the back of the case and sitting on a table (I did it for years), you know how much noise traditional hard drives make and how much heat they throw off.

For the energy and noise considerations alone, I'd like to dump spinning hard drives.

To that end, I'm doing one test and hope to do another soon. I've been running my Self-Reliant Thin Client (converted Maxspeed Maxterm) with an 8 GB CF card in the box's built-in CF-to-IDE adapter as the unit's main drive. I am still running Debian Etch on it (and will continue with it until I manage to get networking into the room). The box isn't in heavy use at present, but it is running (and has been this time for more than a week). I do have swap set up on the flash, and with only 256 MB of RAM, it'll probably get used a bit.

I'm running regular backups of the /home files to a 1 GB USB flash drive with rsync, so I have an all-flash system.

It's not fast. A low-end CF card (mine is a Transcend) doesn't have the performance of a top-of-the-line SSD. For one thing, the Transcend uses MLC instead of SLC and for that reason alone should have a shorter life.

I'll keep the box running for quite some time to monitor its progress with the flash memory and see if it can withstand repeated use. An upgrade from Etch to Lenny would definitely tax the CF card.

Another thing I'd like to try is an SSD in one of my laptops — maybe the $15 Laptop (Compaq Armada 7770dmt), which I've recently put back into service. At least the drive is easy to get to.

I've been writing updates in my print column of the things I've bought/used/discarded/loved/hated over the past year, and that got me thinking: I got started with Linux in early 2007 and used many a distro on the machines available to me.

But for the last six months, I've pretty much stuck with the same OSes on the same machines. There are two reasons for this:

1) I've found stuff that works

2) see 1)

OK, that's one reason, but it sure feels better as two.

Anyhow, the other reason I've kept the same operating systems on my half-dozen or so active computers is that I need them to run — and run well. And they do.

Here's the rundown:

On my main laptop, the Toshiba Satellite 1100-S101, I've been running OpenBSD 4.4 for nearly six months. The only "sticking" point is not having Flash 9 or 10. Flash 7 works for YouTube but not much else. I have a few things that I do that need more up-to-date Flash, but otherwise the OS and applications in packages and ports have been extremely stable. I just upgraded it from Firefox 2 to 3, and tonight I added Mplayer and successfully played a Quicktime video. (Too bad the sound chip on the Toshiba is broken; the video itself looked great.)

If OpenBSD weren't so good, I'd use the Flash situation as a excuse to run back to Linux. But I've enjoyed using OpenBSD and learned so much over these months that for now I'm going to stick with it.

I have an identical Toshiba Satellite laptop running Ubuntu 8.04 LTS. It, too, is performing very well, although I seldom use it since I have all of my data on the OpenBSD laptop. I have few complaints about Ubuntu 8.04, and before it came out I vowed to stick with the LTS for at least a year, maybe longer. I could be persuaded to upgrade if I needed to get a newer wireless adapter to work, but so far I haven't needed to do that. Ubuntu remains very solid, and with better Flash support than OpenBSD it's nice to have it as a backup.

Our daughter has what used to be known as the $0 Laptop, a Gateway Solo 1450. The Gateway could never comfortably run OpenBSD because of its noisy CPU fan, which Linux can manage most of the time (with a simple shell script). FreeBSD managed the fan even better, but only during the first boot after the install. After that, it all went to hell.

Our girl has all her educational games on the Gateway, which is also running Ubuntu 8.04. I still think that the Debian Project packages Gcompris, Childsplay and TuxPaint just that much better than Ubuntu, but all the problems I had with Debian Lenny and X on both the Gateway and later the Toshiba had me running back to Ubuntu and OpenBSD — both of which run X perfectly on both laptops with no xorg.conf file needed.

I'll concede that installing, customizing and maintaining just about any Linux distro is easier than doing the same in OpenBSD, but as I say above, I'm grateful for the learning experience and most of the time can figure out how to do what needs to be done in OpenBSD.

My Self-Reliant Thin Client, the first test machine that I began running Ubuntu, Slackware, Debian, ZenWalk, Puppy, DSL and other distros on in 2007 has been running Debian Etch on a bootable 8 GB CF card for quite a few months now. I don't have it networked at the moment, so I can't upgrade to Lenny. I'm keeping the converted thin client powered on these days in another informal long-term test, and I hope to have networking hooked up to it soon. With 128 MB of RAM and less-than-great video and sound hardware, it's not the greatest machine, but I love having something with no moving parts and minimal power consumption.

I have the Mac G4/466, aka the Debian Mac, running Debian Etch, which I continue to think is the best non-OS X operating system for this particular hunk of hardware. I managed to get 640 MB of RAM into it, and it's a great machine. Since it's a PowerPC box, there's no Flash Player in any OS that isn't OS X. I'm considering an OS X 10.4 install to see how that runs. We have dual-500 MHz G4s in the office that run OS X really, really well. I wonder how this single-CPU 466 MHz box will measure up. We could use a Mac OS backup machine in the house.

Earlier this week, I pulled out the $15 Laptop, a 1999-era Compaq Armada 7770dmt with 233 MHz CPU and 144 MB RAM and fixed what was ailing it: It wouldn't run X in OpenBSD 4.2 in my user account, but would in root. That's because when it comes to screwing around with X, I don't know what I'm doing some of the time. I had created an .xinitrc file with a single line reading "xset b off" to silence the system bell in X, and that was enough to keep the Fvwm window manager from loading. I killed .xinitrc and all was well with the Compaq. I'll probably do a reinstall of OpenBSD, since upgrading from 4.2 to 4.3 to 4.4 to ... is just too much work. Yep, after a long search for the right OS, the Compaq has run OpenBSD for a long, long time.

The real workhorse of our stable is the iBook G4 1 GHz laptop. In the past year I've replaced the hard drive, pumped 1 GB of memory into it and upgraded from OS X 10.3 to 10.4. We needed 10.4 in order to run Firefox 3 and Flash 10. Yep, that's when I upgrade — only when absolutely necessary.

To make a long story short, until I have a burning desire to watch Web video all the time, or until I need to edit and process video into Flash, I just might stick with OpenBSD on my i386 hardware. Otherwise I'll probably move back to Ubuntu or Debian, the latter only if those nagging video problems somehow go away. (I've had similar issues with Slackware ...).

My next "challenge" will be to run OpenBSD -current instead of -release. Since I already hate waiting for things to compile, I don't know how I'll react to keeping a -current installation up to date. There's only one way to find out.

(Here is a screenshot of my Windows XP desktop using PuTTY and Xming to tunnel X over SSH from The Self-Reliant Thin Client running Debian Etch. Click the picture above for a full 1280x1024 image. Clockwise from left, I'm running GNOME's Update Manager, a console with PuTTY and the Rox-filer file manager).

I hadn't used my go-to SSH and X apps in Windows XP to access a Unix-like box in a long while. I actually had to find PuTTY before I could create a shortcut and run it. I already had an Xming shortcut, so I started that and left it in the background until I was ready to begin my X session.

If you use both Windows and Linux/Unix boxes and are not familiar with PuTTY and Xming, you're really missing out. In case it's not totally clear above, PuTTY enables you to run an SSH console session from your networked Unix-like box, and Xming allows you to run X apps over that same connection.

It's all good, clean geeky fun, especially over a local network. One of these days I'm going to experiment with dynamic DNS and figure out how to SSH from a box that isn't in the same building. The stakes there are a bit higher, as the box is out there on the Internet for all to see. But with the proper tools and procedures in place, everything should be secure.

Still, running Linux apps both in the console and in X on a Windows box really never does get old (to me at least).

Related:

As I write in this week's print column, I'm getting ready to give the Ubuntu- and CentOS-powered $0 Laptop to our 5-year-old daughter.

I mentioned that I do have a replacement that was working out pretty well. Of course that wellness went considerably south in the past few days (as chronicled in Dark Side of the Laptop), but I remained determined to prep the laptop, which is currently running Ubuntu/Xubuntu 8.04 LTS as its No. 1 distro, for our daughter, who used it tonight to run TuxPaint.

Whether or not my new/old Toshiba (or newer/just-as-old/identical Toshiba) works out, I'm ready to move on. I've got boxes I've set up in the past couple of months (The Self-Reliant Thin Client, The Debian Mac, which I bet I could finally set up with OpenBSD and actually get it to boot) that could be used more, and boxes I haven't yet had time to work on (an old Dell with something in the 1 GHz-ish range and for some reason stuffed with 256 MB of ECC server memory).

I'm also thisclose to getting my hands on a Sun Sparcstation 20, a box that was the envy of every self-respecting geek ... in 1995. That could be a fun project, don't you think?

The Self-Reliant Thin Client — my converted Maxspeed Maxterm thin client — which has been running Debian Etch now for:

steven@maxterm:~$ uptime
11:47:52 up 35 days, 19:55, 2 users, load average: 2.79, 1.74, 0.79

with the OS and all files stored on an 8 GB Compact Flash module, and backing up the /home files via rsync to a 1 GB USB Flash drive just received two Iceweasel (aka unbranded Firefox) updates:

iceweasel
Iceweasel-gnome-support

That brings the system's version of the Mozilla-powered browser to 2.0.0.18.

Unless I've failed to hear about it, Debian Lenny hasn't yet been declared Stable, so Etch — first made Stable in April 2007 — remains the Debian distro of record for those who like things to stay predictable (and not break).

And now for an editorial: I know that the Debian Project does things the way it wants, but I'd sure like to see them decide to give each Stable distribution a defined life span of, say, three years. Yep, just like Ubuntu does with its LTS.

At the current pace, I imagine that Etch will get three years of security patches anyway. That's because once Lenny is declared Stable, Etch becomes Old Stable and at that point gets an additional year of bug fixes and security patches from the Debian Project.

The ability for sysadmins to plan and know how long they can ride a given release is something I find very valuable. Red Hat wouldn't do it if customers didn't want it. And while I think the 7-year-life of a Red Hat Enterprise Linux release is probably more than a little too long for most uses (not that a print server or internal file server needs to be all that cutting-edge). But three years for Debian (I think at this point that two years of support is pretty much a given) is something that its users — including me — could really get behind.

Note: Ever notice how these entries start off so innocuous and then somehow morph into a diatribe? Yep, me too.

Maybe you're curious about how The Self-Reliant Thin Client is doing.

Here's the uptime output:

steven@maxterm:~$ uptime
13:08:07 up 24 days, 21:15, 2 users, load average: 1.70, 1.32, 1.31

Yep, the VIA C3 Samuel (rated at 1 GHz but running in Linux at 500 MHz for some reason) based converted thin client, running Debian Etch from an 8 GB Compact Flash card, has been working continuously for about a month now (I did reboot a few times during this test for kernel updates).

It's still no speed demon but handles the GNOME desktop fairly well. I did add Fluxbox for testing purposes, and I also installed the lightweight Dillo Web browser, but I'm still relying on the Iceweasel (unbranded Firefox) and Epiphany (GNOME's Gecko build) browsers, plus OpenOffice 2.0 Writer (works surprisingly well, even with 256 MB of RAM and 500 MHz of CPU) and GNOME's GEdit text editor.

I even used CUPS (The Common Unix Printing System) to set up a printer the other day. Even though most systems include native printer-setup utilities (GNOME's is extremely primitive), I find it's both easier and more instructive to use CUPS directly via a Web browser. For those who have never done it, open a browser and go to the following URL to access the CUPS interface:

http://localhost:631

I usually click on Administration and go from there. If you're asked for a login, that login is generally root, with the password being root's password. I can't remember how this goes in Ubuntu, which doesn't let the users (even the main user) at the root password (if there even is such a password).

Ubuntu's root/sudo situation is another kettle of fish for another post, but for most of us, the key to CUPS is using the root login and password to add or modify printers.

I will close out this entry by praising Debian Etch for being so solid on this (and just about every other) platform.

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.

I've already repeated myself enough about the Flashplugin-nonfree being taken out of Debian Etch and relegated to Debian Backports. and I've decided NOT to install it for the time being mostly because a) I don't really need it and b) Flash runs like crap on this rig (blame the ECS EVEm motherboard).

But I do need Java. Since Java is not a totally free program, you must agree to the licensing terms before the plugin for Iceweasel/Firefox will install. And with that in mind, it's not in Debian's default "free" repositories.

To get Java, first edit /etc/apt/sources.list. Use su to root or sudo (and if you don't have sudo set up, now is a good time to do it).

Here's how to do it using sudo with the Gedit text editor (substitute your favorite editor for Gedit, and ignore the word sudo if you used su to root):

$ sudo gedit /etc/apt/sources.list &

Once you're in /etc/apt/sources.list, change these lines to include the contrib and non-free repositories:

deb http://ftp.us.debian.org/debian/ etch main contrib non-free
deb-src http://ftp.us.debian.org/debian/ etch main contrib non-free
deb http://security.debian.org/ etch/updates main contrib non-free
deb-src http://security.debian.org/ etch/updates main contrib non-free

Then save and close /etc/apt/sources.list.

While you still have the terminal window open, update your package lists:

$ sudo aptitude update

If you want to stay in the terminal, do this to add Java:

$ sudo aptitude install sun-java5-plugin

Or use the Synaptic Package Manager. Instead of using aptitude to update your package lists, after making your changes in /etc/apt/sources.list, start with Synaptic and click Reload. Then search for the Sun-java5-plugin package and add it that way. Even though I'm a big fan of using aptitude instead of apt at the command line, if I'm in a graphical environment I use Synaptic more often than not.

Then close and restart the Iceweasel browser. You should have Java. To check it, I learned from TomCort.com that you can try to play the Java game Jpong. If it works, you have Java.

I needed Java for a variety of things, but the one that prompted me to actually get it was LogMeIn. Without ActiveX (in IE) or Java (in everything not IE), you can control a Windows or Mac OS X computer remotely via "any" Web browser (and do it free with LogMeIn Free), but you can't actually type directly in an application window without ActiveX or Java installed. And instead of LogMeIn actually prompting me about this omission, I was reduced to typing into a little "Send Keys" window to get actual screen input.

I can't imagine that LogMeIn cares at all about the non-Windows and -Mac market. I get that, since a product to remotely control a Unix-like desktop would be a bit redundant with X over SSH and other technologies that are easy to use in a GNU/Linux or BSD environment.

But in my case, in which I'm using the browsers in Linux and OpenBSD to control a remote Windows XP desktop, they need to make it clear to users that unless you have a Java-equipped browser, your experience is going to be very frustrating until you add the required software.

Later: After adding the contrib and non-free repositories, installing the sun-java5-plugin, restarting Iceweasel and navigating to http://logmein.com, I signed in to my account.

After the wait for Java to get going, I indeed was able to start a remote session from my Debian Etch box to my Windows XP box and actually use my keyboard to type into application windows on the remote host (is that what you call it?).

Now I have to add Java to the rest of my GNU/Linux installations.

Java is even available for OpenBSD, at least for i386 and AMD64. I believe you have to add the entire developers kit to get the runtime. I've seen more than a few messages on the OpenBSD mailing lists from Java developers, so it's not an unknown platform for that sort of programming.

There used to be a huge rant here about how Flash only runs on PowerPC chips if you are using Mac's OS 9 or OS X and not in any Linux or BSD. I'm not quite sure what the status is regarding Java on Linux/PowerPC. It seems a bit murky, and I'm looking into it. A cursory Google search indicates that it is available, although not as an actively developed technology.

Since I'm keeping my Self-Reliant Thin Client running all the time, every morning that there are new updates to Debian Etch, I seem them right away. We had three yesterday and three more today:

• libmyspell3c2
  
• linux-image-2.6.18-6-486
  
• tzdata

When I was in the Update Manager, I learned that clicking the "Show Details" link allows you to see the description of all the packages in the update as well as the changes made.

For the new kernel image, here's what it says:

Version 2.6.18.dfsg.1-23:

[ Ian Campbell ]
* Fix DMA crash under Xen when no IOMMU is present (closes: #445987)

[ dann frazier ]
* [xfs] Fix attr2 corruption with btree data extents (closes: #498309)

It's a very valuable thing to know why a package has been upgraded. Maybe now in Lenny, when I get new Xorg packages and drives, I'll be able to figure out in advance whether anything is being done to help me with my Gateway video-refresh problems.

I decided to start adding apps to the Self-Reliant Thin Client, which is running Debian Etch from an 8GB CF card as the boot drive with a 1 GHz VIA CPU that insists at running at 500 MHz, plus 256 MB of RAM.

I used aptitude to add the Geany text editor and the Fluxbox window manager.

Fluxbox runs great, as usual, but I really don't see any app-speed improvement with Iceweasel, OpenOffice, Geany or Gedit.

In previous tests, I saw a real advantage to using Fluxbox or Xfce over GNOME, but here in Debian, GNOME is running well enough that I'll probably use it quite a bit. I'll continue testing Fluxbox, but I imagine that GNOME will continue to be my main window manager on this box (as it has been when running off of a traditional hard drive).

It definitely depends on the specific box, and especially on the available RAM. I guess that 256 MB of RAM is enough for good GNOME performance. With 128 MB of RAM, Xfce, Fluxbox, Fvwm or other lightweight window managers might dramatically improve performance vs. GNOME.

One thing I have to do is run top when running the same apps in both GNOME and Fluxbox. If the same amount of swap, relatively speaking, is being used in both window managers, that tells me why my GNOME performance is so relatively good. But if there was a lot more swap used in GNOME vs. Fluxbox, then I'd know that the lighter-weight window managers are really making a difference.

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

This week's Tech Talk column covers the creation of what I call The Self-Reliant Thin Client, which is basically a very-bare-bones PC that is booting and running off of a Compact Flash module instead of a traditional spinning hard drive.

Here is the photo gallery, which will get full captions when I get the time to write them.

I have been wanting to test solid-state storage technology for some time now, and with the solid-state drive option for Mac laptops costing $600 (over and above the MacBook's $1,600 price), the drives themselves as laptop replacements in 64 GB sizes going for $170, I decided to use the slower but way cheaper Compact Flash technology, which is very common in high-end digital cameras.

I finally got an 8 GB Compact Flash chip from newegg.com for about $20, and I'm backing up my user files on a USB flash drive plugged into the back of the box.

The box — which started out as a Maxspeed Maxterm thin client — is running Debian Etch.