Systemd: The Biggest Fallacies

Post by mhogomchungu » Sat, Sep 27, 2014, 3:06 AM UTC

jerf wrote: post #38

dnr wrote: post #22

He's missing the point about socket activation. The problem it solves is different: if you have daemon B that depends on daemon A, you want to express that dependency in the init system, so that it starts A before B. But just starting process A isn't enough to ensure that A is actually listening on the socket that B wants to connect to, since it takes some time to load the binary and do initialization. There's a race…

As a bit of a disinterested observer (I'm mostly in the "just make it work" camp), I can't help but feel that if you pile up the problems that systemd seems to solve on one side, and pile up the enormous piles of code that are apparently necessary to solve the problem on the other, that systemd does not come out looking too good. (Writing this in C was probably a silly idea.)

Post by digi_owl » Sat, Sep 27, 2014, 5:46 AM UTC

astine wrote: post #30

felixgallo wrote: post #26

Earlier quoted context omitted.

You've already been corrected with regard to the rest of your argument, but I'll correct you on the last part too: they could do so just fine. That's the power of a modular, non-tightly coupled system. Any script that uses ksh, zsh, bash, csh, tcl, lua, rc, whatever, runs fine under sysvinit.

No, my point is that you cannot just take a script written for bash and run it on Zsh or Ksh and expect it to just work. (Well, sometimes you can, but that's beside the point.) Yes you can write your init scripts in whatever language you want, even Lisp or Python, but you have to do that for every daemon you switch over. Imagine a lot of these Linux distros which often implement their own init scripts for each progra…

Post by linuxydave » Sat, Sep 27, 2014, 7:58 AM UTC

uselessdguy wrote: post #8

zanny wrote: post #7

I am getting so sick of these blogs for or against systemd. It is free software. If you do not want to use it, use a distro without it. And vice versa if you want it. And if you don't like that Debian or Canonical or Arch a few years back or OpenSuse have switched to using it... too bad, you are not the maintainer of the repos, and if you were an active member of the community with voting power, you were outvoted. Th…

It's obvious you didn't even read the article. EDIT: I don't know the motivation for the downvotes. I replied like this because the commenter posted a canned cookie-cutter reply that is addressed in the article as Fallacy #6.1.

Post by zimbatm » Sat, Sep 27, 2014, 6:14 PM UTC

dnr wrote: post #22

He's missing the point about socket activation. The problem it solves is different: if you have daemon B that depends on daemon A, you want to express that dependency in the init system, so that it starts A before B. But just starting process A isn't enough to ensure that A is actually listening on the socket that B wants to connect to, since it takes some time to load the binary and do initialization. There's a race…

Post by dnr » Sat, Sep 27, 2014, 8:14 PM UTC

thaumaturgy wrote: post #44

dnr wrote: post #22

He's missing the point about socket activation. The problem it solves is different: if you have daemon B that depends on daemon A, you want to express that dependency in the init system, so that it starts A before B. But just starting process A isn't enough to ensure that A is actually listening on the socket that B wants to connect to, since it takes some time to load the binary and do initialization. There's a race…

Honest question, how frequent or serious of a problem is this in practice? Most of the servers I deal with have only a handful of daemons running concurrently, and of those, maybe only a couple of daemons have interdependencies, and of those, they don't seem to have much trouble polling each other and coordinating startup. I mean, from the software developer's perspective, it's probably not fun to write that polling…