I went looking for this laptop's crontab to write a comparison with systemd timers, and there wasn't one. No crontab binary, no /etc/cron.d, no cron daemon running at all — crontab -l just says command not found.
For about a day in August, the Postgres server behind my search engine kept dying. Not slowing down, not timing out: the Linux OOM killer was terminating it, roughly every 20 to 90 minutes at the worst point, and each kill meant a crash-recovery cycle of about 90 seconds while Postgres replayed its write-ahead log.
This VPS runs three sites. Two of them — this one and carmen-crm.net — each have three nginx config files in sites-enabled. The third, fasterwebsites.net, has six.
This site's article pipeline runs unattended from a wrapper shell script, invoking a claude -p session wrapped in timeout to draft and schedule posts. One run, I decided partway through that I didn't like the direction it was taking and killed it — kill <wrapper-pid>, the process I could see in my terminal.
This site runs on a Europe/Warsaw system clock, and its automated article pipeline needed to compute a publish-time window in UTC from a plain local-time string like "2026-08-31 16:00". The obvious tool is GNU date's -u flag, which converts to UTC — except it doesn't do what that sentence implies.
This site runs on a VPS that also runs two other things I don't think about most days: carmen-crm.net and fasterwebsites.net, neither of which has anything to do with linkhub.
I keep a different password for the same service account on every environment it exists in, even on a project where I'm the only person who'll ever type any of them in. That habit paid for itself directly tonight, in a way that would have been a lot more confusing to untangle if I'd taken the obvious shortcut instead.
A cryptominer showed up on production twice in one morning. The interesting part wasn't the malware — it was how ordinary the way in turned out to be, and how many wrong turns it took to find it.
I upgraded this site from Drupal 10 to Drupal 11. The Drupal part went fine, eventually. What actually took the site down for four minutes had nothing to do with Drupal at all — it was a missing setgid bit, and I only found it because I've learned not to trust a Drupal error log to tell me the whole story.
Both tools do the same job. You describe how a machine should be configured, you keep that description in version control, and the tool makes the machine match. Most of what you learned from Puppet still applies.