More structured metadata in journald is nice and I don't have any qualms with binary logging formats, but the author does have a point on log shipping. Additionally, reading journal files has always seemed painfully slow to me (30 seconds of 100% CPU usage)
I'm not overly found of timer units, either. They seem feature rich but much more complicated to setup than a single line in a crontab.
On the other hand, real dependency management between daemons, mounts, and sockets is a huge win.
I can't quite remember the right terminology but afaik systemd-resolvd supports routing different domains to different DNS servers on different network interfaces which can be auto configured via DHCP. The practical implication being, you can connect to a split tunnel VPN and domains accessed over the VPN get routed to the VPN DNS server.
It can be implemented with dnsmasq but dnsmasq doesn't integrate with DHCP (edit, client) out of the box and requires a restart to apply configuration updates which invalidates query cache.
Edit-
I think split dns more commonly refers to serving different internal/private and external/public zones.
In this case, the DNS servers may return the same results but if I'm connecting to a VPN running some distance away, I don't want to route all DNS requests to that server--only the ones for domains on that network. The Domains directive allows configuring this https://man.archlinux.org/man/systemd.network.5#%5BNETWORK%5...
You can add a dhclient hook to reconfigure dnsmasq with `server=` directives to achieve the same thing, but, as mentioned, that still requires restarting the dnsmasq daemon. That usually manifests as: the VPN connection times out, the hook runs, dnsmasq is restarted, but a random web page or request will fail while the daemon is restarting. Sure, you could do SO_REUSEADDR or something to prevent the disruption, but, once again, this all just works out of the box with systemd-*
I don't get your point. DNSMasq doesn't ship with a client, because it's a server. It's a cacheing resolver and a DHCP server that is usually run locally. I don't know of any system that doesn't come with its own built-in (or standard) DHCP client.
His objection is that it doesn't replace the use case that resolvd is supposed to solve. Which is to provide a local service that can redirect DNS queries dynamically as local interfaces go up and down, which is where the integration with a DHCP client comes in.
Makes sense; a lot of the systemd ecosphere seems to be about hotdesking, plugging things in and unplugging them, moving from one wifi AP to another, hibernating and so on. I don't encounter these use-cases, on the whole, which is probably a large part of why I find systemd so annoying.
> I'm not overly found of timer units, either. They seem feature rich but much more complicated to setup than a single line in a crontab.
I’ve twice tried to use them. Closest I got to having one work was that it reported it ran, and didn’t error, but it did not run. Extremely simple cases that were basically copy-paste an example and barely modify it, too.
I'm not overly found of timer units, either. They seem feature rich but much more complicated to setup than a single line in a crontab.
On the other hand, real dependency management between daemons, mounts, and sockets is a huge win.
I can't quite remember the right terminology but afaik systemd-resolvd supports routing different domains to different DNS servers on different network interfaces which can be auto configured via DHCP. The practical implication being, you can connect to a split tunnel VPN and domains accessed over the VPN get routed to the VPN DNS server.