

About the Systemd Controversy - embiggen
http://blog.erratasec.com/2015/08/about-systemd-controversy.html

======
vezzy-fnord
I suppose I'll repost my comment from the previous thread...

\------

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/)

------
embiggen
Note: I removed the weird part of the link from this submission [0].

[0]
[https://news.ycombinator.com/item?id=10144891](https://news.ycombinator.com/item?id=10144891)

~~~
jessaustin
That hash didn't really hurt anyone. E.g., it wouldn't allow one to
impersonate the OP in a comment on TFA, since Blogger has its own auth
cookies. (That would be an embarrassing vuln for a security blogger.)

~~~
embiggen
I agree with you.

When in doubt I publish the nice links.

