Re: Scary bugs
On Sun, 30 Jan 2000, Thierry Laronde wrote:
[..]
> 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.
We're not dealing onlt with #42556. That bug may or may not be caused by
--adjust wackyness. I'd fill it as a new bug, and add a reference to it to
#42556.
So, we just do a full description of the problem --adjust generates in
Debian to justify ourselves, and propose the 'robust --adjust' solution to
upstream. But this can wait.
> So, as a kind of synthesis, there are three options:
And keeping in mind that we're discussing the defaults for potato, and
acknoledging the fact that we only have time for minor documentation
updates...
> 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;
Will confuse the hell out of newbies and Win/dos users. Violates the
"there's one single clock" common idea.
I've just noticed an *EVIL* piece of misinformation (for Debian) in man
hwclock, which implies that the user should use hwclock to set the RTC
without mangling the system clock and reboot to update the system clock.
THIS might be one of the causes of all this mess, since we currently have
--systohc enabled. Added to the list of small doc updates.
> 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;
Will still cause RTC screwups most users will never expect nor know how to
handle, AND violates the "one single clock" idea. --adjust caused trouble
before, and will keep causing it until we fix hwclock.
Please don't enable this for potato. After hwclock gets fixed, sure. For
now, it's easier to deal with a drifiting RTC than a berserker RTC IMHO.
> 3) Remove --adjust and keep --systohc (actual case);
> the bug report is a clear indication that this is problematic. If the
For broken RTC drivers, --hctosys and --systohc do not apply the drift to
the RTC, so they cannot make the problem any worse. So removing --systohc
does not help 42556.
What's the real problem with this option? It looks like the sanest one right
now, even if it is not perfect.
- It lets the users happily delude themselves into thinking there is only
one true clock (the system clock while Debian Linux is active, the RTC when
booting up, the standard Win/DOS clock... all will work).
- We do a crude patch to man hwclock so that the users don't have the stupid
idea the the HW clock is the one true untoucheable clock. --systohc takes
care of the rest. The user is told to disable --systohc by hand if he wants
to decouple the two clocks.
- ntp, ntpdate and friends will work happily out-of-the-box (from
util-linux's point of view).
> system clock is considered accurate this is, IMHO, because the user is
The system clock is better than the RTC in quite a few machines (old desktop
PCs, mostly). It is far worse than the RTC in a lot of others (laptops and
APM-enabled machines which go into suspend mode are a given here).
> 4) Keep both --adjust and --systohc (previous case);
> This *MAY* be kept *IFF* there is documentation.
IMHO should not be done before a more robust --adjust is available.
> 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.
That, and a kernel problem.
> In a perfect world, with good documentation, with a workstation not running
> also M$, the 4th solution is good.
In a perfect world, everyone could have a primary time source (laser/atomic
clock, magic smoke leak-proof oscilator, whatever) at a reasonable cost
(none?) instead of being stuck with a crappy XTAL RTC...
> Actually, for practical reasons, I think the 2nd solution is the best
> ( but I might accept the first...).
We have two acceptable choices IMHO: #1, #3.
#1 -> There's no way the user will be alowed to think there's only one true
clock. They must be either told to always set the clock on the BIOS (bad
idea, clueless users + BIOS = kapow!), or teached about hwclock (argh, three
questions per week in -user, and one per week in -devel ;-) ).
No timekeeping bugs whatsoever, you get what you paid for your RTC.
#3 -> User sees only one clock, as long as we convince them not to try to
change only the RTC (easier than explaining hwclock, as they must use
hwclock and friends to tamper with the RTC to begin with). Properly
configured APM is not a issue, unless you reboot the computer while it is
sleeping. External tampering with the RTC is ignored. The usual number of
questions in -user/-devel, maybe less as we'll be adding some docs.
Add to FAQ/admin guide/docs:
To set the clock, use the standard UNIX date setting facilities or any of
the advanced timekeeping programs (ntp, ntpdate, chronny). The Hardware
clock chip will be updated on reboot. [what you think is worse? stepping
the clock, or the current situation (for a end-user system (screw the
logs))?]
Add to man hwclock somewhere (I'll do a better job than this, this is just
an example):
Debian users: Please remember that the standard debian installation will
copy the system clock to the RTC on shutdown. Edit /etc/init.d/hwclock.sh
if you want to be able to set the RTC directly.
Proper warnings are inserted for ntp, in the /etc/init.d/hwclock.sh script,
and other README files.
Simple, isn't it? The question is: Is this effective enough?
I can get this done by tomorrow 01:00 GMT (probably much earlier) and sent
to -devel, the bts and maintainers of each package (with a "this is not a RC
bug, but please consider doing this update for potato note). Just give the
word.
> With a good documentation, put in the strategic places, I may vote for
> all solutions !
That's for woody... and I don't think I know all the strategic places :^)
Okay, which one? #1, #2 or #3?
--
"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
Henrique Holschuh
Reply to: