FFe: DBus time API should control ntpdate, not ntpd

As I was the one who originally pointed out the issue and was part of the discussion to find the better solution, I abstain from deciding about this FF.

I'd recommend approving it, though. The current status quo is both incomplete (there is no installation of ntpd, the "automatic sync" option is just grayed out) as well as very confusing (the user thinks that the time is handled only manually, while it is actually synced each time an internet connection is established).

It would make much more sense if the "Automatic sync" option would be on by default (reflecting the fact that we enable ntpdate by default), and the user can switch it off manually. Personally I don't see an use case for doing that, but according to Matthew there are some users who deliberately keep their local time off by ten minutes and don't want ntp sync.

Oh, and thirdly, I don't really see enough of an use case for having ntpd on a desktop system that warrants exposing this in the GUI. ntpd has nonzero overhead in terms of extra CPU/memory/battery/start up time/CD space, and also opens a network port.

Approved.

I agree that the way it is right now is confusing. This change should be release noted though, since it will be changing a visible behavior.

(Another possible use case for going to manual, is if traveling and want to use local time temporarily. )

On Mon, Mar 14, 2011 at 04:16:03PM -0000, Martin Pitt wrote:
> Oh, and thirdly, I don't really see enough of an use case for having
> ntpd on a desktop system that warrants exposing this in the GUI. ntpd
> has nonzero overhead in terms of extra CPU/memory/battery/start up
> time/CD space, and also opens a network port.

GUIs notwithstanding, ntpdate is not a proper substitute for ntpd. At best,
ntpdate gives you a one-time sync with a network time source when the
network interface comes up, after which the clock will resume drifting
unchecked. For a true "desktop system", which may have a wired network
connection that never goes down, this can easily result in clocks drifting
well outside the requirements of certain time-synced network protocols (such
as Kerberos).

I don't think this changes anything wrt the FFe or the decision about how to
handle time syncing on the desktop, I just want to be clear about the
rationale and note that there are use cases that ntpdate will not satisfy.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

On Mon, Mar 14, 2011 at 04:25:50PM -0000, Kate Stewart wrote:

> (Another possible use case for going to manual, is if traveling and want
> to use local time temporarily. )

No, you should change your configured timezone setting instead, you should
never set the system clock in local time ;)

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

To be clear, the modified plan is to control both, if available. That is, if requested to use automatic time, both ntpd and ntpdate will be enabled. And the other way around. gnome-settings-daemon just won't *require* ntpd to be installed to be useful anymore.

This bug was fixed in the package gnome-settings-daemon - 2.32.1-0ubuntu9

---------------
gnome-settings-daemon (2.32.1-0ubuntu9) natty; urgency=low

  * debian/patches/33-datetime-service-ubuntu-ntp.patch:
    - Update to disable/enable ntpdate as well as ntpd. LP: #734894
 -- Michael Terry <email address hidden> Mon, 14 Mar 2011 15:38:04 -0400