4 ms·

I don't see a boycott happening. Not unless someone steps in to write an alternative init system, which solves some of the issues openrc and systemd solve, but

I don't see a boycott happening. Not unless someone steps in to write an alternative init system, which solves some of the issues openrc and systemd solve, but without systemd's baggage. taking the discussion out of the opinion level to a more factual level(eg. i like the boot speed of my archlinux machine but the whole consolekit(why did we get that to begin with ?)/logind/ridiculousness, logging and service files vs. startx and grep /var/log is annoying to say the least, but as i said subjective) on a factual level we have ridiculous bugs specifically caused by systemd that take down your system, and the lead developers saying either i don't care or it's by design. let me bring a few examples: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935 > That is the expected current behaviour, "debug" can cause "too many" messages to be useful anymore if things are broken. or this one, systemd segfaulting with cgroups off: https://bugs.freedesktop.org/show_bug.cgi?id=74589 https://bugs.freedesktop.org/show_bug.cgi?id=74589 Lennart: > To make this work we'd need a patch, as nobody of us tests this. There were a few other recent ones. When your new init system consistently takes down your operating syste, because of stupid bugs, and the lead developers say we don't care, and even block efforts to fix these issues, you should indeed worry. https://plus.google.com/111049168280159033135/posts/Kd57G8s1cTD https://plus.google.com/111049168280159033135/posts/Kd57G8s1... In fact Greg KH jumped in to play daddy, and wrote a patch where tom gunderson commented that that patch would not be merged as it's not clear what problem it solves. edit: some say openrc is the one. here's a comparison: https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems

welterde 13y ago
> solves some of the issues openrc and systemd solve, but without systemd's baggage. I thought OpenRC was that init system? Or what systemd baggage comes with it?
- keeperofdakeys 13y ago
  OpenRC is better than sysvinit, but still isn't the best. However in terms of technology, systemd is the best init system available. The main problems are the developer attitudes and architectural decisions they've made (big blob, work with me or nothing).
  - uggedal 13y ago
    Openrc does not provide a pid 1 init implementation. On most openrc systems sysvinit launces openrc to handle service startup.
midas007 13y ago
runit (from daemontools) might not start things up in parallel, but it's a whole lot simpler and reliable. Phusion uses it instead of upstart in their base docker VM. Also a lot of enterprise shops use daemontools and runit, because they just fucking scale.
- aktau 13y ago
  I concur, runit absolutely rocks. Haven't tried systemd yet, I wonder if the two play nice together (if they don't, it won't be runits' fault, that's for sure).
  - midas007 13y ago
    Might try the old-school daemontools, even though the commands are a bit different, it might be less work to get something going.
    - sigil 13y ago
      From your other comments I can tell you're a seasoned daemontools user, so let me just put in a quick plug for daemontools-encore [1]. Like runit, daemontools-encore can now run services in separate process groups with setsid(1). Why is this so darn important? Well, under classic daemontools a ./run file with a pipeline in it -- or really anything that forked -- would spin off orphans every time you did `svc -t|-k`. Very bad stuff to deal with in a production environment. [1] http://untroubled.org/daemontools-encore/ http://untroubled.org/daemontools-encore/
      - deleted 13y ago
        [deleted]
      - midas007 13y ago
        Yup, it's one of those annoying things that makes run scripts more complicated. I rewrote phusion's runit setuser helper in Go because it didn't set all the right env vars. https://raw.githubusercontent.com/steakknife/my_init/master/setuser.go https://raw.githubusercontent.com/steakknife/my_init/master/...
darkarmani 13y ago
> on a factual level we have ridiculous bugs specifically caused by systemd that take down your system, and the lead developers saying either i don't care or it's by design. Agreed. This is a big worry. When the lead developers of something this important sound this callous, I start getting concerned.

welterde 13y ago

> solves some of the issues openrc and systemd solve, but without systemd's baggage. I thought OpenRC was that init system? Or what systemd baggage comes with it?

keeperofdakeys 13y ago
OpenRC is better than sysvinit, but still isn't the best. However in terms of technology, systemd is the best init system available. The main problems are the developer attitudes and architectural decisions they've made (big blob, work with me or nothing).
- uggedal 13y ago
  Openrc does not provide a pid 1 init implementation. On most openrc systems sysvinit launces openrc to handle service startup.

midas007 13y ago

runit (from daemontools) might not start things up in parallel, but it's a whole lot simpler and reliable. Phusion uses it instead of upstart in their base docker VM. Also a lot of enterprise shops use daemontools and runit, because they just fucking scale.

aktau 13y ago
I concur, runit absolutely rocks. Haven't tried systemd yet, I wonder if the two play nice together (if they don't, it won't be runits' fault, that's for sure).
- midas007 13y ago
  Might try the old-school daemontools, even though the commands are a bit different, it might be less work to get something going.
  - sigil 13y ago
    From your other comments I can tell you're a seasoned daemontools user, so let me just put in a quick plug for daemontools-encore [1]. Like runit, daemontools-encore can now run services in separate process groups with setsid(1). Why is this so darn important? Well, under classic daemontools a ./run file with a pipeline in it -- or really anything that forked -- would spin off orphans every time you did `svc -t|-k`. Very bad stuff to deal with in a production environment. [1] http://untroubled.org/daemontools-encore/ http://untroubled.org/daemontools-encore/
    - deleted 13y ago
      [deleted]
    - midas007 13y ago
      Yup, it's one of those annoying things that makes run scripts more complicated. I rewrote phusion's runit setuser helper in Go because it didn't set all the right env vars. https://raw.githubusercontent.com/steakknife/my_init/master/setuser.go https://raw.githubusercontent.com/steakknife/my_init/master/...

darkarmani 13y ago

> on a factual level we have ridiculous bugs specifically caused by systemd that take down your system, and the lead developers saying either i don't care or it's by design. Agreed. This is a big worry. When the lead developers of something this important sound this callous, I start getting concerned.