5 ms·

Something that tends to get lost in these discussions: it's not a question of systemd-versus-sysvinit. Systemd is miles better than sysvinit. There's absolutely

Something that tends to get lost in these discussions: it's not a question of systemd-versus-sysvinit. Systemd is miles better than sysvinit. There's absolutely no question that the vast majority of Linux users would rather sysvinit disappear entirely. But that doesn't mean that there aren't better alternatives. My personal preference is runit[1], which is based on djb's daemontools[2] and gives you all the dependency management and speed gains of systemd without the monolithic architecture and without the complicated shell scripts of sysvinit, as well as cool features like service management trees for non-root users. (In fact, runit doesn't need to be run as init—you can run it as a non-root user and provide service management even if you use another init. It just happens to make a nice init.) The tests I've seen show that a minimal system with runit boots roughly as fast as than a minimal system with systemd. That doesn't mean runit is the end-all solution to "which init"—it's perfect for my needs, but maybe not yours—but it does mean that the choice is not a choice between systemd-but-fast versus sysvinit-but-slow. The field of choices is much, much broader. [1]: http://smarden.org/runit/ http://smarden.org/runit/ [2]: http://cr.yp.to/daemontools.html http://cr.yp.to/daemontools.html

antientropic 12y ago
What mystifies me in these systemd discussions is that people constantly seem to attack a caricature of systemd that has little in common with its actual implementation. Take for instance the perpetual "monolithic architecture" argument. What monolithic architecture? Systemd is in fact highly modular. For instance, PID 1 concerns itself with starting and monitoring units, and not much more. Other functions are implemented in other programs, such as journald, udevd, logind and so on. Of course, some of the components sometimes need to talk to each other, but generally via well-defined (D-Bus) interfaces - e.g., pam_systemd registers user sessions with logind via a D-Bus call, and loginctl asks logind about current user sessions, also via a D-Bus call. What's wrong about that architecture? Now, systemd the package is getting pretty bloated. For instance, there is no reason why stuff like networkd couldn't be in a separate package that depends on systemd. But that's not really an architectural issue, and not much of a problem for users. (For instance, you can disable networkd just fine.)
- jude- 12y ago
  What mystifies me in these systemd discussions is that systemd proponents always seem to think that "modular" is somehow the opposite of "monolithic," when it is entirely possible for a system to be both. "Modular" only means that a system is factored into components that address logically separate concerns. "Monolithic" means that your modules are tightly coupled. For example, the Linux kernel and X.org are both modular and monolithic, as is systemd. Coreutils, by contrast, is modular and NOT monolithic.
  - snarfy 12y ago
    Tightly coupled modules is an oxymoron.
  - antientropic 12y ago
    The Linux kernel is considered monolithic because all those modules run in the same kernel space, where they can all walk over each other and bring down the system. Systemd is not like that: its components run in separate processes. By your line of reasoning, the GNU Hurd is a monolithic OS, because most Hurd servers live in the same source tree and send messages to each other at runtime.
    - vezzy-fnord 12y ago
      systemd's modules are interdependent and all require systemd to be PID1 in order to function. You cannot, e.g. strip out logind only and use it as a ConsoleKit replacement. Contrast this with a toolkit based approach like s6, which can run as init, process supervisor or both, and can have its tools that operate on process state be used independently. Another criteria is whether you can swap out one component without breaking the whole. You can't do this for journald, for example. You're forced to keep it by reducing it to a sink that redirects to your syslogd of choice. On the other hand, replacing parts of the GNU coreutils with those of 9base or sbase, for instance, won't break the rest (though it will break programs that depend on the GNU coreutils' extended options, of course).
      - 12y ago
baudehlo 12y ago
One (minor) problem with runit is that runsv maintains the pipe between the command and the logger. If runsv dies then the pipe is lost and logs are potentially lost. S6 apparently solves this: http://skarnet.org/software/s6/index.html http://skarnet.org/software/s6/index.html

antientropic 12y ago

What mystifies me in these systemd discussions is that people constantly seem to attack a caricature of systemd that has little in common with its actual implementation. Take for instance the perpetual "monolithic architecture" argument. What monolithic architecture? Systemd is in fact highly modular. For instance, PID 1 concerns itself with starting and monitoring units, and not much more. Other functions are implemented in other programs, such as journald, udevd, logind and so on. Of course, some of the components sometimes need to talk to each other, but generally via well-defined (D-Bus) interfaces - e.g., pam_systemd registers user sessions with logind via a D-Bus call, and loginctl asks logind about current user sessions, also via a D-Bus call. What's wrong about that architecture? Now, systemd the package is getting pretty bloated. For instance, there is no reason why stuff like networkd couldn't be in a separate package that depends on systemd. But that's not really an architectural issue, and not much of a problem for users. (For instance, you can disable networkd just fine.)

jude- 12y ago
What mystifies me in these systemd discussions is that systemd proponents always seem to think that "modular" is somehow the opposite of "monolithic," when it is entirely possible for a system to be both. "Modular" only means that a system is factored into components that address logically separate concerns. "Monolithic" means that your modules are tightly coupled. For example, the Linux kernel and X.org are both modular and monolithic, as is systemd. Coreutils, by contrast, is modular and NOT monolithic.
- snarfy 12y ago
  Tightly coupled modules is an oxymoron.
- antientropic 12y ago
  The Linux kernel is considered monolithic because all those modules run in the same kernel space, where they can all walk over each other and bring down the system. Systemd is not like that: its components run in separate processes. By your line of reasoning, the GNU Hurd is a monolithic OS, because most Hurd servers live in the same source tree and send messages to each other at runtime.
  - vezzy-fnord 12y ago
    systemd's modules are interdependent and all require systemd to be PID1 in order to function. You cannot, e.g. strip out logind only and use it as a ConsoleKit replacement. Contrast this with a toolkit based approach like s6, which can run as init, process supervisor or both, and can have its tools that operate on process state be used independently. Another criteria is whether you can swap out one component without breaking the whole. You can't do this for journald, for example. You're forced to keep it by reducing it to a sink that redirects to your syslogd of choice. On the other hand, replacing parts of the GNU coreutils with those of 9base or sbase, for instance, won't break the rest (though it will break programs that depend on the GNU coreutils' extended options, of course).
    - 12y ago

baudehlo 12y ago

One (minor) problem with runit is that runsv maintains the pipe between the command and the logger. If runsv dies then the pipe is lost and logs are potentially lost. S6 apparently solves this: http://skarnet.org/software/s6/index.html http://skarnet.org/software/s6/index.html