Poul-Henning Kamp wrote:
I have told you over and over, that if astronomers got their act
together, they would get this upgrade in the blink of an eye if
business which have real money riding on the leap-second could get
rid of them.
Make us an offer. What have I ever said to suggest that I'm not open
to a bribe ;-)
At the very least, grep the source for terms like "DUT1" to search
for the Y2K-like issues.
This, again, shows that you simply don't understand what our trouble
is. We do not need to grep for DUT1, because it's not there, we
don't care about DUT1.
So no naive subcontractors put DUT1 in after reading the ITU UTC
document? And nowhere in any of these systems does UTC meet GMT
derived from some legacy source? It isn't whether you care about DUT1
- it is whether you are dependent on it. If the Y2K-like strings
aren't there, it should be little trouble to grep for them.
You appear to believe that your argument is with me. Rather, we're
all arguing with the ITU.
What we need to do, at every single leap-second, is to sit and
monitor N computers, to see if they all agreed about the existence
of the leap-second, if their operating systems all did the
standards-mandated stupidity of replaying the 23:59:59 second in
unison and if any applications croaked because of that.
If the computers are hooked up to important or dangerous hardware,
we have to stop that hardware before the leap-second, and start
it again afterwards.
Yes, I understand this. If you want this to influence decision-
making, document it and attach it to a coherent systems engineering
management plan.
However, if you really believe you are fixing your systems by seeking
to limit the inputs to those systems, you are only setting yourself up
for other classes of failures. Are leap seconds the only glitch the
systems might ever see? Surely subsystems should validate their own
inputs.
Rob
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
