13 ms·

We have tried 'fully isolated init' for years and it does not really work for modern systems/applications. I keep hearing this but I haven't seen any conc

by zaphar 12y ago

We have tried 'fully isolated init' for years and it does not really work for modern systems/applications. I keep hearing this but I haven't seen any concrete reasons why it would be true. I'm curious what those reasons are. As I said I don't personally care that much as I work far enough up the stack to not be affected for the most part.

Xylakant 12y ago
I think it's not a problem primarily with "init" itself, but for example that systemd provides you with the capability of starting a service "after network is up" so it needs to be able to tell "when network is up". That's much easier to do if there's a canonical (from systemds POV) way to tell "what's networks state". That again leads to "bah, let's do that ourselves" so there's now an optional systemd component that does this, that, this and people start relying on those - systemd-logind is a requirement for gnome. You could write a replacement for systemd-logind that offers the same functionality, but as long as nobody does, you're stuck with systemd. The way I see it is that the systemd developers just plowed a way through the undergrowth and produced a suite of components that provide functionality that's appealing for people to build on. That's an offering that was accepted and now other people complain that the "systemd people are forcing their system on us and I want sysV init". The right course of action would be "meh, don't like systemd, I'll build a better offering." Talk is cheap, code is what counts. I very much like systemd. It's documentation is actually long, but clear and well structured. The init component is much simpler than the mess of shell scripts used before. There certainly are problems and issues with it, but I've met problems and issues with about any kind of software I had to deal with so far (including my own), so I take that as a given.
- e7620 12y ago
  Your response only makes sense if your alternatives are: (1) systemd, (2) sysvinit and (3) a horrible death. I know dozens of init systems that do much more, markedly better than systemd, and are modular so you can easily replace them when the time for a new technology comes. systemd is very recent, and still its opinionated architecture is showing inflexible to changes.
  - Xylakant 12y ago
    no, the alternatives are (1) systemd (2) write and advocate the usage of a different init system. (3) a horrible death I'm certainly not opposed to having a better alternative, but the systemd people managed to write something that is better than sysvinit and made the package good enough to get people to use it. Now people complain that they're taking over the linux world by force, but they actually don't. They just provide something people want - it's not that they forced the gnome people at gunpoint to use systemd.
    - e7620 12y ago
      I happen to like modern daemontools-like init systems a lot, (runit, s6) but I use various init systems depending on what I want, and that's great IMO. The problem is that systemd is that is being forcefully pushed to all distros. For instance, by merging udev with systemd. We want to keep all the alternatives available.
      - Xylakant 12y ago
        I don't see any force involved. udev is their code. Don't like how they use it - fork. I understand your pain, I sometimes don't like the direction things that I use move or the ways they change, but I'm not sitting at the sidelines complaining about being pushed around. I get to use stuff others provided for free, I'm grateful for that and I either fork/change it or move on to something else. I'm not in a position to tell them what they should be spending their time on. Lennart Poettering could just stop developing and supporting udev any second, that's his personal decision and I couldn't say "he forced me to use windows" and I don't see anybody else could. Don't like the (maybe) coming systemd dependency for udev? Build the code to set up the bus yourself or pay someone or wait until someone knowledgeable gets sufficiently fed up and builds something. Same for the gnome dependency on systemd: Either accept it or contribute the time to make it work without while retaining the features it has.
        e7620 12y ago
        Not only udev, they roadmap is to pack the whole system so as to remove any difference between linux installs, their words, not mine. Currently, we can fork udev, but in the future, are you telling my to fork the whole operating system? And all applications that unnecessarily depend on said system? That would require millions of dollars, at least. Also, Windows can also be forked, by distributing patches instead of binaries. So that argument is a red herring, DOS has been forked before, and every proprietary application, but that doesn't mean I can't ask other developers a bit of respect for those of us who are using other init systems, I will maintain my software, just let me do that. All the discourse about democracy around GNU/Linux wasn't supposed to be summed up as "Fork or GTFO".
- zaphar 12y ago
  Thanks for the detailed response. It makes a certain amount of sense. The right course of action would be "meh, don't like systemd, I'll build a better offering." Talk is cheap, code is what counts. This statement seems to ignore Upstart though. Which is again from a very cursory examination exactly that. A better and more modular init without some of the complaints of systemd and yet is not gaining the mind share. Why isn't it considered a viable alternative?
  - Xylakant 12y ago
    Well, ubuntu used upstart and moved away, redhat/centos the same (though the centos 6.5 version of upstart was horribly outdated and crappy in terms of features). I actually kinda liked upstart, but I prefer systemd.
  - lomnakkus 12y ago
    Upstart's event-based model was semi-broken and AFAIR the original author admitted as much. (I believe he posted a message stating this to a maining list, but I cannot find it ATM.) Exposing the event model directly to the jobs also made reasoning about the current system state (which is what actually matters, not how we got there) tended to make upstart jobs a lot more complicated than necessary. (This is from memory, it's been ages since I actually looked at upstart jobs.)
    - the_why_of_y 12y ago
      Here are some specific examples: read comments #6 and #8 on this 5 year old unfixed bug and weep: https://bugs.launchpad.net/upstart/+bug/447654 https://bugs.launchpad.net/upstart/+bug/447654 in comment #7 on this (unfixed) bug Scott says it could be solved by having upstart use cgroups instead of ptrace to track processes: https://bugs.launchpad.net/upstart/+bug/406397 https://bugs.launchpad.net/upstart/+bug/406397
