Run0, a systemd based alternative to sudo, announced

Why do they have to do this? This is really, really stupid.

My issue isn't even that someone tries to replace sudo. That may or may not be a completely fine thing to do, depending on the state of sudo and what improvements can be made. But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none.

This is a completely insane way to develop software, instead of creating a new piece of software in a separate project they will force all their projects simultaneously onto all their users for absolutely no reason.

I am very glad to have jumped ship from systemd. It is particularly bad software created by a team of people who engage in very bad practices and a totally unhealthy view of software in general.

> But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none.

You should look at it differently, and then it'll make perfect sense.

systemd has long stopped being just an init system. It's a system tooling suite. When thinking about systemd don't think "PID 1", think "Linux New System Software Suite". It's a big umbrella project in the style of Gnome and KDE.

For example, systemd-boot is a perfectly normal bootloader that's just been systemd-themed. It has a "ctl" tool, has the same command-line aesthetics as other systemd-group tooling, and so on. It's not in any way dependent or even interested in the init system.

>systemd has long stopped being just an init system.

I think that this has always been the core criticism of anyone who objects to them. Besides systemd, the init system, just being very poorly thought out.

What's poorly thought out about the init system? It's not perfect for sure, but on the whole I don't have any issues with it.

How much time have you spent writing and debugging systemd init files?

I've written a fair amount. Nothing much to debug in most of them.

Riddle me this: can I create new mount files inside a systemd unit and have them activated to mount the locations specified? Do I need a daemon reload, for this?

That sounds like a job for systemd.generator.

I don't think having an unit that generates units at runtime is an officially supported use case, since generators exist.

This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help.

>I don't think having an unit that generates units at runtime is an officially supported use case

Are you sure? Can you tell me how I would find out?

> This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help.

That's the point. Any situation in which you have a system modify itself at runtime is a recipe for a headache. So you do your auto-generation first, then work from a stable state.

> Are you sure? Can you tell me how I would find out?

Aside from that this kind of recursion seems like a great way to get weird problems, and that generators exist for this exact thing, the whole design of systemd discourages this kind of trickery. Units are just supposed to start a command and little else.

Maybe somebody made an official pronouncement on this somewhere, but my personal take on this kind of thing is that it's a bad idea, anywhere, not just systemd.

>So you do your auto-generation first, then work from a stable state.

You can't do auto generation if that generation depends on the output of some units. Generators can not solve that problem.

>Units are just supposed to start a command and little else.

What a bizarre thing to say. No, that is not just what units are for. I think you are severely misinformed about what systemd is. Units are supposed to take care of ordering accept IPC, define how to handle failures and manage devices.

That comment alone makes me believe that you just do not know what you are talking about at all. It completely misses why systemd is designed the way it is and what it tries to accomplish.