Today I shut down arnold.sabi.net for good.¹ It’s just a computer, but I’m strangely emotional about it.

I first wrote in March 2003 about buying arnold on eBay. A generous friend has been hosting arnold for free at his residence since then—first about a mile away in Champaign, then moving in July 2003 to Virginia where it’s been ever since. It’s served me well with no hardware failures until some ECC errors prodded me into moving the last service (dynamic DNS) off it yesterday.

As I mentioned back in September, I’ve been working on reducing my administrative load. I’m now nearly finished migrating services, but two aging machines—calamity and shrug—remain to be decommissioned.

I’ve mentioned calamity a few times over the years; it predates arnold by a couple of years, having ably served as my parents’ DNS, email, Web, VPN and monitoring server. There’ve been no hardware failures, though I’ve upgraded the hard drives and SCSI card once and switched the backup medium from xfsdump on an external MO drive to the network via Bacula. I moved the email and Web services off a few months ago; when I swap the Mac mini for my old G4 in a few months, I’ll have a slightly newer machine to host its remaining services. (You can see calamity on the right in this photo from May 2006, to the left of hamton, a hand-me-down PC which died before it could be put to any use.)

shrug (which is not a Tiny Toon Adventures character; blame doomsey) is a P3/700 still running FreeBSD 4.11. It hosts my primary email environment, which has had a long and varied history.

In the 90s, I read mail in a bunch of places—some via Eudora and POP, some via Unix mailreaders including pine, mutt and (ex)mh. My accounts included tiac.net, netcom.com, macirc.com, three Brandeis accounts, online service Internet gateways (CompuServe, AOL, eWorld, BIX and Delphi at various times) and some others I’d rather not mention. Over time, I reduced the number of accounts I checked to three, for personal, school and work use. My “forever” personal email address was nriley@shore.net, served by a small ISP in Massachusetts. Mail for school lived on students.uiuc.edu until November 1999, then griffin.canis.uiuc.edu until January 2001.

sabi.net was served starting in mid-1999 by alexandria.invantage.com, an old 486DX2/66 in the corner at my then-employer. (My old reliable USR Courier in that picture was a fallback for our flaky RADSL connection.) At the time I didn’t use sabi.net much for email; my sabi.net mail, what little of it there was, forwarded to my shore.net account. Eventually, Shore.Net got bought and destroyed; I learned the lesson that I should never rely on someone else’s domain name for my email.

Since I was switching labs at the time I didn’t have a server at school to use, but luckily I could borrow Invantage’s new colocated server for a few months. chronos.invantage.com thus became sabi.net’s MX in January 2001. chronos also hosted my first truly consolidated email setup, with procmail and Mutt folder-hooks configured to deliver mail from three accounts into separate inboxes: invantage.com (the mailspool, i.e., !), uiuc.edu (=INBOX) and sabi.net (=+/INBOX). I dumped my Shore.Net account in March and switched sabi.net’s MX to pair.com in August 2001, where it remains. pair is still around, still independent, still conservative and reliable; its CEO still posts in the newsgroups. I plan to keep my account there for the foreseeable future.

With sabi.net’s MX switched, I could finally migrate my email setup from chronos, moving it to theremin.cs.uiuc.edu and finally to shrug.csl.uiuc.edu (later shrug.acm.uiuc.edu) in September 2003. On shrug I added an IMAP server and several generations of spam and virus filtering. I’ll be moving off shrug over the next few weeks to a similar setup where I won’t be the machine’s primary administrator. (shrug was originally like that, too, but its owner graduated and left maintenance to me.)

Planning and executing these migrations is tedious and mind-numbing, so I’m glad they’re coming to a close along with graduate school; I’ll have more time in future to focus on things I really care about. Another good thing about getting rid of machines is that I don’t need to come up with a new naming scheme as I thought I would. My laptops since then have all been named Shirley; my Intel iMac is Mary.

¹Actually, runlevel 6 reboots; I’ve still got to wipe the disks.

