systemd became the de-facto default init sys because Distro Maintainers have chosen it. I posted this link here before, but I will happily post it again: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...
Such a thing doesn't happen if the thing offered isn't an improvement over what was before.
As a matter of fact, this doesn't even happen if the thing offered is only a small improvement. We have seen this time and time again in Programmig languages: Exciting, clever new things that offer real advantages vanishing into obscurity because while they were better, they were not better by a large enough margin.
Diversity is great if it offers advantages. Different kinds of RDBMS are a good example. Different kinds of shells. Rust being there as a C alternative, Go being there as a Java alternative, Julia as a possible Python alternative, WASM instead of JS. All great.
But keeping something mainstream just because its different, adds no value. People can and do still use other init systems, but I am very glad I no longer have to wrestle 400-line sh init scripts on my production servers.
It does happen sometimes. GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted.
And improvement is subjective. Maybe systemd made maintainers' lives better. But it also introduced big nasty software full of bugs that discourages hacking by users. Many users consider that a deterioration of the Linux ecosystem.
I'll take wrestling a bug in a 400-line shell script to wrestling a bug in the systemd C code and compiling my fixed version.
If a bug happens in this code, everything is affected, everyone screams at the same time, it is obvious there is a bug, and once its fixed, its fixed everywhere and for every service.
If there is a bug in one of the old init scripts, it may go unnoticed for several years, until suddenly someone needs service Bar depend on Service Foo, but Bar cannot figure out the state of Foo correctly, and good luck to whoever has to solve this: unless the combination of services is a popular one, whoever has this problem, is likely the first to encounter this, there is no general outcry because nothing else is affected by it. A fix may not be forthcoming because the behavior may not even be considered a bug (the maintainers of Foo and Bar may simply disagree how some service state is to be communicated), and usually someone has to trawl through a pile of sh scripts (because backward compatible all the way to the 90s it has to be!) and implements a fix, which then gets destroyed by an update when the guy who fixed it is on holiday.
As someone who has been that exact guy, I have to say sorry but no, I don't want to do this any more.
Shell scripts are tunable to the specific system. If a rare bug is in a shell script, I can usually find and fix it, unless the script is insane, in which case I can write a sane one.
If a bug is in systemd, I can't easily fix it myself. I now have to fight upstream to recognize my issue and fix it for me. I don't have a good experience with this. Nowadays I'd rather write a small script to work around that bug if possible. Much faster and much more effective.
That's not true. You can do as you would with the shell script and patch it in your local copy. If this is too much hassle then that shell script workflow shouldn't be broken by systemd and you can always fall back to it. It's still possible to run shell scripts as systemd units. You could also run another service manager as a systemd unit as another workaround.
Also, in my experience, if you're fixing an actual crash, those patches are really likely to get accepted. Upstream appreciates that, I haven't seen them fight anyone over an easily verified issue. If you're submitting giant 10,000 line patches that change the public interfaces and cause regressions, that's a different story.
Are we thinking of the same thing? GTK3 had a much better theming system, new widgets, support for high DPI displays, improved rendering, support for animations, and a lot of other things. GNOME 3 had a much more streamlined design too. You may not have liked them but there were plenty of new features to offer.
>I'll take wrestling a bug in a 400-line shell script to wrestling a bug in the systemd C code and compiling my fixed version.
I wouldn't, once you fix the bug in the C code it's fixed for everything. The bugs in the shell scripts keep needing to be fixed over and over again, because copying code around in shell scripts is really common. There is also a line to be drawn where low-level code should be written in C and I think this is well past that line. Service script code is usually privileged and runs as root so the utility of making it hackable seems pretty small. I expect you'd agree running bash scripts inside the kernel is a bad idea too.
Fixing a bug in shell script, even if 30 times, is still much easier than downloading, understanding modifying and compiling and deploying 4000 files and 1.6 million lines of systemd C code. There is an obvious cost/benefit factor here.
If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational. Not with the ever-expanding pile of prototype-level software we got. I'm not reading that code, not even for money.
For desktop app developers? There were a lot of API refinements and enhancements to the widgets too, I didn't mention them all because there's far too many.
>4000 files and 1.6 million lines of systemd C
Just FYI these figures are incorrect, you're likely including the tests, documentation and data files. Running cloc on the current systemd code base I get around 2100 .c and .h files and 520,000 lines of C. That also includes all the other components too, not just the service manager. The service manager is a small fraction of that, it's only around 150 files including the headers.
>There is an obvious cost/benefit factor here.
From the perspective of a distribution I think it's much more cost effective for them to fix this once in C. To you what looks like just 30 shell scripts can quickly multiply into the thousands when you have to consider this is across all users of that distribution who might all have the same buggy set of 30 shell scripts but with different ad-hoc fixes applied.
>If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational.
I think if you actually look at it, you'll find this is already what it does. That's what I saw when I actually took a few hours to familiarize myself with the code.
Because they were forced to choose it due to vendorlock and many other projects became dependent on systemd. Unsystemding everything would be very expensive.
Same problem will be with snap and flatpak.
Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager.
> Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager.
Those are even worse than tarball bundles. Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Centralized delivery is outmoded, future is decentralized distributed distribution. Both package managers deprive me of control over my system. I don't like the aggressiveness with which these projects are enforced. When Let's Encrypt switched to Spat as the only official distribution of their tool, I had to switch to alternative tool acme.sh instead of installing bloated snapd on my server.
Under some circumstances (not all), GNOME has a dependency on logind. If you're in one of those circumstances, you can use elogind as a drop-in replacement. That's far from having a dependency on systemd.
>Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Both package managers deprive me of control over my system.
I don't think snap lets you deploy your own repository, but for Flatpak this is very very wrong. Check here: https://docs.flatpak.org/en/latest/hosting-a-repository.html
While I agree with the broader point about (any) monoculture, I don't think that this can be blamed on systemd.
Systemd did not itself create the monoculture. When it came up, it was one of a multiculture. Distro maintainers then chose it en masse so that it became a de facto monoculture.
I'm not saying that necessarily makes it the best choice, though.
On a slightly different note, I find such comments funny in a way, because one of the reasons given for Linux's lack of market share on "the desktop" and, broadly, as a platform for "enterprise" software (think Adobe, etc.) is because the ecosystem is so fragmented. So, essentially, the platform isn't considered because it's not a monoculture (as would be Windows and Mac).
A normal user will never really link the features they see or do not see back to the init system. I'll draw a parallel with the worst subsystem being cut out of modern Linux - X Windows.
As far as I can tell Linux is missing good macro systems that can record actions taken by a user, then replay them. For loops for non programmers, basically. This isn't because the idea is radical, but because implementing the vision historically needed a programmer to understand X - which is too hard. There is a hidden link between the subsystem being awful and programs not existing.
Similarly, the monoculture created by systemd is influencing how the future of Linux evolves by making some things easier and others harder. End users won't be able to detect those influences though, and unlike X's problems systemd is likely a net positive. Systemd easily improves on the old init scripts.