Lacking Natural Simplicity

For some odd reason I decided to power on my old Gateway 2000 486DX/33 and do something with it. It hadn't been on since Wednesday, May 25th, 2005, if I can believe the BIOS date. (I was pleasantly surprised the settings hadn't gotten corrupted.) Up to the point I turned it off it was acting as a mail server backup for my personal system, and was running Sendmail, Dovecot, a greylisting milter, and Emacs. A little before that it had actually been one of the MPL DNS servers.

Anyway, it had Windows 95 on the original 200MB IDE hard drive and FreeBSD 4.10 on the 2GB Quantum XP32275S Atlas II. It came with Windows 95 of course when I bought it, but I ran SLS Linux on it originally, if I remember correctly, because 386BSD wouldn't install, and later MCC Interim Linux, and eventually FreeBSD. When my wife got me the SCSI controler and CD-ROM I was so thrilled because now I wouldn't get dragging home OS distributions on floppy any more! Once I got the 2GB hard drive I put Windows 95 back on the 200MB drive for my wife and for the occastional work-related Windows 95 excursion. It had 16MB originally, but I scrounged 4MB more of RAM for it very late on, when it was a DNS server.

I wanted to get a more recent OS on it, but remembering how FreeBSD 4.10 was a pretty tight fight there at the end, I decided I'd put NetBSD on it. (NetBSD documentation says it still should be possible to run in 4MB.) I used NetBSD for a while for my main box at home, but I was never satisfied that I'd mastered it as well as FreeBSD, and I thought this would be good way to put the old 486 to work. Luckily I was albe to find an 3c509B card to get it on the network, because it turned out the 3.5” floppy and the CD-ROM drive were both non-functional. (As I worked with the machine I remembered the floppy had been bad when I'd turned it off, but the CD-ROM had been working.) I gathered some confirmation information and then started trying to figure out how I was going to get NetBSD on it. Luckily the FreeBSD 4.10 install was still working and I was able to extract the NetBSD dosboot.com bootloader from base.tgz, copy it and the netbsd-install kernel over the network with FreeBSD, mount the old 200MB Windows 95/MS-DOS disk under FreeBSD, and copy the files over there, then boot into MS-DOS with F8 when Windows 95 started to boot, run through the prompting for each line in the config files and answering “NO”, and then run dosboot netbsd-install.

The installation was successful, but unfortunately the boot process failed.

As I recall, I've had problems in the past getting boot loaders to boot off this drive. I'll have to revisit it when I have some more time.

I ran across htop as I was installing software on my new Ubuntu install, and am finding it invaluable: much clearer than the standard Linux top.

I installed Ubuntu 8.04.1 on a Pentium II machine with 256MiB and was disturbed by how slowly it seemed. It turns out that it was just that bash was starting incredibly slowly. Removing the default Ubuntu ~/.bashrc fixed it. It turns out to be something in /etc/bash_completion which causes the slowdown, but I haven't figured out what yet.

On the advice of a coworker I tried out Chrome; after a day I think it has almost become my favorite browser. If only it built on the BSDs and Linux, and a had a noscript equivalent. I wonder what RSS/Atom reader will integrate with it well? [2019-11-10: Turns out it was Google Reader, which was eventually abandoned. sigh.]

Well, it looks like a leader is slowly emerging in my quest for an Emacs based mail reader: Wanderlust

It handles MH- and Maildir-format mailboxes, UTF-8 in headers, has good facilities for reading and composing MIME messages, and I finally got it to work with Lotus Domino/Notes IMAP/SSL, amazingly.

Moreover, it looks like I'm probably going to switch to using a Maildir-format mailbox, which will work well with my use of Unison: MH-format mailboxes' use of plain numbers for message IDs/filenames (which can change a lot) makes things a little more confusing when syncing mailboxes with Unison.

Moving away from MH-format mailboxes is a bit of a shame, since it means that I'll be losing the ability to use the MH command line programs for accessing my e-mail. I've used MH in the past, and have always liked the command line access it gives you. Ah well. I wish mdmh had advanced further.

Things that precipitated the crisis:

• UTF-8 in e-mail.

• HTML e-mail.

I've been munging my blog some more. Right now it's only running under WSGI, and I've turned the tags and the tag cloud back on. There was some odd behavior earlier, so it may still be somewhat broken.

I'm still having my personal e-mail crisis.

I said, earlier,

Anyway, I've finally come up with a way to switch back and forth between Gnus, Mew, and MH-E while keeping up with my current e-mail[…].

That was a bit premature. What I should have said was that I'd found a way to make sure I didn't lose any e-mail permanently when switching back and fourth between e-mail clients. I'm using maildrop to copy my incoming mail to the normal mail spool file and to a separate archive mail file for each day. So, for instance, all the mail I got on 2008/09/05 is archived in the mbox-format file ~/Inboxes/2008-09-05.inbox.

I also said, earlier

Wanderlust seems moribund.

It turns out that Wanderlust only seems moribund, especially to those who only speak English. If you check the mailing lists there's still some activity, and if you poke around on the Wanderlust site you can find a newer snapshot. Unfortunately, Wanderlust uses several other libraries (APEL, FLIM, and SEMI) and these are also hard to find much information about if you only speak English. So I've been fiddling around with it, and have figured out enough to get it working for me. (Thank goodness for the FreeBSD ports system.)

Oddly enough, although Wanderlust mostly understands MH-format mailboxes, there seems to be no built-in way to get it to read mail out of a standard mbox-format spool file and into your inbox. I guess the assumption is that if you're not using IMAP then you've probably moved on to using a maildir-format spool file, since they're supposed to be more reliable.

Well, I'm not. I'm trying to compare Wanderlust, MH-E, and Mew, and MH-E doesn't understand maildir-format mailboxes, so I have to stick to mbox-format. (Ok, I suppose I could mung things so MH-E uses Mew's incm to read the spool file.)

