💾 Archived View for thrig.me › blog › 2023 › 03 › 27 › systemd-retrospective.gmi captured on 2023-09-08 at 16:23:47. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-04-19)
-=-=-=-=-=-=-
gemini://gemini.hitchhiker-linux.org/gemlog/re_systemd-free.gmi
Ah, systemd. More or less this was Linux under new management, same as the old management. For example, systemd on RedHat Enterprise 7 (2014) had a charming feature where, sometimes, it would fail to shutdown a host, and one would eventually stride to the server room and apply the Paperclip of +3 System Slaying. Such already unbent paperclips had been hung on the racks for exactly this purpose. RedHat 7 (2000) also had this feature. Folks with money might have remote management, or maybe a data centre tech would be wandering about Europe at 2 AM as one kept the Sev-1 line informed of their progress. Regardless, there was a manual reset because of a wedge at shutdown. Different clowns, same act.
[picture of a sysadmin wondering why the reboot is taking so long]
There were also new bugs and features, and old features that they attempted to continue support for alongside the new.
That systemd generated more than 20 log lines by default for each and every mailman cron job on RHEL7 was charming. What was the point of all that log spam? I forget how I squelched it; RedHat Linux is fairly maintenance heavy. At least not also to syslog? Too much complexity. Oddly enough, they make money from selling support contracts...
Probably linuxen should have dropped support for the old /etc/fstab, rather than blowing up with little indication that some line in the "still supported but now surfacing bugs" /etc/fstab was to blame. Things can be difficult to debug after that speedy boot pole-wraps itself. That was a Debian or Ubuntu of some flavor that the user was totally out of their depth with. Perhaps these teething problems have been dealt with? Or have they finally gotten rid of the old interfaces instead of trying to kluge them all together into one big happy system? Curiously, there are rumors of much the same on Windows where there is new and old all bodged together in one big bloody mess.
The past tense means I haven't really touched Linux in a while; there is an Alpine Linux virt under vmd(8) somewhere, gently unused. And a big-endian Debian MIPS qemu thing used even less to test that code does not assume little-endian. OpenBSD gets the complexity and maintenance needs just about right.
I could see arguments for supporting the legacy interfacen in addition to the new thing (especially if you sell service contracts to help folks along with migrations) but when there are legacy networking scripts, NetworkManager, and who knows what all systemd processes trying to get their say into the /etc/resolv.conf file...yeah. About that. I ran the DNS infrastructure so had a pretty good idea of what /etc/resolv.conf should contain, which was never what the various scripts and daemons would randomly cough up. Probably it was deterministic, but verifying that would require delving into the Ancient City below Ruins Untold to see exactly what the code had dreamed up.
https://www.savagechickens.com/2007/05/job-hazard.html
Mostly systemd was "you have to throw two rhubarb pies instead of one lemon pie" for SysV...okay, sure, whatever--either is hilarious, and I'd handle both with configuration management. Both had bugs and hit singles in the CVE charts. So nothing much had changed.
< Uncle Somf> How are we doing, $outlaw_name?
< $outlaw_name> The same as always, Uncle!
< Uncle Somf> That bad, huh?
-- The Battle for Wesnoth. David White et al. 2005.
tags #systemd #linux