timedatex replacing systemd-timedated for NTP packages

[Lennart Poettering]

On Tue, 25.11.14 18:04, Florian Weimer (fweimer at redhat.com) wrote:

> On 11/25/2014 05:15 PM, Lennart Poettering wrote:
> >Really? if you want a UI that controls whether NTP server software is
> >running, why not call into the EnableUnitFiles() APIs directly?
> 
> Both chronyd and ntpd are often used as clients.  Miroslav wasn't talking
> about server usage scenarios, but replacing systemd's NTP client with either
> ntpd or chronyd.  But if you do that, GNOME currently does not report
> correctly if the system uses NTP time, which is the bug Miroslav is trying
> to solve.

Well, GNOME really shouldn't show an NTP check box in the first
place. Instead it NTP should be always on, but GNOME should provide a
way to manually set the time if no NTP synchronization could be
acquired. More specifically, the NTPSynchronized property of timedated
reflects the kernel's UNSYNC flag, and if that boolean is false, then
GNOME should provide a fallback UI for setting the clock manually, but
only then.

Manually setting the clock is something we shouldn't really encourage,
unless there was no way to get a full NTP sync. But if we can get an
NTP sync then we should always prefer that. Hence: removing the NTP
switch from the GNOME UI would be best really. That doesn't of course
mean that admins shouldn't be able to manually override the clock
settings, but that can happen with low-level tools like timedatectl or
even "date" or "hwclock", it needs no friendly exposure in the
graphical UI. Changing the clock manually really should be something
for gurus only, not for the uninitiated...

Never forget that tons of things break if the clock is set incorrectly
(kerberos, nfs, smb, email, make, ...). Users might think that setting
the clock to 1998 is a good idea, but it really isn't, and hence we
shouldn't by default provide a UI for that...

Lennart

-- 
Lennart Poettering, Red Hat