Not much has happened on the train automation recently, or has it? “KTLO” in software engineering refers to “Keeping the Lights On,” the act of performing routine maintenance, bug fixes, and system monitoring to keep current IT infrastructure running. And I’ve had my share of it keeping me busy in the past few weeks.

Routine maintenance is all the under-appreciated work that has to be done and that people don’t notice until it is not done.

Since we’re dealing with HO trains, one of the basic maintenance tasks is track cleaning. Orion cleaned the mainline recently. The branchline automation was getting stuck in the You Bet town a few weeks ago, and I simply fixed it by cleaning the track. I also had cleaned the parking area the week before. Nothing glamorous, but here it keeps the train lights on, literally.

On the IT side, I’ve spent the week updating all the Debian Linux computers. That’s all work I do remotely. There are 4 Linux computers I need to maintain for the model railroad, plus the Windows one for the Earthquake Exhibit. My strategy for the model railroad computers is very simple: I’m extremely conservative. They don’t need to have the latest version of Debian as long as they have all the security updates. And I don’t update them directly -- I first update my home computers, which happen to (unsurprisingly) have almost the same setup as what I installed at the museum. In this case, I wanted to upgrade the entire OS from one old major revision to a newer one. So I do all this work at home first, then once I know what to expect, I can do it at Randall. This takes more time yet it ensures the upgrade process is as seamless as possible and essentially invisible with no side effects. The model railroad computers were running Debian 11 (codename “bullseye”) and Debian 12 (codename “bookworm”) and I’m updating them to the latest Debian 13 (codename “trixie”) one by one. Unlike Windows or MacOS upgrades, these are fairly straightforward full upgrades, as long as they are planned carefully.

The only exception is the main automation computer. That one still runs an even older version of Debian 10 (codename “buster”) and I’m not going to update it at all. That’s because the automation software is stuck using an older version of JMRI 4 with Open JDK 11 and Kotlin 1.6. The problem is that Kotlin 1.6 is deprecated, but JMRI 4 does not work with the latest Kotlin 2.1 with the way I’m using it. Instead, my strategy is different: I got a replacement computer on which I have installed Debian 13, and I’m going to first fix the Kotlin / JMRI incompatibility, then update my automation software to work with it, and finally I’ll have a full new hardware replacement, all setup with up-to-date versions from scratch. That’s unfortunately a bit more work than I expected, and it will happen at a slower pace. But once I’m done, I’ll be able to swap the computers seamlessly, and nobody will notice the change, nor even realize it took 10 months of work to make it happen. That’s the essence of KTLO.