About the Systemd Controversy(blog.erratasec.com)
blog.erratasec.com
About the Systemd Controversy
http://blog.erratasec.com/2015/08/about-systemd-controversy.html
2 comments
Note: I removed the weird part of the link from this submission [0].
[0] https://news.ycombinator.com/item?id=10144891
[0] https://news.ycombinator.com/item?id=10144891
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.)
I agree with you.
When in doubt I publish the nice links.
When in doubt I publish the nice links.
[deleted]
------
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...