[LEAPSECS] Schedule for success

[Rob Seaman]

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?

>

> Rob,

>

> 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  
planet.


> 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  
else.


> 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  
capabilities).

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

> system.)


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.

Rob