Henry Spencer notes that the flight control on an F16 (etc) does not prevent the pilot from losing control of the aircraft. He is correct to the letter. To my knowledge, there is no aircraft yet built which is guaranteed to be stall-free, spin-free and tumble-free. Let me be more precise, and unfortunately more lengthy. I was trying to convey the idea that because of fly-by-wire design decisions, there are different risks to flying a new-generation fighter. An aircraft may enter an accelerated stall at high speed in a sharp turn. An F16 airframe is certainly capable of this, but is control limited since the pilot probably isn't. The pilot believes he or she may thus roll and haul back, strain and black-out, and not have to cope with an accelerated stall while having no vision. With real control actuators in the F16, a pilot would have to be much more sensitive on the stick, and probably couldn't plan to tolerate routine black-outs. The risks have changed - pilots now sometimes lose consciousness, and have little or no motor control for up to a minute when they regain it. That's a dive into the ground from 60,000 feet. This is rather like the ATM example. Usually the transaction is finished when you remove your card, but not always, it seems. With a real teller it would be. But a real teller might make a transcription mistake. The risks have changed. The Airbus example is relevant here, also. Using computer direction to maintain maximal angle of attack on a go-around might lead to disaster if in a microburst rotor, since the winds change faster than the aircraft can respond (as in the DFW accident). I'm sure the airbus people would have thought of that - except that we don't yet know what exactly happens in a microburst, so how can we be assured of the control logic? The computer controls the aircraft better than a human can follow a flight director, but a human can improvise, sometimes, in these unknown situations. The risks have changed - but maybe I'm preaching to the converted? peter ladkin
From the "Safety" column in the March 30 Aviation Week and Space Technology, the magazine-provided abstract follows: Northrup Corp.'s F-20A Tigershark prototype fighter aircraft was flying an authorized practice demonstration at the Goose Bay Airport, Labrador, Newfoundland, on May 14, 1985, in preparation for performances at the upcoming Paris air show. During the final aerobatic maneuver of the 5-min. flight, the aircraft deviated from the planned profile and entered a shallow wings-level descent. The descent continued until the aircraft struck the ground, killing the pilot, David Barnes. The Canadian Aviation Safety Board determined that the Northrup pilot became incapacitated during or following the final high-g pull-up maneuver and did not recover sufficiently to prevent the aircraft from striking the ground. Initial portions ran in Aviation Week and Space Technology Mar 23, p. 75; Mar 16, p. 89. [[[End of Abstract]]] This 3rd part of the series presents the conclusions of the CASB. This is related to Risks only in that previous contributions have suggested that pilots were beginning to depend on the computer to save them in GLC (G-induced Loss of Conciousness) situations and the CASB findings *do not* support this hypothesis. In fact, this civilian pilot "had not received formal aeromedical training pertaining to the GLC phenomenon and no evidence was found that GLC training was required prior to participation in high-g demonstration flights." There were also pilot medical conditions and other contributing factors. It would seem that this was a training and human risk, rather than a computer-related risk. Tom Perrine
1. A couple of weeks ago, my VCR started "malfunctioning." It would turn the TV screen to noise whenever I pushed the TV/VCR button to TV (it does not record without the "TV" being "on"), and so would not record. It also did not play back. I got a picture (very muddy) and not much sound. Since my son (age 2.5) had been "playing" with it the day before, I tried to find out what he had done (if anything). I checked the connections, a few buttons in the "control panel" in front, the channel on the front (with cable, you just leave it on channel 3), but could find nothing wrong. I did not look in the manual for instructions on initial startup. The problem? The channel select IN BACK, a small switch which selects either channel 3 or 4 had been switched to 4. Last week, my radio in the car starting "malfunctioning" (the normal stations were not coming in, etc). I still had not learned the VCR lesson, and it took me several days to find out he (my son again) had hit the FM/AM button. If I had a simple checklist, I would have easily and quickly solved both of these "problems." Now I am wondering about more complicated systems (airplanes, power plants, etc.). What kind of things are on their "checklists"? The simple variety (check fuel gauge), or more elaborate items? Joseph [You forgot that your offspring is very resilient. PGN]
On Saturday, April 18, the major wire and news services carried a story, attributed to the New York Times, saying that the FAA was about to start testing of a prototype neutron beam-based system for detecting the nitrogen in explosives that might be in luggage/cargo loaded into plane cargo holds. This is a computer-based system that bombards luggage or other cargo with a "beam of slowed neutrons" and uses a computer system to analyze the signature of the resulting gamma radiation emissions to characterize for the potential presence of explosives. The Associated Press inaccurately suggested that the manufacturer of this equipment was a firm named "Thermedics." The actual NYT article gives much more detail and accurately names the manufacturer as "Science Applications International Corp." of Sunnyvale. Some months ago, when this technology was originally mentioned in the press, there was some discussion of the radiation problems inherent with this sort of technology. While one would assume care would be used to make sure animals traveling as cargo are not subjected to a neutron beam, the problem of secondary radiation effects on the clothes, foods, medications, and everything else that travels as cargo/luggage seems to be glossed over by the press. While normal X-ray technologies do not produce secondary radiation at conventional power levels, neutrons are extremely energetic and in fact this explosive detection system appears to be depending on secondary radiation for its very operation! When this system was first discussed in the press some months ago, there was mention of the problems of cargo and luggage becoming "slightly radioactive" as a result of being subjected to the "slowed neutron beam." The current discussion in the press seems to be avoiding this issue entirely, instead mentioning that the people operating the equipment will not be subjected to more than "government standards" for radiation exposure (many persons seem to feel that these standards allow far too much exposure as it is). The question then, for anyone who understands this technology or knows about Science Applications International, is: what will happen to luggage, cargo, etc., possibly including foods and other items that can be ingested or will be in close proximity to persons for long periods of time, after passing through such neutron beam systems once or possibly many times in the course of complex or multiple trips? Are airline passengers to be subjected to the radioactive luggage and cargo simply because the emission levels meet "government standards"? Will the frequent traveler be at greater risk than the occasional traveler? What is the real story about these systems? In case you're wondering who will be the first guinea pigs for this technology, it's the folks in the SF Bay area. San Francisco International (SFO) is slated to get the first prototypes of these devices sometime quite soon for at least a 4-week trial. The equipment is then to be tested at other major airports and the FAA hopes to have it in widespread use within 2 years. Apparently the prototypes to be tested are "improved" versions of an earlier model that required 30 seconds per test--the new equipment bombards the target material for 6 seconds (possibly longer if the typical conveyer and luggage problems cause clogs on the transport system). Of the two prototypes, one supposedly uses a continuous neutron emitter based on an internal chunk of some radioactive material, while the other uses a "turn-offable" system for generating the neutrons. Can anyone out there shed some light on the risks associated with this technology? [The computers in this system may or may not present risks, e.g., if the computers are involved in control, or if the signature analysis is faulty. In any case, the risk issues are interesting enough to warrant some KNOWLEDGEABLE discussion here. Let's avoid SPECULATIONS, PLEASE. PGN]
To: email@example.com, mod-back I'm curious: how can you fake a posting without being root? When I post anything to mod.os (er, excuse me, comp.os.research) I'm always listed as the sender. Not wanting to be the bad guy I've never tried to crack it, but I am curious as to the hole that causes the problem. Darrell asks an interesting question, and I might as well let everyone know while I'm at it. As background, be aware that USENET has a major security hole, in that there is no way for the program rnews to know where a message came from. It has to implicitly trust the information in the header of the message. While uucp does site verification across the net, that information is not passed along through uux to the executed program on the other side. It has to trust the data it gets. This leads to a trivial hack for creating bogus and untraceable messages. Take an existing message (I borrowed this one from mod.announce): Path: sun!cbosgd!mark From: mark@cbosgd.ATT.COM (Mark Horton) Newsgroups: mod.announce,news.announce.important Subject: mod.announce is being renamed news.announce.important Message-ID: <3525@cbosgd.ATT.COM> Date: 13 Apr 87 15:09:20 GMT Organization: AT&T Bell Laboratories, Columbus, Oh Lines: 9 Approved: mark@cbosgd.MIS.OH.ATT.COM Xref: sun mod.announce:24 news.announce.important:1 This is your template. Now, change the header lines to fit, and delete the Xref line: Path: cbosdg!mark From: mark@cbosdg.ATT.COM (Mark Horton) Newsgroups: mod.announce Subject: Newgroup renaming is a failure, film at 11. Message-ID: <3.14159@cbosdg.ATT.COM> Date: 1 Apr 87 00:00:00 GMT Organization: The Backbone Cabal, Inc. Lines: 9 Approved: mark@cbosdg.MIS.OH.ATT.COM Don't worry about the # of lines, inews will be nice enough to adjust it for you. Store that in a file, add the message body to it, and execute: % /bin/rnews < file rnews will read it just as if it had come over the network, and install it. It believes everything you said in the header. When it passes it along, the Path: becomes "sun!cbsogd!mark" and it gets passes along just like a real message. The only place where this is traceable is the Path variable, because you can see that my site is at the beginning of the list of real paths. You can avoid this in a couple of ways if you want to be real sneaky: o the kremvax syndrome: instead of having a single address in the path, put in a bunch: Path: kremvax!nsacyber!prarie!wobegon!himom!cbosdg!mark depending on your ingenuity, you make make it almost impossible to tell where the message joined the net for real. o drop out of the loop: even more fun, rather than execute rnews on YOUR site, execute it on someone else's. % uux - -z ihnp4\!rnews < file the Path is now "ihnp4!cbosdg!mark" and your own site is nowhere to be seen. Completely untraceable, unless someone wants to compare uucp's LOGFILE entry times with news 'log' entries and backtrack. Which assumes that they figure out it is happening before they flush the logs. And that they have the time, and care. That's how you forge messages. And as long as the uucp links exist, there is no way to fix this, because a vital piece of information isn't passed out of uucp. The possibilities are endless, of course. You can not only post April Fool's messages, but post messages FOR people that they can never prove they didn't post. completely untraceable. You can change your name, your machine, your religious background, all untraceable. Possibly even skip out on child support, if you find the right control message. Kids, don't try this at home! These people are paid professionals, and know the risks involved... (grin) chuq (next week, how to kick a site off the net with cancel messages!) [For those of you who never saw the KREMVAX 1984 April Fools' Day hoax, see ACM SIGSOFT Software Engineering Notes. July 1984. vol 9 no 4. PGN]
The only place you can be traced using chuq's "posting techniques" is the log files. In the `uux - -z ihnp4!rnews < file` example, the machine and user name will appear in ihnp4's LOGFILE or HDB's uucico, and uuxqt logs. I'm not sure but have a funny feeling one can trace the user (by logs) if he posts it on his machine, beside having his machine on the path list. The brahms people did a good job of tracking down a person faking articles by using log files. rob
> I did not want to carry sixty $20 notes around with me, and I didn't want a > bank cheque either. I asked him to "undo" the transaction, and said I'd come > back later. The teller assured me that the only way that it could be done > would be to redeposit the $1200 into the same account... This may be a people problem rather than a software design problem. I spent the first three years of my career writing communications interfaces for ATMs for one of the major computer vendors. In the process, I became familiar with the computing systems of several Washington, D.C. banks. For each transaction type, there is a "correction" transaction code that will reverse the effects of its corresponding "normal" tran code. This follows manual accounting procedure that requires errors to be explicitly backed out by a separate entry rather than simply erased. At least two of the banks that I did work for monitored their tellers to keep track of who made errors, when, what kind of error, etc. If Ken Ross's bank has a system like this, and the tellers are aware of it, they might prefer not to use a correction transaction that will show up on a report to their supervisor.
> [I'm surprised that someone was smart enough to know about the $1 > billion problem before it really did "blow a fuse". Who knows where > the $600,000 million might have ended up!... (Chuck Weinstock)] !!!! Risks of thinking of UK billions in a US story? This is the second error of this off-by-000 type to make it to the net in a week or two (the last one was in sci.astro)... Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb [Fortunately Chuck's extra zeroes were detectable from context... PGN]
The April 1987 issue of the Hewlett-Packard Journal contains a short (four page) article entitled "Reliability Theory Applied to Software Testing." From the abstract: The execution-time theory of software reliability is extended to the software testing process by introduction of an accelerating factor. It is shown that the accelerating factor can be determined from repair data and used to make prerelease estimates of software reliability for similar products. The article describes how the model was applied to the firmware for two HP terminals. (Subscriptions to the HP Journal are available without charge from Hewlett-Packard Journal, 3200 Hillview Avenue, Palo Alto, CA 94304).
Please report problems with the web pages to the maintainer