Bug #114: expand setclock script
zarin at localhost.localdomain
Tue Jan 13 04:34:56 PST 2004
On Mon, 2004-01-12 at 20:38, Gerard Beekmans wrote:
> There has been some discussion going back and forth on this matter and I
> haven't read a satisfactory answer what to do when ntp is not used and
> if the hardware clock should be saved to match the current system clock.
> I believe the problem is if NTP isn't used, how do you know which clock
> is still accurate? The cmos one might be drifting, but the kernel based
> one might be too, maybe both at the same time at different speeds?
> I don't want to rehash this entire discussion, but I myself don't know
> what to do here. I use NTP myself and never bother to ever save my
> hardware clock. I know my hardware clock is about 30 minutes off, but
> that's no big deal. I boot, as soon as the network card is up, ntpdate
> is started to reset my system clock before any daemons are started.
> Never a worry.
> Anyways, if we can't come to an agreement we ought to close this bug. It
> has been around for over two years now, and it has not been a real issue
> as far as I am concerned.
imho - a short, and simple script to save system time to hwclock is in
order, in BLFS. Not in LFS.
Resaons for this argument are as follows:
1. LFS is, imho, supposed to be as bare, and minimalistic as possible..
a bare booting Linux for you to do as YOU want, not as some distro
forces you to do (yes, hush up the "well users can ignore the script if
they don;t want it" flames please - I know that, but most users are
mostly "to the letter" followers)
2. The only really good reason for syncing yer hwclock to the system
clock is if you know your system clock to be correct (either manually
updating, or ntp)
3. ntp, if installed, is a BLFS issue. Not LFS issue.
So, in BLFS, syncing the hwclock to the system clock (which is synced to
Atomic clock's somewhere) makes sense here. Other than that, I see no
Rob Day (BOFH)
More information about the lfs-dev