Recently in Thin clients Category

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.

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.

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.

It's nice — really nice — to see via Distrowatch that development is continuing on low-spec favorite DeLi Linux. Here's the release announcement.

I've been able to install DeLi on my VIA C3 Samuel converted thin client, but not without a few tricks that I picked up from the forums (here and here). And I also recently did an entry on some good DeLi-related blog entries from others.

I never was able to get my static IP configured in DeLi, but I think I could do it now.

According to the DeLi site, you need 32 MB of RAM to run the GUI version. The Web browser is Dillo, I believe, and that runs great in 64 MB and looks like it can run about as well in 32 MB.

Probably the biggest change is a shift from GTK+1 to GTK+2, which accounts for the memory requirements rising for this release of DeLi.

When you're trying to resurrect and make an old computer useful, DeLI is a great distro to have in your arsenal, along with Puppy, DSL and even Debian (the Standard install with X and a lightweight window manager and your favorite apps added manually).

I just upgraded the $15 Laptop from 64 MB to 144 MB of RAM, and before the upgrade, OpenBSD, Puppy and Debian ran well on it with X ... unless you try to run a "big" application like Firefox. That's where Damn Small Linux leaped ahead of the pack for that low amount of memory.

Now with 144 MB, I hope that I will have more choices as to what will run on that Compaq Armada 7770dmt, but if you do have a box stuck with 32 MB (I used to run Windows 98 in that amount of RAM, and let me tell you, it was pure hell), DeLi is a great distro to try out.

I decided to start from scratch with my Debian server project. Last time I was too hasty in adding the open-source version of Movable Type to my installation and intermingling files before I was ready.

This time I'm going to be a lot more methodical and make sure that Apache and MySQL are working properly -- meaning I can run CGI scripts and have a directory dedicated to same -- before I start with Movable Type.

I could've removed Apache, done some cleanup and gone from there, but since I didn't have much "invested" in the install, I wiped the drive and started over.

I did want to change a few things:

Last time I used encrypted LVM. Since I don't have any grasp about how to work with LVM partitions after the fact, and since I'm not confident enough to have an encrypted drive that I can't get to from a live CD rescue disc, I went with a standard partitioning scheme. I initially was going to roll out separate partitions for everything, but since I don't know how extensively I'm going to use /var -- and since the automatic partitioning in Debian tends to make the root partition too small for my taste (and with a 14.5 GB hard drive, I don't have a whole lot of space to waste), I went with a separate /home partition and one big partition for everything else. That way, even if I'm using /var for my Web files, I can always rsync them to the /home partition and then rebuild the whole damn thing if I need to, yet still have all the files right there.

Another thing I learned: When you check off "SQL server" during a Debian Etch install, you get PostgreSQL, not MySQL. I'll write more about this in an upcoming post, but I'm at such an early stage in my interaction with databases (i.e. smack dab at the very beginning) that I'm going to use MySQL just because of its sheer ubiquity (and because that's what Movable Type recommendseven though Movable Type supports PostgreSQL just fine -- and also allows use of SQLite).

I'm not ruling out using PostgreSQL in the future, but since this is my very first installation of a SQL database -- hell, it's the first time I've even used a SQL database and actually knew I was using it, so I'm going with the flow as much as possible.

In the last install, I also selected "file server," and ended up with a lot of stuff loading at boot that I don't need. What I really do need is an ftp server (and preferably a secure one) as well as the OpenSSH server, both of which are easy enough to install and configure (easy since I've successfully done it before).

And while I considered not installing the "Desktop environment," which brings GNOME and everything that goes with it, I didn't want to leave all that GUI goodness behind just yet; I'd rather have Synaptic, especially, at my disposal.

So right now I have the stock Debian Etch install with the desktop environment and Web server options.

And I need to add:

• Anything I'm missing to make Apache work with PHP and CGI/Perl scripts (that was my big stopper in last week's install)
• MySQL and the phpMyAdmin program to help me configure the database
• The ftp and OpenSSH server packages
• Movable Type

At this point, everything is on the local network, not right out there on the Internet, and I just want to see how hard it is to roll one's own blogging-equipped Web server. Would I rather use Drupal, WordPress ... or anything else? Sure, but since our shop makes extensive use of Movable Type, that's where I'm putting my energy.

I'm getting some help setting up Apache2 from this Debian Admin page. And Carla Schroder's "Linux Cookbook" has some good tips on rolling out Apache (look in Chapter 22 -- and if you don't have this book, you really do need it).

One thing that's screwing me up is the presence of multiple configuration files in Apache2 (apache2.conf and httpd.conf), the placement of those and other files in different directories on different systems, and general confusion of what the proper commands are between Apache 1.3, 2.0 and 2.2.

But since I'm being more deliberate this time, I won't move to the next step in the process until everything works with the previous step. That means I need to get CGI working in Apache, then add MySQL, create the database, and then add MovableType. ... and in between I'll get the FTP and SSH servers going.

Update: I installed a bunch of MySQL and PHP stuff that I saw in Synaptic. I also installed phpMyAdmin, which I already confirmed is working. I also added the proftpd ftp server, which has a MySQL-specific version (not sure what I'm getting myself into there). I also put openssh-server on the box, which worked perfectly in my last Debian Etch install.

A very good tip: This is true for most configuration files, as well as for those in Apache2, especially because there are a whole lot of them: SAVE copies of everything before you mess with it. Look at ALL of the configuration files and attempt to understand them before you mess with them.

By looking, I learned that the default Apache2 installation in Debian is already set up to use /usr/lib/cgi-bin as the CGI directory. This information wasn't in /etc/apache2.conf or /etc/httpd.conf (which is empty, with the implication -- for me at least -- being that this configuration file is no longer necessary in Apache 2.2 ... but don't quote me because I could be totally and completely wrong).

I found out about the CGI situation in /etc/apache2/sites-available/default and /etc/apache2/sites-enabled/000-default.

OK, I realize that Apache is a huge deal. It's production-ready, hugely scalable, time-tested, and all that other good stuff that makes for a bullet-hardened app. Did I throw in enough cliches?

But holy crap -- I've got FOUR configuration files in front of me.

I somehow in my previous installation was able to get the "home" of my Web server out of /apache2-default/, and now that I know where the cgi-bin area is (and presumably how to move it) ... I just might get this thing off the ground.

All I do know is that the online Apache docs led me astray (and were extremely vague about where exactly to put the various configuration lines I needed).

Here's what I'm going to do now: NOTHING. I'm going to sit on this for a day or so and think about how to proceed without screwing the whole thing up.

I'm writing this review on Google Docs in Firefox while running gOS 1.0.1, the Ubuntu-based distribution that steers users toward Web-based applications whenever possible -- mostly those under the auspices of Google -- and which powers the Everex Linux PC being sold for $199 by the truckful at Wal-Mart.

I'm getting more comfortable with Google Docs all the time, but there are times when you need a traditional text editor. Yet there is no GUI text editor to be found in the gOS distro. There is the entire OpenOffice suite and the GIMP image editor, a smattering of games, Rhythmbox for music and Xine for video, but no stand-alone mail client (you're encouraged by the iconography on the gOS desktop to use Gmail ...). Luckily there is a terminal program, which is named UXterm but looks suspiciously like plain ol' xterm, and with that you can bring up Vim or Nano, but that's pretty much it. Come to think of it, without a terminal in the GUI, and a console text editor, gOS would be in a heap of trouble, so it's good that they included one. But every gOS user's life would be a whole lot easier with a GUI text editor. Since you can add anything in the Ubuntu repositories, holes in gOS are easily filled.

