[lmm]

> before systemd won, there were: * SysVinit + RH-derived initscripts * Sysvinit + SUSE-style initscripts * Upstart * OpenRC * prcsys - parallel rc system (Mandrake and derivatives)

Many things about Linux would be easier if we standardized on only one implementation of each thing rather than multiple competing implementations (e.g. only one desktop environment, only one text editor). But we would also lose everything that makes Linux great.

> You don't need to wrap your head around systemd to do things with it that you would really struggle to do with any other init system. But, you've probably been too busy fighting it, or trying to prove why it's worse, rather than trying to do real things with it, or you would be able to point to valid bug reports.

There are any number of major security vulnerabilities, but that's not really the point. Most of the really obnoxious things systemd does are by design so there are no bug reports. Tight coupling to kernel and udev versions, to a non-standardised binary logging daemon, to a custom DNS implementation...

[ti_ranger]

> Many things about Linux would be easier if we standardized on only one implementation of each thing rather than multiple competing implementations (e.g. only one desktop environment, only one text editor). But we would also lose everything that makes Linux great.

Sure, but there is nothing inherent about a text editor or desktop environment that results in you only being able to support one at a time.

It is only practical to run one system initialisation daemon on one system image at a time (unless your system initialisation daemon is too broken to support all the requirements, e.g. if you find yourself running daemontools on sysvinit).

Duplication for the sake of duplication that benefits no-one is just a waste of resources that could be spent on improving other parts of the ecosystem (addressing some of the other gripes the author has).

> There are any number of major security vulnerabilities, but that's not really the point.

There are only about 2 in systemd itself.

> There are any number of major security vulnerabilities, but that's not really the point.

systemd has fewer CVEs than the default syslog implementation used on most distros before systemd (rsyslog), but of course you knew I was referring to open bug reports, not resolved ones.

> to a non-standardised binary logging daemon

There are pros and cons to this. I would prefer to be able to dispense with journald in some situations, but in many cases it is very convenient to have, and it solves problems that no Unix system had completely solved before it.

> Most of the really obnoxious things systemd does are by design so there are no bug reports. Tight coupling to kernel and udev versions

When tight coupling is done by the BSDs, it is considered a good thing, when systemd uses features that don't exist on the BSDs, suddenly that's a bad thing ...

> to a custom DNS implementation...

While a custom DNS resolver is provided as part of the systemd source, which has some advantages, it is by no means a requirement, and it a totally separate service/binary. Many distros don't install it by default (yet).

[lmm]

> It is only practical to run one system initialisation daemon on one system image at a time

Sure, just as it's only possible to run one desktop environment at a time. But just as it's good form to write programs that will run correctly under any desktop environment (by keeping everything loosely coupled and ensuring any interfaces are stable and documented), it's good form to write programs that will run under any initialisation daemon. I don't mind systemd being what gets installed by default. I mind very much when systemd is the only option because other components have been encouraged to use systemd-only interfaces. (and realistically that's the only reason systemd "won" - many of the competing options were much nicer technically, but that doesn't matter when gnome requires you to be running systemd).

> When tight coupling is done by the BSDs, it is considered a good thing

I wouldn't say that. Tight coupling in and of itself is always a negative. If there's clear value gained (e.g. useful features) then that might be enough to outweigh the negative.