Moreover, I've got a fairly odd pattern of e-mail folders. For years in VM I've saved my e-mail in in separate folders with names like 2008/08/users.bond_tk or 2008/08/list.clisp, with VM defaulting the folder names automatically. I think I've mostly figured out how to do this in MH-E, Mew, and Wanderlust, and I've mostly figured out how to get the three of them to coexist peacefully, so I can really give them a good comparison. We'll see how it goes.

Like many Emacs subsystems, the Emacs e-mail clients tend to use modes with single-character commands for many things, and most the commands are just regular keys, not key combinations. I've gotten so used to this that I find using e-mail clients that require mousing to be extremely painful. Moreover, I've become very accustomed to being able to customize my e-mail client extensively using Lisp.

What it all boils down to is that I'm not happy unless my e-mail client is part of Emacs.

On the AADL site, via their Tool Integrators, Toolsets, TOPCASED pages I ran across an interesting presentation about TOPCASED, which at the beginning basically says that with the lifetime of aerospace products running as long as 10 to 30 years no company is able to commit to supporting a development tool for such a long time at an acceptable cost. (I think this was essentially explaining their motivation for developing TOPCASED as an open source project, though it's not quite explicitly stated.)

I find this very interesting, since I've worked on a number of projects that, although not in the aerospace arena, have had lifetimes vastly exceeding the expectations of anybody involved on the project. While some of the original design and development tools are still available, some are not, and replacing them, or in some cases just using the ones that are still available, can be a complicated business. For small projects, collecting all the tools under CM so as to be able rebuild any version of the project with the original tools can be prohibitively expensive when commercial software is involved. The idea of using open source tools because those will still be available in 20 or 30 years and can be supported in a cost-effective way seems reasonable, so it's interesting to see that there are a number of open source projects of this nature in aerospace, an arena known for mission critical systems.

• Cry Wolf, “An Alpha and Omega Novel”, by Patricia Briggs, copyright 2008 by Hurog, Inc.; Ace/The Berkley Publishing Group/The Penguin Group/Penguin Group (USA) Inc.; Ace mass market edition August 2008, 1st printing; ISBN-13: 978-0-441-01615-0.

  This is a spin-off from Brigg's Mercy Thompson series, and judging from the “An Alpha and Omega Novel” it's the start of a new series. I'll be looking for further volumes.

• Jhegaala, by Steven Brust, copyright 2008; Tor/Tom Doherty Associates, LLC; First Edition: July 2008, 1st printing; ISBN-13: 978-0-7653-0147-5; ISBN-10: 0-7653-0147-4.

  Visiting with an old friend is always a treat. I think I've reread the whole “Vlad Taltos” series and all the “Khaavren Romances” and Brokedown Palace within the last couple of years. (I ought ought check.) It's interesting to see how varied the “Taltos” novels are, despite mostly having one main character, how consistent the voice of the “Khaavren Romances” is, and how different from the others Brokedown Palace is. If I ever get my library out of boxes I really need to reread all his other books.

  The “Vlad Taltos” books are good individually, but even better as a whole, much like Kenneth Bulmer's “Dray Prescot” books, which I only really began to appreciate once I had the whole run and could read them in sequence.