But the more I used the new, green OS, the more I wondered whether the Everex (and everybody else) would be be better off with Ubuntu, Xubuntu, Debian ... or just about anything. While the Everex, with its 1.5 GHz VIA processor and 512 MB of RAM is underpowered when compared to most modern desktops, I regularly run Debian and Ubuntu -- both with GNOME -- and even Slackware with GNOME and Xfce on a machine with similar power but half the memory. And as I found out, the speed and lightness on resources that the Enlightenment window manager promises are just not there.

One thing I do like about gOS -- and this may be a feature of Ubuntu 7.10 for all I know -- is that when you're in a terminal and try to run an application you don't have installed, the terminal outputs what you do need to do to get it.

For instance, I tried to run the Joe editor:

$ joe

and I got the following:

The program 'Joe' is currently not installed. You can install it by typing:
sudo apt-get install joe
bash: joe: command not found

Whenever that message comes from, it's a very nice touch and is more than enough to get even a novice user going with apt.

But sheesh, at least give me Leafpad, Mousepad, Gedit ... whatever. Normally I would just add the editor I want, but for this evaluation of gOS, I pledged to stay with Google Docs; that's what they want you to use, so I'll use it. In the past, I've even gone as far as automatically posting a Google Docs item to one of my Blogger blogs, but that feature, in my opinion, is pretty much useless. Why not just write directly in Blogger? And since you can only auto-post from Google Docs to a single blog, the write-to-blog feature won't work for me. However, the post-to-blog feature does work with WordPress and LiveJournal blogs, plus a few others I've never heard of. That makes it more useful, but what I need is for Google Docs to act as more of a "dashboard" app for my various blogs -- I'd like to be able to publish from here to more than one blog (actually about six, and therein lies my sickness).

Update: I was all set to complain about Google Docs' browser-printing problem, but I just printed a document from Docs on my Windows PC, and what Docs did was turn my document into a great-looking PDF, which opened in Adobe Reader and was easily printed on paper. I'm not sure how seamless this integration is in Linux systems, but I plan to find out soon. Printing on actual paper seemed like the weak link in the whole Google Docs scheme, but it looks like they have that problem solved very well -- I may never use a traditional word processor again (especially if the promised offline extension of Docs is ever released).

Google Docs is a whole lot better than many people let on. I never need to insert tables or pictures into my documents. I write stuff. Stuff with words, and if I need to insert photos, I'm generally already in a blog post or on a printed page that I'm dealing with in a publishing program that is a whole lot bigger and more complicated than Google Docs. But Docs CAN insert images, tables, links and more. And it's not a bad HTML generator either. You can look at the HTML source at any time and copy/paste it into your Web content.

For the everyday writer of articles for publication, Google Docs is pretty kick-ass. When not connected to the Internet, or for those who don't want Google to see their documents, there's always the option of using OpenOffice, though I think AbiWord and Gnumeric are more in keeping with the lightness touted by gOS.

