3 ms·

FAQ systemd [pdf]

4 points by talles 11y ago

vezzy-fnord 11y ago
Factual inaccuracies in this FAQ: a) The conflation of init(8) with one particular implementation, sysvinit. b) sysvinit actually wasn't fundamentally sequential. A utility bundled with it called startpar had existed for a while to handle asynchronous executions, and was often used by distributions in conjunction with distro-specific hacks and LSB initscript headers to achieve dependency-based boot and other properties. Others simply started processes as background jobs. The wounds were as such largely self-inflicted. c) The issue of parallelism is orthogonal to that of dependency management. d) Many people had pined for alternatives well before even Upstart (initng, depinit, simpleinit-msb, eINIT, cinit, runit, minit, daemond, etc.) but were largely ignored in their day. e) Upstart doesn't actually have a formal dependency model. It's based entirely on reacting to emitted events, which are really a form of runtime postcondition. You can certainly emulate dependencies by doing things like "start on started foobard", but the semantics and mental model for Upstart job synchronization are very different. f) Opening sockets on behalf of another process is a "clever idea" that is almost 30 years old. This is ignoring the fact that "Features built on top of systemd are very useful" and "systemd has been proven to work, and it works well - hey, many distros and GNOME are using it!" aren't even arguments.
lwhalen 11y ago
Darn, and here I was hoping for a FAQ on using/administering systemd. Ideally something along the lines of "if you wanted to see what was starting in a runlevel under sysvinit, you'd look here. Under systemd, you look there." "Want to start/stop a daemon on boot? You'd do X under sysvinit, you'd do Y under systemd", and so on.
Hnrobert42 11y ago
Could the experience of using systemd be more aptly captured than by ardously panning around its FAQ in a stupid PDF?

3 ms·

FAQ systemd [pdf]

4 points by talles 11y ago

vezzy-fnord 11y ago
Factual inaccuracies in this FAQ: a) The conflation of init(8) with one particular implementation, sysvinit. b) sysvinit actually wasn't fundamentally sequential. A utility bundled with it called startpar had existed for a while to handle asynchronous executions, and was often used by distributions in conjunction with distro-specific hacks and LSB initscript headers to achieve dependency-based boot and other properties. Others simply started processes as background jobs. The wounds were as such largely self-inflicted. c) The issue of parallelism is orthogonal to that of dependency management. d) Many people had pined for alternatives well before even Upstart (initng, depinit, simpleinit-msb, eINIT, cinit, runit, minit, daemond, etc.) but were largely ignored in their day. e) Upstart doesn't actually have a formal dependency model. It's based entirely on reacting to emitted events, which are really a form of runtime postcondition. You can certainly emulate dependencies by doing things like "start on started foobard", but the semantics and mental model for Upstart job synchronization are very different. f) Opening sockets on behalf of another process is a "clever idea" that is almost 30 years old. This is ignoring the fact that "Features built on top of systemd are very useful" and "systemd has been proven to work, and it works well - hey, many distros and GNOME are using it!" aren't even arguments.
lwhalen 11y ago
Darn, and here I was hoping for a FAQ on using/administering systemd. Ideally something along the lines of "if you wanted to see what was starting in a runlevel under sysvinit, you'd look here. Under systemd, you look there." "Want to start/stop a daemon on boot? You'd do X under sysvinit, you'd do Y under systemd", and so on.
Hnrobert42 11y ago
Could the experience of using systemd be more aptly captured than by ardously panning around its FAQ in a stupid PDF?