5 ms·

Sure. What I think is unclear that I intend to highlight is that systemd (and yes, upstart) have intentionally and unnecessarily created this technical conflict

Sure. What I think is unclear that I intend to highlight is that systemd (and yes, upstart) have intentionally and unnecessarily created this technical conflict.

vacri 13y ago
well, I wouldn't call the technical conflict unnecessary - if there wasn't a need for a more featureful init system, then there wouldn't have been a motive to write a new one. As for the social conflict, that's just what you get with social groups experiencing change.
- throwaway092834 13y ago
  Your assertion is strictly false. All features of this new process invocation system could be implemented without making a "new init system." That's my primary point in commenting here. It is a false dichotomy.
  - mercurial 13y ago
    > All features of this new process invocation system could be implemented without making a "new init system." Er, no. A major feature of systemd is that it is declarative. You have hooks for running custom commands, but a unit file is declarative and easy to parse. If you want to acquire more intelligence about an init script, you have to resort to disgusting hacks like parsing comments in order to get a dependency system working. And socket-based activation? Sysvinit is a dead end. It's the counter to "keep it simple, stupid": when you fail to capture enough information in your "simple" model, you are going to end up with more issues than if you had created a slightly more complex system.
    - icebraining 13y ago
      I think the point is that you could have the old init system launch systemd, which would then work as it pleased.
      - FooBarWidget 13y ago
        Then you have two init systems. That's even more complicated than having only systemd.
        throwaway092834 13y ago
        We already do. I think most people in this discussion aren't realizing that the current sysV init system is an extremely small pid 1 /sbin/init, and most of the logic in external rc scripts. Moving rc scripts to systemd declarative syntax is fine. The important part with respect to software architecture is less complexity in pid 1. Subprocesses of init can be safely updated and restarted. More code in init is a real problem -- that's why systemd as pid 1 is controversial.
        mercurial 13y ago
        At the same time, there is a point to be made for having things in a single process - this makes it much easier to ensure that the crucial parts of the init system are available and working.
        throwaway092834 13y ago
        Can you elaborate? I don't understand this perspective.
      - mercurial 13y ago
        I'm not sure this was the point of parent, but anyway, why would you want something like that? It's not like sysvinit has any redeeming feature, and you would still want to have systemd .service files. I could understand an argument like "/bin/systemd does too many things and ought to be split up more", but the rationale for having bad old sysvinit launch /etc/init.d/systemd.sh escapes me. Not to mention that you definitely don't want both systemd and sysvinit to attempt to launch scripts in /etc/init.d, when they don't have a .service...
        13y ago

Sure. What I think is unclear that I intend to highlight is that systemd (and yes, upstart) have intentionally and unnecessarily created this technical conflict.

vacri 13y ago

well, I wouldn't call the technical conflict unnecessary - if there wasn't a need for a more featureful init system, then there wouldn't have been a motive to write a new one. As for the social conflict, that's just what you get with social groups experiencing change.

throwaway092834 13y ago
Your assertion is strictly false. All features of this new process invocation system could be implemented without making a "new init system." That's my primary point in commenting here. It is a false dichotomy.
- mercurial 13y ago
  > All features of this new process invocation system could be implemented without making a "new init system." Er, no. A major feature of systemd is that it is declarative. You have hooks for running custom commands, but a unit file is declarative and easy to parse. If you want to acquire more intelligence about an init script, you have to resort to disgusting hacks like parsing comments in order to get a dependency system working. And socket-based activation? Sysvinit is a dead end. It's the counter to "keep it simple, stupid": when you fail to capture enough information in your "simple" model, you are going to end up with more issues than if you had created a slightly more complex system.
  - icebraining 13y ago
    I think the point is that you could have the old init system launch systemd, which would then work as it pleased.
    - FooBarWidget 13y ago
      Then you have two init systems. That's even more complicated than having only systemd.
      - throwaway092834 13y ago
        We already do. I think most people in this discussion aren't realizing that the current sysV init system is an extremely small pid 1 /sbin/init, and most of the logic in external rc scripts. Moving rc scripts to systemd declarative syntax is fine. The important part with respect to software architecture is less complexity in pid 1. Subprocesses of init can be safely updated and restarted. More code in init is a real problem -- that's why systemd as pid 1 is controversial.
        mercurial 13y ago
        At the same time, there is a point to be made for having things in a single process - this makes it much easier to ensure that the crucial parts of the init system are available and working.
        throwaway092834 13y ago
        Can you elaborate? I don't understand this perspective.
    - mercurial 13y ago
      I'm not sure this was the point of parent, but anyway, why would you want something like that? It's not like sysvinit has any redeeming feature, and you would still want to have systemd .service files. I could understand an argument like "/bin/systemd does too many things and ought to be split up more", but the rationale for having bad old sysvinit launch /etc/init.d/systemd.sh escapes me. Not to mention that you definitely don't want both systemd and sysvinit to attempt to launch scripts in /etc/init.d, when they don't have a .service...
      - 13y ago