Dev Diary 2020-07-06

Every time I learn about another thing that systemd does now (besides being an init system), I wonder how things could have been different. A more permissive license (to get the BSDs on-board), memory-safe language use, an approach that allowed better forward-compatibility. I walked miles while rolling this around in my head.

What got me thinking about systemd again was a little foray into the Fedora 33 changes and seeing that systemd-resolved is going to be enabled by default. This is not totally a surprise - it’s been around for years, but as someone who remembers when systemd first came on the scene as an init system, it’s still weird. Just when I feel like I’ve finally started identifying the higher level problem, I find a blog post that nails the problem so totally. “Technology Holy Wars are a Coordination Problem” is a piece that covers so much more than just systemd - it’s about the platform effect and how changing popularity makes bitrot inevitable. Now that the problem is clearly stated, how can we fix it? Anyhow, enough of me screaming at clouds.

I decided to get off my butt and figure out how to do cross-compilation for Go, and it turns out it’s improved a ton since last I looked. gox pretty much takes all the sting out of the process, and so the entire evening I had planned to set aside for slamming my brain against a keyboard got spent instead watching the new Eurovision movie.

“What are you cross-compiling in Go” you didn’t ask? Well, I did a rewrite of the coffeeoutside bot in Go, and needed a tidy little Linux executable at the end. I’m hoping that the maintenance effort will pay off, but honestly I doubt it. I think the payoff will come in standardizing all my little weird little home projects into go, and having a nice little CI process to go with it (but more on that later.)