> What did they have to do? `systemctl disable systemd-timesyncd` is not very complicated. If they want to create a service, they can have it disable timesyncd iff chrony has started successfully (in an ExecStartPost), or doing a logic chain.

This was over 5 years ago so I don't recall the details, but it did involve an issue/bug with systemd's handling of the way its internal services were disabled - it MAY have been unique to RHEL. Their fix was ultimately to upgrade RHEL that by then defaulted to chrony, but they were planning on that upgrade anyways. At the time I was making fun of my friend for using Kubernetes, which IMO is another overly complicated solution. :-P

> Maybe I can help you with that - I used to run a non systemd DHCP

Thanks, but I did solve most of the problems; it was a pain as both documentation and other issues (that again may be resolved) at the time made it a much larger hassle and we were an ubuntu shop moving from upstart to systemd that ubuntu 16.04 moved to. Now that systemd has "won out" (and I have accepted that it has), there's more clear and concise examples in documentation and stack overflow. I still dislike that it bloated out what IMO should be just a service and process management framework, though.

> RE IPv6

As I said, IPv6 (and IPSec) was used as an example of how flexibility is required when supporting services or protocols (and I'm a bit pleasantly surprised that systemd-networkd does), not an issue I was actually fighting. Also, enough consumer ISPs hand out /64's that flexibility isn't easy.

I'm also a strong believer that network configurations shouldn't be "chunked" out into multiple files, as it makes it harder to get a holistic configuration view. Fortunately that's a rare experience I need to deal with in today's world and I don't use linux as a router.