On 2026-09-12 I rescheduled 38 articles on this site with a single SQL statement. The JSON:API showed the new schedule straight away, and it kept showing it for 17 days. The Scheduler module, which is the thing that actually publishes them, never saw the change. It kept publishing on the old schedule the whole time.
A lot of the articles on this site over the last months have come out of one project: a web search engine I'm building from scratch.
My search engine has an admin page, /admin/host-space, where I can mark a whole host for eviction: every URL from that host gets dropped from the corpus on the next eviction cycle. I shipped it on 2026-09-13.
A query written to handle "a host's uncrawled pages" ran fine against every host in the corpus except one. That one host had six times as many uncrawled pages as the next largest, and a query shaped around the assumption of an ordinary-sized host turned a routine operation into a hundred-second stall.
My from-scratch Linux build boots into a KDE Plasma desktop now, and for a while it booted into one with a strange set of problems. Wi-Fi scans in NetworkManager didn't work. Power management didn't work. Login sessions weren't being registered properly. Three subsystems with nothing obvious in common, all broken at once.
A slow query got fixed with a rewrite — 8.1x faster, same result set, verified row for row. The more obvious fix, the one that would have addressed the actual physical reason the query was slow in the first place, got rejected. Not out of caution. Because it was measured first, and the measurement said no.
This site has had an llms.txt file since 2026-08-29. I've written about it twice already: once about the first version being robots.txt with a different filename, and once about AEO and GEO making the same mistake at industry scale.
Two different graph databases got evaluated for the same search engine, three weeks apart, by way of two completely independent efforts. Neither one made it into production. The second attempt's own closing writeup ends up explaining, cleanly, why the first one never had a chance either — even though nobody set out to prove that when either evaluation started.
A graph-database extension got installed, tested, proven correct, and kept running for two weeks on the explicit reasoning that it might be useful later. Then it got removed entirely — not because anything about it was broken, but because two weeks of not needing it turned out to be the actual answer to whether it was worth keeping.
Loading data into a graph database usually means writing it in the graph database's own query language. For one real workload — 388 million edges — that turned out to be the one approach guaranteed not to finish. The fix wasn't a tuning flag or a bigger machine. It was skipping the query language entirely.