Great talk. Truly wish I could have been there. Thanks, +Jon Miller
, for sharing the link. A good intro to our brave new world.
+ switch service name and start/stop (better args ordering with 'systemctl' compared to 'service')
+ breaking out of the 0..6 "run levels"
+ tighter resource controls
+ assimilating too many functions into one program
+ maintaining content (the journal) in binary form (rather than plain text) see below
+ an RPM/Yum "feel" to the whole design (INIT should be simpler)
+ deceptive claim of logging everything (what happens before SystemD?)
+ replacing non-flaws in prior programs
Switch from text to binary is security through obscurity.
Ask any security professional how secure that is.
Much better to push logging to another host for true "hands off".
And yet, "rsyslog" is still required?
There's a learning curve. No complaints there for true innovation. But some features of programs which SystemD replaces were not broken. Sad that we have to re-learn more than from simply adding a new package.
The presentation has some "ad-hominem attacks" on SysV INIT. In particular, the complexity of INIT scripts is not an inherent fault with SysV INIT.
Others may have reported similar experience: I had no serious delays in booting with SysV INIT. Ironically, I have had noticeable delays when booting with SystemD. Have not investigated why, but interesting since the most public claim of SystemD value is faster boot times.
It's no secret that I don't like SystemD.
Would like to think my objections are more pragmatic than knee jerk.
I honestly believe I would have no problem with it if I could select the traditional arrangement, so the frustration is with the distributors more than with SystemD per se. Wasn't that what we were all about in Linux land? the ability to choose?
-- R; <><