4 ms·

Systemd is the very definition of monolithic. > It comes with a set of utilities that do a lot of things "monolithic" vs "modular" has isn't about the number

by pdkl95 11y ago

Systemd is the very definition of monolithic. > It comes with a set of utilities that do a lot of things "monolithic" vs "modular" has isn't about the number of binaries you build. This is about coupling. Replacing systemd itself is the modularity we're talking about, which becomes harder to replace (less modular) every time systemd annexes another set of features. Do those utilities use only well-defined, simple interfaces both to the system and between utilities? Can I replace one or more of those utilities with something else that implements those simple, stable, and well-defined interfaces? This what we mean by modularity; each piece of the complex system can be considered in isolation, with only minimal dependencies. When I can remove systemd-PID-1, OR keep using systemd-PID-1 but replace those utilities with other tools, only then will systemd be a "modular" set of tools. If I have to recompile daemons to remove systemd dependencies (libsystemd-journal0, libsystemd-login0), those daemons are now part of the systemd monolith. > needs to stop The only things that should stop are these attempts at changing word definitions.

pavanky 11y ago
That's like claiming binutils collections is monolithic..
chris_wot 11y ago
Really? How do you figure that? It shouldn't be that hard to replace most of the components that come with systemd with replacements. Do those utilities use only well-defined, simple interfaces both to the system and between utilities? Can I replace one or more of those utilities with something else that implements those simple, stable, and well-defined interfaces? This what we mean by modularity; each piece of the complex system can be considered in isolation, with only minimal dependencies. Um, yes - you can. When I can remove systemd-PID-1, OR keep using systemd-PID-1 but replace those utilities with other tools, only then will systemd be a "modular" set of tools. If I have to recompile daemons to remove systemd dependencies (libsystemd-journal0, libsystemd-login0), those daemons are now part of the systemd monolith. There is no factual basis to this claim. There is only really one component that can't be easily replaced, and that's journald. I challenge you to tell me which component of systemd other than journald can't be swapped out if you so desired.
- pdkl95 11y ago
  > Um, yes - you can. Systemd's own documentation[1] disagrees. Several important interfaces - which are used by other parts of systemd- are marked as not being independently reimplementable. Another way to say that is that systemd considers those to be tightly coupled. > There is only really one component that can't be easily replaced, and that's journald. You're contradicting yourself. If I remove all of systemd, existing daemons will need to be recompiled because libsystemd-journald.so is missing. You don't just to pretend that isn't a dependency. The common response that we should just keep the library file is an attempt to pretend this problem does not exist. Klaus Knopper even gave a talk recently[1] about this very problem, which is causing problems (some of which have workarounds) for the next version of Knoppix. [1] https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart https://www.freedesktop.org/wiki/Software/systemd/InterfaceP... [2] https://www.youtube.com/watch?v=lDXsw2ijRkw https://www.youtube.com/watch?v=lDXsw2ijRkw
  - chris_wot 11y ago
    > Systemd's own documentation[1] disagrees. Interestingly, most of it is reimplementable independently elsewhere. But I think it's instructive to quote why they say what they say: "A number of systemd's APIs expose Linux or systemd-specific features that cannot sensibly be implemented elsewhere. Please consult the table below for information about which ones these are. Note that not all of these interfaces are our invention (but most), we just adopted them in systemd to make them more prominently implemented. For example, we adopted many Debian facilities in systemd to push it into the other distributions as well." So yes, there are some interfaces that are tightly coupled to Linux interfaces, and there are a few things like unit configurations, generators, system updates and presets that are very specific to systemd and, like they say, don't make any sense being implemented outside of systemd! > You're contradicting yourself. If I remove all of systemd, existing daemons will need to be recompiled because libsystemd-journald.so is missing. You don't just to pretend that isn't a dependency. I don't believe I have contradicted myself. That component is a sticking point, and is a problematic dependency. I'm curious what the devuan guys did to sort this out. I assume they recompiled everything. Edit: I'm watching the talk by Klaus, thanks for the link - very interesting! I think I'm a bit confused about his point about the kernel taking an extra 15 seconds to load... does that have anything to do with systemd? I would have thought that's something else. I'm also not following his point about systemctl being a "GUI"... that's a command line utility, not a GUI based tool? OK, he's not happy about journald's binary format. I get it, I'm not keen on it either. But I guess he didn't realise that in journald.conf you just change storage to 1 and ForwardToSyslog to 1 also... He's concerned about parallelization on slower hardware. Fair enough... in that case, setup the unit files to set the order? OK, and now he's concerned about Ubuntu's packaging... ?? I'm not entirely sure how that is a problem for systemd... and seems to be concerned about a sysvinit package that's not a standard part of Ubuntu any more? That seems a bit of a strawman... Yup, that's what I thought! It takes 15 seconds when he replaces systemd - so not an issue with systemd in terms of bootup speed. And now he's saying he doesn't like the fact that his system now requires multi-user session management. What? Oh come on, that's silly. He also doesn't know why the error is occuring...