- makomk 12y ago
  > systemd provides you with the capability of starting a service "after network is up" so it needs to be able to tell "when network is up" That's not that hard once you have proper dependency-driven init, Gentoo's done it for a long time. You just need some way for the networking scripts to tell init that they're started now. Traditionally they'd do it by forking into the background once they're done starting just like any other init script. It's a bit harder if the network might not become available until after startup but not that much so.
  - kijin 12y ago
    > It's a bit harder if the network might not become available until after startup but not that much so. That rarely happens in server environments. I wonder how much of the recent debates about init systems is caused by the the rise of mobile consumer devices and developers' desire to cater to them. I care when my laptop takes more than a few seconds to start up, but I really don't care when one of my cloud servers takes a few minutes to start up. Network not ready yet? Meh, we could just sleep(10) and try again.
danieldk 12y ago
Socket activation: http://0pointer.de/blog/projects/socket-activation.html http://0pointer.de/blog/projects/socket-activation.html Socket activated containers: http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... Resource management: http://0pointer.de/blog/projects/resources.html http://0pointer.de/blog/projects/resources.html Better service information: http://0pointer.de/blog/projects/systemctl-journal.html http://0pointer.de/blog/projects/systemctl-journal.html In fact, the whole series is a recommended reading. Anyway, all these features requirer tighter integration with other components than SysV init. E.g. Linux' cgroups, services that support socket activation, integration with the logging system for status information, etc. Also, a lot of techniques in systemd were already pioneered in launchd on OS X since Tiger.
- exarch 12y ago
  <i>Socket activation</i> Because minimal boot time is way more important than predictable, repeatable functionality. It's totally cool if some other daemon lies about whether or not my service is actually listening while just happily buffering into /dev/null. This is all brilliant stuff and a huge step forward over UNIX.
  - teddyh 12y ago
    1. The purpose of systemd is not speed; it is simply a happy side-effect of its design. 2. Socket activation do 𝐧𝐨𝐭 buffer into /dev/null; that is simply FUD.
    - exarch 12y ago
      They don't buffer into /dev/null... until you fill the buffer. And the purpose of systemd, as near as I can tell, appears to be making my system into a Windows box, complete with binlogs.
      - deleted 12y ago
        [deleted]

by zaphar 12y ago

Xylakant 12y ago

I think it's not a problem primarily with "init" itself, but for example that systemd provides you with the capability of starting a service "after network is up" so it needs to be able to tell "when network is up". That's much easier to do if there's a canonical (from systemds POV) way to tell "what's networks state". That again leads to "bah, let's do that ourselves" so there's now an optional systemd component that does this, that, this and people start relying on those - systemd-logind is a requirement for gnome. You could write a replacement for systemd-logind that offers the same functionality, but as long as nobody does, you're stuck with systemd. The way I see it is that the systemd developers just plowed a way through the undergrowth and produced a suite of components that provide functionality that's appealing for people to build on. That's an offering that was accepted and now other people complain that the "systemd people are forcing their system on us and I want sysV init". The right course of action would be "meh, don't like systemd, I'll build a better offering." Talk is cheap, code is what counts. I very much like systemd. It's documentation is actually long, but clear and well structured. The init component is much simpler than the mess of shell scripts used before. There certainly are problems and issues with it, but I've met problems and issues with about any kind of software I had to deal with so far (including my own), so I take that as a given.

