The "Devuan" Debian fork and the fuss about systemd
The "Devuan" Debian fork and the fuss about systemd
Posted Dec 2, 2014 23:39 UTC (Tue) by cesarb (subscriber, #6266)In reply to: The "Devuan" Debian fork and the fuss about systemd by kleptog
Parent article: The "Devuan" Debian fork
Because a complete NTP daemon disciplines the clock, so not only the time is correct, but also the frequency is correct, and because a complete NTP daemon has a selection algorithm which compares the time returned from all the servers and discards falsetickers, instead of trusting the first server which answers.
I will not use systemd-timesyncd on any of my systems until it becomes more than a dumb SNTP client. In the meantime, I'll use chrony or ntpd.
OTOH, systemd-resolved looks interesting, but can it work when the network is managed by NetworkManager instead of systemd-networkd? I don't think systemd-networkd can manage a laptop's wireless card as well as NetworkManager (i.e. choosing the SSID and entering the PSK from a GUI within KDE or Gnome), AFAIK it's more of a replacement for e.g. Debian's /etc/network/interfaces.
The "Devuan" Debian fork and the fuss about systemd
Posted Dec 3, 2014 10:15 UTC (Wed)
by kleptog (subscriber, #1183)
[Link]
Posted Dec 3, 2014 10:15 UTC (Wed) by kleptog (subscriber, #1183) [Link]
You do have a small point there, which is why I said "NTP server daemon". We just need a smarter client. I'm not sure if it's important enough for me though. What we need is something smarter than timesyncd but not as complicated as ntpd. Actually disciplining the clock is not hard, might fix that myself if it bugs me enough.
> I will not use systemd-timesyncd on any of my systems until it becomes more than a dumb SNTP client. In the meantime, I'll use chrony or ntpd.
Chrony looks interesting but appears to solve a different problem. It's still a server though.
The "Devuan" Debian fork and the fuss about systemd
Posted Dec 3, 2014 11:25 UTC (Wed)
by anselm (subscriber, #2796)
[Link] (1 responses)
Posted Dec 3, 2014 11:25 UTC (Wed) by anselm (subscriber, #2796) [Link] (1 responses)
Because a complete NTP daemon disciplines the clock, so not only the time is correct, but also the frequency is correct, and because a complete NTP daemon has a selection algorithm which compares the time returned from all the servers and discards falsetickers, instead of trusting the first server which answers.
Actually, systemd-timesyncd does discipline the clock. Right now it does talk only to one NTP server at a time, so it will work best syncing against a set of local time servers that run a full NTP server implementation.
I will not use systemd-timesyncd on any of my systems until it becomes more than a dumb SNTP client. In the meantime, I'll use chrony or ntpd.
And there is nothing wrong with that. In fact, systemd's documentation explains how to do this.
The "Devuan" Debian fork and the fuss about systemd
Posted Dec 3, 2014 13:29 UTC (Wed)
by cesarb (subscriber, #6266)
[Link]
Posted Dec 3, 2014 13:29 UTC (Wed) by cesarb (subscriber, #6266) [Link]
I took a quick peek at its source code, and it does not seem to use ADJ_FREQUENCY. Does it really adjust the clock's frequency?
> Right now it does talk only to one NTP server at a time, so it will work best syncing against a set of local time servers that run a full NTP server implementation.
That can work for a server or desktop usecase, but it will not work as well for a laptop or similar usecase, where a "local" time server might not exist at the moment.
And even on a controlled network, there's the risk that one server has gone insane; the recommendations I have seen is to have three or four NTP servers in your network, so a NTP client can detect and ignore the falseticker.
> And there is nothing wrong with that. In fact, systemd's documentation explains how to do this.
Does it even need documentation? Do a "systemctl disable systemd-timesyncd", a "systemctl enable chrony", and you're done.