28 ms·

Some of these are arguments I'm glad to see getting more attention, such as Fallacy #1: "Systemd is multiple binaries, therefore it is not monolithic". Others

by sciurus 12y ago

Some of these are arguments I'm glad to see getting more attention, such as Fallacy #1: "Systemd is multiple binaries, therefore it is not monolithic". Others strike me as a stretch. For example, Fallacy #4.1: "Unit files reduce complexity". No, I don't want the least complex init system init system possible. I think it's obvious to people who have written both system v init scripts and systemd or upstart configurations that the latter are dramatic improvements. The chance that I will write a buggy init script is, unfortunately, high. The chance that I will need to debug systemd when writing a unit file is very low.

wmf 12y ago
Really the only "monolithic" problems I see are with journald and logind. For the other pieces people don't want to use them and they don't have to. The fact that e.g. networkd can't run without systemd is fairly irrelevant since no one is asking for that; they're asking to not run networkd which works fine.
SwellJoe 12y ago
This. I would have been happy with anything that turned initscripts, which are often hundreds of lines, including tons of decisions and variables, into a simple declarative conifguration file. systemd seems to do OK at that, though I am vaguely uncomfortable with how tightly coupled things are in a systemd system.
imanaccount247 12y ago
>I think it's obvious to people who have written both system v init scripts and systemd or upstart configurations that the latter are dramatic improvements Except that is a false dilemma, which he points out. Sysv init takes more work because nobody has bothered to fix it. You don't need a massive complex set of software like systemd to make this easy, see the BSDs init scripts like he suggests.
- TheCondor 12y ago
  That doesn't really invalidate the argument. Upstart and systemd units are dramatically easier and less bug prone than the existing sysv alternative. If it was nontrivial to fix they would have. The missing beef here is actual bugs and problems with systemd. Post some zero days... Nobody challenges that businesses with paying customers all indepdently came up with the need for smf, launchd, upstart, and systemd. Are they just adding shit to add it or do the see value and need?
  - imanaccount247 12y ago
    > If it was nontrivial to fix they would have. There is no basis for that assertion. It is trivial to fix, again, see BSDs. Just because nobody bothers (or people bother and their effort is rejected due to politics) doesn't mean it is nontrivial.
stonith 12y ago
Apologies if you already knew this, but you may be interested in pleaserun[1] which attempts to manage the differences in init formats from a common interface. It's still quite new but I've been reasonably happy with it so far. I did have to extend it a little to allow commands like bootstrapping for clustered software. [1] https://github.com/jordansissel/pleaserun https://github.com/jordansissel/pleaserun
- sciurus 12y ago
  Pleaserun is a much-needed project, I would recommend that people use it as a starting point for generating init configurations (although unsurprisingly the sysvinit script it generates has portability issues [0]), and there are plenty of situations where what it generates will be good enough. I'm warming up to the idea that configuration management systems like chef should use pleaserun or add a similar abstraction themselves. [0] https://github.com/jordansissel/pleaserun/issues/49 https://github.com/jordansissel/pleaserun/issues/49

by sciurus 12y ago

wmf 12y ago

Really the only "monolithic" problems I see are with journald and logind. For the other pieces people don't want to use them and they don't have to. The fact that e.g. networkd can't run without systemd is fairly irrelevant since no one is asking for that; they're asking to not run networkd which works fine.

SwellJoe 12y ago

This. I would have been happy with anything that turned initscripts, which are often hundreds of lines, including tons of decisions and variables, into a simple declarative conifguration file. systemd seems to do OK at that, though I am vaguely uncomfortable with how tightly coupled things are in a systemd system.

imanaccount247 12y ago

>I think it's obvious to people who have written both system v init scripts and systemd or upstart configurations that the latter are dramatic improvements Except that is a false dilemma, which he points out. Sysv init takes more work because nobody has bothered to fix it. You don't need a massive complex set of software like systemd to make this easy, see the BSDs init scripts like he suggests.

TheCondor 12y ago
That doesn't really invalidate the argument. Upstart and systemd units are dramatically easier and less bug prone than the existing sysv alternative. If it was nontrivial to fix they would have. The missing beef here is actual bugs and problems with systemd. Post some zero days... Nobody challenges that businesses with paying customers all indepdently came up with the need for smf, launchd, upstart, and systemd. Are they just adding shit to add it or do the see value and need?
- imanaccount247 12y ago
  > If it was nontrivial to fix they would have. There is no basis for that assertion. It is trivial to fix, again, see BSDs. Just because nobody bothers (or people bother and their effort is rejected due to politics) doesn't mean it is nontrivial.

stonith 12y ago

Apologies if you already knew this, but you may be interested in pleaserun[1] which attempts to manage the differences in init formats from a common interface. It's still quite new but I've been reasonably happy with it so far. I did have to extend it a little to allow commands like bootstrapping for clustered software. [1] https://github.com/jordansissel/pleaserun https://github.com/jordansissel/pleaserun

sciurus 12y ago
Pleaserun is a much-needed project, I would recommend that people use it as a starting point for generating init configurations (although unsurprisingly the sysvinit script it generates has portability issues [0]), and there are plenty of situations where what it generates will be good enough. I'm warming up to the idea that configuration management systems like chef should use pleaserun or add a similar abstraction themselves. [0] https://github.com/jordansissel/pleaserun/issues/49 https://github.com/jordansissel/pleaserun/issues/49