I wonder what other existing programs Will Systemd attempt to replace in the future.
My bet is /bin/sh, maybe they went further to replace the entire POSIX utilities.
Run0, a systemd based alternative to sudo, announced
121–130 of 902 posts
Re: Run0, a systemd based alternative to sudo, announced
#122Earlier quoted context omitted.
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
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.
> This is literally just basic systems engineering
Well… yes it is. Public interfaces and contracts, anyone? Decoupling?
Re: Run0, a systemd based alternative to sudo, announced
#123Earlier quoted context omitted.
> 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…
>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…
> You can't do auto generation if that generation depends on the output of some units. Generators can not solve that problem.
True
> 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.
I mean that part of the point of systemd is that units mostly work out to ExecStart=/usr/bin/binary, and an unit isn't supposed to contain the arbitrary jank one can put into a SysV script.
IPC and the like is an explicit systemd feature, not something you improvise behind the scenes and then expect to work anyway.
Re: Run0, a systemd based alternative to sudo, announced
#124Earlier quoted context omitted.
I think dynamic linking pre-dates systemd by quite a number of years.
SSH being linked to XZ doesn’t.
So aim your ire at the distributions who (I agree) cocked this one up. "Take a library dependency to implement basic functionality" is not a systemd mentality, it's pernicious throughout software development - see leftPad as another example.
Re: Run0, a systemd based alternative to sudo, announced
#125Earlier quoted context omitted.
> Systemd is DESIGNED to be an all or nothing deal. ^[Citation needed]
Again and again people in this thread have told me that the great thing about systems is that it delivers integrated tools.
And people are also telling you that tight integration is not a mandate. Having a bunch of stuff designed to work together does not mean that they're tightly coupled and can only work with their specific implementations.
We've all got confirmation bias, the trick is to be aware of it.
Re: Run0, a systemd based alternative to sudo, announced
#126Earlier quoted context omitted.
So that's your best shot against systemd? - Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library. - libsystemd depends on libzlma - libzlma depends on xz And therefore, systemd is insecure? And what does this have to do with the fact that SUID is a terrible idea that needs to go?
> - Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library. Why was that? Would that "trivial" approach have broken the next time systemd made one of their incompatible interface changes, perhaps? Was using libsystemd the kind of thing the systemd maintainers recommended? > And therefore, systemd is insecure? Systems with systemd had a vulne…
My understanding is that the UNIX socket based protocol which libsystemd wraps for this specific feature is documented, stable and simple.
Re: Run0, a systemd based alternative to sudo, announced
#127Earlier quoted context omitted.
> If you don't read my posts please do not respond to me. Look at the first post I made and carefully read it. I read your OP. It does not contain a technical / security criticism of run0. It's an angry, hand-wavey, vague rant against a project that took a design decision you apparently disagree with, but lacking any actual analytical evaluation of the thing up for discussion. This sort of top-level post shows up on…
>I read your OP. It does not contain a technical / security criticism of run0. Yes, I literally say there is nothing wrong with the idea, so you going ahead and demanding I criticize the idea, is just absurd. Really, this is completely bizarre. I even say that the thinking behind replacing sudo is fine, yet you are here complaining that I don't deliver technical arguments against something which I even told you might…
Let me get this right: you see an article on a new thing, which you have no problem with, but have an angry rant in the comments section anyway? And now you're baffled by people's reaction to that?
I'm not sure there's much point engaging further, I hope you have a good rest of the day.
Re: Run0, a systemd based alternative to sudo, announced
#128Earlier quoted context omitted.
So that's your best shot against systemd? - Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library. - libsystemd depends on libzlma - libzlma depends on xz And therefore, systemd is insecure? And what does this have to do with the fact that SUID is a terrible idea that needs to go?
> - libsystemd depends on libzlma > - libzlma depends on xz > And therefore, systemd is insecure? Yes. You have literally just described the way it is insecure. It bundles a large amount of functionality under a single system, and therefore anything using that functionality is at risk. You seem to be suggesting that Systemd would be secure if you didn't use it, which is obviously fallacious. Anything is secure if you…
LZMA is a widely used compression protocol. The kernel uses it. xz - the compression tool that was affected gets used by the kernel build makefiles - they reference it in the build docs https://docs.kernel.org/staging/xz.html. It's absolutely fair from systemd to have this dependency and to use the trusted library that the most fundamental part of the underlying OS uses.
It was purely the attackers choice to leverage the exploit via systemd instead of injecting code in the kernel at build time.
Re: Run0, a systemd based alternative to sudo, announced
#129Earlier quoted context omitted.
Again and again people in this thread have told me that the great thing about systems is that it delivers integrated tools.
And people are also telling you that tight integration is not a mandate. Having a bunch of stuff designed to work together does not mean that they're tightly coupled and can only work with their specific implementations. We've all got confirmation bias, the trick is to be aware of it.
This is such a bizarre statement. Of course any system with tight integration demands more precise specifications. Literally systems engineer 101.
This is such an absurd hill to die on.
Re: Run0, a systemd based alternative to sudo, announced
#130Earlier quoted context omitted.
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.
> This is literally just basic systems engineering Well… yes it is. Public interfaces and contracts, anyone? Decoupling?
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.