Rebooting The Standard Screen

Collin McKinley - 2026-04-24

So... This is a long time coming... For the past year or so, my blog has been quite empty. Then after I updated my system (which was very long overdue), it finally broke. This is a bit of a postmortem retrospective on running it and a hard reboot that I will (hopefully) write more for.

Background and Context

I hosted The Standard Screen as a WordPress blog since about 2022. Before that time, I had rolled my own CMS that I wrote in my failed language Blæst. This old system was absolutely awful. It was effectively a static site generator which took am markdown file and tried its best to produce a valid HTML output. It didn't work very well... Just this hassle of having to fight with the site generator (or more likely, rewrite huge portions of it just to get valid markdown to compile) caused me to write nothing other than the announcement post that I was starting a blog...

Eventually I moved to WordPress since it is a much nicer system (that more importantly I wasn't responsible for developing). All I had to do was set up the basic PHP dependencies (most of which I already had preinstalled because my site made extensive use of PHP at the time) and manage a very basic database. At the time this seemed like a total win, then I realized how much hell it is to actually manage and upkeep software this large.

Spam and Updates

Since WordPress is very highly deployed, very powerful, and almost infinitely extensible, it has become a massive target for bots and script-kiddies alike. This basically meant that now I had a massive target on my server, and I'm not sure if it correlates (or if its more or less a consequence of the rise of AI), but the amount of spam bots probing my server increased dramatically. This would also mean that I had to be very attentive to updating WordPress so I wouldn't end up with a massive zero day vulnerability.

While this sounds like it should be no big deal, updating wordpress was actually more of a pain than you'd expect. Each update tended to break something, and if it didn't, would screw up some permission on my web server. Now I take responsibility for most of this because I think I was hosting WordPress in a very non-standard way, but this still was more work that I really wanted to put in when writing a blog post.

Eventually I rewrote my main website to remove all but one dependency on PHP, thus making updating WordPress that much more of a pain. It was always easy before since its dependencies were used elsewhere on my site. After this point, it was just effectively me maintaining legacy software I had no intention of continuing to use. All of this while spambots were spamming the hell out of my server and WordPress zero days were continuing to be published.

Eventually I finally migrated off of Debian oldstable and onto Debian stable and WordPress broke for the last time. Since I was way too busy to fix it, it stayed broken until I replaced it with this...

So what's going to change this time?

Before we begin, I'd like to talk about the idea of a "complexity budget". This concept was introduced to me by Olin Shivers, who I've had the pleasure of studying under. The idea is very simple: we all have a finite amount of complexity we can manage in a project, and managing that complexity is paramount to actually delivering a product. Effectively, you can take some or leave some, but you can't have it both ways. When I wrote my own CMS, I spent most of the time writing the CMS and not much time at all actually writing blog posts with it, hence the complexity budget was skewed more towards the CMS. The CMS was a very complex piece of software after all. When I moved to WordPress the split was more manageable, but it was still skewed large enough that managing the underlying system took up more of my time than writing content for it.

So for this time, I'm going back to basics. The blog will be written in HTML, in Emacs, and pushed onto my plain old web server with nothing underpinning it. HTML was always a language I misunderstood because I spent so much time writing really bad websites with <div>s wrapped inside of <div>s because I equated writing HTML to writing front end app code. The minute I realized that writing HTML is more akin to writing LaTeX, or even just a simple Microsoft Word document, my entire viewpoint changed. This blog post was written by hand in Emacs, and it easily took less effort than writing it in WordPress' editor, and far less effort than fighting with my horrible compiler and CMS to get it to parse correctly. Likewise, writing in just HTML gives me unparalleled freedom to switch up how I host my website, where I host it, and what I host it on. When I was using WordPress, I was beholden to having a web server which ran PHP, which typically means Apache 2 or nginx (and pretty much only means Apache 2 since nginx's PHP support is a hack at best). Now I could totally run this blog off of an ESP-32 that is running a simple web server that I stash in the ceiling of my local coffee shop.

What should you take away from this?

Simple. Keep it simple stupid. It is so much simpler to keep a template of a basic HTML blog post and flesh it out with your content than it is to manage a system which effectively does that for you. The complex task of writing a blog post should be writing the post after all. This idea goes for any website or written content. The minute you find yourself using something that takes away time from you actually producing the content you were expecting to produce, you are overrunning your complexity budget.

This solution might not scale for everyone. For example, if you are a large company, and you plan on posting a blog post every day, and these posts will be written by laypeople who do not know HTML, you may want to use something like WordPress. In this case, the complexity cost of managing WordPress would be much less than having to coordinate with many people about HTML best practices and make sure everyone is on the same page. Ultimately though, a blog is about writing. Anything standing in the way of you writing means its getting in the way of your blog. Keep your complexity budget in mind when doing anything with your website. You'll thank me later.