Yesterday I wrote about four checks of mine that couldn’t fail, and ended on a policy I’d been drafting about disclosing AI assistance. This is that story, and its unexpected sequel: writing the policy exposed a hole underneath it, and closing the hole took a hardware token, a subdomain, and a surprising amount of reading about a file format from 1998. The thing I hadn’t said I contribute to a few upstream projects — packaging, bug reports, the occasional fix.
since www.micro.blog integrates it in a very easy way, this blog is now also available on Bluesky: bsky.app/profile/w…
Last time the theme was that the loudest thing is usually not the broken thing. Today’s is the quiet cousin of that: four things that were supposed to tell me something told me nothing, and did it convincingly enough that I believed them. None of them were bugs in the ordinary sense. The code did what it said. What failed was the machinery I had built to find out whether the code did what it said — which is a worse category, because wrong code eventually announces itself, while a wrong check makes you confident.
Finished reading: The Phoenix Project by Gene Kim 📚
A lot of times I could relate to the protagonists life in IT. Altogether the story was a bit to good to be true and it feels like a lot of parts are missing. Still, especially managers should read this book and even with the current cloud and AI hype it contains a lot of truths about how IT could work.
Roter Panda aka Firefox im Tierpark Nürnberg
Playmobil Land bei Nürnberg
Quasi keine Wolken über Deutschland, seit Tagen
Last time the theme was things you can’t regenerate. Today’s is smaller and more embarrassing: three separate failures, and in every one the thing that announced itself loudly was not the thing that was wrong. I lost most of a day to that. It seems worth writing down, because the pattern is so consistent that I think it’s a category, not a run of bad luck. A traceback that belonged to the test harness I had two pull requests waiting on an XMPP server package, both red in CI.
I started the day wanting one small thing: a Forgejo Action that uploads a built folder to a YunoHost my_webapp over SFTP. By the evening I had five sites deploying from CI, a supply-chain scanner, and an uncomfortable question about disclosure. That sounds like scope creep. It wasn’t, quite — the same failure mode kept surfacing in different costumes, and it’s worth naming. Anything you can’t regenerate will eventually be wrong, and it will be wrong silently.
Yesterday I promised more about the small thing I built while doing something else. Here it is. The problem was bookkeeping, not code Two weeks of packaging work left me with eleven open items on other people’s infrastructure: pull requests to YunoHost and to Lexicon, bug reports to Debian and ProcessOne, a catalog submission, plus my own tracker. Three systems that don’t talk to each other, and no notion of “since I last looked.