That’s a short list of other packages (none of which I think are part of a base Linux install, correct me if I’m wrong) that have decided to depend on systemd?

Where's the "hard dependency on libc" list? Or "hard dependency on Bash"?

It's ridiculous to imagine that no program is allowed to depend on SystemD.

> Where's the "hard dependency on libc" list?

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.

> There are multiple libc implementations

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.

> You could make another SystemD implementation if you really wanted.

No you can't, because they don't offer stable interfaces as a matter of deliberate policy.

That seems to be completely untrue: https://systemd.io/PORTABILITY_AND_STABILITY/

That's changed then, now that the competition has been killed off; at the time certainly logind and the cgroup integration had no stable interface.