I&#x27;m mainly sysadmin, but I also do some occasional embedded development, and use systemd-enabled Arch on the desktop.<p>Systemd solves <i>so many pain points</i> in <i>all</i> areas that I don&#x27;t care about ideological debates.<p>And most of the touted &quot;advantages&quot; of sysvinit are, in practice, a nightmare. &quot;people should just know what they&#x27;re doing&quot;? Well, too bad, nobody does! Distribution maintainers don&#x27;t know how to write robust init scripts, software vendors don&#x27;t know how to write robust init scripts, <i>nobody does!</i><p>Taking away the &quot;freedom&quot; to introduce the halting problem to service definitions is, in practice, <i>godsent</i>.<p>&quot;With BSD init, I can just edit the &#x2F;etc&#x2F;rc script and replace it with arbitrary shell code.&quot;<p>And now try to debug it one year later when you don&#x27;t even remember that you did any changes to it. The shit I&#x27;ve seen on Linux systems&#x27; &#x2F;etc&#x2F;rc.local would give Lovecraft nightmares.<p>And the ability to sprinkle echo statements all over your init system does not make a system &quot;easy to debug&quot;, unless you&#x27;re a PHP &quot;devop&quot; who thinks that OOP is the source of all evil in the world.<p>&quot;The way systemd does parallel startup bothers me. If service A depends on service B, they were traditionally started in sequence; A only starts after B is done starting.&quot;<p>Unless it doesn&#x27;t, because init scripts _cannot_ reliably determine whether a daemon has started up. Grab, say, debian&#x27;s sysvinit sctipts and count the amount of sleep statements sprinkled all over them. That&#x27;s not sequential startup, that&#x27;s a race condition waiting to happen!<p>&quot;Why should systemd implement NTP when ntpd already exists?&quot;<p>Because ntpd is a steaming, insecure pile of crap. And no, openntpd is not a solution, it&#x27;s just a nicer problem. Why do I need an ntp <i>server</i> on a pure client machine? Just because ntpdate is an even bigger pile of crap?<p>&quot;Being unable to shutdown the system.&quot;<p>As if that never happened with sysvinit. Badly behaving init scripts can cause a lot of havoc, at least systemd has a configurable hard cut-off.<p>&quot;Debian should not have adopted it for at least a few more years; they’re supposed to be the slow, steady, and stable distro. &quot;<p>Debian profits the most from ripping out the unusable joke that was their own &quot;parallelized startup enabled&quot; sysvinit. I&#x27;ve seen more Debian stable+sysvinit systems unable to boot up than I&#x27;ve seen Arch+systemd systems.