1.4njr3, released on November 5, fixes some graphical rounding issues reported by Andy Reitz; the times were displayed as 3:01, 2:00, 2:59, etc. I was really surprised I never noticed this myself.

1.4njr4 shows the break window in all Spaces on Leopard; of course you could do this with the Spaces preference pane, but doing so by default makes sense. It also stops AntiRSI from getting focus when you hit the “Postpone” button (Cocoa’s API for this is…interesting). Or, if you have AntiRSI set to force itself to the front during breaks, it’ll bring your previous app to the front when the break is finished so you can resume work.

I’ve made some Spaces-related changes for Pester, too, and will try to get beta 8 released one of these days. Happily, my research is going really well at the moment and I don’t want to disturb my focus.

Download AntiRSI 1.4njr4 here, or just use the “Check for Updates…” item in the AntiRSI menu if you’ve already got my version of AntiRSI installed.

For various reasons I didn’t pick Pester back up until this weekend, because NSDateFormatter broke natural language date parsing for Pester 1.0 in Leopard. Pester 1.0–1.1b4 ran on Mac OS X 10.1 or later; Pester 1.1b5 requires Mac OS X 10.4 or later. It was a bit sad to rip out painstakingly developed workarounds for old Cocoa date parsing bugs, but good to see that the new ICU-based formatters basically work, even if they completely lack any natural language parsing ability.

In an effort to get something usable on Leopard released, this version has some features disabled because they aren’t stable enough yet (QuickTime playback, speech), don’t work at all (dock bouncing) or are untested (wake from sleep). The user interface is still mostly what I came up with back in November 2002 (wow, Jaguar really was that ugly).

Among the changes that aren’t from 2003 are my first use of Sparkle:

Subsequent updates should therefore be simple.

Back to the reason for this update: NSDateFormatter in pre-10.4 mode used to understand “tomorrow”; in Leopard, it doesn’t, despite being documented as doing so.
There seems to be a severe lack of open source libraries for natural language date parsing—all I found was chronic (Ruby, English only); jchronic (Java port of chronic, English only) and Date::Manip (Perl, multilanguage).

I chose Date::Manip.

Yes, this means Pester now embeds a Perl interpreter.

Perl’s embedding API is interesting, but it works, and aside from the memory usage, nobody has to know. I don’t actually have non-English parsing in this version yet, because I ran into some weird bugs in Date::Manip; I’ve emailed the author but haven’t heard back yet.

I’m otherwise in the middle of the final work for my PhD, so I can’t guarantee 1.1 final will come out soon, but I think it’ll be less than 4 years!

Still remaining in the great server migration: moving rileys.us, mail.rileys.us and dev.sabi.net from their current locations on arnold.sabi.net, calamity.bos.sabi.net and gilford.textdrive.com, respectively. It’ll be great when I have consolidated and don’t have to play sysadmin quite so much.

If you’re missing frequent posts and are interested in the minutiae of my life, feel free to watch Twitter and Flickr. As I’m wrapping up writing and getting back to research coding again, you’ll find lots of complaints about broken software in the near future, I’m sure. (Currently I’m fighting with JPackage; why oh why must the CS department have standardized on Red Hat?)

However, AntiRSI had some problems. The animated progress bar displayed during breaks sucked CPU like crazy, causing problems if I was watching a video at the time. Breaks kept getting prematurely reset because AntiRSI thought I was typing when it was a program like VLC calling UpdateSystemActivity, trying to avoid triggering the screensaver. Finally, the break window was just plain ugly—look at those poorly antialiased corners.

The last problem was more of a missing feature. While programming, I spend enough time thinking that I’m generally pain-free even if I work all day; unfortunately, debugging, writing and system administration can be much more typing-intensive, so I have to limit my daily typing time in aggregate, but AntiRSI didn’t keep track of it.

Over the past few years I’ve fixed these issues, and since my previous emails offering patches have gone unanswered, thought the result might be useful to others: download AntiRSI 1.4njr2 if you’re interested.

Some screenshots:

