Almost like with etcd, it started simple, but got expanded into a huge incomprehensible monster by the original developers. Politically and business-wise, systemd is a clear win for Lennaert and his clique, as well as the whole Redhat/IBM.
But I am sure that future historians will view the impact of systemd on computing as largely negative.
The systemd/RH relationship is complicated. Red Hat doesn't use most of systemd's features--they don't even ship systemd-networkd on RHEL8, preferring NetworkManager instead. On the flipside, I see more use of systemd's features on Arch or Debian.
I don't think you can frame systemd as some kind of RH trojan horse when so little of it makes it into RHEL/Fedora.
So while Arch ships everything, and being Arch it doesn't really have a default, its recommended networking system isn't systemd-networkd but rather netctl, which is basically everything systemd-networkd should have been.
`netctl` was explicitly written because systemd didn't have a network daemon. The past 3-4 years the community has in general recommended against using `netctl`.
It was never removed from the ISO because the releng maintainer didn't put that much thought into it, but I'm happy to tell you `netctl` was replaced with `iwd` on this month ISO release.
> But I am sure that future historians will view the impact of systemd on computing as largely negative.
I don't really think so. They probably will point out a lot problems with at some point somehow got fixed but it should be net-neutral or positive.
The thing is todays linux is running manny services and to do so nicely you want to have some form of service manager which does startup/shutdown/restart/circicute braking and helps with interconnect. Which is what systemd does and what mainly differentiates it from many previous systems which where mainly "just" start-up helpers. Through there are IMHO a large amount of problems with systemd the general approach is IMHO good, just the implementation isn't so much.
Sorry, no. Systemd doesn't add anything for service management that didn't previously exist elsewhere other than the unit file syntax for service definition. What it did is pull as many disparate aspects of "how do you run a thing" under its umbrella as it could, so it controls as much of the environment as possible and doesn't have to care about playing nice with anyone else. That's the general approach.
It's a logical fallacy to assume, because systemd was the thing that came along and resulted in the problems in sysv being fixed, that systemd's approach or implementation were necessary, desirable, or the best option available.
But I am sure that future historians will view the impact of systemd on computing as largely negative.