<story><title>Why Did ArchLinux Embrace Systemd? (2016)</title><url>https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/</url></story><parent_chain><item><author>darkwater</author><text>Looking back, I still don&amp;#x27;t get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I&amp;#x27;m looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only a a very tech-savvy user could generate in the first place.</text></item></parent_chain><comment><author>megous</author><text>Until it doesn&amp;#x27;t.&lt;p&gt;Until very recently having wrong permission on one of the networkd config files would result in networkd ignoring the rest of the perfectly readable network configuration files too, cutting off all network connectivity. (Systemd also requested the permission change iself.)&lt;p&gt;Currently there&amp;#x27;s a bug where if you have a bridge and all interfaces are disconnected from the bridge (I use hot-pluggable USB network interfaces) when you re-connect them, networkd will keep the bridge off. If you restart systemd-networkd it will fix itself.&lt;p&gt;I can name at least two instances already where I lost networking in my entire SBC farm, and had to pop out all microSD cards and fix the breakage manually, just because of systemd-networkd bugs. And I don&amp;#x27;t do anything crazy, just a single ethernet interface and two overlay wireguard networks, and mostly default config.&lt;p&gt;And fixing it yourself is not easy. I can do C coding perfectly fine, but I run 3 different CPU archs, so fixing it myself means compiling (3 times) and distributing my own systemd version to all my machines until upstream fixes the bug. It&amp;#x27;s not pleasant, nor easy.&lt;p&gt;I certainly understand people who miss having an ability to more readily script the system startup&amp;#x2F;network config.</text></comment>
<story><title>Why Did ArchLinux Embrace Systemd? (2016)</title><url>https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/</url></story><parent_chain><item><author>darkwater</author><text>Looking back, I still don&amp;#x27;t get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I&amp;#x27;m looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only a a very tech-savvy user could generate in the first place.</text></item></parent_chain><comment><author>adrian_b</author><text>Before using SystemD for the first time, I also wondered if there is any grain of truth in what its opponents said about SystemD.&lt;p&gt;However, after trying SystemD for one week, I became convinced that the designers of SystemD are incompetent, so they cannot be trusted with a component of such importance for a computer.&lt;p&gt;I am normally a Gentoo user, but a few years ago I wanted to install Linux in a hurry on a small computer. With a slow CPU installing Gentoo can take several hours, unless you have a previously prepared image, so I decided to try ArchLinux.&lt;p&gt;The installation was indeed fast and without problems. However, SystemD behaved in an unexpected way. SystemD is advertised as booting quickly. It indeed booted quickly, but no faster than my optimized Gentoo systems.&lt;p&gt;On the other hand the shutdown with SystemD was very slow. This was a huge surprise, because never before and never after have I encountered any computer where the shutdown is annoyingly slow.&lt;p&gt;Moreover, sometimes the shutdown &lt;i&gt;FAILED&lt;/i&gt;, which is also something that I have never encountered on any computer not using SystemD, and I have used thousands of computers, with many kinds of operating systems, including at least eight or nine UNIX flavors other than Linux.&lt;p&gt;The failure of shutdown was apparently due to some kind of race condition when some process was killed faster than some SystemD component expected and that SystemD component was still trying to communicate via DBUS with the defunct process and it blocked because its messages no longer reached the destination.&lt;p&gt;I suppose that this bug might have been corrected eventually, but this is a design error that I consider unforgivable, i.e. to conceive a shutdown sequence which depends on successful inter-process communication.&lt;p&gt;After seeing such a mistake I have lost any confidence in the abilities of the SystemD developers, so I have never tried it again.</text></comment>