Linux From Scratch builds coreutils with an extra patch, the i18n patch, which adds multibyte character support to tools like cut and expand. In my scripted LFS build, applying that one patch took four rounds of fixes spread over eleven days.
CaRMen's backend container builds its Docker image from a Dockerfile that runs composer install during the build, so the image ships with a real, populated /app/vendor baked in.
CaRMen, my CRM, runs on a single VPS as two instances: the real one and a public demo. In October, I gave it a deploy script that can undo itself when a new version doesn't come up, including, when it has to, the database. The database is the interesting part.
CaRMen's customer section used to be split across two controllers for no particular reason: CustomerController owned the list and detail pages, and a generic WebController owned the "add new customer" form, declared as its own route:
#[Route('/customer/add', name: 'customer_add')]
CaRMen didn't have a setup flow for most of its life. Getting a fresh instance running meant running migrations by hand and inserting the first admin user directly through a database client — fine for a one-person project, less fine the moment I wanted to hand someone else a copy of the app without also handing them a shell.
When I moved CaRMen's Playwright tests into GitHub Actions, every login test failed. Partway through each test, the login page redirected to the first-run installer, as if the database were empty. It wasn't. The PHP backend wasn't looking at the database the job had set up at all, because it never saw the environment variables that pointed to it.
The very first Doctrine migration in CaRMen's history — the one that creates the user and messenger_messages tables — was auto-generated against MySQL and never meant to run anywhere else. For a stretch of 2025 it had to run against SQLite too, because the test suite used SQLite while the actual migrations were written for MySQL.
In August, a page from a small Danish website turned up on the "recently indexed" admin page of my search engine. That site's robots.txt is two lines long and couldn't be clearer:
A CPU isolation setting sat unchanged for weeks, explicitly documented as deliberately left alone to avoid destabilizing a live system. When it finally got measured instead of just trusted, the setting turned out to be backwards — giving unrestricted access to the exact processes it was supposed to be isolated from, while pinning the processes causing the contention to almost nothing.
When I switched this site's outgoing mail from a missing local sendmail to proper SMTP submission on my own mail server, the first test send failed. Authentication worked, STARTTLS worked, and then the server rejected the recipient:
450 4.2.0 <...>: Recipient address rejected: Greylisted