[LEAPSECS] Schedule for success (was Re: (no subject))

[Rob Seaman]

Poul-Henning Kamp wrote:


> In message <D754EF5C-767A-4FF0-AC64-6E9543AAA62A at noao.edu>, Rob  

> Seaman writes:

>

>> Instead of building computer hardware, operating systems and

>> applications that pretend the relentless update cycle doesn't exist,

>> build such systems to expect scheduled updates to software and key

>> data structures.

>

> Great idea!

>

> As a system programmer I would love that.

>

> Why don't you take that idea to to Airbus, Boeing, Lockheed, the

> FAA, NRC and the nuclear powerplant industry ?

>

> I am sure they are more than eager to get their EAL processes given

> a workout every six months.

>

> Let me know the pricetag they slap on your proposal.


But you're the one who brought up the issue of updates occurring every  
six months.  If this is indeed going to happen, we are surely better  
off planning for it.  The plan would certainly include the possibility  
of certain systems opting out.  Again - it is better to plan special  
cases than to simply fail to accommodate frozen (in whatever regard)  
legacy systems in your update process.

At any rate, aircraft and ATC already go through a well controlled set  
of update procedures before every takeoff.  If updating a table of  
leap seconds, for instance, were critical to flight operations, then  
this could be accommodated at any frequency between maintenance cycles  
several times a year and operations cycles several times a day.  Data  
with at least as high a level of criticality as leap seconds are  
updated over and over again on aircraft.

I indicated that such data tables *could* be accommodated within a  
well managed software update schedule.  These could also be updated  
according to other schedules.  There is nothing special about a table  
of retrospective and predicted leap seconds compared to all sorts of  
other non-static procedural information describing public policies.

And whatever the pricetag is, it can't be zeroed out by attempting to  
ignore an issue that is intrinsic to the problem at hand.

Rob