As a computer programmer and user, my productivity depends primarily on my fluency with a handful of complex, powerful tools that flexibly suit many contexts alone or in combination: a family of operating systems, a package manager, a revision control system, a programming language, and a web content management system. Each of these tools has a very long learning curve, but the price is worth paying, because I expect to continue using Unix systems at work and at home indefinitely. I'm heavily invested in maximizing my efficiency on these systems over the long term.

Most of the time, though, the gains are opportunistic and incremental. And some of the time the river runs backward and it takes effort just to stand still. This weekend, for example.

Reading feeds

In the great crash of 2008, I lost my rss2email configuration and the mail server it lived on. I've been “temporarily” using Google Reader ever since. Never liked it; never did anything about it. By retiring the service in a few weeks, Google is doing me a favor: I'll finally go back to reading feeds the way I like best. In the meantime, rss2email has found a new upstream maintainer who's actively developing it. The pkgsrc package, which I maintain, trails reality by one major and several minor versions. I prepared an updated package by whacking on it with a piece of wood (I don't know Python or its conventions) until it worked, realized I couldn't commit it because the new configuration and cache are incompatible with the old, and set a plan in motion to smoothly ferry users through the upgrade. If everything goes to plan, the latest version of rss2email will arrive in pkgsrc within days of the demise of Google Reader.

Upgrading software on my desktop

I hadn't updated pkgsrc on my Mac Pro in a while. Many of the outdated packages proceeded to update without incident, but I had to exclude a few because they would produce locking errors in an infinite loop. I couldn't reproduce the problem on my MacBook Air with the same Mac OS X and Xcode. It turned out to be a libtool bug that manifests only on OS X under certain multiple-filesystem configurations. After filing the bug and applying my workaround, libtool did its job and my software upgrades completed.

Upgrading software on my server

pkgsrc-current recently got Perl 5.18.0, so I figured I'd try a full package rebuild. Everything went fine until the last package, ikiwiki, hung indefinitely while building its documentation. It almost certainly had to be the new lang/perl5's fault. I ran out of weekend to keep digging, so I posted my findings for discussion.

Nothing's been fixed

Unless I patch it, libtool still works wrong on my desktop. Unless I roll back to an older Perl, ikiwiki still doesn't build on my server. And I haven't stopped using Google Reader quite yet. But I could. (Maybe I should.)

When this sort of effort is required, why bother? The question is worth considering. I could read feeds with some other web service or native application. I could stop upgrading software from source, or stop having multiple filesystems, or maybe switch to some other package manager or operating system. I could wait for others to fix the fallout from a Perl upgrade.

But each of those options, in its own way, constitutes greater total long-term effort. If I can treat feeds like mailing lists in the tools I've already got, why should I bother with a dedicated feed reader? If I can keep my system as is and get software to build the way it used to, why should I merge my partitions? If I'm invested in pkgsrc and Perl, why should I wait for someone else to deal with them?

Even so

Sometimes computing means building cool new things, or extending existing things in fun ways, and sometimes it means this crap. But every small battle against local entropy is an obstacle removed, every obstacle removed is efficiency gained, and every bit of efficiency gained adds up over time.