I started by trying to install the latest and greatest Ubuntu, 6.10, Edgy Eft. No go. I got about halfway through the install only to be presented with the flashing underscore of death. This happened twice. I was worried about hardware problems, but I did manage to successfully reinstall 5.04, Hoary Hedgehog, the release I’d had on the same box previously.

I then tried to upgrade to 5.10. No go. I couldn’t find ISOs anywhere, and the upgrade instructions didn’t work. Apparently Ubuntu has pulled crucial files off their web site. I bet you can upgrade from Windows 2000 to Vista though. Ditto for Mac OS X Jaguar to Leopard.

I then downloaded ISOs for 6.06, which is at least still supported. This installed, though my father couldn’t have done it. (/dev/hda1? What’s that?) Setting up partition tables has improved since the early Debian days, but we still shouldn’t be asking users to do it at all; especially when there’s a perfectly good Linux partition set already installed on the hard drive. Of course, you shouldn’t erase the user’s data when you upgrade, which is exactly what the easy install would have done. Thankfully I’m tech savvy enough to decode all this, but I really shouldn’t have to.

Once I finally got everything up and running, I began installing various packages like Apache and PHP. This is actually easier than it was on my Mac, but only because I didn’t stick with Apple’s default version of Apache. On a Mac, Apache is a checkbox item. It’s a little more complex on Ubuntu. I also had to figure out a way to transfer and share files between my Mac and the Ubuntu box. This required installing more software (SSHD and netatalk). On a Mac or Windows machine, this would already be installed and ready to turn on.

Once I finally got it all configured, I’m left with a system that has clearly improved and is equally clearly not ready for prime time. Ubuntu still can’t handle my 1600×1024 widescreen monitor (Windows and the Mac both can). I’m sure there’s a way to setup X to make this work. I’ve done it before; but right now I don’t have time. Instead I’ve just chopped off the left and right sides of my monitor into big black bars.

The networking is better than it used to be, but still not nearly good enough. When I accidentally booted up without the Ethernet cable plugged it it couldn’t find the network. That’s natural enough. However. once I plugged the cable back in, Linux still coudln’t find the network. I had to reboot before it would realize it was reconnected, and this is on a wired desktop. I can only imagine how it behaves on a laptop with a spotty wireless connection.

The default menu layout has improved, but it mixes up menus with buttons, and requires you to navigate a hierarchical menu to find anything.

The file system view (Nautilus?) is still a disaster, but then that’s the case on Mac OS X and Windows too these days. File system interfaces reached their apex in MacOS 9, and have only degraded since then. This probably won’t improve until we abandon file systems completely, perhaps sometime in the 22nd century at the rate we’re going.

The screen savers are very pretty (My cat Marjorie loves them a little too much and almost pushed the monitor on the floor while batting at them) but the desktop itself uses very funny fonts, that seem to be about twice as wide as they are high.

Simple dialogs like the Synaptic Package Manager display too small by default so some of the content is chopped off until you resize it. You’d never see something like this on a Mac, and usually not on Windows. There are lots of other little annoying inconsistencies throughout the package manager , like menu items that bring up dialogs but don’t end in …. And while I’m on the subject of the package manager, why not just call it “Package Manager” or “Install Software”? What, exactly, does “Synaptic” tell anyone?

Another example: setting up a shared folder with Samba requires a non-standard file dialog that confuses opening and adding a file.

There are lots of glitches like this throughout the user interface. Programs don’t seem to follow any coherent guidelines. Every program goes its own way. I’m not just picking on a few bad programs, by the way. Almost every single program, dialog, or menu item I’ve run in just a couple of hours has had multiple serious issues of one kind or another. In fact, in this article I’m cherry picking just a few of the dozens, perhaps hundreds, of problems I could point to.

Some things clearly have improved. CDs now mount automatically. The network was detected when I installed without asking me for anything; but a lot of stuff still doesn’t just work; and what does work is quirky and weird. It’s not that applications don’t act like Mac applications or Windows applications. It’s that they don’t act like each other.

I’ve heard it claimed that Linux is good enough for users who just want to browse the Web and write simple office documents. That’s false. It clearly isn’t. It probably wouldn’t take too much effort to put Linux in a usable state; but I see no evidence that anyone is doing this. The entire desktop UI needs a talented and knowledgeable redesign. This is going to have to extend into all bundled applications, and I suspect some toes are going to need to be stepped on and some applications forked when their developers refuse to follow basic principles of user interface design and consistency. Until that happens, tasteful Unix geeks everywhere are going to continue to buy PowerBooks and run Mac OS X.

