Sunday, April 19, 2026

A Few More Words about LLMs for Coding

One of the clear and present dangers to LLM coding is to produce a codebase which can only be operated on by LLMs. Shall we be so eager to have the corporations make us an offer we can’t refuse?

Sunday, April 12, 2026

Server Management: We Should Be Able to Recreate Pets, Too

For anyone not familiar with the analogy, there are two types of server or private instance: “cattle” exist en masse and have names like atl-prod3-24.  If one has problems, the first solution is replacement.  “Pets,” on the other hand, are unique instances that matter a lot, often with whimsical names.  Problems with pets are approached by working to cure what ails them.

Once upon a time, we had a single pet server which was our bastion host, cron job runner, and SFTP file-exchange point with third parties.  We split those roles apart; the cron jobs get access to the SFTP files (for input or output) by sharing an EFS mount.  The SFTP machine everyone uses can be firewalled off from the rest of our codebase and AWS resources.  (Not that I expected 0days, but there was a notable close call a couple of years after this split was made.)

After a couple of Debian upgrades, the SFTP host had some network issues.  Investigation found a post putting the blame on ‘the image builder’ and telling the person with the question (my same question, unfortunately) that because of that, they were on their own.

It seems likely, then, that we’ll want to rebuild this pet from scratch at some point.  I fixed everything this time, but who knows what might happen on the next upgrade?  It seems like it would be far more stable if we could re-customize a clean base image, instead of doing a series of in-place upgrades.  This is especially true if each Debian upgrade isn’t prepared for anything that is specific to the Debian AWS cloud images.

A long aside about the networking problems I faced follows.

Sunday, April 5, 2026

systemd took my VPS offline for five days

systemd's randomized device names changed, so enp0s3 no longer matched enp0s4, and the network didn't come up.  It took me a bit to notice, hence the five days.  I don't even know if it's a problem with a new kernel or if the provider's virtio_net configuration changed, because journalctl basically locks up when trying to look three or more boots back.  Alas!

It took so long to notice because of spam, more or less. I normally look at mail on my phone and respond (if not urgent) from the desktop, but under siege by a 1:40 ham-to-spam ratio, I quit looking at my phone. Unfortunately, I'm also out of the habit of opening Thunderbird unprompted on the desktop.