If you have a Mac and don’t like AntiRSI, try Time Out: it’s much more customizable, but takes over the entire screen, making it unusable for me. According to a VersionTracker review, it also hogs CPU during breaks.

For Windows and X11, check out Workrave; it’s great, includes a session timer and even comes with network support if you use multiple computers.

First, some background. Since version 1.4, ICeCoffEE has let you hide items in contextual Services menus. Peter Hosey covers the feature nicely here.

Service menu items can be localized, like almost everything else in Mac OS X. The service provider apps include one or more language translations for their item names. The user configures a list of languages in order of preference in the International System Preferences. And the service-invoking application—the one from which you pull down or pop up the Services menu—also has a list of languages in which its user interface is localized.

Mac OS X makes the (sensible) choice that the service-invoking application’s user interface language dictates the language of all text in that application. But the fact that we’re dealing with ordered lists of languages, rather than individual languages, makes things a bit more complicated. Let’s take an example:

Your user interface language preferences are, in order, Japanese, German and English.

(Those also happen to be the languages I understand in ascending order of proficiency, with a gigantic gap between Japanese and German.)

Service menu item A has Japanese, German and English localizations. Item B has only German and English.

Say the app you’re running has only an English localization. Items A and B both appear in English.

What if your app has a Japanese localization? Item A appears in Japanese, but item B appears in German, even if the app has no German localization.

I’m guessing (have not completely verified) that OS X picks a list of potential service menu item languages by looking at the user’s preferred language list, starting with the user interface language of the current application.

What’s the bug? ICeCoffEE’s configuration sheet is hosted in System Preferences. When looking for a list of filter-able services, ICeCoffEE asks System Preferences for its Services menu and saves your choices according to the displayed item text. See for yourself:

