5 ms·
systemd is, but it has a well integrated ecosystem of other binaries that are managed in the same project (ie. systemd-networkd, systemd-resolvd, etc.). These g
by packetlost 2y ago
systemd is, but it has a well integrated ecosystem of other binaries that are managed in the same project (ie. systemd-networkd, systemd-resolvd, etc.). These generally follow the unix philosophy of doing one thing and doing it well and are almost all completely optional.
I personally find systemd-networkd to be a tiny fraction of the headache that NetworkManager is, so I'm glad it exists.
- bayindirh 2y ago> I personally find systemd-networkd to be a tiny fraction of the headache that NetworkManager... I find this take interesting, because NM automagically gets out of the way in both Debian and RedHat. Any interface you define in /etc/network/interfaces is automatically "unmanaged" by NM in Debian, and since RedHat stores NM configs in /etc/sysconfig/network-scripts files directly, you can either create your own files, or edit already existing ones. systemd-* doesn't have this magick and loves to compete and override other daemons silently and wreak havoc in the process.
- packetlost 2y agoI maintain pretty tight control over all of my systems. I don't typically want miscellaneous daemons floating around with configs strewn about /etc, so systemd's ecosystem fits nicely with that. Sure, that's personal preference, but there's something to be said about cohesive system configuration.
- bayindirh 2y agoNM is not a miscellaneous daemon which throws configuration files around. It's under "/etc/NetworkManager" for Debian, and it uses standard sysconfig/network-scripts folder in RedHat. So it's pretty cohesive since it integrates with everything pretty nicely from get go. All the config files are pretty human readable, and there are tons of tools plus your favorite editor to work with it. Of course you can prefer to use the tools from the same toolbox, it's your system, it's your choice. However, my experience shows me that using full-featured stacks even if they are not that tightly integrated is better in the long run. E.g. I used to use DHCP options in my home network in the past, and we use them at work. So even if systemd-networkd feels good, it means nothing if I can't configure my system the way it should be. When I have thousand servers to tend, I want my configs to work the way they should. I can't get emotional about how using all my tools from a single toolbox, or this and that. I just want my systems installed, work reliably over long periods of time, and just sleep at night. Network manager proved to be both helpful and reliable in that regard, so I'm a happy camper.
- packetlost 2y agoGood to hear! I'm glad NM (and other tools) exist, and I'm not saying they shouldn't. My needs are adequately met by the tools systemd-networkd provides, and I find it works well. Again, it's optional. I also wasn't really referring to NM itself, but about other ancillary daemons that were referenced in the GP.
- throw0101d 2y ago> I don't typically want miscellaneous daemons floating around with configs strewn about /etc, so systemd's ecosystem fits nicely with that. Ironically resolved running is another miscellaneous daemon, and it messing around with /etc/resolv.conf makes systemd's ecosystem super annoying to me.
- throw0101d 2y ago> These generally follow the unix philosophy of doing one thing and doing it well and are almost all completely optional. So I can take just systemd-networkd or just systemd-resolvd and install it on a FreeBSD box? Just because these are different binaries does not make them 'separate'. All the things in the systemd code base are tightly coupled together. That is the opposite of the Unix philosophy.
- throw0101c 2y ago> I personally find systemd-networkd to be a tiny fraction of the headache that NetworkManager is, so I'm glad it exists. And I just want my Debian/Ubuntu interfaces(5) file back. Once I set up a server I want it to stay still, and static text files are the best way to do that IMHO. I also found manipulating them much easier than the messy that is YAML (where whitespace is important—which is one of dumbest notions I've come across: given me {}s for better context any day of the week).