Getting back to gOS ... almost: Even though this is supposed to be about gOS, the bare-bones Linux distro relies heavily on the Firefox browser and links to various Web tools like GMail, Google Docs, Wikipedia (see, they're not all Google), Facebook, Blogger, YouTube, Google Maps and Picasa. So any review of gOS must take heavily into account the browser experience.

Since I work on four or five separate computers a day, working with docs online and using Web-based (or IMAP-delivered) e-mail is a must for me. I could add a standalone mail client to gOS as easily as I can with any Ubuntu or Debian system, but for now I won't. Even so, a user with gOS can pretty much make it do anything they could do on Ubuntu. Or they could wipe gOS from the drive and replace it ... or perhaps dual-boot.

One of the most attractive things about gOS and the Everex PC is that the combination promises full power management, making for a more green PC than most anything else out there on the desktop, so if you have the Everex PC, making gOS work the way you want it becomes a more attractive option. Hopefully Linux, as it matures even further, will include better power management for all motherboards.

More mail: I'm divided about the use of mail clients anyway. Most of the time, a Web portal is fine for me, especially if the entire session takes place in a secure connection (thanks, DSL Extreme). And I suspect that the vast majority of computer users have never heard of a mail client -- they barely know what Outlook is -- and have been accessing e-mail through the browser as long as they've had e-mail access, so gOS is going in the right direction there.

Gmail tip: To keep your Gmail session secure throughout, start out in your browser with the following:

https://mail.google.com

Note the "s" for a secure connection. You can also type https://gmail.com. Unsecure e-mail, particularly over unencrypted wireless connections, is a real problem, and it makes me reluctant to use Yahoo Mail because only the password is sent over a secure connection. The rest of your e-mail is right out there for others to intercept and use for ill.

Speaking about the greenish gOS desktop, the Enlightenment window manager isn't that bad. I think gOS could've been done just as well with Xfce -- maybe even better -- but I know that some Enlightenment developers are behind the project, and I'm always happy to see any desktop environment taken to the next level. At least it sets gOS apart from the dozen or so Xfce-based distros out there. But speedy, it's not.

One of the first things I did in gOS was add some virtual desktops; it's one of the best features that Windows doesn't offer, and I think the gOS people should ship the OS with more than a single desktop showing. I like the traditional four, so I left-clicked on the mouse and went to Desktop -- Virtual -- Configure Virtual Desktops. I could've added more than four, but I didn't. Switching between desktops is done with the usual ctrl-alt-arrow keys. You can't tell in gOS which desktop you're on, but at least they're there.

One feature I turned on in Enlightenment that I've never seen before in any other window manager (although I'm pretty sure it's there in most window managers) is the ability to switch or "flip" screens by moving the mouse pointer to the left or right edge of the screen, effectively scrolling to the next desktop. It's kind of neat. I don't know if I need it (I discovered it by accident after forgetting that I set it), but it may just be something that gOS users will grow to like. I had to turn the feature off because I kept triggering it by accident -- I like my Firefox windows to fill up the screen, and more than once I found myself on the next desktop when I didn't want to be there just yet. Ctrl-alt-arrow is good enough for me. But if you like the "flip screen" feature, you can make it look even more groovy with "animated flip."

One successful install, one less so: Both my regular test box (the VIA C3 Samuel-based Maxspeed Maxterm converted thin client) and the $0 Laptop (Gateway Solo 1450) are very Ubuntu friendly, meaning installs of Ubuntu-based distros generally go well on both. gOS installed like a champ on the thin client, but it won't install at all on the Gateway. On the latter, the live CD environment comes up fine (and the graphics are much snappier than on the Maxspeed), but when I do the install, I enter all the relevant information, and about six seconds into the actual install, the program crashes -- and that's it. Since I recently did an install of Ubuntu 7.10 on this very same laptop, it's curious, indeed, that gOS will not install. It's regretful, but at least I got gOS on one box. Hopefully the bug, whatever it is, will be squashed in future editions of gOS.

Potential problem: I'm running top in a terminal window on one of my four desktops, and it consistently shows Enlightenment using 9 percent to 12 percent of my CPU and 12 percent of my 256 MB of memory ... at idle. That's not exactly light. I'll have to go back to Ubuntu and Xubuntu and see how much CPU and memory GNOME and Xfce take up. I don't think it's this much. That said, gOS seems to be running as well as anything else, but not radically better. I'm able to switch windows in Firefox fairly quickly and do the same with my virtual desktops. Again, I'd have a better feel for how gOS compares if I could install it on my Gateway laptop.

So I decided to install the next distro I'm testing -- Wolvix Hunter 1.1.0. In case you haven't heard of Wolvix, it's a live CD based on Slackware that runs the Xfce and Fluxbox window managers. It can be used as a live CD, or put on the hard drive as a frugal install or traditional hard drive install. I opted for the traditional hard drive install.

The Wolvix installation process is excellent. I already had partitions set up, but the Wolvix installer offered to start up Gparted and make some or modify those I have. I also had the option of designating separate partitions for /home and other directories (I declined but would have configured a separate /home if I planned to use Wolvix long-term). The installer also gave me the option of booting Wolvix at the console or in a GUI (I chose the GUI), and it offered to put GRUB on the master boot record (I accepted). It also detected gOS, which allowed me to dual-boot. If whatever I install on the remaining partition messes up GRUB, I can easily reinstall it from Wolvix without having to geek out too much. (Note: Wolvix didn't do so well on GRUB, I instead used the gOS install disk to reinstall GRUB, and it recognized gOS perfectly).

I ran top in a terminal in Wolvix Hunter running Xfce, and at idle, with the Firefox window open on another screen (just like in gOS), the top running process was X at between 2 and 4.6 percent CPU and 7.6 percent memory. In short, a whole lot lighter than Enlightenment.

Maybe Wolvix isn't the best distro with which to compare gOS, but the Xfce vs. Enlightenment comparison is more than valid. Is it possible that the Everex PC could perform better with Xubuntu instead of gOS? (The answer is yes.)

Anyway, since Wolvix includes Fluxbox, I decided to go further and check top again. I opened Firefox, opened this document, switched to another window, opened a terminal and ran top. X was still the top running process and veered between 0.3 percent and 1.7 percent of CPU, and 6.1 percent of memory. Again, much better than Enlightenment in gOS.

To provide an even clearer picture of the performance of gOS and Enlightenment, I tested the load times of Firefox and OpenOffice Writer in a variety of Linux distributions and window managers. (Note: Slackware 12 doesn't include OpenOffice, and I haven't bothered to add it, so times are provided for KOffice's KWord -- which is generally quicker to load than OO). Load times were checked twice for each setup, since the second load of each of these two applications often happens much more quickly than the first.

Other variables that may have affected the times: Ubuntu 6.06 uses Firefox 1.5. All others used variants of Firefox 2.0. OpenOffice versions ranged from 2.0 in Ubuntu 6.06 to 2.3 in gOS.

The distros and window managers tested on the Maxspeed converted thin client (1 GHz VIA C3 processor, ECS eveM motherboard, 256 MB RAM) were:

gOS 1.0.1 (Enlightenment)
Ubuntu 6.0.6 LTS (GNOME)
Wolvix Hunter 1.1.0 (Xfce and Fluxbox)
Slackware 12 (KDE, Xfce and Fluxbox)
Ubuntu 7.04 (GNOME)
Xubuntu 7.04 (Xfce)
Debian 4.0 Etch (Xfce)

To sum up before the results are given, gOS was the slowest of the bunch -- even slower than Slackware under KDE -- and also slower than Ubuntu. It may be surprising, but Ubuntu with GNOME compares somewhat favorably to other distros running Xfce; you don't lose much speed by running GNOME as opposed to Xfce. Slackware and Debian with Xfce were another story; both were extremely fast when it came to loading applications. I didn't include Debian Etch with GNOME in the test because I didn't have it installed on one of the thin client's drives. But Debian compared very well to Slackware when both used the Xfce desktop environment. Curiously, Xubuntu -- Ubuntu's Xfce variant -- was slower than Debian with Xfce; in fact (as I already mentioned), Xubuntu didn't provide much of a speed advantage over regular Ubuntu.

I expected Wolvix to be the fastest, or at least as fast as Slackware. but it was buried by Slack. Not surprisingly, when Xfce was chosen for the window manager instead of KDE, Slackware was the undisputed winner, with a first-load time for Firefox of 8 seconds. That said, Ubuntu was slower, but not overly much, so if you prefer Ubuntu and GNOME to Slackware and Xfce, it's not like night and day in terms of application load time; it's more like noon and 2:30 p.m. -- a difference, but not so much as to make the slower of the two unusable.

The reason I even did this test was that from a "desktop feel" standpoint on my underpowered test box, gOS lacked the quickness of most of the other distros, including the Dapper and Feisty versions of Ubuntu.

And while Ubuntu has made some performance gains between 6.06 and 7.04, compatibility with hardware and desire for (or lack of interest in) more up-to-date apps should govern users' choice of the LTS vs. regular releases of the distro. For instance, on the converted thin client, hardware recognition is great in both versions, but on my Gateway laptop, ACPI and touchpad configuration work better in 7.10, and almost as well in 7.04. But ACPI management of the CPU fan only works with the kernel provided in 7.04.

Another aside: I saw practically no difference in application load times between Xfce and Fluxbox. So if you prefer Fluxbox, go ahead and use it, but you won't be gaining any performance over Xfce, at least in 256 MB of RAM. On the $15 Laptop (Compaq Armada 7770dmt), which only has 64 MB of RAM, I ran Debian with Fluxbox for months, and it runs just as well now that I have Xfce on it. And the superior tools included in Xfce put it ahead of Fluxbox when it comes to usability on the desktop.

The Slackware KDE vs. Slackware Xfce numbers are the most startling; using Slack with Xfce will save considerable load time on slower systems.

On "modern" PCs, however, much of this is moot. With a dual-core processor and 512 MB to 1 GB of RAM, everything loads so quickly that for desktop use, personal preference for one window manager or another holds more sway than load times, which will be acceptably short in just about any desktop environment. And for those who like all the bells and widgets of KDE, if you have enough power to enjoy them, it's probably worth it. Just Konqueror alone, with its ability to function as a Web browser, file manager, file viewer, FTP client and configuration portal, makes KDE very attractive. If only I could get X configured properly in Slackware on my Gateway Solo 1450 laptop.

Here are the test results:

gOS 1.0.1 (Enlightenment)
Firefox 2.0.0.10 1st load: 30 sec.
                 2nd load: 15 sec.
OpenOffice 2.3   1st load: 56 sec.
                 2nd load: 21 sec.  

Ubuntu 6.06 (GNOME)
Firefox 1.5.0.13 1st load: 21 sec.
                 2nd load: 10 sec.
Open Office 2.0  1st load: 44 sec.
                 2nd load: 26 sec.

Wolvix Hunter 1.1.0 (Xfce)
Firefox 2.0.0.6 1st load: 19 sec.
                2nd load: 12 sec.
OpenOffice 2.2  1st load: 37 sec.
                2nd load: 23 sec.

Wolvix Hunter 1.1.0 (Fluxbox)
Firefox 2.0.0.6 1st load: 22 sec.
                2nd load: 12 sec.
OpenOffice 2.2  1st load: 42 sec.
                2nd load: 23 sec.

Slackware 12 (KDE)
Firefox 2.0.0.8 1st load: 24 sec.
                2nd load: 14 sec.
KOffice         1st load: 19 sec.
                2nd load: 16 sec.

Slackware 12 (Xfce)
Firefox 2.0.0.8 1st load:  8 sec.
                2nd load:  8 sec.
KOffice         1st load: 15 sec.
                2nd load: 13 sec.

Slackware 12 (Fluxbox)
Firefox 2.0.0.8  1st load: 9 sec.
                 2nd load: 9 sec.
Koffice         1st load: 15 sec.
                2nd load: 13 sec.

Xubuntu 7.04 (Xfce)
Firefox 2.0.0.10 1st load: 18 sec.
                 2nd load:  9 sec.
OpenOffice 2.2   1st load: 36 sec.
                 2nd load: 22 sec.

Ubuntu 7.04 (GNOME)
Firefox 2.0.0.10 1st load: 17 sec.
                 2nd load: 10 sec.
OpenOffice 2.2   1st load: 40 sec.
                 2nd load: 18 sec.

Debian 4.0 Etch (Xfce)
Firefox 2.0.0.8  1st load: 10 sec.
                 2nd load: 10 sec.
Open Office 2.0  1st load: 17 sec.
                 2nd load: 17 sec.

As I say above the biggest thing to emerge is the speed advantage of Slackware and Debian, especially with Xfce. The relative slowness of Slackware 11-based Wolvix was puzzling. And while I didn't have OpenOffice installed in Slackware, and KOffice is pretty much a quicker program, I included its load numbers for comparison's sake. I did first and second loads of all apps because the second load is often -- but not always -- much quicker. Times for office suites were the number of seconds it took to open up a new OO Writer or KWord document.

While I didn't expect Debian to be slow, I also didn't expect it to be so comparable to Slackware. That's good news for Debian users.

But the biggest thing to come out of this test is that standard Ubuntu pretty much crushes gOS. The new, hot distro may be green in color, but it's incomplete and slow.

That said, the idea of doing most work in the browser and drawing on Web-based portals for not just e-mail and "social networking" purposes, but also document creation, photo editing and storage is becoming more attractive and viable all the time. In this realm, gOS is making a big "idea" contribution to the OS game, but in terms of sheer performance, polish and basic tools, it has a long way to go.

The average user -- even newbies -- would be better off with Ubuntu or Xubuntu on the Everex. And as these tests show, the Xfce desktop environment, in most instances, provides more bang for your MHz.

I wanted gOS to be great, but when it comes to Linux and BSD distros, greatness only comes with time and painstaking effort. After all the hype over the gOS-Everex-Wal-Mart effort -- some of it even generated by yours truly -- I didn't expect to see gOS beaten by every single established distro I threw at it. I don't usually do extensive time tests, but the sludginess of gOS drove me to it.

And while I expected Slackware and Debian to acquit themselves well, I wasn't prepared for out-of-the-box Ubuntu to best gOS. It wouldn't make as great a story -- "Wal-Mart chooses Ubuntu" -- but it would be way better for those buying the $199 box from the world's largest retailer.

Nothing much to report today, except that the monitor does go into power-saving mode when idle. It just takes awhile.

Everything is running great. I almost forgot how much I like using Seamonkey as a Web browser. I haven't yet set up the mail-client portion yet, but I do plan to.

I still think Geany is one of the best text editors out there. And despite it's lack of typographical, "smart" quotes, AbiWord is a model of how light yet powerful a word-processing application can and should be. And MtPaint continues to get the job done when it comes to preparing images for the Web (although I'd just about kill for a Linux-compatible photo editor that didn't obliterate and even allowed editing of the Photoshop-implanted IPTC info embedded in JPEG images).

Today's "free memory" in the Puppy Memory Applet: 113 MB.

As I look back on the past year's worth of Click entries, I see my adoption of Linux play out. The pace of free, open-source software development is so fast that it makes the year seem very long indeed.

The most fun I had writing these entries was during the month of the original Thin Puppy Torture Test, in which the converted Maxspeed Maxterm thin client ran on Puppy Linux (I think I was using 2.14 at the time) for a month with no hard drive -- in fact, no storage at all except the onboard RAM.

Since then, I've been able to create and access a pup_save file on an attached USB flash drive, and I thought it would be a good time for a second Thin Puppy Torture Test. This time, I burned a fresh Puppy Linux 3.01 CD, booted the thin client, and "upgraded" an existing pup_save file on the flash drive.

I've been planning to get a 2 GB or 4 GB Compact Flash module on which I can dual-boot Puppy and Damn Small Linux with frugal installs (copying the few and huge CD files over to the flash drive and making it bootable) and no spinning drives of any kind attached whatsoever, but in the interim, I'm doing this new rendition of the torture test.

One of the reasons I'm going back to a long-term Puppy test is the nagging feeling that running Puppy and/or Damn Small Linux from live CDs -- or going all-out and doing the same with Knoppix or Wolvix on a 1 GB RAM box -- is a very viable alternative to traditionally installed Linuxes for desktop computer users.

Having a recent Ubuntu Gutsy install go bad on me (twice!) didn't exactly endear me to traditional Linux installs, and from my use of all the live CDs mentioned -- all of which are designed to be used as live CDs rather than as sludgy demos of what a traditionally installed system will do much quicker -- running a live CD completely in RAM, with no spinning hard drives or whirring CD drives, is a refreshing change.

I originally wanted to do a Damn Small Linux Torture test, but I couldn't get DSL 4.0 (or any previous version; I have CDs for 3.2 and 3.3) to boot from CD without a hard drive connected.

So before I begin the torture, I'll give DSL another try with the USB flash drive connected ... but even as I close out this entry, I know that Puppy, out of the box, has more of the apps I want (AbiWord, MtPaint) even while DSL seems lighter on overall resources. (Note: since the original writing, Damn Small Linux has added MtPaint).

Final thought: The mere fact that you can run Linux in a traditional install, frugal install, as a live CD, and make it even quicker by running completely in RAM, illustrates the wonderful freedom of choice we have with a fully open and modifiable operating system.

As one of the ways to keep track of my journey through the world of Linux and BSD distributions, on every CD I try to write the date I burned it. I can't remember how I found out about my first Linux live CD, Knoppix 5.1.1 (some Web story must've gone on about how great it was to run a full Linux without doing a hard-drive install), but the date I wrote on the case is Jan. 29, 2007 -- soon after the 5.1.1 release came out. And it wasn't just my first live CD, it was also the first Linux CD of any kind I made -- and my first experience with a Unix-like operating system since leaving adm3a and VT-100 terminals behind after my college days in the 1980s.

I remember running that Knoppix CD on my Dell box. I didn't know what Debian was. I had no idea that KDE was Knoppix's desktop environment -- or that there were many alternatives. I didn't know why the Web browser that looked like Firefox was called Iceweasel.

Since then I've spent considerable time running Puppy and Damn Small Linux from live CDs (and in hard-drive installs, usually of the three-or-so-file "frugal" variety).

I recently burned both Puppy Linux 3.0 and Damn Small Linux 4.0. On the one hand, I'm thinking about doing reviews of both. On the other, I think it's time to replace the Debian setup on the $15 Laptop, a Compaq Armada 7770dmt. I've been running it for months with a very basic Debian Etch install. I started with the "standard" install, then added X and Fluxbox, along with the apps I wanted. It's been running fairly well, but the problems with various applications have been piling up. I know that if I use Puppy or DSL, the apps I want should work perfectly from the get-go. Of course I could also do a fuller Debian install -- say the Xfce version -- which would include many more applications ...

So before I dive back into live CDs, here's what's been troubling me with my Debian Etch install. The laptop is so old (probably circa '98) that it doesn't have USB ports. I have my trusty Orinoco WaveLAN Silver PCMCIA wireless card installed -- it works with just about every Linux distro out there -- and I have the CD drive plugged in. The floppy drive is dead, but who needs it? I have the original 3 GB hard drive, and it's pretty full, even though I've got nowhere near the full Debian install on it. I really should buy a new hard drive that's way bigger and less prone to failure.

Anyhow, the 233 MHz, 64 MB system probably could run Xfce, but I've been conservative, running both the console and Fluxbox as needed. Maximum memory for the Compaq is 144 MB, but I've been too lazy and cheap to buy the RAM. The CMOS battery is dead, and I've really been too lazy to crack the case (TORX screws aplenty) and see how to switch it out. I have the network time server app installed, and that resets the clock at each boot.

I originally wanted to handle my work e-mail over IMAP with Mutt and MSMTP. Never mind that to get a Mutt setup seems to be the height of geek competence (a height to which I do not reach), but since my original push to get the .muttrc and .msmtprc files just right, something changed and I can no longer send mail. I could never figure out how to handle multiple mail accounts over IMAP (POP is easier, since you can POP all the mail down and filter it ... and by "easier," I mean harder but doable).

So I installed Sylpheed, which I figured would be light enough for the 233 MHz box. I've always liked Sylpheed, although I've migrated over to Evolution and Thunderbird on my other boxes.

On first launch of Sylpheed, I got an error message that some parameter in some file (I confess, I didn't recognize any of it) was missing. So I went ahead and configured Sylpheed. It didn't work.

I have AbiWord installed -- my go-to lightweight word processor -- but the graphics of the laptop just can't keep up. I type, and the letters appear seconds later. Ted might work better, but it's broken in Etch. You can neither create a new file nor open an old one.

On the brighter side, the Dillo browser works great (although the fonts are better in Damn Small Linux and Vector), and I also have had no problem with Iceweasel (aka Firefox), Lynx or my favorite light image editor, MtPaint (which should be an official Debian package available via apt-get but for some reason can only be found at Sourceforge and on other distros like Vector and Zenwalk). I've also been very pleased with Mousepad as a text editor, with Nano and Vi as backups. (I'm more of a Nano users because I just don't spend a lot of time in console editors and have ragged Vi chops).

So I'm able to get my work done in Etch, but I have a feeling that I'd be better off -- especially at 64 MB of RAM -- with Damn Small Linux.

And with the release of version 4.0, what better time to re-evaluate the distro, which has been in or near the Distrowatch top 10 for quite some time.

So I pulled the CDs for Puppy 3.00, DSL 4.0 and Knoppix 5.1.1. I'm not ready to break out the Compaq laptop just yet, so I used my main test box, the converted Maxspeed Maxterm thin client that runs a VIA C3 Samuel 1 GHz processor and 256 MB of RAM.

I plugged in a USB drive, with my hope being that I could then unplug the hard drive, boot from CD and then have no drives whirring for the duration.

That worked with Knoppix, Puppy, even with a Vector SOHO live CD I burned a week ago (and let me say that just as Vector excels with the Xfce desktop, it also does remarkably well in KDE).

But Damn Small Linux? No, it wouldn't boot with the hard drive disconnected. I tried versions 3.3 and 3.2 as well. No go for any of them.

My USB key is a little unsual. It was a freebie, and has a CD advertising image (detected almost always as drive sr0) as well as a 256 MB flash memory. Puppy found the flash just fine (I've always had great luck with hardware detection, especially of drives, with Puppy), and I was able to boot without a hard drive, run entirely in RAM, and save my settings and files to the pup_save on the USB drive. Brilliant, as usual.

Neither Knoppix nor DSL could find the USB flash drive, but I suspect with a "pure" USB drive the results would be different.

Even so, I've done quite a few Puppy reviews, and I wanted to start out with Damn Small Linux. So I plugged in a hard drive, booted DSL (using the dsl toram boot code that loads the whole distro into RAM) and was off.

Quickly, things that are better in DSL 4.0: network configuration is smoother than ever. Once I entered my static IP, DSL guessed the rest of the info pretty darn well. I entered my local name servers, but the gateway and broadcast addresses were correct without me doing anything. I was able to get printing working with apsfilter (I could never replicate my success in Etch, by the way).

The default window manager in DSL is now JWM, and the thing I miss most is the menu that used to come up with a right mouse click. It's easy enough, however, to change window managers to the old DSL's Fluxbox, and then everything is the way I like it. But I'm getting used to JWM (Joe's Window Manager) in DSL, and I like the clickable folders on the desktop -- it's easier and more intuitive than using the file manager.

Anyhow ... I'm not ready yet for a full DSL review, so let me just tell you that to me -- and many others, I suspect -- Puppy, DSL and Knoppix are VERY important distros in the Linux universe. Going from Windows or Mac to the world of Linux might not have happened for many of us if we didn't have live CDs that actually work that way with which to experiment.

And in many cases, working with a live CD or frugal install that allows files and parameters to be saved, either on the hard drive or on removable media, can be an easy, secure and preferable way to use a PC. Especially when it comes to DSL and Puppy, upgrading can be as easy as downloading and burning the latest ISO. And if you don't want to upgrade? No problem -- just use the version you want.

I did spend at least half a day running Knoppix with no hard drive. As I said above, Knoppix didn't find my USB drive (a situation that might be remedied with a more standard flash drive). As the king of live CDs, Knoppix, which is not one of those distros that is continually coming out with new releases, runs very, very well. Even when not running it in RAM, Knoppix is surprisingly quick, even with KDE. And if you do have 1 GB of RAM, I highly recommend running it with the toram boot option. I definitely plan to get the book "Knoppix Hacks," which has a new release slated for this month, as well as the new Damn Small Linux book.

And this thought has crossed my mind: I just might hack together a PC with 2 GB of RAM, and either a Compact Flash card or USB flash drive for storage, with no hard drive at all, to run Knoppix entirely in RAM.

(By the way, Puppy seems to know when it has enough memory to run in RAM -- I don't think you have to pass that information in a boot code).

And while the live CDs of Ubuntu, Mepis and others are helpful in terms of evaluating hardware detection, they're not designed to be used day-to-day in that manner. But DSL, Puppy and Knopix are -- and they all can be installed to the hard drive if you wish.

Before I wrap up this entry, I want to say that everybody should try Puppy, DSL and Knoppix. Download the ISOs, burn the CDs and start experimenting with all the boxes you can find. I've had more fun with live CDs than in anything else I've done with Linux. After a few months in Debian, Slackware and Ubuntu, it's a nice change of pace (and yes, I've tried Slax -- which I like -- and I plan to give Wolvix a spin soon).

So burn yourself some live CDs -- and make a half-dozen or so extras to hand out at will. It's the best way to get people started on exploring the non-Windows world of computing.

Back in the days before the Thin Puppy's CF card died, I was running my Maxspeed Maxterm thin client with flash memory instead of a conventional hard drive. And since Puppy Linux takes great care NOT to write to flash very often, the media is supposed to last virtually forever. Why mine died is a mystery, but it wasn't due to wear (more likely I killed it with static electricity).

Now that I'm running Puppy 2.16 (new to me this week!), I've been thinking about going back to flash for this thin-client box -- I'm booting from CD and also have a regular-sized 14 GB hard drive connected outside the box (yes, I truly am thinking outside the box -- or my PC is).

But the conventional wisdom is that for "normal" operating systems that don't use RAM disks, you'll kill flash quickly with the constant writes required by the OS.

But today on Low End Mac, that question didn't come up for these guys who are running their Mac laptops from flash memory. That link was to the letters about this original article, which, in turn, refers to this article about doing it with a Powerbook 1400 (one of which I have ... but which is too frustrating at this point to even contemplate using for my everyday computing for reasons that have nothing to do with flash). This final article -- filled with woe about flash cards that didn't work with the 1400 -- does address longevity of the flash media, saying it should work for "years and years."

I'm going to try it again (maybe even with Debian), but I'm also going to back up all my data ...

And again, if you want to boot from flash but are nervous, give the new Puppy 2.16 a try. I'm in my first full day of use, but so far all is going very, very well.

I made some progress -- and some discoveries -- today with my Xubuntu 7.04 Feisty installation on the Maxspeed Maxterm thin client.

First of all, can we all agree that the GIMP, in its heaviness, doesn't really fit in with the Xubuntu philosophy of lighter apps for a lighter window manager?

And with this heaviness in mind, today I installed my first Debian package -- mtPaint, which despite having greater capabilities than GNU Paint while being as quick to load, is not available as a Ubuntu package, either in Universe, Multiverse, or any other 'verse. I found it and downloaded it from the Web, then clicked on it to install. I couldn't figure out how to add it to the Applications menu, but I was able with Xfce to create a desktop shortcut.

Incidentally, I did try out GNU Paint, which is a Ubuntu-approved application, and quite nice for what it does, except that it can't resize images, which is the main thing I need an image-editing program to do.

But the result is that I have, indeed, installed a Debian package in Xubuntu, and it couldn't have been easier. I'll look into getting mtPaint into the Graphics menu under Applications -- how hard can it be? But another thing I did learn is that while the GIMP is torturously slow to load, and probably is quite a memory hog on this 256 MB box, once you have it loaded, it's not any slower or faster at actually processing images. I didn't detect any speed boost using mtPaint ... except for the fact that it loads in about 3 seconds ... as opposed to the GIMP's 60 or so seconds.

The other thing I did was add Wine and Internet Explorer 6 in my quest to do work on Dailynews.com in Linux. Wine is about as mysterious to me as it gets, but I did go into the Ubuntu Multiverse (or whatever 'verse it is) and install Wine from the Synaptic Package Manager. As an aside, it's interesting that besides Synaptic, there's the Add/Remove Programs utility, and I almost prefer it to Synaptic at this early stage.

Back to Wine: I installed Wine from Synaptic and then used IES4Linux to get Internet Explorer into the Wine world. I did this successfully once before with Xubuntu when running it as a live CD, so I knew that this worked. I had IE6 on my desktop, and it actually worked. And while I was able to use the Daily News Web-publishing software (which is browser-based and requires IE), that system is so buggy that I really couldn't run it under Wine due to repeated crashes. The problem is more ours than Wine's, but it's disappointing nonetheless. I tried to install some other publishing software under Wine by moving entire directories from my Windows box to the Xubuntu box, but nothing would run. I'll have to delve further into Wine to see exactly what I need to do. It may be a lost cause, but I'm not expecting much. Still, I'm not above giving Codeweavers a try.

That said, it was only with the IES4Linux package that I got Internet Explorer at all. I wish I didn't have to use it at all, because sticking with Linux-specific browsers and not dealing with Wine at all is a whole lot easier than the alternative.

And what about the 256 MB memory ceiling of this thin client? Some commenters said that it's not an enviable position, to be with this little memory. All I can say at this point is that while there's been quite a bit of use of the swap partition on the hard drive, the system hasn't gone down once, even with all the stress I'm putting on it.

I spent the day upgrading my new Xubuntu 6.10 (Edgy) installation to Xubuntu 7.04 (Feisty), and since Xubuntu is derived from Ubuntu, far and away the most popular Linux distribution for the desktop, I expected -- and still expect -- a lot more from it.

During my nearly month-long Thin Puppy Torture Test (chronicled extensively in this blog), I managed to get quite a bit of work done with my Maxspeed Maxterm thin client (1 GHz VIA processor, 256 MB RAM, no disk drives at all), most of it related to producing this and other Daily News blogs. From extensive Web surfing to light photo editing, heavy writing and use of Movable Type for Web publishing, Puppy Linux 2.14 performed admirably, even if, along the way, I lost the ability to mount external drives and couldn't really deal with large audio files due to the lack of available memory. But for the basics, Puppy did the job, day in and day out.

With Xubuntu, I hooked up a 14.4 GB hard drive and a 32x CD-RW drive. And by the time I installed Xubuntu, I expected to get even more real work done. This time I seek to up the ante, doing work for Dailynews.com, which entails working with larger photo files (downloaded from services such as GettyImages.com and WireImage.com, although the latter offers a choice of smaller images to begin with).

And eventually, it means, installing some version of Wine (allowing use of Windows programs without the Windows OS installed), with Internet Explorer 6 running, because the Daily News Web publishing system requires IE. (And for the love of God, WHY??)

As far as text editors go, I can use just about anything. Even the anemic Mousepad editor that comes with Xubuntu would be OK, even though I prefer Geany, and even EditPad for Windows. And since Xubuntu's word processor, AbiWord is so light on resources and quick-loading, that could really serve as a text editor for my purposes.

And when it came to image editing, Xubuntu offers the GIMP, which though part of the GNOME office suite (featuring the loosely tied-together AbiWord, Gnumeric for spreadsheets and the GIMP), is a true resource hog, taking a full minute to load in Xubuntu on my 1 GHz box. For my purposes at least, I'm very familiar with the GIMP, as I've been using the Windows version for at least a year (and never having used Photoshop, had nothing to "unlearn"). So already the GIMP is a mismatch for Xubuntu, if indeed one is running it on "low-spec" hardware. I missed mtPaint from Puppy (which I just might install for Xubuntu, if I can figure it out), but I didn't miss the paint program that comes with Damn Small Linux, which doesn't do nearly what I need.

Long story short, I did work on about five photos for Dailynews.com, but the times required to save them in the GIMP really had me thinking about whether or not Xubuntu on this platform could handle this level of work. But I had to stop myself. I don't recall working with original images this big in Puppy 2.14. I mostly took images already sized for the Web and then made them even smaller. Even the GIMP in Xubuntu could make relatively quick work of that. And as far as general Web work with Firefox in Xubuntu, it went smoothly. I was even able to add the Flash plug-in for Firefox without working up a geekish sweat (translation: no command line needed, no Synaptic Package Manager, just clicking in the bar on Firefox to get the needed plug-in -- it was positively Windows-like).

When I write my full-length review of Xubuntu, I'll recount my odyssey of getting network printing working. Yes, it did take me most of the day, and yes, I'm surprised at how unintuitive Xubuntu's printer-configuration utility actually is (I gave up and used the CUPS interface), and I'm shocked that I got printing working much, much easier in both Puppy and DSL (and MepisLite ... and Slax and Knoppix and even standard Ubuntu Dapper). But that's another battle to recount on another day.

Suffice it to say that my first full day with Xubuntu Feisty was maybe a bit less bumpy than expected, especially given the high expectations I have for something that's billed as a speedier version of the hottest desktop Linux distribution on the planet -- however dubious such a distinction may be.

But in my search for answers on whether or not Xubuntu and its Xfce desktop interface is truly ready for real work (or at least for what it is that I do to put out Web pages and newspapers), I'm going to have to compare it to Zenwalk 4.4.1, which features the same interface but is built upon Slackware, as opposed to Ubuntu/Xubuntu's base of Debian. And I'll have to do a traditional hard-drive install of Puppy to see how it performs in that kind of traditional install (and whether that kind of setup allows me to deal with the kinds of large files that I do, in fact, have to process during the course of my day).

And last ... and only least if you think of it that way ... I will do a standard Windows 2000 install on the 1 GHz thin client (because I've got a 2000 disc and not one with XP on it) ... load it up with the requisite open-source apps (Open Office, AbiWord, the GIMP, Avast antivirus, Firefox, even SeaMonkey) to have a truly well-played field on the same hardware before drawing any definite conclusions in the battle for OS supremacy on my low-spec desktop. And honestly, as I work on this entry at home on an iBook G4 1 GHz/384MB laptop with OS X 10.3.9, and seeing how well it runs, I can't leave Apple and its BSD-derived operating system out of the equation.

After trying -- and failing -- to install about 10 distros yesterday on my Maxspeed Maxterm thin client, with a CD-RW drive and hard drive connected but sitting on the outside of the thin client box, I slid my Ubuntu 7.04 Feisty alternate-install disc into the drive and hoped for the best. Keep reading for an account of my day in the Edgy-Feisty trenches.

Since I'd previously installed Damn Small Linux 3.3 on a different hard drive, I tried to install it again on the drive I had connected at the time, an 80 GB Seagate ATA. But even DSL wouldn't boot from the drive, so I reached into my stack of IBM-labeled 14.4 GB hard drives and tried Feisty again. I did a command-line system install, and that went without a hitch. But since I'm not going to be doing everything with vi (I did that in college, thank you), I immediately began to reinstall Feisty in full.

The first time, it hung up somewhere in the middle -- my disc light was pegged on, but none of the drives were doing anything, so I had to reboot. Now it looks like the install is going to happen. I didn't time it, but it hasn't been quick. I'm currently on the "Select and install software," which just failed. But I have the option to try again.

We'll see how it goes.

Update (2:45 p.m.): The installer just won't go past "Select and install software." After a couple of failures, I skipped ahead and installed GRUB, then went back. Why, WHY isn't this part working? (I previously checked CD integrity, and it's fine). As I've written before, this is no typical hardware installation, being a hacked thin client, but I'd still like things to work.

Update (2:55 p.m.): Since it looks like the "Select and install software" step is just completing when I get the error message, and since I already skipped ahead and installed GRUB, I decide to skip ahead again and "Finish the installation." That goes fine, and the CD drawer opens. I move the CD and reboot ... AND get a command-line system again. No GUI.

Update (3:15 p.m.): I had the Live-CD ISO of Ubuntu 6.10, but I had never burned a CD of it. I decide to do so. By mistake, I burn Xubuntu 6.10 (now I've got two), so I load that as a live CD.

Update (3:50 p.m.): The Xubuntu install from live CD is proceeding swimmingly. If this install sticks, I'm going to keep it for awhile. I don't know how the traffic is now on the mirrors for the Ubuntu 7.04 live CD, but I just might wait until the Xubuntu Feisty upgrade is ready ... if this install sticks, that is.

Update (4:10 p.m.): The Xubuntu 6.10 install is almost done. It's currently REMOVING stuff -- language packages, GNOME utilities ... but I'm 97 percent done with the install.

Update (4:12 p.m.): The install finishes, the CD drawer opens, the screen goes blank. I hit return a couple of times and the system proceeds to reboot.

Update (4:20 p.m.): I open Firefox, and it says "Welcome to Xubuntu 6.06." I've got Xubuntu, but did I burn the wrong version? Also, the graphical installer never asked me for my networking settings, so I'll have to do those manually. Only I would burn the wrong CD ... But I do have a legitimate 'Buntu installed on the hard drive connected to my thin client. ... Should I call it Thin Xubuntu, or Thinbuntu? Maxbuntu?

Update (5:05 p.m.): I check my other Xubuntu 6.10 CD ... it seems that they never changed the "welcome" page in Firefox, and even 6.10 says 6.06. One thing's for sure -- Xubuntu isn't as snappy as Puppy Linux and Damn Small Linux. And when I try to shut down the system, the monitor goes blank, but the box stays on. I have to push and hold the power button to get the box to power down all the way. (I didn't have to do that with Puppy or DSL.)

Update (5:10 p.m.): In the Xubuntu menu, I go to System--Update Manager, which tells me that "New distribution release '7.04' is available." I click the Upgrade button. I get this message: "Authentication failed." Is it the traffic on the Internet, or a flaw in the process? I check for other software updates, and there are 90, totalling 139.2 MB. I start it. As an aside, I miss being able to bring up a menu anywhere on the desktop with a right-click, like I can in the Fluxbox and JWM window managers.

Update (5:55 p.m.): The updates download and install fine. Another try at the 7.04 upgrade. It fails for the same reason. But I do have Xubuntu installed on the thin client. And I'm about 80 percent sure it's 6.10. Time to turn the box off and go home. I'll live to fight another day on Monday.

Update (10:05 p.m.): I neglected to mention that the DesktopBSD install CD will NOT boot on the thin client. Just won't do it. I'd love to get a BSD on there -- will I have to build up from FreeBSD? I'm not completely opposed, but I hoped to get my feet wet with DesktopBSD. And as far as Xubuntu goes, the text editor is not as good as Geany. It's a bit basic, and doesn't have word count. But the word processor with Xubuntu is AbiWord, which is quick enough to launch that I serves as a nice text editor for my purpose, which is writing blog entries and not programming. And yes, I can use vi to hack at config files in the shell.

One of my projects should be digging through my boxes of crap in the shed and seeing if my copy of "Unix for Luddites" is there. I'd love to scan it in and have it available to all, in all its 1980s glory. That photocopied book by UC Santa Cruz's Scott Brookie got me going on Unix during college to write my papers. We used vi to write, nroff to format, and the printouts on a laser printer (in the '80s, for shit's sake) could be collected at the computer center on the far-flung campus, which had dumb terminals to access the system at every one of its eight colleges, as well as at the campus library.

I probably should've tried Zenwalk Live 4.4.1, which was released Wednesday, but I figured that since Ubuntu Feisty 7.04 is out today (or at least that's when Distrowatch announced it), I might as well get Feisty. I thought I would try Xubuntu instead, given that my hardware is generally as old as the hills, but Xubuntu seems to be the only official 'Buntu NOT to have a release at this time. Ubuntu, Kubuntu and Edbuntu are all available ... that is if you can get them. All the mirrors are crazy busy -- I started one download that said it would take 36 hours (and I have a wicked-fast connection). I couldn't seem to even start any more downloads of the ISO for the Ubuntu 7.04 Live CD, and I was surprised when I was able to begin a much-faster download of the alternate-install CD.

In my last post, I recounted how the Xubuntu 6.10 alternate CD would not install on my Maxspeed Maxterm thin client. Well, today I decided to shove a few more CDs into the drive to see what would happen. I began with Ubuntu 6.06 LTS, the long-term support edition of Ubuntu. It booted, no problem. But I hesitate to continue with the install because my Feisty download should be done in 3.5 hours.

I did like Zenwalk 4.2, and I will be looking at 4.4.1, but let's face it, in a month that has seen new releases of Debian and Mepis, plus my personal favorites Puppy and Damn Small Linux, Ubuntu is the 9,000-pound gorilla of Linux, and it must be contended with.

... Now my download is saying four hours ... time to install 6.06.

As I wrote in the final Thin Puppy Torture Test entry, I wanted to try some other distributions with the Maxspeed Maxterm thin client, so I finally shut it down.

After that, I opened up the box, unplugged the CF-to-IDE adapter and plugged in a 14.4 GB IDE hard drive by IBM and a 32X TDK CD-RW drive. I had trouble before even booting many Debian-derived Linux distributions, and I'm not exactly well-versed in the jumper settings for a hard drive and CD drive chained to a single IDE interface (there's only one IDE plug on this VIA-equipped Mini-ITX motherboard).

After leaving both drives as masters, nothing was happening, so I made the HD the master and the CD the slave, and then both were recognized by the BIOS.

And since this is a thin client, there's nowhere to physically mount any drives, so the thin client box is on its side, with the power cable (I had to use a splitter to power both drives from the single power plug) and IDE ribbon cable poking out from the box and the drives stacked on top of it. Man, I didn't know that a hard drive throws off so much heat. It's a far cry from when the thin client was running Puppy 2.14 from a Compact Flash card.

So I had a bunch of discs ready to try. I had previously booted Zen Walk 4.2, so I didn't want to try that one right away. The Fedora Core live CD wouldn't boot -- it kept rebooting the machine in a loop without actually doing anything. I tried to run the alternate install CD of Xubuntu 6.10, and the install went pretty far before I got repeated warnings like this:

Debootstrap Warning
Warning: Failure while installing base packages. This will be re-attempted up to 5 times.

I hit enter and kept going a bunch of times, but the install just wouldn't happen. Previously, the Xubuntu live CD wouldn't run, so I didn't even try it.

I tried openSUSE's net-install CD, and that wouldn't boot either.

Now this box is pretty untypical and tempermental -- when I first got it, the only thing that would run was Puppy Linux. DSL wouldn't boot then, but I tried it again and it not only booted but installed on the hard drive. Near the end of the install, the installer script told me I'd have to reboot, and I figured the system would do it automatically. It didn't, so I rebooted with ctrl-alt-del. The machine restarted and asked me to set root and user passwords (I elected multi-user during the install). I set the password and was off and running with the new DSL 3.3 on my hard drive!

The fact that of all the Linux distributions I've tried, I've only gotten Puppy, DSL and Zen Walk to boot is a testament to the people who put them together.

I should probably try to install Xubuntu again ... or Zen Walk, possibly dual-booting with DSL (I selected Grub as the boot loader, not that I know how to tweak it yet).

But so far, DSL 3.3 is running great on the thin client. Configuration of static IP networking was easy -- it's pretty much the same as in Knoppix, with a terminal window opening and a standard script running. I haven't checked the sound yet (gotta plug in the headphones), but I'll do that soon.

And I'm writing this entry on Firefox 1.0.6, the main browser with DSL 3.3, which also offers the light Dillo that runs so great in Puppy (but which really can't do Movable Type as well as a CSS-equipped browser).

As I wrap up this entry, I have no doubt that just about all of these distros mentioned would install on a "normal" system, and I acknowledge and understand that a thin client with a rare motherboard, non-Intel (or AMD) CPU and single IDE header might be far from normal, but the fact that some distros will boot on this somewhat exotic platform begs the question -- why won't they all?