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 protected] [email protected] -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-settings-daemon in ubuntu. https://bugs.launchpad.net/bugs/734894 Title: FFe: DBus time API should control ntpdate, not ntpd -- desktop-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
