Currently, I don't have any issue at all, and I'm not aware of any either.
I like how it's very reliable and integrated: the "kitchen sink mentality" can have positive effects
> It didn't help that the systemd head (Lennart Poettering) was extremely intransigent with any complaints, often outright refusing to deal with various historical edge cases for long-established norms.
In retrospect, given how well it all works, maybe he was right to refuse to compromise.
Many people don't. When something more complex and integrated works it can seem perfectly fine. When something more complex and integrated fails, it often has more cascading effects that would otherwise be desired.
> In retrospect, given how well it all works, maybe he was right to refuse to compromise.
systemd's timesyncd is less accurate than ntpd and is terrible at dealing with drift; it is mostly only suitable for desktop timesyncing. As soon as you need to deal with synchronous timing with multiple machines, it's usually the number one problem. Even worse is that it doesn't tend to use less memory or cpu than alternatives.
systemd's DHCP client continues to be a nightmare for people using it with many ISPs or corporate networks due to the creators deciding to only handle one format of optional headers (in particular option 43, but also many others) resulting in networking issues in many situations. These issues are long-historical and can even be due to ancient endian issues. Every other DHCP client implementation deals with this - except systemd's. I have to cleanup my ec2 instances because systemd's dhcp client adds 032 instead of a space to resolv.conf's search field because we have more than one domain there.
In some cases these problems are because of long-established practices that technically violate an RFC. In others it's because they refuse to deal with more than one legit way of doing things. Either way, what is a service/process manager doing in this fight?
When you replace something that's been around for decades (init), you're going to ruffle feathers for good and bad reasons. It's had decades of maturity. But now one is going to do it for dozens of services and not appreciate or handle the nuances that come with such a responsibility? It's literally pure arrogance - hence the hate.
For time sync, what you do depends on what you need: there's a long list of option: rdate, sntp, ntp, ptp and I have used all of them.
Even if rdate is technically obsolete, for embedded systems it's sufficient that the time is not grossly wrong (and it's faster to write a rdate client and server)
However, when I'm doing high precision sampling data with multiple computers and I have to reorder the observations, sub microsecond accuracy is not enough: then I use PTP with a GPS and PPS (or chrony with special NICs if I can't get a GPS signal)
Both of these are very far from the normal needs of linux installs: there is no one size fits all, there are even interesting inbetween (chrony doing hardware timestamping with ntp is very clever) but when you design a system, you have to make choices.
> But now one is going to do it for dozens of services and not appreciate or handle the nuances that come with such a responsibility? It's literally pure arrogance - hence the hate.
I'm very happy systemd exists, because I like the well thought out design it has created: I can feel how it's lacking in the BSD.
I understand systemd success was not a given, and choices had to made. I just don't think it was arrogance, but compromises needed to achieve a vision.
> it's because they refuse to deal with more than one legit way of doing things. Either way, what is a service/process manager doing in this fight?
It's making choices.
Maybe systemd could have used ntp or better (maybe it will? or maybe there's a reason it's a bad idea?) but it does most things extremely well: if I have very specific needs (ex: ptp) far outside the norm, I can concentrate on that and let systemd do everything else far better than I would.
> these problems are because of long-established practices that technically violate an RFC
For DHCP, you should suggest an update, and if it gets adopted, a patch to make systemd follow the updated RFC.
That would show some love, and it might be better (and more productive) than the hate
There were choices/options, some of which have existed for decades. Instead of replacing them, systemd could have provided optional or mandatory services (eg time, dhcp, etc) that could be passed into systemd. "NTP is enabled and provides time, so it gets started at this point in the dependency tree"...or "NTP with priority 1, chrony with priority 2 provide time, start NTP and if it fails, switch to chrony". This also means that systemd could lag if successor protocols for time syncing, etc take off.
Millisecond or less time syncing is not outside the norm for distributed tracing or other server-side tech stacks, especially if there's lots of traffic. I've been lucky in that AWS's modern underlying hardware seems to keep clock pretty well, meaning I've not had to personally fight with it (that and ubuntu already defaulted to chrony, doing the override work for me.), but I do know people doing on-prem kubernetes loads that have had to...
Swinging back to networking, the tight integration with systemd makes (made? I am only now starting to plan the upgrade of our ubuntu 20.04 fleet to 24.04, so maybe it is better now...) disabling components a huge pain in the ass. My initial fights with systemd's dependency management meant that disabling its internal DHCP had several cascading consequences with other things that expected networking to be "up". This is to say nothing of the tooling that expects a full-slate of systemd services.
> For DHCP, you should suggest an update, and if it gets adopted, a patch to make systemd follow the updated RFC.
It's not mainly an issue with strict adherence to RFCs. There's quite bluntly real-world usage and industry norms.
Firstly RFCs can be vague and unclear. IPSEC is a notorious example in that vendors treat the IP restriction headers differently because the spec is nebulous to how precisely it should work (some call it a proxy-id or proxy-header, others subnet range, etc). Due to a variety of reasons that can be summed up as the consequences of committee driven design, a lot of the spec was defined with great "flexibility" in mind. Some vendors will not bring up the tunnel unless both ends agree on the ranges exactly. Others will happily bring up the tunnel, but only allow traffic that overlaps within the local restrictions. Even more infuriatingly, some vendors (cisco in particular) tie it to the firewall rules, which could include other non-vpn traffic. Some (like checkpoint) dynamically supernet the configured entries. The result is every person who's setup IPSEC VPN tunnels with third parties maintains a "quirks" record to understand how best to bring up tunnels between vendors (eg juniper srx to cisco ASA, juniper srx to palo alto, etc). You just cannot be stubborn here. You need to work with the way the real world works.
Secondly, there can be competing standards or necessary migration paths between them. I'm not sure what the IPv6 status is on systemd so this is only an example, but IPv6's autoconfiguration didn't initially include DNS and other optionally useful fields, meaning DHCPv6 was a thing. This is now mostly deprecated by SLAAC, but DHCPv6 deployments will be needed for awhile as it's all that windows' IPv6 implementation supported until recently. You can't just say "RFC now supports SLAAC...don't whine to me that DHCPv6 doesn't work as it's not part of the RFC".
> That would show some love, and it might be better (and more productive) than the hate
People have tried, but the response can be TL;DR'd to "works on my machine/setup" or to go harass AWS, Microsoft (via AD), etc to make things work the way the systemd mainainers think is right. There's a reason Lennart Poettering has a "difficult" reputation.
