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…
This message is a potpouri of several random thoughts that I've had
in the past few days. The first two are apropos to recent topics on RISKS,
the last is new material.
Re: SDI and unexpected inputs. I have a friend who works for the
Army Night Vision Lab (I'm not sure that's actually the correct name).
They work on "find the tank in the jungle at night" problems. He once
described a program that looks for tanks in a battlefield — the first
thing it does is find the horizon and concentrate on the area below (i.e.
the ground). My first thought was "what happens when they start dropping
tanks by parachute?"
Re: Planes loosing engines. I gather than in many of the cases of
planes having gross defects (i.e. a control surface torn off), the
situation was at least meta-stable until the pilot tried to do something
(i.e. turned off the auto-pilot to take control). I'm just guessing, but
it seems that a chase plane could take off and intercept the damaged plane
to make a visual inspection of its exterior quickly enough to be of some
use. Am I being naive to think that this would be 1) practical and 2) of
any use? Is it done already?
Re: feeping creatureism. There is an annoying trend towards
computerizing things that just don't need computerization. Even worse is
the urge to make things *seem* computerized when the microprocessor in them
does nothing more than scan for switch closures on the control panel and
run a simple timer. I recently bought an air conditioner — it doesn't
have a control panel, it has a "command center". It has the same controls
(on/off, etc) as any other air-conditioner, but the panel is made up to
look like some sort of computerized gizmo. My new electric dryer is the
same way — it's got "electronic drying", which means is it has a
thermostat is the exhaust vent just like my mother's old mechanical-timer
model. Speaking of my mother, she just bought a new car and hasn't figured
out how the radio works yet because the familiar volume and tuning knobs
aren't there any more.
So, how does all this tie in with COMPUTER RISKS? Take the dryer;
by making it appear that there is some kind of computerized system
monitoring and controlling the drying process, the consumer is duped into
believing that his dryer is somehow better than the old ones. He doesn't
really understand *why* it is better, but since it computerized, it *must*
be better, right? Likewise with the car radio. While it may be true that
digitally synthesized tuning is better than mechanical variable capacitors,
(let's not start arguing about *that*) there was nothing wrong with the
user interface (2 knobs to turn, maybe some pre-set pushbuttons). While
the real advantage of the new radio over the old is the PLL instead of the
variable cap, the *percieved* advantage is the "tune-up/tune-down" buttons
instead of the tuning knob to turn. In fact, the new-fangled user
interface is no better than the old one, and may in fact be worse.
Roy Smith, {allegra,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
Doug Humphrey asks:
" ... I am not sure why a pilot would need a video monitor to tell him that
Number 2 just fell off the wing, ... . He will no doubt understand this
by the way the aircraft is acting."
A perfect example of why a pilot could use a monitor is the American Airline
DC-10 crash at O'hare. The pilots knew they had lost power on the engine.
However, they had no way of knowing that they had physically lost the engine
(because you can't see the engines from the DC-10 cockpit.) Upon detecting
that they had lost power in one engine, the pilots went exactly by the book -
they changed the airspeed to best-2-engine-climb speed. Unfortunately, when
the engine fell off the wing, it also ripped out some hydraulic lines in the
wing, which were holding the slats (high lift devices on the leading edge of
the wing) extended. With the slats retracted, the stall speed of the damaged
wing was *above* best-2-engine-climb speed. So, one wing stalled, the other
kept generating lift, and the plane rolled over.
It should also be noted that pilots in simulators, when given the exact same
situation, were able to save the aircraft when they knew that they had
physically lost the engine, while pilots that did not know uniformly failed to
save the aircraft.
Doug is correct in stating that a pilot should be able to understand if he's
lost something important. However, that understanding could come too late, or
in and of itself be fatal.
I basically agree with Will's thesis about missions, but I don't the difference is that simple (binary). Two years ago, an F-8 Crusader (single engine Navy fighter, older) lost power over San Diego. The pilot had time to eject, but before doing so, he tried to avoid hitting buildings in the Serrento Valley area. (True he might have misjudged prior to ejection, but the plane did come down in a parking lot and not the nearby electronics buildings.) Many pilots have faced this dilemma in the past: including civilian pilots (do I kill several hundred people on the ground in addition to the passengers I have just killed?). I think this also goes for civilian rescue missions. Ford' Mayeguez (sp) mission in 1975 cost more Marine lives than civilians rescued. True we will never know the real political consequences of not rescueing (liberals: "we would have negiotated release," conservatives: "they would have died"), but my point is many of the fundamental types of systems are no different in the civilian or military sphere, and that there is overlap (with tricky trade offs) with military operations. --eugene miya
To LIN : In response to a message, you state that none of the anti-SDI
folk ever stated that the software had to be perfect. I have
heard constantly in both the widely read (Washington Post) and
limited (?) distribution industry media (Aviation Leak and
Space Mythology) SDI critics that contect that it must be perfect
or it is useless. I don't beleive this, and I would hope you
don't either, but saying that the whole must be perfect
certainly implies that the parts must be perfect. (Opps. contend..)
About failure modes in software systems, yes, it is possible to
design fault tolerant and fault permissive systems. Systems that
have a know 'prefered failure mode'. Example, hardened underground
facilities, I have been told (no references here) are not designed
to withstand forces equaly throughout the structure. That would mean
that when the structure finaly failed under load, there would be no
reliable way to project where the failure would happen. Better to
design with structural over load failure in mind and specificaly
designate one area as the failure area, and then take withever
measures one can (air/water tight bulkheads, etc.) in that
area since you now have a high degree of confidence that the failure
will happen where you want it, and are ready for it.
Software can be designed the same way by dealing not only with the
quantity (targets) by the quality of targets (destinations) and
selectivly 'failing' on those which are the least important.
I would guess that a catostrophic failure would be the one
to avoid, even of the system decided that it was time to reboot,
clearing target tracking data since some of it was detected as
bad. The system might then let through whatever was locked at the
time of the failure, but at least it would resume defense rather than
either crash outright, or get into a position where its target load
started to effect its real time processing and maybe preventing it
from reacting well enough to to its job.
Hey ! If we get flaming about this much deeper, we should all start
submitting bills to SDIO.......
Doug
Two anecdotes about shipboard emergencies.
In that fire, one sailor did think about what was happening, and
ran aft as fast as his little legs would carry him. A _giant_ Chief Gunner's
Mate named Mills grabbed him, pointed him back to his battle station, and
said something like "Son, you better get to your battlestation. When a
destroyer has a fire in a magazine, you just can't run far enough!"
In another emergency that was really too complex to explain on
Risks, I _really_ went automatic. I had far more charge of the situation,
and far more depended on my own actions. Simply put, the USS Saratoga was
about to run over us, and we had lost control of our rudders. I did the
requisite things, and am here to tell about it. But _during_ the experience
I was "out of body" - Some part of me was floating above and behind me,
watching me give orders & do things, sort of supervising/monitoring me,
but not interfering. I have no recollection of the situation from my
body's eyes and ears once the situation developed. All of my quite
detailed memory is from that viewpoint floating up in the aft port
quarter of the pilothouse. I must have done good, because everybody said so,
from the skipper down to the real authorities, the mess cooks. I have to
conclude that I had been so thoroughly trained that I was operating on a
learned-reflex basis, leaving my conscious mind free to observe. I don't
know if we can use that somehow in designing "operator assistants" or not.
- Mike
If you have the MH Message Handler (a user agent for UNIX) you have the
"burst" command which seems to work just fine on Risks digests. MH is
now distributed as user-contributed software on the 4.3BSD tape, and is
available for anonymous ftp from the host louie.udel.edu. Also, you can
get a magtape copy for $75 from the University of California, Irvine.
I've included the release announcement below.
/JLR
A new release of the UCI version of the Rand Message Handling (MH)
system is available for distribution. This release of MH is called
MH 6.5
There are a lot of changes between MH.6 and MH 6.5; a lot of
performance enhancements were made, there's also a lot of support
for distributed mail (personal mail and bulletin bboards).
Here are the details:
- MH is in the public-domain
- MH runs on a number of versions of UNIX (4.[123]BSD, V7, SYS5, and
related variants, e.g., HPUX) [sorry, no support for SYS3.]
- MH runs on top of a number of mail transport systems
(MMDF-{I,II}, SendMail, stand-alone (with UUCP support))
Although MH is not "supported" per se, it does have a bug-reporting
address, Bug-MH@ICS.UCI.EDU. Bug reports (and fixes) are welcome, by
the way. There are also two ARPA Internet discussion groups:
MH-Users@ICS.UCI.EDU and MH-Workers@ICS.UCI.EDU (somewhat analogous in
charter to Info-UNIX and UNIX-Wizards).
There are two ways to get a distribution:
1. If you can FTP to the ARPA Internet, use anonymous FTP to
louie.udel.edu [10.0.0.96] and retrieve the file portal/mh-6.tar.
This is a tar image (approx 4MB). The file portal/mh-6.tar.C is
the tar image after being run through the compact program (approx
2.3MB). The file portal/mh-6.tar.Z is the tar image after being run
through the compress program (approx 1.5MB).
2. You can send $75 to the address below. This covers the cost of
a magtape, handling, and shipping. In addition, you'll get a
laser-printed hard-copy of the entire MH documentation set. Be sure
to include your USPS address with your check. Checks should be made
payable to
Regents of the University of California
and must be drawn on U.S. funds. It's also a good idea (though not
mandatory) to send a computer mail message to "Bug-MH@ICS.UCI.EDU" when
you send your check via USPS to ensure minimal turn-around time.
The distribution address is:
Support Group
Attn: MH distribution
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717
714/856-7553
Sadly, if you just want the hard-copies of the documentation, you
still have to pay the $75.00. The tar image has the documentation
source (the manual is in roff format, but the rest are in TeX
format).
/mtr
Please report problems with the web pages to the maintainer