Did you miss the systemd drama? There was a new distro created out of it...
back
4 comments
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.
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.
There are 2 major problems cache invalidation, naming things and off by one errors.
> 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.
> 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.
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.
I cam not counting feature lists, but having sysvinit like replacements, certainly.
https://en.wikipedia.org/wiki/Launchd
https://en.wikipedia.org/wiki/Service_Management_Facility
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rza...
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!
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.
It's not that it has warts, it's that it's overly complex for what it does, and beyond the initial feature set wasn't so much planned as organically grown.
I think the best and most thorough explanation of this is gotten through reading the systemd retrospective[1] that someone posted earlier this year. What becomes abundantly clear when reading it is what I think I was trying to express above, that there is so much that could be better in systemd but that it's hampered by it's own legacy baggage, which accumulated very quickly and very soon after the first implementation was released.
That link is a long read, but if you have any time or effort invested into systemd and systems that use it, and find yourself having to create unit files or diagnose weirdness with services, it's very worthwhile to read if you haven't already.
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.
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.
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.
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)
I don't want to leave my hearsay uncited, but try here:
https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...
Slightly more recently:
https://digitizor.com/gnome-linux-only/
This was an eternity ago in internet time, and I'm not all up and up on BSD development, but maybe enough folks are keeping it going on BSD nowadays?
Interesting, I checked and the only upstream component of GNOME I could find that requires systemd and doesn't have a compile flag for it is gdm. This isn't required to start GNOME (you can use any other display manager) and FreeBSD/OpenBSD seem to be maintaining consolekit patches for it downstream. So I see why there is little incentive to fix this upstream. (On non-systemd Linux distros the focus has shifted to staying compatible with elogind, but that doesn't work on BSD)
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)
And I'm sure the 3 people using it really like it.
No point in being popular and unhappy :)
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?
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."
Maintainer terrorism? Can we keep this discussion rational.