% defaults read net.sabi.icecoffee ICServiceOptions
{
    ChineseTextConverter = {ICServiceHidden = 1; };
    "CocoaMySQL-SBG" = {ICServiceHidden = 1; };
    "Define in OmniDictionary" = {ICServiceHidden = 1; };
[...]

I did this because it seemed to be a WYSIWYG method of filtering, but it means that the user interface language of System Preferences influences what service names you see. If an item is also localized in a different language, it won’t get hidden.

I’ve never received a report of this bug. However, if it affects you, I can suggest two workarounds.

1. Edit the preferences property list yourself. The format is pretty simple, but I don’t recommend this. If you break it, you get to keep both pieces.
2. For every user interface language you use, launch System Preferences with that language at the top of the preferred list, and select the localized service names for that language in ICeCoffEE’s preferences. This assumes, of course, that System Preferences is localized in every language for which a service item you want to hide is localized. At worst, you will end up with something like this, where ICeCoffEE’s interface is in German and the service names are in Japanese:

   

   (Sharp-eyed people may notice two changes in the screenshot above, which hint at features coming in ICeCoffEE 1.5

I plan to fix the bug by doing something like option 2, adding the text of every available service menu item localization to the ignore list. It makes things more complicated because I currently store hidden services hierarchically, such that if you disable the submenu, everything inside it goes away; however, it’s possible that different localizations of service names will have different submenu structures. (Yuck.) This method also breaks if a newer version of an application adds a service name localization, but simply opening and closing the ICeCoffEE configuration sheet should fix that problem.

There are other ways I could handle this. I could store the bits used to define a service (NSMessage, NSPortName, etc.) but that would mean a lot more work to do when filtering the service list without scanning the disk as Service Scrubber does. Or I could canonicalize to English before filtering, which conflicts with applications that have no English localization, or applications like Monolingual which delete localizations—although deleting English is often unsafe because it’s the ultimate “fallback” language.

One issue that bugs me is that, after connecting my iPod, I must update podcasts then update the iPod again in order for the already-listened episodes to disappear from the iPod. While the play counts update on the first, automatic iPod sync, the associated action (removing the corresponding episodes) doesn’t happen until you do another podcast update.

Another issue is the update timeout—after a few days if you haven’t played an episode of a podcast, it’ll stop updating. For people like my father who abandon their iPod for months at a time (hi, Dad!) it is a great bandwidth-conserving idea, but for me, with video podcasts and a non-video iPod, I like to accumulate episodes to watch when I’m exercising at home.

One of Doug’s AppleScripts for iTunes handily solves the second issue, and I’ve written a script to deal with the first. iTunes doesn’t let you query its iPod update status, so I instead wait for iTunes to unmount the iPod. I found this script which periodically checks the iPod disk space usage, but it fails for me, probably because iSync takes a long time to often do nothing.

Embedding this bash script into AppleScript was a real pain, what with do shell script’s many and varied limitations, as I had to remove line breaks, indentation, my use of extended globs and even the while loop, because iTunes failed to finish updating the iPod while the script was executing. I think I will be checking out the newly revived PyOSA so I can do all this in Python instead.

Download the AppleScript, unzip it and place it in ~/Library/iTunes/Scripts.

(Note: this script is only tested on my Mac with my 3G FireWire-connected iPod; it definitely won’t work if you have iPod disk mode turned on, and may not work on other configurations.)

2007 is a year a lot of things will be changing for me, and I hereby resolve to try my hardest to make sure the transition is a smooth one.

Happy new year, everyone; may this year be better than last.

Let’s see, this one is on clearance because its battery lasts 2 weeks.

This one seems to give a lot of false alarms, and has a rather humorous review attached.

Reviewer: A Kitchen & Housewares enthusiast
This is not and I repeat is not a good alarm. There is one alarm light and you can hardly tell which one is sounding. It looks as if the specs are lying to me and I hate lies. Also the battery died after 6-8 months. The low battery alert is loud and chirps so anoyingly. I also noticed that the alarm sounds a loud shrieking alarm when it sounds. I will return this alarm. Never again will I trust in First Alert!

It also makes me wish I never meet a “kitchen and housewares enthusiast” in person.

This one goes off when you try to use an infrared remote control. The detector goes in the hallway behind my stereo, so that one’s out.

Finally, I give up on Amazon.com and do a Google search. I eventually stumble upon the Firex 12000, which has such useful features as a mute button that actually mutes for longer than you hold it down, an alarm that starts out quiet, a battery that’s easy to replace, and an industrial design that looks vaguely like someone cared. It’s AC/DC so I don’t have to replace batteries every 6 months, and even communicates over the power line with other units of its type. I read prior ones have freaked out after 4–6 years, but I plan to be gone by then.

A bonus review (for a CO-only alarm). The username is a nice touch.

• Fonts: inconsistencies between rendering paths, bad support for bitmaps (I still can’t use my favorite font in BBEdit), ATSServer hangs/crashes, silent refusal to activate, font cache corruption, worthless Font Book interface, etc.
• Disks/filesystems: HFS+ slowness, Spotlight flakiness. AFP instability, slowness and complete inability to handle concurrent accesses. Disk Arbitration flakiness. Disk imaging instability and yet more flakiness. Flaky network browsing. Still no LVM. ZFS on OS X can’t come too soon—it’s been a joy to use on Solaris.
• USB: crashy drivers (less so of late), poor transfer throughput, overly aggressive port deactivation and poor feedback when something appears to go wrong. Some of these problems might be hardware—this Intel mini doesn’t work with my external USB 2 enclosure, whereas my iBook worked fine.
• Finder (need I say more?)

Today alone I spent about an hour troubleshooting font problems. First I spent about four reboots trying, and eventually failing, to get the fonts in ~/Library/Fonts to activate. No amount of font cache trashing or safe booting fixed it; I eventually just renamed the folder and told FontExplorer X to import them, at which point everything worked… until half an hour later when Camino hung then Terminal hung (as did every other app I tried, such as Dock and LaunchBar). Turned out ATSServer was using 100% CPU in some C++ destructor. I had to SSH in from another machine to kill ATSServer, at which point everything started working again. Guess I should be glad that it worked, or something.

I wonder how bad the underlying code really is, and pray it’ll get some attention in Leopard.