Between August and September I built a Linux From Scratch system on my ThinkPad, scripted end to end, and took it from an empty partition to a KDE Plasma desktop that I now do my work on. Along the way I wrote up the problems one at a time, as separate articles. This is the map: the build in the order it happened, a sentence or two on each problem, and a link to the full story.
In September, my search engine had a job that kept getting slower. Once per PageRank cycle, it wrote the new authority score into every row of the url table, about 150 million rows. Right after a database upgrade, that step took 64.5 minutes. Two weeks later, one run was still going after 13.5 hours.
"Queries got slow after upgrading PostgreSQL" is a common complaint, and one of the usual causes is a step that's easy to skip because the upgrade itself already reported success. When I upgraded my search engine's database from PostgreSQL 15 to 16, the upgrade notes record that step done before any traffic was allowed back: rebuild the planner's statistics.
In July my search engine needed a queue that several servers could share: crawlers on one machine putting fetched pages in, indexers on others taking them out. The project already depended on Symfony Messenger, and a Messenger transport DSN pointing at the database was even configured on one of the servers. Reusing it looked like the obvious move.
The monitoring stack for my search engine ran Prometheus and Loki in Docker on one of the project's servers, with their ports published: 9090 for Prometheus and 3100 for Loki. The compose file still said "LAN only" next to both ports, from when the stack lived on a local network.
Articles on this site are drafted with an AI agent, Claude, working from my git history and design notes, and every draft goes through a verification pass before it's scheduled. On 15 October, an unattended pipeline run drafted and scheduled seven articles. I then checked them against the commits they were based on, and six of the seven contained a factual error.
In August, two background workers in my search engine had been crashing with PHP out-of-memory errors for about 20 hours before anyone noticed. Nothing looked wrong from the outside: docker ps showed the containers up, with a restart count of zero. What gave it away was that the whole fleet looked unusually loaded.
"Is one big query faster than many small ones?" is one of the most-viewed database questions there is, and the usual answer is "batch it". In July I batched the writes of my search engine's indexer, which cut the number of MySQL queries per indexed page roughly in half.
Until September, this site had no structured data at all: no JSON-LD, no microdata, not even Open Graph tags. I noticed because the search-appearance report in Search Console came back completely empty in two exports in a row. I added Open Graph tags and a block of JSON-LD to every article page, including publisher and mainEntityOfPage.
My search engine parsed every crawled page with PHP 8.4's new HTML5 parser, Dom\HTMLDocument::createFromString(). In July, someone pointed out that a Danish result showed its title as "Bes�g i hansestaden L�beck" instead of "Besøg i hansestaden Lübeck".