You can, though? And many distros do by default.
Don’t like systemd-boot? You can replace it with grub.
Don’t like systemd-networkd? You can replace it with networkctl. Want to use it but prefer to handle Wireguard tunnels with wg-quick? Fine!
Don’t like systemd-resolved? You can replace it with dnsmasq.
Don’t like systemd-cryptsetup? systemd won’t care if some other system takes care of your LUKS partitions.
Etc, etc.
It's ridiculous to imagine that no program is allowed to depend on SystemD.
There are multiple libc implementations. libc independence is important and valuable. You'll probably find a "hard dependency on glibc" list in the documentation of e.g. Alpine.
> Or "hard dependency on Bash"?
Ubuntu will have a list from when they switched to ash as /bin/sh. Again, multiple implementations and independence are important, and something the linux community generally cares about.
You could make another SystemD implementation if you really wanted. The point is that there are plenty of APIs - even ones with a single implementation - that nobody bats an eye about programs having a "hard dependency" on, but suddenly for SystemD it's apparently a big issue?
It's bullshit technical excuses to hide the real reasons people object to SystemD, which are more embarrassing.
No you can't, because they don't offer stable interfaces as a matter of deliberate policy.
Or maybe the maintainers are I don’t know do you have links to show this is the case?
Systemd is used by all major linux flavors because it’s the best solution for the problems it solves.
The distro maintainers are too smart to be stuck with systemd against their will.
And it’s linux …. make a better solution, if it’s truly better it’ll be used.
Systemd was minority pretty much till GNOME 3.8 introduced super-hard dependencies on it through an interface that was supposedly documented (Ubuntu sunk a bunch of money trying to keep alternative implementation running).
For many a distro, it became a question - "do we include GNOME, or do we drop it?" and that was impetus to move to systemd
> This is really unfortunate, but GNOME 3.8 does not require logind. I discussed the non-dependency of logind+systemd on #gentoo-desktop and why they thought different. Apparently GDM 3.8 assumes that an init system will also clean up any processes it started. This is what systemd does, but OpenRC didn’t support that.
Systemd was adopted because it was (and still is) simply superior in many aspects to previously available process managers, because application developers had it up to here to maintain n different init scripts for n different distributions and distribution packagers didn't want to have to write custom init scripts for each application anymore.
As an example, check out the discussion around the adoption of systemd in Debian[1].
[0] https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...
And no, not in "GDM doesn't clean up after itself", which was given as explanation for the infamous "systemd now defaults to destroying everything in a session on logout" change few years later. (Which GDM could require anyway earlier, but apparently somehow it wasn't enough)
There is a lot of good ideas that went into systemd though, and I'd agree that a lot of anger is in how badly they are implemented (the only reason I do not complain more about systemctl is because upstart managed to be even worse). In my copious free time, I've been tinkering at alternative, but even if I disagree at the format of systemd service files, it includes a parser for them.
If you by 'it' mean the fact that the distributions switched to systemd, I would be declined to discount the speculation that 'it was because people did report in trying to run GNOME 3.8 without logind [...]'. Do you honestly think that Fedora, Arch or any of the other distributions would not try to evaluate other strategies of getting GNOME 3.8 to run? Replacing the process manager and PID0 is not an endeavor chosen lightly - it is a massive undertaking that every distribution would have weight very carefully. "Oh, there are people having trouble running GNOME 3.8 without systemd present" seems not to be enough reason to go through all the pain of switching to systemd.
It's rather that systemd offered something that systemd offered something that the preceding mess of shell scripts and conventions didn't offer; consistency and reliability, as much as you might doubt that. Have a look at the Debian general resolution with regards to systemd and the provided arguments by the proponents[0].
> I've been tinkering at alternative
I would be very glad if your alternative implementation were even modestly successful. And I'd be thoroughly thankful if it managed to replace systemd.
Not because I think systemd is badly implemented (I've yet to see any actual evidence in that regard from any detractor) but because systemd needs competition and I would prefer to see some well established and stable protocols between the individual parts of systemd. That will only happen if said protocols get also provided by alternative implementations.
With regards to you re-using the systemd configuration format; that's probably a smart move. Systemd is at this point a well established fact and anyone trying to best it at its game will have to make is as easy to migrate as possible. Hurdles like a new file format might well be too much for an indifferent user.
As for supporting configuration format - it's an obvious move, though more as "import" rather than only source of truth (different internal data models), and the format... is not exactly good (mostly due to lack of sane defaults that start to hit you once you wander beyond functionality that can be summarised as "SysV initd plus dependencies")
Looks like we're still in disagreement about this. As far as I can tell, there was never a 'hard' dependency of GNOME 3.8 on logind; logind was an optional dependency[0].
> beyond functionality that can be summarised as "SysV initd plus dependencies"
I would attribute that to the lack of similar "service manager" functionality in other "boot managers". That comes down to the hesitancy of these "boot managers" to embrace the role of "service managers". There's tons of functionality that the systemd project (not necessarily the pid0 binary) introduced to make services run consistently and reliably. They paved the way in that regard and we're still waiting for contenders to catch up.
[0] https://mail.gnome.org/archives/desktop-devel-list/2013-Marc...
Because it's tightly coupled to everything (particularly to the few profitable parts of linux - most open-source is maintained on a shoestring, so it's pretty cheap to take control over development of even vital low-level infrastructure). This is how systemd bypassed the bikeshedding problem of there being half a dozen replacement inits but no clear consensus, with the result that everything relied on a lowest common denominator. But it's toxic for the long term, because it undermines the whole point of using linux if you can't swap out pieces or maintain your own forks of individual components.