4 ms·

Did you miss the systemd drama? There was a new distro created out of it...

by doublepg23 6y ago

deadbunny 6y ago
And I'm sure the 3 people using it really like it.
- qz2 6y ago
  No point in being popular and unhappy :)
kbenson 6y ago
Systemd in general makes me sad. It feels like the complete rewrite that happens only for the people doing to finally learn all the project needs at the end, and immediately need another rewrite, but nobody has the stomach for it now. Don't get me wrong, I think the authors are and we're probably the best authorities on what is and was needed in an init system, but the problem space was so poorly documented and understood because of all the crazy custom she'll init scripts people were using that they just kept having to tack on weird directives in piecemeal ways, until were left with what we have now. What the world needs is for the systemd authors to take all that knowledge an apply it to a new init system in a sane way, but nobody had the will to go through that again, most likely especially them.
- 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
michaelmrose 6y ago
If you are a regular end user You can safely ignore it and just use systemd or not and not worry too much either way. Whats the worst case scenario? You find that you don't like the choice you made and spend 2 hours switching to the other option?
- rodgerd 6y ago
  More like "oh hey encrypted LVM doesn't work and the package maintainer is refusing to allow fixes because he hates systemd and is indulging in maintainer terrorism to try and block it."
  - michaelmrose 6y ago
    Maintainer terrorism? Can we keep this discussion rational.
pessimizer 6y ago
The systemd drama is redhat drama. The pulseaudio drama was redhat drama. The glibc drama was redhat drama. This is redhat drama. It's not all redhat drama, sometimes it's Microsoft drama or Gnome drama, but it's funny: all of the sources have really good relationships with each other and commingle their drama until it's nearly indistinguishable. Get involved with one of them and you now have dependencies on all of them.
- Spivak 6y ago
  The specific systemd drama the parent is referring to was really Debian drama and the requirements put on maintainers to support alternative init systems. If upstream drops support for non-systemd setups do the maintainers have patch in support? If upstream now has a hard dependency on systemd do maintainers have to patch it out? Red Hat wasn't involved in any of the drama outside of being the ones writing and funding OSS software for themselves.
  - detaro 6y ago
    But as a user I basically didn't have to care about the details and the "drama" aspects of that drama (I had the result to deal with of course)
  - jasonjayr 6y ago
    Redhat was involved because they heavily maintain some of the upstream packages that put in a hard systemd/logind requirement (GNOME), thus forcing Debian into the uncomfortable position of taking on a large compatibility project, when upstream could have instead taken small patches to continue to maintain compatibility with non-systemd systems.
    - cycloptic 6y ago
      Which packages had a hard systemd/logind requirement upstream? As far as I understand it, GNOME still gets upstream patches from BSD developers and is still supported there. (Some Debian packages do have hard dependencies on systemd, but this is a downstream packaging issue)

Did you miss the systemd drama? There was a new distro created out of it...

deadbunny 6y ago

And I'm sure the 3 people using it really like it.

qz2 6y ago
No point in being popular and unhappy :)

kbenson 6y ago

Systemd in general makes me sad. It feels like the complete rewrite that happens only for the people doing to finally learn all the project needs at the end, and immediately need another rewrite, but nobody has the stomach for it now. Don't get me wrong, I think the authors are and we're probably the best authorities on what is and was needed in an init system, but the problem space was so poorly documented and understood because of all the crazy custom she'll init scripts people were using that they just kept having to tack on weird directives in piecemeal ways, until were left with what we have now. What the world needs is for the systemd authors to take all that knowledge an apply it to a new init system in a sane way, but nobody had the will to go through that again, most likely especially them.

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

michaelmrose 6y ago

If you are a regular end user You can safely ignore it and just use systemd or not and not worry too much either way. Whats the worst case scenario? You find that you don't like the choice you made and spend 2 hours switching to the other option?

rodgerd 6y ago
More like "oh hey encrypted LVM doesn't work and the package maintainer is refusing to allow fixes because he hates systemd and is indulging in maintainer terrorism to try and block it."
- michaelmrose 6y ago
  Maintainer terrorism? Can we keep this discussion rational.

pessimizer 6y ago

The systemd drama is redhat drama. The pulseaudio drama was redhat drama. The glibc drama was redhat drama. This is redhat drama. It's not all redhat drama, sometimes it's Microsoft drama or Gnome drama, but it's funny: all of the sources have really good relationships with each other and commingle their drama until it's nearly indistinguishable. Get involved with one of them and you now have dependencies on all of them.

Spivak 6y ago
The specific systemd drama the parent is referring to was really Debian drama and the requirements put on maintainers to support alternative init systems. If upstream drops support for non-systemd setups do the maintainers have patch in support? If upstream now has a hard dependency on systemd do maintainers have to patch it out? Red Hat wasn't involved in any of the drama outside of being the ones writing and funding OSS software for themselves.
- detaro 6y ago
  But as a user I basically didn't have to care about the details and the "drama" aspects of that drama (I had the result to deal with of course)
- jasonjayr 6y ago
  Redhat was involved because they heavily maintain some of the upstream packages that put in a hard systemd/logind requirement (GNOME), thus forcing Debian into the uncomfortable position of taking on a large compatibility project, when upstream could have instead taken small patches to continue to maintain compatibility with non-systemd systems.
  - cycloptic 6y ago
    Which packages had a hard systemd/logind requirement upstream? As far as I understand it, GNOME still gets upstream patches from BSD developers and is still supported there. (Some Debian packages do have hard dependencies on systemd, but this is a downstream packaging issue)