Run0, a systemd based alternative to sudo, announced

You're always welcome to write an alternative if you don't think systemd's direction is correct. Frankly with the number of detractors you could likely form a much larger team to "do it properly" instead!

Love or hate Pottering and his team, they're at least writing code instead of postulating on internet forums. systemd's adoption and popularity among many is proof of that

> it requires a ton of systemd infra to use

I understand your frustration, but is it really fair to criticize a systemd feature for requiring systemd itself?

> instead of postulating on internet forums

Love or hate internet discussion, you're always welcome to not participate in it.

To your point. Lennart instead of participating, just writes code? :)

> You're always welcome to write an alternative if you don't think systemd's direction is correct.

They actually exist. Namely OpenRC and s6 as the main competitors to the core systemd functionality (init). There exist other alternative projects for the other components of systemd as well.

My complaint is that they are adding another tool that depends on their core software in an attempt to replace a portable, well established tool in a non-drop-in way.

This is a consistent pattern with systemd that feels very embrace-extend-extinguish-y and it does nothing but increase the cost involved in keeping code portable between different platforms.

When that feature is trying to replace an existing, portable feature? Yes.

Isn't that most of systemd's extra stuff already? like DHCP, network manager, time daemon, boot loader etc.

Yes and that has earned systemd a lot of complaints but most of that isn't really user or service facing. Vs sudo which the user and a lot of applications use.

For what it's worth I actually like the idea that run0 is proposing. It's basically the same idea as what s6-sudo does for the s6 service manager.

My issue is that if this is something they are pushing, instead of making it another "we are doing it this way and breaking with convention" issue, they should go the dbus route and put together a standard with a freestanding reference implementation that's managed by a separate org and then build their tools on that. That way everyone else can go and implement their versions without trying to chase the moving target that is the current systemd implementation.