It has been brought to my attention that the Atom feed for this site was very poorly formatted. If you read my twaddle using this feed, you’ll be pleased to know that the problem has now been fixed.

I’ve also added an RSS 2.0 feed feed, should anyone prefer or need that.

Update: This site no longer uses Movable Type, so there’s a new URL for the RSS 2.0 feed. An Atom feed is no longer offered.

In the absence of female distraction, I took the opportunity in recent weeks to upgrade all of the machines in the house to Fedora 7, including the MythTV box.

A couple of years ago, with a few weeks still to go before the birth of Eloïse, I took advantage of the calm before the storm to move my domain to dedicated hosting at managed.com. Unfortunately, and as I’ve documented in the past, that company turned out to be less than dedicated, so after a year, caliban.org ended up back in our cellar, hosted over a domestic DSL line.

With the girls out of the country for a while, the time was ripe to move the domain back out to dedicated hosting. The DSL line has been incredibly reliable, but there’s always the chance that it will go on the blink while we’re travelling. Moving house would also automatically mean downtime, which is out of the question when one is responsible for one’s own domain e-mail. Downtime means lots of bounced e-mail, not to mention an unreachable Web site.

I’d done my homework before the girls left for their trip, so with the new contract signed, the slow process of copying all of our files over the slow upstream DSL link to the new server began. The process wouldn’t be completed until approximately ten days later.

As you read this, all services have been migrated to the new machine (and have been for over a week).

For you, the user, there shouldn’t be much noticeable difference, except that browsing our photo gallery should be considerably faster than before. For me, however, it’s nice to know that the continuity of our e-mail and Web site is no longer tied to our home DSL being up.

Some time ago, I turned off the ability of unauthenticated users to comment on entries made to this blog. Registered TypeKey users could still comment, but apparently it was too much trouble for a lot of people to register with this service. After all, who cares about being able to comment on what I say?

Well, in case you do care, I’ve now switched unauthenticated commenting back on and moved to a CAPTCHA-based scheme for distinguishing between human and automated users. If you want to comment on an entry now, you just have to answer a simple question with a one word answer and your comment will be accepted for publication.

Note, however, that if you are a registered TypeKey user, nothing changes. You can continue to post comments as an authenticated user without having to jump through any hoops.

The migration of our blog data from Berkeley DB to MySQL is now complete and the performance of the site has, as expected, improved somewhat. By how much depends on what you’re doing: reading, commenting, searching, etc.

I’m sure I’ll find a few minor residual glitches here and there over the next few days, but the major work is now complete.

Even though it was a slow and painful process (and one I said I wouldn’t bother to endure), I moved the blog over to the latest Movable Type templates in the course of yesterday.

The hardest part was getting the three column look that I favour to work properly. Even though Movable Type’s styles-site.css stylesheet contains styles whose name suggest that everything should just fall into place, that’s not the case; or, at least, not for me, as I don’t know how to apply them properly.

In fact, whilst Movable Type’s site is definitely not short on reasons why you should upgrade to the latest version, it falls down on telling you how to actually do so. All of the instructions are aimed at first-time installers. The only upgrade instructions refer to migrating from the standard version to the Enterprise product.

Apart from twiddling with the stylesheet, the biggest debugging headache was trying to figure out why the archives wouldn’t rebuild. Apache kept returning HTTP 500 errors. I debugged this by removing chunks of MT tags from the archive templates until they could successfully be rebuilt.

However, once I’d found what I thought was the culprit, starting afresh with an archive template and removing just that one tag no longer fixed the build problem. It was starting to seem as if the quantity of MT tags, not the type, was the issue.

I suspected some kind of time-out problem, possibly with mod_fcgid, so I turned to Google and eventually came across documentation that mentioned the IPCCommTimeout configuration directive. This controls the time-out when waiting for a response from a fastcgi application. Since the archive build process takes longer than this directive’s default setting of 20 seconds, mod_fcgid abandons the task, causing Apache to return an internal server error.

Simple, once you’ve localised the problem, but it was actually quite a bit of work to turn that up.

The next step will likely be to move the blog’s data from Berkeley DB files to MySQL, which should considerably improve its performance.