e7620 12y ago
Your response only makes sense if your alternatives are: (1) systemd, (2) sysvinit and (3) a horrible death. I know dozens of init systems that do much more, markedly better than systemd, and are modular so you can easily replace them when the time for a new technology comes. systemd is very recent, and still its opinionated architecture is showing inflexible to changes.
- Xylakant 12y ago
  no, the alternatives are (1) systemd (2) write and advocate the usage of a different init system. (3) a horrible death I'm certainly not opposed to having a better alternative, but the systemd people managed to write something that is better than sysvinit and made the package good enough to get people to use it. Now people complain that they're taking over the linux world by force, but they actually don't. They just provide something people want - it's not that they forced the gnome people at gunpoint to use systemd.
  - e7620 12y ago
    I happen to like modern daemontools-like init systems a lot, (runit, s6) but I use various init systems depending on what I want, and that's great IMO. The problem is that systemd is that is being forcefully pushed to all distros. For instance, by merging udev with systemd. We want to keep all the alternatives available.
    - Xylakant 12y ago
      I don't see any force involved. udev is their code. Don't like how they use it - fork. I understand your pain, I sometimes don't like the direction things that I use move or the ways they change, but I'm not sitting at the sidelines complaining about being pushed around. I get to use stuff others provided for free, I'm grateful for that and I either fork/change it or move on to something else. I'm not in a position to tell them what they should be spending their time on. Lennart Poettering could just stop developing and supporting udev any second, that's his personal decision and I couldn't say "he forced me to use windows" and I don't see anybody else could. Don't like the (maybe) coming systemd dependency for udev? Build the code to set up the bus yourself or pay someone or wait until someone knowledgeable gets sufficiently fed up and builds something. Same for the gnome dependency on systemd: Either accept it or contribute the time to make it work without while retaining the features it has.
      - e7620 12y ago
        Not only udev, they roadmap is to pack the whole system so as to remove any difference between linux installs, their words, not mine. Currently, we can fork udev, but in the future, are you telling my to fork the whole operating system? And all applications that unnecessarily depend on said system? That would require millions of dollars, at least. Also, Windows can also be forked, by distributing patches instead of binaries. So that argument is a red herring, DOS has been forked before, and every proprietary application, but that doesn't mean I can't ask other developers a bit of respect for those of us who are using other init systems, I will maintain my software, just let me do that. All the discourse about democracy around GNU/Linux wasn't supposed to be summed up as "Fork or GTFO".
zaphar 12y ago
Thanks for the detailed response. It makes a certain amount of sense. The right course of action would be "meh, don't like systemd, I'll build a better offering." Talk is cheap, code is what counts. This statement seems to ignore Upstart though. Which is again from a very cursory examination exactly that. A better and more modular init without some of the complaints of systemd and yet is not gaining the mind share. Why isn't it considered a viable alternative?
- Xylakant 12y ago
  Well, ubuntu used upstart and moved away, redhat/centos the same (though the centos 6.5 version of upstart was horribly outdated and crappy in terms of features). I actually kinda liked upstart, but I prefer systemd.
- lomnakkus 12y ago
  Upstart's event-based model was semi-broken and AFAIR the original author admitted as much. (I believe he posted a message stating this to a maining list, but I cannot find it ATM.) Exposing the event model directly to the jobs also made reasoning about the current system state (which is what actually matters, not how we got there) tended to make upstart jobs a lot more complicated than necessary. (This is from memory, it's been ages since I actually looked at upstart jobs.)
  - the_why_of_y 12y ago
    Here are some specific examples: read comments #6 and #8 on this 5 year old unfixed bug and weep: https://bugs.launchpad.net/upstart/+bug/447654 https://bugs.launchpad.net/upstart/+bug/447654 in comment #7 on this (unfixed) bug Scott says it could be solved by having upstart use cgroups instead of ptrace to track processes: https://bugs.launchpad.net/upstart/+bug/406397 https://bugs.launchpad.net/upstart/+bug/406397
makomk 12y ago
> systemd provides you with the capability of starting a service "after network is up" so it needs to be able to tell "when network is up" That's not that hard once you have proper dependency-driven init, Gentoo's done it for a long time. You just need some way for the networking scripts to tell init that they're started now. Traditionally they'd do it by forking into the background once they're done starting just like any other init script. It's a bit harder if the network might not become available until after startup but not that much so.
- kijin 12y ago
  > It's a bit harder if the network might not become available until after startup but not that much so. That rarely happens in server environments. I wonder how much of the recent debates about init systems is caused by the the rise of mobile consumer devices and developers' desire to cater to them. I care when my laptop takes more than a few seconds to start up, but I really don't care when one of my cloud servers takes a few minutes to start up. Network not ready yet? Meh, we could just sleep(10) and try again.

danieldk 12y ago

Socket activation: http://0pointer.de/blog/projects/socket-activation.html http://0pointer.de/blog/projects/socket-activation.html Socket activated containers: http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... Resource management: http://0pointer.de/blog/projects/resources.html http://0pointer.de/blog/projects/resources.html Better service information: http://0pointer.de/blog/projects/systemctl-journal.html http://0pointer.de/blog/projects/systemctl-journal.html In fact, the whole series is a recommended reading. Anyway, all these features requirer tighter integration with other components than SysV init. E.g. Linux' cgroups, services that support socket activation, integration with the logging system for status information, etc. Also, a lot of techniques in systemd were already pioneered in launchd on OS X since Tiger.

exarch 12y ago
<i>Socket activation</i> Because minimal boot time is way more important than predictable, repeatable functionality. It's totally cool if some other daemon lies about whether or not my service is actually listening while just happily buffering into /dev/null. This is all brilliant stuff and a huge step forward over UNIX.
- teddyh 12y ago
  1. The purpose of systemd is not speed; it is simply a happy side-effect of its design. 2. Socket activation do 𝐧𝐨𝐭 buffer into /dev/null; that is simply FUD.
  - exarch 12y ago
    They don't buffer into /dev/null... until you fill the buffer. And the purpose of systemd, as near as I can tell, appears to be making my system into a Windows box, complete with binlogs.
    - deleted 12y ago
      [deleted]