Re: Scary bugs
On Sun, Jan 30, 2000 at 08:41:27AM -0200, Henrique M Holschuh wrote:
> On Sat, 29 Jan 2000, Thierry Laronde wrote:
[..]
> > 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.
>
OK, I agree for this one. This could be sent as a "wishlist" bug to the
upstream author. But what must be pointed out is that, before we discuss
about these issues, the bug report sent wasn't accurate.
[..]
> 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
> chrony's README.Debian.
>
> 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.
So, as a kind of synthesis, there are three options:
1) Remove both call to hwclock (--adjust and --systohc);
This will be useful for an absolute beginner whose workstation is shut
down every day : the system date is not accurate, but every day, the
"phenix" is born again with the hardware clock untouched;
2) Keep the --adjust, but remove the --systohc;
so that, for a standalone workstation the hardware clock is not spoiled
by a system clock which is not accurate, letting the average user tuning
a hardware clock which remains the reference;
3) Remove --adjust and keep --systohc (actual case);
the bug report is a clear indication that this is problematic. If the
system clock is considered accurate this is, IMHO, because the user is
not a beginner, or because the workstation uses NTP : this is not a
solution for an inexperienced user. But in this case, I don't understand
why --adjust is not kept. The hardware clock is far more easy to tune
than the system clock !
4) Keep both --adjust and --systohc (previous case);
This *MAY* be kept *IFF* there is documentation.
There is one thing sure : the bug report is not a "program" problem, but
a problem with setting the date when you don't know how Debian handles this.
In a perfect world, with good documentation, with a workstation not running
also M$, the 4th solution is good.
Actually, for practical reasons, I think the 2nd solution is the best
( but I might accept the first...).
However that may be, please write documentation, that will be great :) With
a good documentation, put in the strategic places, I may vote for all
solutions !
Cheers,
--
Thierry LARONDE
thierry.laronde@polynum.com
website : http://www.polynum.com
Reply to: