On Sat, 2017-03-04 at 20:33 +0000, Roger Lynn wrote: > On 28/02/17 01:00, Ben Hutchings wrote: > > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote: > > > Right, ntpdate for some reason doesn't set the flag to do this. > > > > There is a very good reason, which is that without continuous > > adjustment the system clock cannot be assumed more stable than the RTC. > > This doesn't make sense to me. Most users are probably not aware that there > is a separate hardware RTC. Most users don't know what ntpdate is, either. > Why would one assume that the clock the user is not aware of is better than > the clock the user can see and is presumably happy with? *I* would assume that when a user sets the system clock through a high- level UI, such as GNOME provides, that is the most accurate source of information and the RTC should also be set. But I would not assume that the system clock *remains* very accurate after that point, which is what the flag in question is supposed to indicate. I would also expect that users running command-line tools to set the time, such as ntpdate, have enough technical understanding to distinguish the system clock and RTC. Ben. -- Ben Hutchings All the simple programs have been written, and all the good names taken.
Attachment:
signature.asc
Description: This is a digitally signed message part