←back to thread

Run0, a systemd based alternative to sudo, announced

(mastodon.social)
466 points CoolCold | 6 comments | 29 Apr 24 23:59 UTC | HN request time: 0.02s | source | bottom
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 #
constantcrying ◴[30 Apr 24 08:34 UTC] No.40208568[source]▶
Half the people here tell me that systemd is great because it tries to create an integrated complete system, the other half tells me I can just pick and choose.

Obviously one of these groups is lying.

replies(2): >>40208600 #>>40215586 #
thiht ◴[30 Apr 24 08:40 UTC] No.40208600[source]▶
Both can be true though, it can create an integrated system where everything systemd-* works together, but where you can replace any systemd-* you don’t like with something else
replies(1): >>40208646 #
1. constantcrying ◴[30 Apr 24 08:48 UTC] No.40208646[source]▶
The point of an integrated system is that interactions between components enhance the system as a whole. This is obviously incompatible with an easy replacement of components.

This is literally just basic systems engineering. I don't even know what you are arguing here. The more tightly integrated a system is the harder it is to replace individual components.

replies(3): >>40208882 #>>40209671 #>>40215229 #
2. growse ◴[30 Apr 24 09:24 UTC] No.40208882[source]▶
You can have a well-integrated system without having tight coupling between components. Interfaces are a thing, and a high level of integration just means having a good collection of interfaces between well-defined conceptual components with well-defined capabilities. The actual software that implements those components is entirely separate.
replies(1): >>40208959 #
3. constantcrying ◴[30 Apr 24 09:34 UTC] No.40208959[source]▶
I don't know what you are arguing. Replacing a component in a tightly integrated system means that the component has to be compatible to that tightly integrated system, meaning lots of assumptions and replication of functionality.

This means components have to tightly conform to the components they are replacing, which obviously decrease modularity as these components are harder to maintain for available system configurations.

This isn't about whether someone can rewrite a part of systemd, but whether you can freely mix and match, which tight integration works against. Obviously

4. thiht ◴[30 Apr 24 11:11 UTC] No.40209671[source]▶
> This is literally just basic systems engineering

Well… yes it is. Public interfaces and contracts, anyone? Decoupling?

replies(1): >>40210033 #
5. constantcrying ◴[30 Apr 24 11:58 UTC] No.40210033[source]▶
The more tightly integrated a system is, the more involved the contracts between the components become. I seriously didn't believe that a single person here would disagree with that.

A component that depends on one simple interface is far easier to replace than one which depends on twenty complex ones. This seems like the most basic stuff.

6. wmf ◴[30 Apr 24 19:31 UTC] No.40215229[source]▶
You can replace most systemd components but in that case you have fewer features and probably more code overall. If you run the whole systemd bundle you get more features.