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…
/**** ccvaxa:fa.risks / LIN@XX.LCS.MI / 2:47 am Sep 29, 1986 ****/ > From: Charles R. Fry <Chucko at GODZILLA.SCH.Symbolics.COM> > > > No matter how many automated controls we install on cars (and airplanes) > > to prevent operators from exceeding their vehicles' limits, there will > > always be a need to allow the deliberate violation of these limits. > From: LIN@XX.LCS.MIT.EDU > This discussion about allowing overrides to programmed safety limits > worries me. One of the nice things about computer-driven controls, as opposed to mechanical controls, is that they allow you to be less draconian in specifying limits. You don't have to build a bomb release that can never, ever allow the pilot to drop a bomb while inverted; you can instead say "You know, if I do what you've asked, the bomb is going to fall on the wing and probably strip off your starboard control surfaces." and the pilot can say "Yes, I know, do it anyway." And by providing a (safety-covered and hard-to-reach) button that says "Override control limits" you can even make it possible for the pilot to say in advance that at this point she feels the danger in overriding the controls is smaller than the danger in not overriding the controls. The reason we think it's reasonable to require automated controls to allow exceptions is that we know the automated controls have allowed and encouraged us to incorporate limits and we recognize that (1) those limits may have erred on the side of normal safety, (2) since the systems are new, the necessary operational envelope may not be known, and (3) the interaction of the limits may create unanticipated problems. Yes, users should be allowed to override automated controls in almost all cases AND designers should make very, very sure that the effort to override is proportional to the danger of the override. In many cases there should also be logging of overrides, so that operators, maintainers, and designers have an opportunity to notice that actual use seems to be violating the design assumptions. I wonder how many readers of this list [NO, this is NOT a survey, DON'T write to tell me] drive cars with manual transmissions precisely because they want to be in control, want to know that doing x and y will result in the car doing z, without any control system in the way to place limits on actions or responses... scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece
Today's AP noted that the FAA may cite the pilot of the Grumman Yankee for being in restricted airspace, at precisely the moment of the crash between the Aeromexico jet and the Piper Archer (which was also in restricted airspace), which distracted the air traffic controller from attending to the jet and the Piper (the absence of whose altitude information was also a factor) — at precisely the time the crash occurred. The controller did tell the Grumman pilot that he was in restricted air space, but then granted him permission to continue (and that negotiation took two precious minutes away from his attention to the jet).
A computer of the AAAS sent out renewal bills for SCIENCE to some subscribers:
Subscription price $6647, Postage $732,
Voluntary contribution $10, Total $5437.
The subscription price during 1986 was $60, and the accompanying letter from
the president of AAAS noted that inflation had required an increase. A quite
amusing editorial by Daniel Koshland, Jr. in the 26 Sept 86 issue wondered
whether any people would rush out to take advantage of the incorrect addition.
A minor correction to Chuck Fry's comments - the first anti-skid system on a production car was installed on a Jensen (pre-dating the Jensen-Healey) in the 60s. It was made by Lockheed, and derived directly from aircraft systems.
Here is an example of a risk associated with the use of computers. The risk
is to the accurate dissemination of information and is caused by faulty
programming (programmers?).
Today, the BRL Librarian informed us that the Defense Technical Information
Center (DTIC, formerly known as DDC) now requires that the titles of our
technical reports (the principal products of a research lab such as the BRL)
be written so that the "keywords" are found in the first five words of the
title.
Thus, a report which formerly was titled "Communication Modeling in the
Artillery Control Experiment" with keywords "error control," "tactical
communications," "networks," and "modeling" would have to be titled
"Modeling, Tactical Communications, and Error Control Networks," thus
sounding like, as one chap here put it, "a four volume set by Harry van
Trees" instead of a 25 page report.
Exact text of our librarian's notice follows:
> We have been advised by DTIC that the titles of technical reports should
> be designed with the key words positioned in the first five words of the
> title. This is because only the first five words are used in a title
> search in the DTIC electronic data base DROLS.(DEFENSE RESEARCH ON LINE
> SYSTEM). Important to know (and remember) is that articles are counted
> in those first five words. Therefore a report entitled "A report of the
> effect........." will not have any key words picked up in a title
> search. If you currently have a report in editing, we will review it
> and if it it does not comply with the DTIC recommendation we will advise
> you so that it can be reworked. If you currently have a report under
> review or in writing you might like to think about a title change.
> Please give this widest possible dissemination.
Brint
ARPA: abc@brl.arpa UUCP: ...{seismo,unc,,decvax,cbosgd}!brl-smoke!abc
Dr Brinton Cooper, U.S. Army Ballistic Research Laboratory
Attn: SLCBR-SE-C (Cooper), Aberdeen Proving Ground, MD 21005-5066
Offc: 301-278-6883 AV: 298-6883 FTS: 939-6883 Home: 301-879-8927
[ASK NOT WHAT YOUR COMPUTER CAN DO FOR YOU,
ASK WHAT YOU CAN DO FOR YOUR COMPUTER!
I started to add a diatribe, but gave up in annoyance. PGN]
There has been an enormous amount of difficulty in dealing with the ARPANET since early September, perhaps related to the installation of new IMP software and subsequent patches when the new release did not work properly. I had devastating problems TELNETing from four different East-coast hosts to three different SRI systems (irrespective of whether there was a gateway at my end, and even with no loads on either system). No answers have been forthcoming from any of our gurus, so the problems remain pervasive and painful. I am also getting a rash of returned net-barfed RISKS mail (as well as RISKS filling up peoples' directories when they go on vacation). There are also local problems. Last Friday a message from SRI-STRIPE to SRI-CSL took 7 hours to be delivered, while TN and FTP between those two machines worked fine. From: David L. Edwards <DLE@SRI-STRIPE.ARPA> It is becoming increasingly apparent that there are serious network problems. There has been some discussion of this on the TCPIP forum. Network delays, failed connections, inability to make connections etc. are being reported by hosts all over the network. BillW has noticed that direct communications between SRI and SU are bad. In your case there are one or two gateways involved in addition to the IMPs. The mailer recently reported 750+ attempted connections with 670+ failures. Old age? Software rot? Incompatible changes to net software? Saturation? Who knows. Stay tuned.
Please report problems with the web pages to the maintainer