[microtonal]

I am also in the middle ground, but I have moved from the opposite direction. I used to like systemd a lot, especially for its simple unit files (compared to ugly System V shell scripts) and the fact that it could properly track processes and restart them on failure.

I have become a bit more skeptical, because most of the problems that I recently had seemed to be related to systemd. Including some networking problems, long boot delays because systemd decides to wait 90 seconds be default on some conditions that it considers to be errors, and problems such as having to restart systemd-logind manually because of some d-bus update [1]. Before the update, logging in via SSH blocked for a large amount of time.

The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems.

[1] https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-2...

[pawadu]

I think systemd would benefit from a slower adaptation.

The network and boot issues that practically everyone have encountered are mostly due to incorrect default configurations. This shows that the maintainers are not ready to use systemd as they don't yet fully understand it.

[sevensor]

Like PulseAudio in its early years, systemd bothers a lot of people because it was pushed out before it was quite ready, and therefore breaks things that used to work. But also like PulseAudio, it solves a whole lot of problems for which the solutions were becoming increasingly hacky and unstable. I don't believe a slower roll-out would have helped in either case, because many of the issues were undetectable without a broad user base.

Anti-Lennart partisans would say here that both pieces of software are broken by design and leave in a huff. I sympathize with their aversion to complexity, but I'll take a complex init system and simple configuration over a simple init system with baroque configuration.

[pawadu]

From a users point of view there is little difference between software that crashes because its garbage and software that crashes because it is in early stage of development but otherwise a good solution.

Lennart should write more robust software and maintainers should do more QA when doing this type of system-wide changes.

[microtonal]

I agree very much with the points that you are making.

It would also help if small parts of a system would be replaced at a time. Replacing daemon/process supervision, login handling, logging, network configuration, etc. all at the same time in distributions that are used by millions of users is quite risky.

[digi_owl]

Sadly the best you will get out of the systemd camp is "tough luck, should have joined from the start to avoid the pain".

[rkangel]

> The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems.

This is a reasonable criticism of systemd. The other points seem mostly to be a criticisum of the various distro implementations that use systemd. The sort of thing that gets tidied up over time anyway.

[throw2016]

The bigger question is whether an init should be a continuously developed project with rapidly increasing scope as now various distributions are on differing versions of systemd with widely varying compatibility and feature sets.

[cakes]

Generally agreed. I know that my priorities for what should be done in systemd are not going to match someone else's but there are also some clearly problematic things that just seem to go unaddressed no matter the scale (e.g. rebooting nspawn containers [1], problems with DNS/resolved [2]).

systemd can do a lot of really useful things but when I can't reliably reboot machines or struggle with resolving things using DNS...it's hard to be optimistic.

[1] https://github.com/systemd/systemd/issues/2809 [2] https://github.com/systemd/systemd/issues/3649

[digi_owl]

The whole systemd for containers thing seems like a massive cause of "because we can". Also allowed them a better pitch towards devops and RHEL than "faster boot"...