Technology Stir Fry, the blog

I have been writing here (or on the predecessor site) since 1996. That means that at the time of writing in 2018, some of that content is over twenty years old. If your reaction to that statement is “that’s plenty of time for something to break” then your instincts are perfectly sound.

It has been a month now since I finished my Nanoc conversion work, and it’s pretty obvious from the chart below that the performance improvements I expected from converting to a static site are real, and are here to stay.

The chart is from Google’s search crawler, so it doesn’t represent real human usage, but the dramatic lowering of the access times since the beginning of February is undeniable. Previously, if you got unlucky, you might have waited more than a second for even one of my pearls of wisdom. Now the most banal observations might be available in mere milliseconds.

I’ve been using rsync to build my site as a combination of a base layer held in git plus an overlay generated using Nanoc. Here’s how.

This site is going all-HTTPS, all the time. Read on for background and details.

[2018-03-11: HSTS implemented with max-age=1800, i.e., 30 minutes.]

[2018-04-16: HSTS implemented with max-age=31536000, i.e., one year.]

I have completed the migration work started back in December. As a result, this site is now entirely constructed using the Nanoc static-site generator, and the Drupal content management system has been retired.

If you’re reading this through a feed reader like Feedly, please drop me a line to let me know that the new feeds are working.

Continue reading for some thoughts on the process and on the results.

One thing I’ve wanted to do for a long time is move this site further towards the use of clean URLs. I am currently migrating to a static-site generator and that seemed like the ideal time. Here are a couple of tricks I’ve used to get clean URLs for my older content without breaking bookmarks.

I started using Drupal to manage most of this site a little under six years ago. That wasn’t a mistake — it solved the problems I wanted to solve at the time — but it hasn’t been an unqualified success either. It’s time to move on to the next thing, which for me looks like Nanoc, a static-site generator written in Ruby.

I am pretty paranoid about data loss. Locally, my Macs all use Time Machine, the servers all have RAID of some kind, and virtual machines are regularly backed up using Bacula. Local backup is not enough, though, so most of this is also backed up to the cloud. Unfortunately, the cloud service I’ve been using for the last few years has just been discontinued, so it’s time to pick something new.

I’ve been working on a large XML processing system in which a sequence of steps implemented in Java and other technologies are orchestrated using Apache Ant. It has to run on Mac OS, Linux and Windows. It has been pretty stable for some time, but I recently set up a new Windows system and started seeing errors like this:

Exception in thread "main" org.xml.sax.SAXParseException:
    Invalid byte 3 of 3-byte UTF-8 sequence.

The key ceremony for the REEP service took place on 2014-05-18 after the REFEDS meeting in Dublin, Ireland.

I witnessed this ceremony and was convinced that the key attached to this post as a self-signed X.509 certificate was generated during the ceremony within the hardware security module in Sweden that will be used by the REEP service to sign metadata served by it. To certify this, I have generated a detached signature file for reep.pem using my PGP key.

To the extent that you trust me to have taken care while witnessing the ceremony, you may find that validating my signature on reep.pem gives you some comfort that metadata documents signed by the private key associated with reep.pem are, indeed, legitimate outputs of the REEP service.

As an aside about the ceremony itself, proof that a particular computational event has occurred in a particular way is almost impossible in a world of networking and virtual machines. We’ve known this for a long time: the paranoia goes back at least as far as Ken Thomson’s Reflections on Trusting Trust. We’re not quite living in The Matrix, but the evidence of ones senses doesn’t really go very far towards absolute proof. So what the other witnesses and I did during the ceremony — all we could do, really — was gain confidence by asking questions, taking photographs of the steps and trying to think of ways to validate them. For example, I was later able to verify that the pkcs11-tool command being used was indeed the one which would be installed on a system running 64-bit Ubuntu 12.04. Unless, of course, Leif foresaw that trick and subverted the md5sum command as well. It’s turtles all the way down.