Re: [LEAPSECS] Software requirements

From: Rob Seaman <seaman_at_NOAO.EDU>
Date: Wed, 21 Dec 2005 16:40:20 -0700

On Dec 21, 2005, at 1:33 PM, Poul-Henning Kamp wrote:

> I think the difference between you and me as a programmer is that
> if you make a mistake, some radio telescope bungles up an
> observation or worst case runs against a mechanical end-stop. If I
> make a mistake in FreeBSD millions of machines may bungle up things
> I have not even dreamt about them doing.

Sucks to be you.

My daughter had an assignment to find logical fallacies in newspaper
articles and letters to the editor. Reminded me of my undergrad
course in logic. Perhaps you took such a course, too. You might
also find like I did that you can benefit from a refresher: http:// Your postings often resort to variations of ad
hominem attacks. Your assertions in various instances may or may not
be correct, but your arguments are often fallacious and provide no
benefit to your own position, let alone to the larger discourse.

Observatories and other scientific establishments are actually rather
risky places. Those risks are often familiar (hearts attacks on
remote mountaintops, car accidents on icy switchbacks) but may also
be rather terrifyingly strange:

> You can't separate software from "the real world" any more and
> therefore "software must be responsive to real world issues" is
> about as meaningless as saying "timber must respect the US
> constitution".

And yet roller coasters must acknowledge gravity, and the space
station control software, the vacuum of space.

The US Constitution and Federal Code (the software) must rather be
responsive to the realities of forest growth. We can pass laws
allowing the clear cutting of timber, but growing a new forest
depends on facts outside of the legal framework.

It can be asserted that nobody (important) cares about leap seconds -
but that doesn't mean it's true. Saying "timber must respect the US
constitution" is actually more closely akin to saying "Earth
orientation (UTC) must respect the ITU".

> It used to be that a timeout for the light in a staircase was a
> small rubber gadget that slowly let air out, these days it is a
> microcontroller programmed by some random bloke who can't even
> pronounce your name.

Rather the deployed systems include examples of each of these. Many
staircases don't have timeout devices. Many don't have lighting.
Many buildings don't have staircases where they should. There are
more fundamental issues than outsourcing, and a mastery of English is
not required to program microcode.

> As complexity increases, the situation only looks more and more bleak.

You're a real fun guy, you know it? Complexity is where the fun is.

> A couple of weeks ago to unmanned trolley busses in Holland
> collided despite all the testing of the controlling systems.

What precisely is the useful cargo of an unmanned trolley? Perhaps
you meant "unpiloted"? Would love to see one of our perennial local
light rail proposals adopted. I guarantee a Teamster will be at the
controls. Some real world constraints are even less negotiable than
the laws of physics.

> PGN's RISKS digests has been full of tales of software that is
> "responsive to the real world" and I can only say I am amazed that
> no more people have been killed by computers so far.

Oh please! The enumerated risks are much more frequently (like
always) the result of being unresponsive, or "improperly responsive",
to the real world. Planes fall from the sky because of gravity.
They stay up because of aerodynamics. Their rapid descent may only
be triggered by FreeBSD, not caused by it. You're not the only one
who reads RISKS:

Once more with feeling. There are risks associated with leap
seconds. There are risks associated with not issuing leap seconds.
Software (whether OF the real world or IN the real world) must be
responsive to both classes of risk if the programmers are to avoid
moral and legal responsibility for any harm that results.

Blindly pursuing the deprecation of leap seconds doesn't avoid
liability, it creates it. Arguing that programmers are too ignorant
or careless to correctly account for real world constraints is not a
winning selling point for software solutions.

Rob Seaman
National Optical Astronomy Observatory
Received on Wed Dec 21 2005 - 15:41:08 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT