←back to thread

Run0, a systemd based alternative to sudo, announced

(mastodon.social)
466 points CoolCold | 1 comments | 29 Apr 24 23:59 UTC | HN request time: 0.214s | source
Show context
constantcrying ◴[30 Apr 24 07:23 UTC] No.40208131[source]▶
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.

replies(15): >>40208192 #>>40208204 #>>40208221 #>>40208253 #>>40208266 #>>40208277 #>>40208280 #>>40208283 #>>40208314 #>>40208386 #>>40208516 #>>40209218 #>>40215207 #>>40215247 #>>40215377 #
zokier ◴[30 Apr 24 08:27 UTC] No.40208516[source]▶
Instead of just hating based on assumptions it would be useful to actually familiarize with the thing you are critizising

> But what makes me really upset is this completely unexplainable need to make everything part of one particular init system

systemd is not init system, its and umbrella project for various core system components, which includes an init system.

> There is absolutely no reason to tie your new sudo replacement to systemd

well, in this case there is good reason to have it interact with service manager in general

> But with one key difference: it’s not in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user’s UID [...] Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client

strictly speaking it's not 100% coupled to systemd specifically, it most likely uses systemds d-bus API, which is part of their "portable and stable" APIs and as such could be implemented by other service managers https://systemd.io/PORTABILITY_AND_STABILITY/

> 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

The couplings between systemd projects are not that tight, you can pick and choose which parts you want, they explicitly are not "forcing all their projects" to consumers. The minimal systemd build has only init, journald, and udev, which is not exactly sprawling huge. All the rest of the projects are fully optional, and I believe quite many of them can actually work without systemd-init

replies(2): >>40208568 #>>40208680 #
1. mid-kid ◴[30 Apr 24 08:53 UTC] No.40208680[source]▶
> systemd is not init system, its and umbrella project for various core system components, which includes an init system.

The point being made is that it directly depends on the init system part.

> well, in this case there is good reason to have it interact with service manager in general

I disagree! There's no reason to not have it be its own daemon with its own configuration and looser bindings to the rest of the systemd ecosystem (e.g. through dbus and other protocols). KDE applications do this a lot, where they take advantage of other KDE components if present. This is strictly a philosophy thing and not a requirement for achieving what he proposes.

> their "portable and stable" APIs

"we're portable if you reimplement our APIs", idk how this is an argument. They consistently make very little effort to be compatible with (or provide fallbacks for) what's already there. Having stable APIs is nice but there's a reason most of the interfaces on that page don't have alternative implementations: They solve questionable problems and provide no tangible benefits over the methods there were before. Yet projects feel compelled to hard-depend on them...

> The couplings between systemd projects are not that tight, you can pick and choose which parts you want, they explicitly are not "forcing all their projects" to consumers.

In practice they are. The primary reason why everything is shipped as a single project is because that makes it easier to make available in different distros (they just enable everything), allowing it to become the "de facto" standard since it's available everywhere. There's a lot of projects that solve some of the systemd tools' in sometimes better ways, that never see the light of day because they don't have a trojan horse to ride in with.

There's a reason why projects like elogind exist, because there's only a very select few systemd tools that work without systemd at all