3 ms·

People keep saying it's tightly coupled, but never supply any proof for that. You can still run udev without systemd, the NTP stuff is completely optional and i

People keep saying it's tightly coupled, but never supply any proof for that. You can still run udev without systemd, the NTP stuff is completely optional and in separate binaries and the same is true for the network management stuff. The journal is indeed required, but any traditional syslog daemon still works, and you can trivially disable the persistent journal (I even believe that's the default on Debian).

arminiusreturns 6y ago
Please checkout the progression of Devuan if you are wanting to understand just how viral systemd is in modern linux. If it wasn't so tightly coupled, why did it take 2 years to decouple it? https://sysdfree.wordpress.com/2017/08/16/112/ https://sysdfree.wordpress.com/2017/08/16/112/ https://nosystemd.org/ https://nosystemd.org/
- Denvercoder9 6y ago
  First of all, Devuan wants to get rid of any and all systemd code. This includes for example libsystemd-daemon0, which is a tiny library that implements the stable notification protocol and is a no-op on systems not running systemd. You can reimplement it yourself in pretty much any language, but lots of programs just link against the systemd library because it's easier and has no tangible downside, even for people not running systemd. Eliminating such dependencies isn't particulary hard but takes a lot of work. Likewise, the rest of the world has left SysV init scripts behind, so they have to write those too. The second reason is that systemd provides features for which there simply is no alternative. Desktop environments are entangled with logind, because it's the only software providing that functionality. Before logind they had a hard dependency on ConsoleKit, which was pretty much abandoned. Reimplementing all these features takes time.
  - arminiusreturns 6y ago
    If you are referring to the lack tight coupling being the ability to remove journald, time sync, etc, then you are correct. I should have been more clear I was talking about systemd as a whole, and not just those other subsystems, but I'll assume you meant the latter, in which case, yeah, it's possible to stop using lots of the systemd subsystems without too much pain (which I have done quite frequently, and found great stability improvements.) To be frank, I just really don't like the handwaiving away of valid criticisms people have (on any topic), with such dismissive language as "People keep saying ... but never supply any proof for that." This to me reeks of intellectual dishonesty, but again, that was my response because I probably misunderstood you to say that about systemd as a whole instead of how you meant it which was focused on gp's comment about subsystems. One note: many people pretend sysv init has been dead and left behind, but I've seen production systems in major places still using it (not just embedded either). It's not nearly as dead as people might like to think.
zrm 6y ago
Suppose I want to write my own competitor to systemd-resolvd. I want it to work with systemd-networkd, in the same way as systemd-resolvd does. Or just patch dnsmasq or unbound to be able to do that. Is there a stable interface for that? An RFC I can read? Any guarantee they won't change the interface and break my version, while they update both of theirs together?
- johnr2 6y ago
  > Any guarantee they won't change the interface and break my version, while they update both of theirs together? No, I think you can guarantee that the interface will change at some point.
- Denvercoder9 6y ago
  Judging from the manpage and a quick look at the code, the only thing for which systemd-networkd and systemd-resolved interact is to get the DNS servers pushed over DHCP, which it does over the D-Bus interface that falls under the interface stability promise[1]. [1] https://systemd.io/PORTABILITY_AND_STABILITY/ https://systemd.io/PORTABILITY_AND_STABILITY/
  - zrm 6y ago
    That is not the only thing for which they interact, see e.g. systemd.network(5). The systemd-resolved.service itself reads the systemd.network config files. This is what people mean by tightly coupled. But more importantly, you're telling me what it does currently, not what it's going to do tomorrow. Suppose it did currently only interact through a stable D-Bus interface. What stops them from adding some new interaction and supplementing or replacing the existing one with it? You're left with a guarantee that systemd-resolved will continue to support the old API that systemd-networkd may stop using.
johnr2 6y ago
> you can trivially disable the persistent journal (I even believe that's the default on Debian) The persistent journal is enabled by default in Debian testing.

arminiusreturns 6y ago

Please checkout the progression of Devuan if you are wanting to understand just how viral systemd is in modern linux. If it wasn't so tightly coupled, why did it take 2 years to decouple it? https://sysdfree.wordpress.com/2017/08/16/112/ https://sysdfree.wordpress.com/2017/08/16/112/ https://nosystemd.org/ https://nosystemd.org/

Denvercoder9 6y ago
First of all, Devuan wants to get rid of any and all systemd code. This includes for example libsystemd-daemon0, which is a tiny library that implements the stable notification protocol and is a no-op on systems not running systemd. You can reimplement it yourself in pretty much any language, but lots of programs just link against the systemd library because it's easier and has no tangible downside, even for people not running systemd. Eliminating such dependencies isn't particulary hard but takes a lot of work. Likewise, the rest of the world has left SysV init scripts behind, so they have to write those too. The second reason is that systemd provides features for which there simply is no alternative. Desktop environments are entangled with logind, because it's the only software providing that functionality. Before logind they had a hard dependency on ConsoleKit, which was pretty much abandoned. Reimplementing all these features takes time.
- arminiusreturns 6y ago
  If you are referring to the lack tight coupling being the ability to remove journald, time sync, etc, then you are correct. I should have been more clear I was talking about systemd as a whole, and not just those other subsystems, but I'll assume you meant the latter, in which case, yeah, it's possible to stop using lots of the systemd subsystems without too much pain (which I have done quite frequently, and found great stability improvements.) To be frank, I just really don't like the handwaiving away of valid criticisms people have (on any topic), with such dismissive language as "People keep saying ... but never supply any proof for that." This to me reeks of intellectual dishonesty, but again, that was my response because I probably misunderstood you to say that about systemd as a whole instead of how you meant it which was focused on gp's comment about subsystems. One note: many people pretend sysv init has been dead and left behind, but I've seen production systems in major places still using it (not just embedded either). It's not nearly as dead as people might like to think.

zrm 6y ago

Suppose I want to write my own competitor to systemd-resolvd. I want it to work with systemd-networkd, in the same way as systemd-resolvd does. Or just patch dnsmasq or unbound to be able to do that. Is there a stable interface for that? An RFC I can read? Any guarantee they won't change the interface and break my version, while they update both of theirs together?

johnr2 6y ago
> Any guarantee they won't change the interface and break my version, while they update both of theirs together? No, I think you can guarantee that the interface will change at some point.
Denvercoder9 6y ago
Judging from the manpage and a quick look at the code, the only thing for which systemd-networkd and systemd-resolved interact is to get the DNS servers pushed over DHCP, which it does over the D-Bus interface that falls under the interface stability promise[1]. [1] https://systemd.io/PORTABILITY_AND_STABILITY/ https://systemd.io/PORTABILITY_AND_STABILITY/
- zrm 6y ago
  That is not the only thing for which they interact, see e.g. systemd.network(5). The systemd-resolved.service itself reads the systemd.network config files. This is what people mean by tightly coupled. But more importantly, you're telling me what it does currently, not what it's going to do tomorrow. Suppose it did currently only interact through a stable D-Bus interface. What stops them from adding some new interaction and supplementing or replacing the existing one with it? You're left with a guarantee that systemd-resolved will continue to support the old API that systemd-networkd may stop using.

johnr2 6y ago

> you can trivially disable the persistent journal (I even believe that's the default on Debian) The persistent journal is enabled by default in Debian testing.