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.
A build running inside a chroot on this project has no network access, by design — every source tarball is fetched ahead of time and extracted locally, and nothing in the build process is supposed to reach outside the machine while a package compiles. One package's default configuration quietly assumes otherwise.
One package in this from-scratch build's KDE stack contains no compiled code at all. It's a database of hardware IDs — PCI, USB, and PNP vendor and device names — and it exists only because a different package's build script checks for a specific file at configure time, before anything about hardware detection actually matters at runtime.
The console font on this from-scratch build changed three times before it settled. Each swap had a specific, quantified reason tied to this exact monitor, not a general sense that the text was "too small."
Most of the compatibility work in this build's KDE packages involves code that compiles fine but never actually runs — dead paths behind a runtime check that always evaluates false. This one is different: two small helper programs that don't compile at all, because the graphics toolkit underneath them was never built with the one feature they need.
This system has no display manager. No login screen, no graphical prompt, nothing that starts automatically when the machine boots. KDE Plasma starts from a plain console login, by running a script by hand — and that script exists at all only because the first time someone tried starting Plasma manually, it failed with nothing to show for it.