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:// www.fallacyfiles.org. 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: http://en.wikipedia.org/wiki/ Louis_Slotin
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: http://catless.ncl.ac.uk/Risks/20.71.html#subj14.1 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