At first glance JCP specs look OK; but once you really start digging into one at the level you need to write a book about one or implement it, you rapidly discover huge areas of unspecified behavior. Then when I write about it, I have to test the implementations to see what they actually do. I rarely test more than one or two, and then I write down its behavior as what happens. Then other people come along and read my book to figure out what they’re supposed to. The behavior that gets fixed is chosen almost by accident.

I blame this on the JCP‘s culture of implementation as specification. Many specs are nothing but the JavaDoc compiled from the reference implementation and pointlessly encoded in PDF and/or a zip file. The specs are thus only marginally better than documentation for a typical software product (i.e. slightly better than wretched).

By contrast W3C specs are normally written independently of implementations. Then the working group checks to see if the specs can actually be implemented in a compatible fashion. Since they require two implementations of each feature, this tends to identify any grey areas in the spec, especially when the people doing the implementing are not the people who wrote the spec.

The manual tells me to use the Full install to copy all the maps to my hard drive, but the installer doesn’t offer me that option. Since I couldn’t install the maps locally, when I zoom into Silicon Valley, Map Source asks for the West Coast CD. However I have the East Coast CD loaded; and I’m not really interested in the West Coast right now, so I press the Cancel button. MapSource promptly asks me for the same West Coast CD again. And again. And again. Even when I tab into another program. I have to go to the Task Manager to force this stupid thing to quit.

I’m not going to even start on how stupid a computer has to be to not know when I’ve inserted the disk. That’s really a Windows design flaw, and I probably shouldn’t blame Garmin for it (though Microsoft gets a big raspberry for this one).

I finally figure out how to transfer maps to the GPS receiver. Then I try to transfer a second map. It doesn’t work. Why? After some futzing around, I realize the GPS is turned off. Hmm, that’s funny. I just put in new batteries. Did they go bad? And when plugged in the eTrex runs off USB power anyway. (It draws almost twice as much power off the USB bus as it should, but that’s a story for another day.) Oh, guess what? After transferring the maps, MapSource turns off the GPS. <sarcasm>It’s not like you might want to upload and then download, or upload two maps, or anything like that.</sarcasm>

Simple fact is no one would use MapSource if there were any reasonable alternative for talking to the hardware. I knew when I bought the eTrex that it was a closed, proprietary system that only talked to Windows. I put off buying it for over a year precisely because of that, but the sad fact is there’s no open device that meets my needs in this space; nor is there any closed device that supports the Mac or Linux. The units from other manufacturers are just as bad. I only broke down and bought the eTrex because I needed it for a book I was writing. Why is it that companies that sell closed, proprietary devices that require you to use their software write some of the worst software out there? Hmm, now that I put it that way, I think I’ve answered my own question.

What really surprises me is that these are all problems I found within 15 minutes of tearing the shrink wrap off the package. That’s how bad this software is. I’ve barely touched the product, and I’ve already found bugs I’d be embarrassed to ship in a free-as-in-beer-beta, much less software people actually pay for. Garmin desperately needs to hire a dedicated software tester and UI designer; and listen to what they say. Better yet, Garmin should give up on selling software, which is clearly not their core competency; and focus instead on the hardware which isn’t bad. Open up the specifications, and let the very energetic open source mapping community figure out how to write a decent interface for downloading and uploading data to their devices.

Yesterday I spent a couple of hours avoiding real work by upgrading my software. Specifically I upgraded MySQL 4.1, Apache 2, and PHP here on cafe.elharo.com after noticing that MySQL had crashed. I didn’t do any major version upgrades, just moved everything up to the latest point release of the branch I was using. Along the way I noticed big, gaping holes in the documentation for all three. Not one of them had any upgrade instructions. They all had poorly written instructions for a first time install (Apache was probably the least bad here, PHP the worst) and a couple had instructions for moving between versions (e.g. 1.3 to 2.0 or 4.1 to 5.0) but not one had anything to say about how you should upgrade from 4.1.1 to 4.1.2 while keeping your data, configuration, and extension modules intact. Since point releases often fix security holes, these are the most critical upgrades. I had to go to IRC to figure out how to upgrade MySQL, where I was told it would happen by “magic,” which would be nice if it were true, except it wasn’t.

