...will get people rethinking some other aspects of "How It's Done On UN*X".
Latest mention of the systemd thing here.
Sometimes, things get set in stone too early, for the wrong reasons... and then, despite the proliferation of libraries-that-do-similar-things in the UN*X world, the old way remains the only way.
My personal peeve here is setting the Baud rate on a serial port. The UN*X way, formalized in the POSIX standard, involves passing the choice of rate as a small integer selected from a list in a header file.
This makes sense in the context of a PDP-11, with a serial-port card that takes a 3-bit number (or whatever it was) to select one output from a Baud-rate generator that does 110 and a few multiples of 300. It's completely outdated in the modern era of UARTs with Baud-rate generators that divide 60 MHz by an arbitrary factor.
Heck, even Windows allows setting arbitrary Baud rates. But Linux? Nope. There's a system-defined short list of allowed rates, and that's it.
And, most of the time, that's OK. But, when you need to talk to an embedded-device UART that runs at 1000 Baud because that's the standard in Upper Whatchacallistan? Having to use Windows just to do that sucks almost as much as writing a special-purpose Linux device driver just to get a custom Baud rate.
(OK, so there is a way of mucking about with the Baud rate using the standard driver. Ugly! Seriously, the API should have been fixed decades ago to take the actual requested Baud rate, with the legacy rate #defines redefined to the actual number, e.g., B9600 would be 9600.)