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

Rob Seaman seaman at noao.edu
Sat Dec 20 13:01:03 EST 2008

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.


More information about the LEAPSECS mailing list