bk99.de entertain the web since 1997

bk99.de
Own project · Administration & operationsOwn post

One month, one post a day: what October on bk99.de taught me

Summary

For October 2026 I set myself the goal of publishing one post on bk99.de every day, and with this review it came to 33 posts in 31 days. It was not easy, not even with my SoftwareSklave at my side and on top of ordinary everyday stress. Looking back, one thread runs through almost all the texts: what mattered almost always lay one level deeper than the first display, report or default setting.

The plan and reality

The plan was simple: one post every day in October, sometimes an own project, sometimes someone else's text worth reading and putting into context. The result was 12 own posts and 21 curated ones from 20 different sources, from Hacker News and LWN.net to Citizen Lab and the French online outlet Blast.

Counted honestly, though, only just over half went online on their own day. Of the 32 posts dated 1 to 30 October, 17 appeared on time, 14 later, mostly by one day, the Kolibri post even five days late, and one a day early. This review and the RIPE 93 post were only written on 1 November.

Writing the texts is not the hard part. Searching sources, drafting, building the site and uploading are done quickly by my SoftwareSklave. What costs time and energy is everything around it: finding a topic worth the day, really reading the original, checking figures, proofreading the draft and finally deciding whether it goes online as it is. Every day, alongside everything else a day brings.

The month by topic

Ten posts belong to security, five to AI, the rest are spread across DIY, networking, Linux and society. Here they all are, sorted by topic:

The common thread: one level deeper

Looking back, I notice something I had not planned while writing. Almost every post is about a point where one trusts a display, a default or a promise, although the truth lies one level below.

Status messages. An HTTP 200 can lie: my AI server answered requests that were too long with "all fine". After PHP2Shell, "update installed" is not enough; you have to check whether it really arrived. And what looked like an attack on me in the firewall log was a reflection aimed at a completely different network.

Defaults. Since version 1.24, Go opens listeners with Multipath TCP on its own, without most operators knowing. The refrigeration controllers in France were directly reachable from the internet. Out of the box, anyone on the same network can reconfigure WLED.

Trust anchors. At eMudhra, the chain broke at the certificate authority itself. With EDK II, foreign code runs before Secure Boot checks anything at all. AdFection delivers spyware to devices through ordinary ad exchanges such as Google and Yandex, and for the 333 Tor exits with Ebury it held true that on a compromised server, logs and process lists lie.

Dependencies. How dependent a provider is on its registry and bank only became clear to Autistici/Inventati when both switched off at the same time. In France, the DNS block was ready before anyone decided on it.

Numbers and promises. Torvalds' patches were 23 times faster in an artificial test and still contained a bug. The "8 GB" for FLUX only apply to the INT8 files in ComfyUI, and not all of Mark Benecke's figures survived the fact check.

The own builds show the other side: the level below is almost always within reach. A serial console via a Flipper Zero rescued the NAS, firmware rebuilt register by register turned a router into a receiver, and with the ISS a small script mattered more than the antenna.

For me, that is the lesson of this month: whoever only reads the top level believes. Whoever looks one level deeper knows. That one level is rarely hard to reach: a log, a packet capture, a serial console, the original text instead of the report about it. It only costs time, and time is exactly what is scarcest.

And what that says about AI

With AI, the top level becomes cheap. A draft is ready in minutes, a summary in seconds. That makes one post a day conceivable in the first place, but not easy, because looking one level deeper cannot be accelerated to the same extent. Sascha Friesike describes this with Polanyi's paradox and Bainbridge's ironies of automation: the more the machine does, the more depends on the knowledge of whoever checks it.

I stick with the image from my birthday post: AI is a cordless screwdriver. It turns faster than any hand, but someone still has to know where the screw belongs and whether it holds.

What you can take away

  • Do not trust a status message on its own. Check the path a real user takes, not just the green tick.
  • Write down which defaults your services come with: open protocols, factory passwords, remote access.
  • Read the original before you believe the report about the original.
  • Back up the starting state before every change, whether flash image, configuration or repository.
  • Know your dependencies: registry, certificate authority, mail provider, bank.
  • Use AI for speed, but plan time for checking. It does not get shorter just because the draft is ready sooner.
  • If you set yourself a daily rhythm, you need slack. A day late is better than an unchecked text.

Numbers at a glance

  • 33 posts in 31 days: 12 own and 21 curated from 20 different sources.
  • Ten posts belong to the main category security, five to AI and four to DIY.
  • Of 32 posts dated 1 to 30 October, 17 went online on their date, 14 later and one a day early.
  • Two posts each appeared on 16 and 27 October.
  • The Kolibri post had the largest delay: it went online five days after its date.

References

Remarks

  • This review was written on 1 November and is dated 31 October so that the month is complete.
  • Searching sources, drafts, building and uploading were done by my SoftwareSklave. Which topic appears and whether a text goes online as it is, I decided myself every day.

See all posts from 2026

Own project · 2026

6,594 emails from my servers: What 20 years of robot mail tell

While building my mail archive, I found a folder with 6,594 emails that servers I was responsible for sent me between 2004 and 2025. Logwatch reports, cron output and warnings show how my server operations changed over twenty years. This post shows what this robot mail reveals, when it became a burden and how I would approach monitoring by email today.

Own project · 2007

MRTG without SNMP: graphs from your own scripts

From 2007 on, bk99.de showed MRTG graphs of DSL, LAN, Wi-Fi, VPN, temperatures, memory and load of my machines, produced not via SNMP but by small shell scripts. I never wrote the promised guide; instead a reader shortened my script in the comments to a fraction of the program calls. This post catches up on both, explains how external scripts work and shows what has taken MRTG’s place today.

Own project · 2006

A server move in 19 hours: when my host Alturo shut down

In September 2006 United Internet announced the end of its discount hosting brand Alturo, where my server was located; all customers were given notice for 31 October. In a 19-hour session, 23 domains, a mail server, three forums and several gigabytes of data moved to a new server with a new Debian and much stricter security. This post from my old blog retells the move, shows what belonged to the toolkit at the time and what I would plan differently today.