Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The following is an excerpt from a report of the talk by David
Parnas, Lansdowne Professor of Computer Science at the University of
Victoria and consultant to the Naval Research Laboratories in Washington
DC. The talk was a list of reasons for why the envisaged SDI BMD software
can never be trusted to work. The full report appeared recently on the
arms-d bulletin board. To me, the most telling point reported is contained
in the following exerpt from the report of the talk:
-------------------------------------------------------------------------
The other members of the SDI advisory panel that David Parnas was on
and other public figures have said "Why are you so pessimistic? You don't
have any hard figures to back up your claims." Parnas agreed that he
didn't have any until he thought of the only one that he needed: ZERO.
ZERO is the number of real systems that were trustworthy at first use.
ZERO is the number of real systems that met unknown requirements at
first use. ZERO is the number of prototyped systems that worked at first
use. ZERO is the number of simulated systems that worked at first use.
ZERO!
----------------------------------------------------------------------------
To set the context, Professor Parnas is discussing military battle
software in the above, or so the report leads me to believe.
Question: Can anyone offer evidence of military battle software which
belies any of Professor Parnas' claims as reported above? Does anyone
know about software which belies any of Professor Parnas' claims, even
if they cannot, for security or other reasons, provide evidence?
I would greatly appreciate learning of such.
E-mail address: benson.wsu@csnet-relay
Postal service address: Professor David B. Benson, Computer Science
Department, Washington State University, Pullman WA 99164-1210, USA
Thank you very much for whatever information you can provide.
In the course of catching up with a backlog of reading, the October 1985
issue of SEN (the ACM SIGSOFT newsletter) came to the top of the pile.
Among its contents is an informal report by Jim Horning on his visit with
a committee assessing the solvability of the SDI software problem. What
I found most interesting was his report of a comment by one of the folks,
Lipton I think, to the effect of "The physicists, given a few billion
dollars, are quite willing to commit themselves to improvements of several
orders of magnitude in laser efficiency. The computer science community
is unwilling to suggest even one or two orders of magnitude improvement
in the software-production problem." Granted that the comparison is not
really entirely fair, this still got me thinking.
I went and re-read Terry Winograd's old "Reactive Engine" paper. He comments,
roughly: "If, by decree of God or ARPA, we were only allowed to run one user
at a time on the PDP-10, just think of all the effort that would be invested
in making that one user's time productive." Despite the enormous increases
in computing power available to individual users since then, that has not
happened: much of that extra power is simply being thrown away. Most of
the millions of personal computers out there spend most of their *active*
time (when a user is actually seated in front of them using them) idling.
Even the LISP machines are a pale shadow of the sort of thing that Winograd's
observation calls to mind.
The other thing that came to mind was the genesis of the "Chief Programmer
Team" in the "super-programmer" experiment at IBM. The key fact about the
C.P.T. approach is that it was *not*, in its original form, a team at all:
it was a support system for a single programmer. Consider the elaborate
support setup that surrounds, say, a top trial lawyer: assistants, clerks,
information-retrieval specialists, etc., all there to make sure that the
central figure can spend his time using his unique abilities, rather than
squandering endless hours on chores that don't require such skill.
How many programmers, even ones working on life-critical software like
airliner flight control or fiercely difficult problems like ballistic-missile
defence, have the kinds of electronic and human support that these thoughts
suggest are possible?
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
In another post mortem on the Challenger explosion, the 6 Apr 86 SF Sunday Examiner & Chronicle ran a Chicago Tribune story on the presidential commission finding "a tangle of bureaucratic underbrush": "Astronauts told the commission in a public hearing last week that poor organization of shuttle operations led to such chronic problems as crucial mission software arriving just before shuttle launches and the constant cannibalization of orbiters for spare parts."
SAN BERNARDINO, Calif. (AP) - When President Reagan comes to
California for vacation, thousands of homeowners lose their automatic
garage door openers to the interests of national security, a
businessman says.
Larry Murdock, owner of Genie Garage Doors in San Bernardino, says
he's certain that high-powered radio transmissions from the
president's airborne command post jam the signals of the
remote-control switches that open and close garage doors.
Murdock said Thursday he'd had 800 or 900 calls since Reagan arrived
Sunday for a vacation at his Santa Barbara ranch. The E-4B plane is
parked about 10 miles south of here at March Air Force Base.
Press officers for the Air Force and Secret Service would neither
confirm nor deny knowledge of garage-door problems.
''We are concerned the president is in a safe and secure
environment, and that plane is just that,'' Secret Service spokesman
Bill Corbett told the San Bernardino Sun.
(This follows Matthew Weiner's message in Risks Vol. 2, No. 36)
This underscores a problem a lot of people have with computers — they tend
to regard them as "infallible." I always try to plant some seeds of doubt
when I talk to people like that — when I opened my bank account, the person
at the bank did a quick electronic check to see if I was in trouble
financially (she didn't call it a credit check when I asked.) While the box
buzzed, I asked where it got its information, and she said she didn't know
but was certain "the computer" was always accurate. She was quite surprised
when I laughed and explained that that is not necessarily true. We talked
about it, and her comment was, "Great — now I'll always wonder if the
computer's right whenever I do this check."
Maybe someday people who use computers (as opposed to those who program
them) will learn not to trust them completely.
Matt Bishop
[By then there wouldn't be any computer jobs left. AI programs will do
everything, including being the users, and we can all go down to the
seashore. But we probably wouldn't be able to go in the water. PGN]
Please report problems with the web pages to the maintainer