4 ms·

Who is asking for a rewrite of systemd? From what I have seen, there are two camps: Either you believe systemd is fine, or you believe sysvinit never should hav

by shawnz 6y ago

Who is asking for a rewrite of systemd? From what I have seen, there are two camps: Either you believe systemd is fine, or you believe sysvinit never should have been replaced or should have been replaced with something totally different than systemd with a much smaller scope.

michaelmrose 6y ago
There are 2 major problems cache invalidation, naming things and off by one errors.
kbenson 6y ago
> Who is asking for a rewrite of systemd? Me? > Either you believe systemd is fine I don't think anyone really believes that. They just believe the benefits it provides over sysvinit are real and generally worthwhile in most cases. Systemd has many warts. I'm not sure anyone refuses to believe that. > or you believe sysvinit never should have been replaced Yep, there's plenty of people that believe that. I've had discussions with them here. > or should have been replaced with something totally different than systemd with a much smaller scope. I'm sure there are people that believe this. Personally I think it's mostly due to being unaware of some facets of the situation. Systemd itself was much smaller in scope originally. The scope increased as they ran into things that it really made more sense to combine than leave separate. A different project may have chosen to leave those things out when encountered, but then it would have all the problems systemd tried to avoid. That actually aligns quite a bit with my argument. With time and foresight (which wasn't necessarily possible the first time, since this is the first time an init system has tried to accomplish these goals that wasn't already intended for a tightly coupled system like Windows or MacOS), they could plan: 1) A more sane unit file syntax that wasn't ambiguous and confusing because of accreted features (After vs Wants, etc). 2) A sane API for subsumed services so if someone doesn't want to use the reference version provided by systemd, it's straightforward to drop in something else as long as you an make it talk systemd (or provide an interop layer). E.g. DHCP client, login managers, etc. This may or may not be done to some acceptable level currently, I'm not sure (but I suspect it depends on the service). 3) Take advantage of even more new kernel features for additional benefits (it's eBPF all the way down). But here's the thing, while I think everyone would agree that something like systemd that's more modular in a well defined way and more sanely configured and documented would be preferable to systemd (I mean why not, it's basically "systemd but better" which is preferably even if you don't like systemd), I don't think anyone really wants to go through the process of either developing, integrating, or learning a new system at this point. We're all too exhausted. And that's a shame, because what we all have now is the mad scientist's awesome flying car. Sure, it does amazing things, and you can do things that would be near impossible in the past, but you control part of it with your thighs and elbows and there are two steering wheels, and the one on the ceiling is the one that steers it like a car.
- pjmlp 6y ago
  > hich wasn't necessarily possible the first time, since this is the first time an init system has tried to accomplish these goals that wasn't already intended for a tightly coupled system like Windows or MacOS If we ignore similar systems on big iron UNIX and mainframes.
  - kbenson 6y ago
    Are you making a case that big iron UNIX systems and mainframes had something with as many features and that tried to accomplish something similar in score to systemd (that is, far beyond what sysvinit does)? I'm happy to hear of them, because I'm ignorant of them if they exist.
    - pjmlp 6y ago
      I cam not counting feature lists, but having sysvinit like replacements, certainly. https://en.wikipedia.org/wiki/Launchd https://en.wikipedia.org/wiki/Launchd https://en.wikipedia.org/wiki/Service_Management_Facility https://en.wikipedia.org/wiki/Service_Management_Facility https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzal2/rzal2ipltypeco.htm https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rza...
      - kbenson 6y ago
        I was specifically comparing it not just to sysvinit replacements, of which there are many, but trying to bring a lot more features. Launchd doesn't count, I already mentioned MacOS specifically to account for it. :) SMF has some features beyong sysvinit that systemd also provides, but I'm not familiar enough with it's advanced usage to know how much beyond the obvious ones (service restart, etc) it does, so I'll try to take a look. I don't know anything about the IBM one, so that's worth taking a look at. Thanks!
- shawnz 6y ago
  Personally I do think it's fine and I don't think that a technology having warts (which is essentially a given for any reasonably complex software) indicates a need for a rewrite. The rewrite will have warts too, just like sysvinit had warts.

by shawnz 6y ago

michaelmrose 6y ago

There are 2 major problems cache invalidation, naming things and off by one errors.

kbenson 6y ago

> Who is asking for a rewrite of systemd? Me? > Either you believe systemd is fine I don't think anyone really believes that. They just believe the benefits it provides over sysvinit are real and generally worthwhile in most cases. Systemd has many warts. I'm not sure anyone refuses to believe that. > or you believe sysvinit never should have been replaced Yep, there's plenty of people that believe that. I've had discussions with them here. > or should have been replaced with something totally different than systemd with a much smaller scope. I'm sure there are people that believe this. Personally I think it's mostly due to being unaware of some facets of the situation. Systemd itself was much smaller in scope originally. The scope increased as they ran into things that it really made more sense to combine than leave separate. A different project may have chosen to leave those things out when encountered, but then it would have all the problems systemd tried to avoid. That actually aligns quite a bit with my argument. With time and foresight (which wasn't necessarily possible the first time, since this is the first time an init system has tried to accomplish these goals that wasn't already intended for a tightly coupled system like Windows or MacOS), they could plan: 1) A more sane unit file syntax that wasn't ambiguous and confusing because of accreted features (After vs Wants, etc). 2) A sane API for subsumed services so if someone doesn't want to use the reference version provided by systemd, it's straightforward to drop in something else as long as you an make it talk systemd (or provide an interop layer). E.g. DHCP client, login managers, etc. This may or may not be done to some acceptable level currently, I'm not sure (but I suspect it depends on the service). 3) Take advantage of even more new kernel features for additional benefits (it's eBPF all the way down). But here's the thing, while I think everyone would agree that something like systemd that's more modular in a well defined way and more sanely configured and documented would be preferable to systemd (I mean why not, it's basically "systemd but better" which is preferably even if you don't like systemd), I don't think anyone really wants to go through the process of either developing, integrating, or learning a new system at this point. We're all too exhausted. And that's a shame, because what we all have now is the mad scientist's awesome flying car. Sure, it does amazing things, and you can do things that would be near impossible in the past, but you control part of it with your thighs and elbows and there are two steering wheels, and the one on the ceiling is the one that steers it like a car.

pjmlp 6y ago
> hich wasn't necessarily possible the first time, since this is the first time an init system has tried to accomplish these goals that wasn't already intended for a tightly coupled system like Windows or MacOS If we ignore similar systems on big iron UNIX and mainframes.
- kbenson 6y ago
  Are you making a case that big iron UNIX systems and mainframes had something with as many features and that tried to accomplish something similar in score to systemd (that is, far beyond what sysvinit does)? I'm happy to hear of them, because I'm ignorant of them if they exist.
  - pjmlp 6y ago
    I cam not counting feature lists, but having sysvinit like replacements, certainly. https://en.wikipedia.org/wiki/Launchd https://en.wikipedia.org/wiki/Launchd https://en.wikipedia.org/wiki/Service_Management_Facility https://en.wikipedia.org/wiki/Service_Management_Facility https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzal2/rzal2ipltypeco.htm https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rza...
    - kbenson 6y ago
      I was specifically comparing it not just to sysvinit replacements, of which there are many, but trying to bring a lot more features. Launchd doesn't count, I already mentioned MacOS specifically to account for it. :) SMF has some features beyong sysvinit that systemd also provides, but I'm not familiar enough with it's advanced usage to know how much beyond the obvious ones (service restart, etc) it does, so I'll try to take a look. I don't know anything about the IBM one, so that's worth taking a look at. Thanks!
shawnz 6y ago
Personally I do think it's fine and I don't think that a technology having warts (which is essentially a given for any reasonably complex software) indicates a need for a rewrite. The rewrite will have warts too, just like sysvinit had warts.