by pdkl95 11y ago

pavanky 11y ago

That's like claiming binutils collections is monolithic..

chris_wot 11y ago

Really? How do you figure that? It shouldn't be that hard to replace most of the components that come with systemd with replacements. Do those utilities use only well-defined, simple interfaces both to the system and between utilities? Can I replace one or more of those utilities with something else that implements those simple, stable, and well-defined interfaces? This what we mean by modularity; each piece of the complex system can be considered in isolation, with only minimal dependencies. Um, yes - you can. When I can remove systemd-PID-1, OR keep using systemd-PID-1 but replace those utilities with other tools, only then will systemd be a "modular" set of tools. If I have to recompile daemons to remove systemd dependencies (libsystemd-journal0, libsystemd-login0), those daemons are now part of the systemd monolith. There is no factual basis to this claim. There is only really one component that can't be easily replaced, and that's journald. I challenge you to tell me which component of systemd other than journald can't be swapped out if you so desired.

pdkl95 11y ago
> Um, yes - you can. Systemd's own documentation[1] disagrees. Several important interfaces - which are used by other parts of systemd- are marked as not being independently reimplementable. Another way to say that is that systemd considers those to be tightly coupled. > There is only really one component that can't be easily replaced, and that's journald. You're contradicting yourself. If I remove all of systemd, existing daemons will need to be recompiled because libsystemd-journald.so is missing. You don't just to pretend that isn't a dependency. The common response that we should just keep the library file is an attempt to pretend this problem does not exist. Klaus Knopper even gave a talk recently[1] about this very problem, which is causing problems (some of which have workarounds) for the next version of Knoppix. [1] https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart https://www.freedesktop.org/wiki/Software/systemd/InterfaceP... [2] https://www.youtube.com/watch?v=lDXsw2ijRkw https://www.youtube.com/watch?v=lDXsw2ijRkw
- chris_wot 11y ago
  > Systemd's own documentation[1] disagrees. Interestingly, most of it is reimplementable independently elsewhere. But I think it's instructive to quote why they say what they say: "A number of systemd's APIs expose Linux or systemd-specific features that cannot sensibly be implemented elsewhere. Please consult the table below for information about which ones these are. Note that not all of these interfaces are our invention (but most), we just adopted them in systemd to make them more prominently implemented. For example, we adopted many Debian facilities in systemd to push it into the other distributions as well." So yes, there are some interfaces that are tightly coupled to Linux interfaces, and there are a few things like unit configurations, generators, system updates and presets that are very specific to systemd and, like they say, don't make any sense being implemented outside of systemd! > You're contradicting yourself. If I remove all of systemd, existing daemons will need to be recompiled because libsystemd-journald.so is missing. You don't just to pretend that isn't a dependency. I don't believe I have contradicted myself. That component is a sticking point, and is a problematic dependency. I'm curious what the devuan guys did to sort this out. I assume they recompiled everything. Edit: I'm watching the talk by Klaus, thanks for the link - very interesting! I think I'm a bit confused about his point about the kernel taking an extra 15 seconds to load... does that have anything to do with systemd? I would have thought that's something else. I'm also not following his point about systemctl being a "GUI"... that's a command line utility, not a GUI based tool? OK, he's not happy about journald's binary format. I get it, I'm not keen on it either. But I guess he didn't realise that in journald.conf you just change storage to 1 and ForwardToSyslog to 1 also... He's concerned about parallelization on slower hardware. Fair enough... in that case, setup the unit files to set the order? OK, and now he's concerned about Ubuntu's packaging... ?? I'm not entirely sure how that is a problem for systemd... and seems to be concerned about a sysvinit package that's not a standard part of Ubuntu any more? That seems a bit of a strawman... Yup, that's what I thought! It takes 15 seconds when he replaces systemd - so not an issue with systemd in terms of bootup speed. And now he's saying he doesn't like the fact that his system now requires multi-user session management. What? Oh come on, that's silly. He also doesn't know why the error is occuring...