Systemd programming, 30 months later

"were"? We used to use them instead of distro-maintained sysvinit. Today, we use them instead of upstream-maintained systemd.

> I'm warming to systemd now that I've finally managed to wrestle it into deterministic ordering of service starts in a specified sequence

Arguably that's not entirely systemd's fault--it's units that have underdocumented dependencies (and/or bugs) and deficiencies in the schema (e.g. "remote" is hilariously insufficient to express the subtleties of networked filesystems on top of networked storage devices with a layer of locally-hosted VM server instances mixed in). Also some older packages are just spectacularly bad at living in a modern on-demand world. Better packages and units with more explicit and robust dependencies will fix that, eventually, but it will take several years of patient development by an extremely diverse and skilled group of contributors to get there. This is nothing the original article doesn't already point out, but it does still understate the magnitude of the problem.

On the other hand, the training, maintenance and testing cost of 200-line generator scripts (and the dynamic behavior they create, and the other changes introduced by other upstream and site-local contributors) has to be compared against the maintenance and testing cost of writing a 60-line site-specific rc script, once, that does everything your machine will ever need from now until its hardware dies. Untested code doesn't work, and I know which code I'd find easier to test. That implies that even if systemd were magically fully finished tomorrow, it'd still be too much work to use in practice for all but the most careless of user.

Is anyone working on testing process or tools for a collection of systemd units? e.g. force systemd to generate valid permutations of units and start them in random order to catch missing dependencies, or use path-coverage testing to ensure random valid combinations of options do the right things, and verify it all really works by rebooting and smoke-testing a VM? I use "random" here because systemd probably allows far too many combinations to enumerate them all, so some sort of statistical approximation of coverage is the best we're going to get.