IMHO Andreas managed to summarize this clown car crash way more constructively than I could. Kudos to that.

IMHO supporting several init tools does more harm than good to any distribution. Its a lot of extra effort that few users will even notice.

Traditionally we used a script to boot. Those of course looked different in each distribution, but the "init tool" was the same. Then we switched over to sysv init (and man did people complain about this overcomplicated mess of symlinks!), yet pretty much all distributions switched to that. Of course they shipped widely different init scripts, but the tool was pretty much the same everywhere. The Linux Standard Base even prescribed the sysv init and any compliant distribution had to use that. We never had a time where distributions offered options wrt. init tooling.

I doubt the portability issue reporting from gentoo makes any difference whatsoever for the BSDs. They come up with all kinds of Linux compatibility stuff and that gets them the software they want.

Of course there are dependencies. They all are tools that do one thing well amd call into other tools to do thenthings those tools were built to do. E.g. many need systemd-init to function as that is the tool to manage the livetime of services running on the system.

So why bother about making init tools portable? You end up with a tool that works poorly on all OSes and nobody needs more of that.

Hardly any of the core systemd people work at Redhat these days. Microsoft employs more of them then Redhat. Right now I think Lennarts new company employes several of the key systemd people.

Contributions are comming in from all major distributions though.

Out of interest: Which init system is used on several OSes by default? Last I checked all OSes wanted init systems that made actual use of their unique kernel features. Any POSIX compliant init tool will by definition not support OS specific features out of the box. Maybe you can hack them on?

I see this "they depend on systemd-specific features": Of course. The systemd project listens when user space developers report the probpems they face with their problems and tries to solve them. Of course developers are going to use that, why would they want to hack around a problem poorly instead of using a proper solution that is more stable, robust and has seen way more testing than anything they could write themselves? The problem is not systemd here, its nobody else bothering to do something.

Yeap, you now get logs from all stages of the boot process, and you notice logs going bad or getting manipulated. It's a huge step forward for Linux, especially for people that look at logs every day. They can finally trust the logs to be correct and complete.

And it is not even a change: I have never had real unix servers with plain text logs in 30 years working with them. Proper computers have always stored logs in databases or whatever. That's actually a legal requirement in many parts of the world for many kinds of servers.

Just use a distribution that uses the init system you want to test by default. The init system is a pretty central piece of infrastructure in todays unix, ditsributions need to invest a lot of effort to make it work well. The default init system always works better than any other options a distribution offers (if they even over options).

There are significant security/reliability improvements all over the place. E..g. logind actually works as promissed, which none of the clones do as they can not have the necessary infrastructure that is provided by other parts of systemd. Or udev using systemd-pid1 to start services: That fixes a well documented problem with udev starting services itself -- which most non-systemd distributions do till today. Problems do notngo away by ignoring them.

Checkout non-systemd distros, most of them still use group based access to devices a user needs to run wayland. Of course that does not matter at all for X11, security is so poor there anyway.

These comparisons assume the systems do the same thing, resulting in a comparable system once everything is up and running.

That is just not the case. Systemd does a ton more wrt. security, hardening and reliability. E.g. it has udev integrated and not running "stand-alone" since it tends to lock itself up when it needs to start long-running services in response to HW showing up. Yes that happens rarely but there is nothing you can do about it. Logind locks down permissions to HW way more tightly than the "forks" that have the same problems that the pre-logind system had -- and that led to logind getting developed in the first place. Lots of sandboxing options are built into systemd and widely used to run services (I rarely saw any sandboxing elsewhere so far out of the box), measured boot is pretty much a systemd-only thing at this time, ... .

How does systemd dare to provide useful functionality? It should be just as useless as all the other inits that nobody ever felt the need to depend on, simply because they do nothing interesting.

You can just build a way more functional and secure system with all the cool features systemd provides.

The security theater is strong in this one.

"Nothing on this page asks for your faith.", immediently followed by a whole list of "trust me" (to manage the keys correctly, that the person notices the keys getting stolen, that she manage the entire signing process correctly, ...). No HW is used that could make it harder to steal keys, just some offline USB storage and a password manager. Every mainstream distro does way better than this, incl. Void linux this is based on.

No systemd with all the security improvements that brings either, but I guess that will bring in a small fan base:-)