On 1/20/22 8:04 AM, Thomas Goirand wrote:
On 1/19/22 20:34, Richard Laager wrote:For people that want something more than systemd-timesyncd, e.g. to get NTS, I think either are acceptable choices. It seems that the consensus for new installs is towards chrony over ntpsec. But I don't think we as the distro need to push either over systemd-timesyncd. For people who don't care, systemd-timesyncd should be fine.Do you disagree on that point (that systemd-timesyncd is fine for people who don't care about NTP)? If so, can you elaborate?Well, could you elaborate why you didn't write "chrony is fine for people who don't care"?
Because that question is about changing the status quo, where systemd-timesyncd is the default.
I fail to understand why you're having a preference on systemd-timesyncd...
Let me separate the two scenarios:A) Imagine we had no NTP support by default and we are considering adding NTP support to the default install.
B) systemd-timesyncd is currently the default and we are discussing whether it should be changed.
In both scenarios, I assume that most users don't particularly care about their NTP daemon. They don't generally interact with it. They just want their clock to be "accurate enough". (And for people who don't care, "accurate enough" is pretty wide. If you need extremely precise time, you presumably know that and thus care about things like NTP or even PTP.) This is no different than other system components: some people have preferences (sometimes strong ones) about certain components, but essentially nobody cares about every single one.
In scenario A, any of chrony, ntp, ntpsec, or systemd-timesyncd will achieve the desired objective of having an accurate enough clock by default. So we would consider other things, for example:
One might say ntpsec > ntp, because ntpsec comes from the same history (so has the same advantages) plus the codebase has been cleaned up (which has security and maintainability advantages). Also, the ntp maintainer wants to discontinue maintaining it.
One might say that chrony > {ntp, ntpsec, systemd-timesyncd?} because chrony is more accurate. FWIW, I can't personally weigh in on that argument, as I haven't researched it well enough myself.
One might say that systemd-timesyncd > {chrony, ntp, ntpsec} because it's part of systemd, which we're already using by default.
One might say that {chrony, ntpsec} > systemd-timesyncd because they support NTS. Of course, there are problems with configuring NTS by default, as I mentioned.
These, and potentially other factors, would need to be weighed. Different individuals might come to different conclusions.
In scenario B, it's the same calculation, PLUS we need to overcome the inertia of the current default. The new default must be sufficiently better to be worth the change.
Personally, my take is:It's not practical to deploy NTS by default right now. If we had multiple operators of geo-diverse, high-capacity, non-smeared (or consistently smeared and a consensus that this was desirable by default) NTS servers, that'd be different. So NTS is not currently a consideration for the default.
systemd-timesyncd is good enough for people who don't particular care about their NTP daemon. For people that do care, they are free to install software of their choice, be that chrony or ntpsec.
-- Richard
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature