> > No thanks. > > > > I talked with a few people like this, and people who want to use rdate > > should > > be using it as rdate -n probably, and in that case, they should use ntpd -s > > instead. > > I find rdate_flags useful on my work laptop - I usually boot at my > desk while connected to the network where our internal ntp servers > are. It syncs, and then I take the laptop out to other > locations/networks where ntp is not accessible.
There is ntp everywhere. Use: server myownmachine.mynetwork.xx servers pool.ntp.org > Running ntpd isn't > useful then and I would have to kill it after it set the time. I > could run rdate manually after boot but the clock jumps. That is why you should not run rdate. > How do other people keep correct time on their laptops when access to > ntp servers is intermittent? Using the example above. From inside my network, I cannot talk to pool.ntp.org. From outside my network, I cannot talk to myownmachine.mynetwork.xx. But one of them works fine, in all cases. ntpd will cope with hosts coming and going. It will even do DNS lookups to find new hosts, when it has to. It can make better decisions about time than you can. > Yeah, at first I didn't want to special-case it in /etc/rc and using > an rc.d script allowed it to nicely fit in at the right time during > boot. How about this instead: The diff you supplied is exactly what I deleted previously. No. ntpd or ntpd -s are good for you; rdate without -n is really bad for you, and rdate with -n is almost as bad.
