[LEAPSECS] Schedule for success
seaman at noao.edu
Sat Dec 20 17:21:39 EST 2008
Poul-Henning Kamp wrote to start this thread:
> Please identify computer communications where it is not guaranteed
> that all involved computers will have their software updated every
> six months.
Presumably this was at least half humorous, but I took the chance to
point out that if this were true (or indeed any other enforced update
schedule), one could use this proactively to effectuate updates to the
leap second list. No enforced updates - no opportunity to exploit.
No big point - just one more minor discussion on the mailing list.
Now, Poul-Henning Kamp writes:
> In message <4957DFE1-9C18-4941-AA87-79E5DD429E5B at noao.edu>, Rob
> Seaman writes:
>> Again - why are engineering best practices regarded as an annoyance?
> They are not, but they are far different from what you think
> they are, and they are slavishly adhered to.
"Slavishly" isn't an adjective to describe best practices of any
sort. You also appear to think that I'm seeking to continue the
little side discussion about software updates. Rather, my main point
is that planning is good, in particular planning to change a civil
timekeeping standard effecting the vast majority of clocks on the
> I know several astronomers, including the one who I think were the
> first to use a computer observationally.
> And they are a really cool crew, and fun to be with, but they
> wouldn't last 10 minutes in the real IT world.
I won't waste time disputing which world is actually the real
world :-) But if you are asserting that your applications are more
important than my applications, then my opinion is that your
applications require better planning than mine do.
As far as the actual proposal were debating here, the one to change
UTC. Evaluate the economic costs. Investigate the risks of all
options. Generate a plan for what happens at the inevitable point
that the leap second embargo fails. The current proposal is
embarrassing in its lack of details. Improve the proposal.
> None of them, and obviously you in particular, have any idea what
> "safety of life" means in an IT context.
> Yeah, sure: you could knock a phd out cold with a radio-telescope,
> but that is just an average industrial accident, that has nothing
> to do with computers really.
I won't belabor how many ways this might relate to computers. But
systems engineering isn't an esoteric technical discipline, nor is it
the same thing as meeting reporting and other requirements for
regulatory agencies. Systems engineering is a pragmatic exploration
of human and technological factors in relation to human goals.
> Real "safety of life" systems often must be approved by several
> authorities, and tested to predetermined and randomized scenarios,
> and then, likely as not, you will end up not rolling them out,
> likely for several months, because some other issue, anomaly or
> just operational pattern prevents it.
And a proposal equivalent to "1) stop issuing leap seconds, and 2)
stop issuing DUT1 announcements, and 3) ignore everything else"
somehow meets this test?
> Getting a new OS rolled out under an ATC system every six months ?
> F'get it buddy, not even close, lets talk about it in 2012, OK ?
Ok, then next time you shouldn't initiate such a rhetorical argument
in that case :-) I've spent the last half dozen messages making a
completely different point over and over. Let's move on to something
> And you know what ?
> That _is_ good engineering practice for systems like that: you do
> not risk blacking out an entire ATC sector, just because some raving
> astronomer cannot find stars with his telescope.
Nobody has spent a dime on investigating possible risks involved in
aircraft navigation. This discussion has never been about astronomers
(other than the unfunded costs to simply maintain our current
Rather it is about civil timekeeping as in civil aviation and every
other aspect of modern society. The assertion that absolutely nothing
about aviation could possibly care about mean solar time is something
that could and should be tested before proceeding to change the UTC
standard. Has anybody even started by grepping for strings like
"DUT1" in the source code for any of these systems?
> (Who has waited 3 months for the paperwork to move, so he can install
> patch which changes the color of a touch panel button in an ATC
So the color of a button should receive more attention than the clocks
ensuring that airplanes don't collide?
I remain fascinated that after all my flights of fancy, the one
talking point that receives such a staunchly negative response is a
simple suggestion to generate a realistic and at least marginally
complete proposal before voting on it.
More information about the LEAPSECS