<story><title>Broken by design: systemd</title><url>http://ewontfix.com/14</url></story><parent_chain><item><author>bitwize</author><text>Nice article, but at this point it&amp;#x27;s game, set, match -- systemd has won. The Linux community overwhelmingly supports it, and its advantages clearly outweigh its perceived disadvantages.&lt;p&gt;&amp;quot;It&amp;#x27;s not Unix&amp;quot; is no longer a valid critique. The old Unix design philosophy is dead. People want systems of components that function as an integrated whole. They do NOT want pieces that are generally unaware of each other (this is touted as the virtue of &amp;quot;loose coupling&amp;quot;).&lt;p&gt;Yes, pid 1 does a lot. That&amp;#x27;s by necessity. It&amp;#x27;s not your grandpap&amp;#x27;s Unix anymore. Do you want to control all the system services, including the &amp;quot;badly behaved&amp;quot; ones? That functionality needs to be in pid 1. Do you want to bring the system up safely and sanely, accounting for things like hotplugged disks in &amp;#x2F;etc&amp;#x2F;fstab? That functionality needs to be in pid 1. Systemd is the correct design for modern Linux. It also brings the advantage of better integration and greater commonality across distros.</text></item></parent_chain><comment><author>asdfaoeu</author><text>Even on systemd that stuff isn&amp;#x27;t all handled in pid 1.&lt;p&gt;There are 6 systemd service processes running on my machine handling different components.&lt;p&gt;Snipped out the irrelevant processes.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    % systemd-cgls
    ├─user.slice
    │ └─user-1000.slice
    │   └─user@1000.service
    │     ├─6612 &amp;#x2F;usr&amp;#x2F;lib&amp;#x2F;systemd&amp;#x2F;systemd --user
    │     └─6616 (sd-pam)
    └─system.slice
      ├─1 &amp;#x2F;sbin&amp;#x2F;init
      ├─systemd-udevd.service
      │ └─151 &amp;#x2F;usr&amp;#x2F;lib&amp;#x2F;systemd&amp;#x2F;systemd-udevd
      ├─systemd-logind.service
      │ └─345 &amp;#x2F;usr&amp;#x2F;lib&amp;#x2F;systemd&amp;#x2F;systemd-logind
      └─systemd-journald.service
        └─125 &amp;#x2F;usr&amp;#x2F;lib&amp;#x2F;systemd&amp;#x2F;systemd-journald&lt;/code&gt;&lt;/pre&gt;</text></comment>
<story><title>Broken by design: systemd</title><url>http://ewontfix.com/14</url></story><parent_chain><item><author>bitwize</author><text>Nice article, but at this point it&amp;#x27;s game, set, match -- systemd has won. The Linux community overwhelmingly supports it, and its advantages clearly outweigh its perceived disadvantages.&lt;p&gt;&amp;quot;It&amp;#x27;s not Unix&amp;quot; is no longer a valid critique. The old Unix design philosophy is dead. People want systems of components that function as an integrated whole. They do NOT want pieces that are generally unaware of each other (this is touted as the virtue of &amp;quot;loose coupling&amp;quot;).&lt;p&gt;Yes, pid 1 does a lot. That&amp;#x27;s by necessity. It&amp;#x27;s not your grandpap&amp;#x27;s Unix anymore. Do you want to control all the system services, including the &amp;quot;badly behaved&amp;quot; ones? That functionality needs to be in pid 1. Do you want to bring the system up safely and sanely, accounting for things like hotplugged disks in &amp;#x2F;etc&amp;#x2F;fstab? That functionality needs to be in pid 1. Systemd is the correct design for modern Linux. It also brings the advantage of better integration and greater commonality across distros.</text></item></parent_chain><comment><author>repsilat</author><text>&lt;i&gt;People want systems of components that function as an integrated whole. They do NOT want pieces that are generally unaware of each other (this is touted as the virtue of &amp;quot;loose coupling&amp;quot;).&lt;/i&gt;&lt;p&gt;This may be true of &amp;quot;mainstream&amp;quot; users&amp;#x27; applications, but is it really true of system software? And should we really attribute the cultural shift toward monolithic systems to shifting preferences rather than leap-first &amp;quot;design&amp;quot;?</text></comment>