

About the Systemd controversy - wmat
http://blog.erratasec.com/2015/08/about-systemd-controversy.html#.VeOeWvlVikp

======
vezzy-fnord
Firstly, the age-old canard of microkernels being "too slow for the real
world" is decades out of date, and L4 and QNX today are ubiquitous.

One should not make the mistake of using the term "init" to refer to a
particular implementation. init(8) is simply the first process. There never
was a single "Unix init system", though the BSD rc was always the superior one
out of the originals. This is reflected to this day by its ridiculously short
init scripts and the fact that a dependency system (rcorder(8)) was easily
retrofitted.

The issue of boot speed is a misunderstood one. Properly benchmarking and
having a deterministic boot process has always been difficult. Linux distros
were by and large using the same tricks with sysvinit (startpar, insserv,
Makefile-style concurrency, etc.) that systemd centralizes to get the same
speed benefits for a while. Further, systemd introduces failure points in the
boot process of its own, particularly with how it handles job scheduling and
states, the occurrence of dependency loops and so forth. A lack of proper
integration (which is still common, it turns out having a full proper systemd-
based init configuration is hard [1]) can exacerbate this, and I've had
experiences of >2 minute-long booting on Fedora 20.

It must be stated that the problem with systemd isn't its violating the "Unix
way". The problem is with systemd itself, _a priori_. It's a landmine of an
architecture with chronic mission scope issues and lack of proper creative
direction.

I can also understand why a security researcher like Rob would be wary of
systemd. The risks of systemd are indeed exceptionally great compared to
previous systems. systemd's PID1 handles things like configuration parsing,
cgroupfs writing, supervision, system state management, mount/automount points
and its coverage is much higher than even something like launchd or Solaris
SMF. The central I/O bottleneck of something like the journal (which by far
has been the buggiest systemd component) is also noteworthy.

[1]
[https://wiki.freedesktop.org/www/Software/systemd/Optimizati...](https://wiki.freedesktop.org/www/Software/systemd/Optimizations/)

------
ChuckMcM
I think he calls it quite accurately, its a different architecture and that
breaks things. Having used FOSS OS'es for a long time now Linux userland has
been tugged back and forth between people who want things to be more UNIX like
and people who want things to be more Windows like. I wish that they would
just fork and lean in on those missions, have one fork go all in Windows NT
clone and the other UNIX clone.

