[palata]

I am not sure if we are talking about the same thing. I am not saying that systemd is bad. I am saying that when a project has a hard dependency on systemd (which is not necessarily systemd's fault, to be fair), then it doesn't work with an alternative init system.

[theamk]

Right, but my point is that unlike earlier init systems, unless that dependency on pid 1 itself, there is nothing preventing alternative implementations, and in fact, there is all the support to make such implementations possible.

To give an example, let's say a package depends on systemd because it uses sd_journal protocol, presumably because it wants to send enriched logs. That protocol is fully described (in [0]), and is actually pretty trivial to implement, on both server and client side. It even have a build-in "upgrade" mechanism (via $JOURNAL_STREAM) to allow seamless switch between base/systemd-logs, although AFAIK sd_journal_* functions do not implement it by default.

So this brings us a question: if a program wants to provide rich logs, and it is is using a documented protocol to do so, but there is only one implementation of the receiver, is this a problem? Is the onus on the program's authors to support multiple log sending functions, or on the distributions to provide a log receiver that the program expects?

[0] https://systemd.io/JOURNAL_NATIVE_PROTOCOL/