The grandparent comment was about how the issue was actually systemd. My comment is pushing back against that. As you point out, that isn’t a simple swap out. The replacement to systemd can be as complicated and intertwined as systemd is today if not more.

But what init system you use is irrelevant to the issue of what do you do when an upstream project is taken over by a malicious developer?

> The grandparent comment was about how the issue was actually systemd.

It's not my view that "the issue was actually systemd". The issue was a complex, sophisticated attack by someone taking a long view. But the attacker injected his code into the system by manipulating part of systemd into loading a fairly obscure compression library that he had hacked. Systemd is of course more-or-less omnipresent these days.

Why does an init system need to load libraries at all? Well, it doesn't, unless it has arrogated to itself much more functionality than PID1 should ever have.

The init system was utilized in a supply chain attack. Fixing the init system helps but is only a bandaid to the issue of supply chain attacks.

libsystemd isn't the init system, it's a shared library

> How would you handle dependencies,

I don't think most people mind system as a service manager, if that's all it did.

> port, socket,

That's inetd.

> timed triggers

That's cron.

> etc?

Etc.