Re: Scary bugs
On Sat, 29 Jan 2000, Thierry Laronde wrote:
> On Sat, Jan 29, 2000 at 12:19:23PM -0200, Henrique M Holschuh wrote:
> > I disagree. It is also a upstream problem, and one not easy to fix.
> Well, for this, I'm afraid I don't quite agree with you. Not for
> `technical' reasons, but for a `philosophical' reason : unix type of
> programs. hwclock does well what it's supposed to do : set the
> hardware clock. As you say, setting the date on the system is a kind
IMHO hwclock --adjust doesn't do well what it is supposed to do (dangerous
assumption that nothing else touches the RTC). I have no problems with the
other functions of hwclock...
> of pain in the ass. This *complex* task must be done by a higher level
> program, namely a script. So this is not an upstream problem, this is our.
Not really. --adjust should be more tamperproof, and that *requires* changes
in hwclock. "Do a few things, and do them well" for hwclock requires either
fixes to --adjust (deny big adjustments to the drift file, deny big
adjustments to the RTC, configure how big is 'big') or the complete removal
of the feature IMHO.
> local time) but this can be solved by a decision made at install time
> when asking if the date must be set to local or GMT.
Can it? It will cause trouble if any user who likes GMT in his RTC changes
it in any way and doesn't rm /etc/adjtime.
If you don't want this problem in potato, leave --adjust disabled and let
people cope with drifting RTCs, it's the least surprise principle, and I
don't see any Windoze users complaining of clock drift while the system was
Now, if someone doesn't like clock drift, he'll try to find a way to fix it.
In that process, he'll need to read the docs (if he doesn't read docs, I
don't pity him), and as long as the docs are fixed, he'll know about RTC
I could have written patches to the docs for ntp, util-linux and man hwclock
(it has false assumptions for debian in there, namely the --systohc in the
shutdown script) and chrony in the time it takes to reply to this email :-(
> The second point is a lack of documentation, but the maintainer isn't
> responsible for this : the task is big, and I don't think that it will
> be easy to put something good in time for potato.
We don't need a full-blown doc rewrite to fix this for potato. Just one or
two paragraphs in ntp's README.Debian, a couple in util-linux README.Debian
or README.hwclock, a few sentences to man hwclock, and maybe something in
I'll write the documentation patches myself if the maintainers want me to,
as long as concensus is reached in the --adjust and --systohc defaults.
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot