&#x2F;sbin&#x2F;systemd doesn&#x27;t do any of that. Hotplugging devices was the domain of the kernel and udev (and consolekit for user access). The only reason &quot;systemd&quot; does this now is because they replaced consolekit (yay) and absorbed udev (boo). You either love or hate the ambiguity of terms like &quot;systemd&quot; and &quot;modular&quot;, and the way it has been exploited to full extent during the systemd takeover.<p>&quot;Modern usage scenario&#x27;s&quot; should still include reliable boot and predictable behaviour. Systemd seems to have been developed under an assumption of infallibility, which makes recovering from a failing boot much harder. And a failing boot is much more common under systemd, because it has been designed to fail hard instead of fail safe.<p>I&#x27;m running Debian on seven systems, and only one of those is running systemd. The others simply won&#x27;t boot with it, or are headless and I won&#x27;t risk bricking them (see fail hard above). The one system that I do run systemd on, I&#x27;ve had to disable the lvm and luks generators because they would fail hard, and I&#x27;ve had to compile it from git because Debian&#x27;s shipped versions of networkd and resolved are broken.<p>I agree with the article that systemd adoption was premature. Throughout the discussion, I got the impression that the decision was forced because of primarily the interests of desktop and service developers, with only a minor nod to system maintenance.<p>imnsho, &quot;systemd&quot; the project was not ready for inclusion. Systemd as PID1 may have been ready, but systemd the project does not allow systemd to run as PID1 without the rest of the project.