3 ms·

> 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

by 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...
- chris_wot 11y ago
  Right, so the issues that he seems to have - I see the main issue is that some software links directly against systemd libraries. That is indeed not very good. However, his issues about the difficulties of swapping over packages - well, he has his own distro and he's actually worked out after a bit how to replace it with System V. Linking libraries is not very good, but that's surely more of an issue with developers making bad dependency choices? or perhaps they find it convenient. And he worked out how to get around it with a shim anyway, which obviously increases his workload, but then again he's the one who wants to diverge from what all the other distros are doing! Of course, there is the other point in that it could be argued that the SystemV system doesn't have features that are provided by systemd... which would tend to indicate that perhaps it's lacking in a few areas. He also belabours the point of parallelisation. I cannot understand why he just doesn't change the before or after directives in the unit config files. That's really not much different to the pain of reordering services in the existing System V-based systems! So I'm really not convinced :-) Anyway, that was rather a fun talk, I liked how he was troubleshooting the issue, more power to him that he got his system in the way he likes it.

by pdkl95 11y ago

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...

chris_wot 11y ago
Right, so the issues that he seems to have - I see the main issue is that some software links directly against systemd libraries. That is indeed not very good. However, his issues about the difficulties of swapping over packages - well, he has his own distro and he's actually worked out after a bit how to replace it with System V. Linking libraries is not very good, but that's surely more of an issue with developers making bad dependency choices? or perhaps they find it convenient. And he worked out how to get around it with a shim anyway, which obviously increases his workload, but then again he's the one who wants to diverge from what all the other distros are doing! Of course, there is the other point in that it could be argued that the SystemV system doesn't have features that are provided by systemd... which would tend to indicate that perhaps it's lacking in a few areas. He also belabours the point of parallelisation. I cannot understand why he just doesn't change the before or after directives in the unit config files. That's really not much different to the pain of reordering services in the existing System V-based systems! So I'm really not convinced :-) Anyway, that was rather a fun talk, I liked how he was troubleshooting the issue, more power to him that he got his system in the way he likes it.