Word to software vendors: most of your customers are not starting from scratch. While it is critical to provide good instructions for first time users, it is equally critical to provide upgrade instructions for the majority of your customer base that is upgrading old systems. This is especially true for systems with relatively complicated installs like PHP and Apache. Some of the pieces were in place. Apache figured out to keep some of the old data when doing “make install” but the README still should have told me it would do that. However, my first attempt to upgrade Apache failed because I didn’t have exactly the same options to ./configure I had used a year ago when I installed it for the first time. The PHP “make install” broke my Apache config, which then had to be edited manually. MySQL’s “make install” failed to find my old data files, and I had to learn quite a bit more about MySQL just to get it to load the old data.

I don’t think it would be all that hard to write decent upgrade instructions for any of these products. Based on my experience, it’s mostly just a slight tweak of the normal install instructions; along with some words of caution about which files to back up and a little advice on how to figure out your orginal compile options that you now need to duplicate. Time to file a few RFEs in the relevent Bugzillas.

The latest one to piss me off is my FTP client, which has decided to forget all my passwords since upgrading to Mac OS X Tiger, and won’t let me enter any new ones. Technical support responded to my e-mail several days later with suggestions that didn’t actually work. (i.e. after following the instructions they sent me, the software put up an undismissable dialog and still never saved my passwords.) So, while waiting another several days for them to respond to that issue, I decided to check out other free-as-in-speech FTP clients, and I’m now prepared to recommend two:

• Cyberduck is a Mac OS X FTP/SFTP client with a better user interface than my old payware client ever had.
• j-ftp is another open source FTP/SFTP client. It’s not nearly as polished as CyberDuck; but it is written in Java so I can fix any bugs or add missing features myself. Unlike CyberDuck it runs on all Java supported platforms.

I want to give a little shout out to these two quality products, in the hopes that fewer people will pay for the poorly supported, closed source, payware clients; and the free market can do its job of chasing these posers back to the bowels of an insurance company IT department where they can spend their days churning out green screen code for actuarial tables. To speed them along in their career change, instead of sending them $17.95 to pay for an upgrade that might or might not fix their bug, I’ve donated that money to the Cyberduck programmers. For j-ftp, I may do something different. Time permitting, I plan to work on a Mac port myself and contribute the code back.

But this is just the beginning. There’s another, much bigger company that’s pissed me off lately by asking for another $29.95 more for a product I’d already paid for, just to support the new release of their own operating system. In this case, there’s no good open source alternative to this product; but I’m in a position to do something about that. After about a week of part time coding, I’ve already reimplemented more than half of their application, and I’ve added a couple of features they don’t have to boot. Very shortly I should be ready to kick the legs out from under their market. More on that next week.

One thing Stallman has never really acknowledged (at least that I’ve ever heard) is that the freedom he talks about is only for programmers and people who can afford to pay them. Everyone else is a serf who has to bow at the table of their programmer masters. In some ways it reminds me of ancient Athenian philosophers and Roman republicans philosophizing about freedom and democracy in a society built on the backs of slaves. The simple fact is that until the free software movement starts to take user interface design seriously, a typical end user is vastly more free using a Mac or even Windows than they ever will be using Linux.

The only counter example I can think of is Firefox. Firefox has a genuinely good user interface, with only a few minor glitches; probably less than you’d see in a typical end-user Windows application and only a few more than you’d find in an average Mac app. But that’s it. Mozilla’s a little worse than Firefox when it comes to the user interface. And I can’t think of any other open source, end-user application that even comes close to its non-free counterparts. No, OpenOffice doesn’t qualify. Claims that OpenOffice is as good as Microsoft Office, itself not a sterling example of user interface design, are wishful thinking at best. Maybe 2.0 will be better, but 1.x is at most adequate. I speak as someone who wrote an entire book using OpenOffice, and boy was that a mistake. There are real costs to using software with poor user interface design, and in this case the cost was a book that came out months later than it was supposed to. There are advantages to OpenOffice compared to Microsoft Word. The native XML format is a big one. But as typical for open source, this advantage does not make the slightest bit of difference to a non-programmer end user. Until open source developers start writing software for end users instead of each other, the situation will not improve; and most of the world will remain serfs. The only difference will be whether they bow in the direction of Redmond, Cupertino, or Cambridge.