After yet another mysterious Perl-related SNAFU, I decided that it’s time to say goodbye to the venerable “Blosxom” engine. As of this entry, I don’t plan to add any new entries to this blog, and I have kludged blosxom.cgi into working, however temporarily, just so that I can do one last final static HTML rendering of all the posts.

The result is that all the existing content should stay where it is, and all links should remain unbroken. I have a terrible hatred for people who break links or pull content down out of sheer laziness; as it costs very little to keep a bunch of static HTML files around, I see no reason not to do so — without the live CGI running, there’s very little security issues, and it just seems like The Right Thing To Do, on the off chance anyone finds some of my old posts useful or interesting.

Going forward, I plan to spin up a new site using Jekyll, and may in fact import all the old entries from this blog into it (making them instantly a lot less ugly, since I don’t plan to roll my own HTML and CSS this time around). However, those will end up, at least in my current plan, in a different URL namespace (perhaps /blog/ instead of /weblog/ — the latter seems a bit dated by modern standards anyway), so that all the old links will continue merrily onward until either the SDF goes down for good, or the heat death of the universe.

Anyway, if there’s anyone else out there using Blosxom in 2017… good luck. My recommendation, given modern hardware and storage capabilities combined with the hostile security environment the Web has become, is to use it as a static site generator (similar to Jekyll) rather than a live CGI with mod_rewrite as most of us start off using it originally. If you wanted to give a little nod to modern conveniences, you could certainly trigger the static regeneration via a Git hook, just like Github does with Jekyll.

When I first started this blog, the idea of a dynamic site without a database seemed pretty cool. Today, the idea of a site without a database is still cool, but I’ve become gradually less and less enthused about the idea of dynamic sites in general, largely because of the security/maintenance tradeoffs. If you don’t have time to maintain a secure dynamic site, you don’t have time to maintain a dynamic site. Static HTML, in contrast, is much easier as long as your webhost is reasonably competent.

But there’s not much compelling about Blosxom today, given that Jekyll and a variety of other static site generators exist, and have a much more robust ecosystem of themes, plugins, and documentation available.

I can’t say that Blosxom owes me anything at this point. It ran this blog for more than a decade, and that’s longer than most pieces of software ever get to exist in production.