Why Did ArchLinux Embrace Systemd? (2016)
Ah, I&#x27;m going to lose karma here because I&#x27;m a sysadmin and not a programmer and programmers seem to really like systemd, and this forum is represented strongly by programmers.<p>Regardless, every time these types of threads come about I feel like I _have_ to speak because there&#x27;s a lot of bitterly divided people regarding this issue. (or, rather the people who are bitterly opposed and the people who don&#x27;t care, think systemd is a net good in the vast majority of cases or those who think the backlash is very much unwarranted).<p>I&#x27;d like to say first off: SystemD solves real problems that nothing before it was solving, maybe it doesn&#x27;t solve those issues in the way I personally like, but it definitely does and was one of the first to do so- so for this reason the original maintainers should be warranted respect, it&#x27;s also a given that it&#x27;s not the developers fault that this is so widely adopted or even forced. I see them as problem solvers first and foremost so any gripes I have with systemd as a thing which is foisted upon me is definitely not on them.<p>However, I do consider that systemd as a new -layer- between user land and kernel space (called &quot;system space&quot; by Poettering) necessitates a lot of breaking changes. I do not consider this by itself as a bad thing, but having a poorly defined interface for these things does not enable systemd to be replaced without some form of &quot;systemd-esque&quot; emulation in future.<p>Thus while we have improved from where we were, we do not have fertile ground to improve in the future.<p>Additionally; SystemD as a &quot;modular&quot; system is, in my opinion, a myth; even if you take for granted the fact that systemd+journald are the only core dependencies, you then quickly start to drag in more and more rapidly (udev and systemd-resolved being famous examples).<p>Some design paradigms are scary, for instance socket activation leaves PID1 listening for traffic on the network, by default bound to all interfaces. (a good example is to look at cockpit) this could be a very large footgun if there exists any form of exploit in systemd.. and since systemd is not written in a memory safe language, and the overwhelming majority of security bugs are memory safety bugs... this is mildly concerning.<p>There are other concerns regarding opacity of the dependency system, the fact that no-two-boots are the same and thus some race conditions are likely to never be solved by me. (a lowly sysadmin type who only knows enough C to make linked lists). The design very much reminds me of Microsoft Windows in many ways, but perhaps that was a good design to choose from?<p>FWIW: SystemD is amazing on my laptop, I am really happy with it. But for my servers I am very unhappy with it, but the major distributions chose to use systemd and I&#x27;m a sysadmin so I&#x27;m beholden to what the company considers stable and developers.<p>I very much begrudge the fact that I&#x27;m not allowed to have a dissenting opinion on this.<p>I also hate that when people talk about systemd vs &quot;anything&quot;, invariably people assume I am talking about openRC or sysvinit, but there are much better init systems available today, such as Runit.<p>SystemD is not a panacea, it should leave fertile ground for replacement. If that cannot be done it should not be adopted because that is a scary amount of lock-in.