10 ms·

I get the impression which is admittedly informed by very cursory examination of the issues that ripping systemd out may be far more difficult than ripping say,

I get the impression which is admittedly informed by very cursory examination of the issues that ripping systemd out may be far more difficult than ripping say, Upstart. Definitely. But this is probably true for many things at a low-level in the stack. E.g., it would also be hard to replace D-BUS or the Linux kernel (as evidenced by the fact that Debian/KFreeBSD will probably not be in Jessy). I agree that it is a worry. But you can never make progress without taking any risks. We have tried 'fully isolated init' for years and it does not really work for modern systems/applications.

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.
- 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]
exarch 12y ago
Why make apples and oranges comparisons to the kernel? It isn't that hard to replace sysvinit. Why should sysvinit's replacement regress in this area?
- TheLoneWolfling 12y ago
  Because systemd is, although people argue this point, essentially monolithic. Sure, in theory it's modular, but the module dependencies are so intertwined that good luck using any of the modules without the entire thing - or writing so many compatibility shims that you might as just write the module yourself. And that's even assuming a compatibility shim can be written without essentially reimplementing the entire module. It prevents incremental replacements. And it keeps expanding to pull more and more essentially unrelated functionality into itself. It's "you're stuck with this architecture unless you redo the whole darn thing". And, again, systemd keeps getting larger and larger. As you say, it isn't that hard to replace sysvinit. But to replace systemd you need to replace / write shims for far more things. (Your window manager? I wish I was joking...)
  - thoughtpolice 12y ago
    I'm confused by the Window manager comment. As far as I understand, essentially, ConsoleKit development was stopped, and work on systemd-logind etc began as a better way forward, rather than rewriting ConsoleKit. During this timeframe, GNOME developed integration with systemd-logind, similarly to how it developed ConsoleKit support beforehand. And in fact the ConsoleKit backend was supported for a while afterwords. But this is no longer the case as nobody was willing to support it and maintain it in upstream GNOME. So it was removed. So I'm confused by the comment. Your insinuation seems to be this is somehow the fault of systemd for requiring a shim for things like GNOME, if you want them to work without systemd itself as PID 1. But the reality is that any software which has an API dependency that you want to replace is either going to A) need a shim or B) need a replacement that is also supported by the project. And the ship already sailed on option #2 - ConsoleKit held on until upstream decided to remove the bitrot. I find this line of argument very weird. Indeed, this whole scenario seems to be a story of exactly how FOSS often works and how we envision it to work: people do the work, and in some cases they may compete with or achieve superiority over another project. And other people adopt that work and use it for their own work later on. And people may develop replacements that are or are-not compatible as they see fit. It's probably very true that GNOME and systemd developers worked together to reach agreements on systemd-logind, so it could be used by both and they could understand each others needs. But why is it systemd's fault if nobody stepped up to maintain ConsoleKit, and systemd's fault if GNOME decided to remove support for something they saw as bitrot? Am I missing something extremely key here? Or do you consider this nobody's fault and just something that happened?

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.
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]

exarch 12y ago

Why make apples and oranges comparisons to the kernel? It isn't that hard to replace sysvinit. Why should sysvinit's replacement regress in this area?

TheLoneWolfling 12y ago
Because systemd is, although people argue this point, essentially monolithic. Sure, in theory it's modular, but the module dependencies are so intertwined that good luck using any of the modules without the entire thing - or writing so many compatibility shims that you might as just write the module yourself. And that's even assuming a compatibility shim can be written without essentially reimplementing the entire module. It prevents incremental replacements. And it keeps expanding to pull more and more essentially unrelated functionality into itself. It's "you're stuck with this architecture unless you redo the whole darn thing". And, again, systemd keeps getting larger and larger. As you say, it isn't that hard to replace sysvinit. But to replace systemd you need to replace / write shims for far more things. (Your window manager? I wish I was joking...)
- thoughtpolice 12y ago
  I'm confused by the Window manager comment. As far as I understand, essentially, ConsoleKit development was stopped, and work on systemd-logind etc began as a better way forward, rather than rewriting ConsoleKit. During this timeframe, GNOME developed integration with systemd-logind, similarly to how it developed ConsoleKit support beforehand. And in fact the ConsoleKit backend was supported for a while afterwords. But this is no longer the case as nobody was willing to support it and maintain it in upstream GNOME. So it was removed. So I'm confused by the comment. Your insinuation seems to be this is somehow the fault of systemd for requiring a shim for things like GNOME, if you want them to work without systemd itself as PID 1. But the reality is that any software which has an API dependency that you want to replace is either going to A) need a shim or B) need a replacement that is also supported by the project. And the ship already sailed on option #2 - ConsoleKit held on until upstream decided to remove the bitrot. I find this line of argument very weird. Indeed, this whole scenario seems to be a story of exactly how FOSS often works and how we envision it to work: people do the work, and in some cases they may compete with or achieve superiority over another project. And other people adopt that work and use it for their own work later on. And people may develop replacements that are or are-not compatible as they see fit. It's probably very true that GNOME and systemd developers worked together to reach agreements on systemd-logind, so it could be used by both and they could understand each others needs. But why is it systemd's fault if nobody stepped up to maintain ConsoleKit, and systemd's fault if GNOME decided to remove support for something they saw as bitrot? Am I missing something extremely key here? Or do you consider this nobody's fault and just something that happened?