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 article about a "drive-by-light" automobile appeared in the
column OPTONET: INDUSTRY BRIEFS in the newspaper OE REPORTS, April 1988,
p 16. OE REPORTS is a publication of SPIE (Society of Photo-Instrumentation
Engineers).
"A fibre-optic LAN-controlled automobile will be demonstrated this month at the
Hanover Trade Fair. ... The automobile uses polymer optical fibre (POF)
components and systems. In the fibre-optic automobile, everything from
headlamps to electronic trunk locks will be controlled by a few meters of POF
and networking techniques."
(There was a diagram of the car showing modules labelled only "module 1" etc.
with lines connecting them up. There were a lot of modules in the passenger
compartment and dashboard and one under the middle of the hood, but none
in the wheel wells. I get the impression this is actually supposed to be
more of a trade-show attention-getter than an attempt to develop a practical
way to build a car.)
- Jonathan Jacky, University of Washington
The following report appears in ELECTRONICS, March 3 1988, in the MILITARY/AEROSPACE NEWSLETTER column. No author is named: "SIMULATORS GAIN GREATER ROLE IN FLIGHT TRAINING The Air Force is cutting in half the number of aircraft used for training and relying more heavily on simulators to train fighter pilots and gunners. "It used to be that 25% of all our aircraft were for training, but now we're going to 12.5%," says (an Air Force spokesperson). ... The $30 million system (to simulate the F-15E trainer) which includes five mainframe computers and 25 video displays, will get a real workout: the Air Force expects eight flight crews to work two-hour shifts on the simulator every day." - Jonathan Jacky, University of Washington
In RISKS DIGEST 6.50, jon@june.cs.washington.edu (Jon Jacky) related stories from the NY Times regarding cockpit automation risks. Two of these, in my opinion, are more the result of poor procedures than the result of cockpit automation. The China Airlines 747 incident (where the crew lost control of a 747 after losing an engine) was really caused by the captain failing to follow established Boeing procedures for handling loss of one engine. Proper procedures stipulate that the autopilot should be disengaged upon failure of one engine during cruise; the captain left the autopilot engaged, leading to the results described in Mr. Jacky's message. (Incidentally, loss of one engine while enroute in a 747 is NOT considered an emergency.) The Eastern Airlines L-1011 crash in the Everglades was a direct result of the flight crew's neglecting their primary job: flying the airplane. It was not so much a matter of an inadvertent disengagement of the autopilot as it was the flight crew's failure to perform their primary duty that caused the accident. (The Eastern L-1011 has become a classic case study in aviation circles. A re-enactment of the accident, in a simulator using text from the transcript of the cockpit voice recorder, was video taped a few years ago. The video tape is used by numerous airlines in their crew training. The tape was also shown as part of a _Nova_ episode entitled, "Why Planes Crash." That re-enactment is, simply, the most frightening thing I have ever seen. Alan M. Marcum Sun Microsystems, Technical Consulting marcum@nescorna.Sun.COM Mountain View, California
> In RISKS 6(36), Jerry Harper asks: > (Is it true that missiles were recently destroyed on launch that had > their guidance systems coded in Ada? I very much doubt it. I researched the Ada story quite thoroughly about two years ago for an article I was writing. At that time, almost no software about to be fielded in weapons was being coded in Ada, despite DoD requirements. The reason was that compilers then available either did not produce code at all, or did not produce sufficiently high-performance code, for the small processors used in missiles and other weapons. I have been following the story since then and things appear to have improved a little but there is still a problem, moreover lead times are quite long. So I doubt Ada could have been at fault. I have not heard of any recent missile losses caused by software faults. In fact the only case I know of was the very famous loss of Mariner I in 1962, which has been discussed at length in RISKS. (I notice that a company called Northwest Instrument Systems, Inc. of Beaverton, Oregon has been advertising an embedded code debugger with full page ads featuring a photo of a missile exploding a short distance from a launcher, captioned "The ultimate bug." The ad has appeared in ELECTRONICS and ELECTRONIC ENGINEERING TIMES. I presume that a certain amount of license has been taken, in that the pictured incident is not to be literally attributed to a software problem.) > Didn't some famous computer scientist express grave reservations about Ada? Yes. C.A.R. Hoare of Oxford used the occasion of his Turing Award lecture in 1980 to say: "I appeal to you, representatives of the programming profession of the United States, and citizens concerned with the welfare and safety of your own country and of mankind: Do not allow this language in its present state to be used in applications where reliability is critical, i.e., nuclear power stations, cruise missiles, early warning systems, anti-ballistic missile systems. The next rocket to go astray as a result of a programming language error may not be an exploratory space rocket on a harmless trip to Venus: It may be a nuclear warhead exploding over one of our own cities. An unreliable programming language generating unreliable programs constitutes a far greater risk to our environment and to our society than unsafe cars, toxic pesticides, or accidents at nuclear power stations. Be vigilant to reduce that risk, not to increase it." Reference: C.A.R. Hoare, "The emperor's old clothes," COMMUNICATIONS OF THE ACM, 24(2), Feb. 1981, pps. 75 - 83. Also reprinted _The Ada Programming Language: A Tutorial_, ed. by Sabina H. Saib and Robert E. Fritz, New York, IEEE, 1983, 487 - 495. No doubt also reprinted in the book, ACM Turing Award Lectures: The First Twenty Years: 1966 - 1985, ACM Press/Addison Wesley 1987. > Is the Pentagon insisting on the use of Ada for all military software? Not exactly all. Defense Directive 3405.2, March 30 1987, orders the use of Ada in all new weapons systems. The DoD also buys a lot of software that is not used for weapons control. A similar directive issued in 1983 ordered the use of Ada in all "mission-critical" systems after January 1, 1984, and was almost totally ineffective. Contractors found that the compilers then available were unsuitable, and petitioned DoD for waivers, which they received. DoD's position is that the compiler technology is now much more mature, and waivers will be quite difficult to get. - Jonathan Jacky, University of Washington
Several months ago, I was making a $20 cash withdrawal from my bank's automated teller machine. While waiting for my money to come out, the CRT went blank; several seconds later, a message saying "Please Wait" appeared. I theorized that the machine was being reloaded with money - just a guess. After 15-20 seconds, the screen cleared and put up the normal "Welcome to First National Bank Teller/24" message. No money. No card. No receipt. Being the kind of person who likes to figure out how/why things work, needing the money so I could eat dinner, and having the good fortune of being with my wife, I borrowed her card to see if the machine would do the same thing again. The strange sequence of events did not recur, and everything proceeded normally. When the money/receipt door opened, however, I received TWO $20 bills; one that I expected, and the other from the previous (failed) transaction. I found out later that a momentary power failure had blacked out a large part of the city, including my bank branch, just after my $20 was ejected into the cash drawer and just before the machine returned my card and opened the door. Had I been un-curious, well-fed, and alone, or had the power failure been longer in duration than my patience, I would have shrugged my shoulders and walked away after the failed transaction, and the next guy would have gotten my $20 (and a bit of trouble, had he/she not been honest about it). I suppose that everything would have gotten straightened out eventually... I was going to suggest to the bank that they change the sequencing of events to handle this possibility a little better when they replaced the locking money doors with they're-always-unlocked-lift-em-yourself type. I still wonder, though, if there are some other hitches where such a power failure could mean trouble for a system handling cash. A humorous, true, but perhaps not as RISKy story: A local bank uses full-sized "play-money" to train employees to load the teller machines with cash. At one branch, the practice money was inadvertently left in the machine. Customers were quick to point out this oversight to the branch personnel. The first person to receive the bogus cash, though, did not immediately notify the bank. By chance, this person was the next-door neighbor of the bank's CEO. After laughing it off with the CEO, the neighbor went back to the branch the next day and made his monthly mortgage payment, in "cash", to the bank. Rick McTeague, Electrical Engineering Department, Speed Scientific School University of Louisville, Louisville, KY 40292
From: cudney@sm.unisys.com (Paul Cudney) >Before the beginning of computing was time, and with time was change. You >might think we would all be familiar enough with calendar time to cope with >it easily, even to the point of designing systems to accommodate both the >predictable and the politically inevitable. Is it the fault of computers when the political definition of what "Time" is changes? The collection of political lobbying groups included those industries involved in outdoor barbeques (large part) as well as a society to help those with night blindness. The legal definition of Daylight Savings Time has changed more in the past 15 years than all prior years. How many people were aware of the change of the laws regarding daylight savings? I'm not condeming the change, I think however, we rely heavily upon media watchers. Some of these loobying groups, BTW, are still trying to change the definition of Daylight Saving Time in the fall to include two more weeks. So I hope you guys get your software changed before then. Perhaps, we should compromise and average the 1/2 hour.....;-) Also, the article on the Cray Shinto blessing was a Cray Press release and will probably be published in Cray Channels. This isn't anything special (in Japan). See "The Faces of Japan" hosted by Dick Cavett. --eugene miya, NASA Ames
The New York Times article reported by PGN on April 2 unfortunately has a minor error of fact. The study referred to, which is incidentally in the current issue of the Communications of the ACM, used the MUSIC/SP editor. The author of the article apparently assumed that this was some sort of PC. However, MUSIC/SP is an operating system that runs on IBM mainframes. (It is developed by McGill and marketed by IBM.)
David Thomasson's complaints of philosophical shoddiness in some recent RISKS pieces on discrimination seem off the mark to me, perhaps owing to the concerns of *my* field (literary criticism). In all the instances I recall, and particularly Les Earnest's, nobody was talking about the question of what the ideal Motor Vehicle Bureau should ask you on their application. Les Earnest's was a *story* that told of becoming uneasy about certain classifications in the light of substantial evidence of their misuse. Thomasson would have us ignore how information is used in society, and once you do that then of course a discrimination's bad effects will often disappear from view; you can pretend that a Southern state, in the early 60s, would ask about your race merely because it's useful for identification. Just because they can cite good reasons doesn't mean their real reasons aren't bad. I don't say that it's useless to discuss these questions without relating them to real life. But surely one theme of the RISKS list is that something which looks fine in the lab can become quite different out in the field. John Lavagnino, Department of English and American Literature, Brandeis Univ.
> Date: Wed, 30 Mar 88 10:12 CST
> From: Joel Kirsh <KIRSH@NUACC.ACNS.NWU.Edu>
> The user interface on the new diving computers is certainly critical, ...
Since the people at the shop where I buy my gear are not experts on
decompression theory, they were understandably reluctant to make specific
comments on this article, and did not want their names used. But, it is their
understanding that many top-name manufacturers *are* using the new, improved,
safer data as the basis for their computerized decompression meters. Since
this is comp.risks, and not rec.scuba, I don't think the subject to be worth
an "in-depth" treatment, but I would suggest that anyone concerned about
buying a particular manufacturer's meter simply give the manufacturer a call
and ask what tables are being used. One thing worth saying is that a number
of different systems have been devised over the past fifteen years for
reducing the expected incidence of DCS to more acceptable levels than had been
observed with the old USN tables.
-- Phil Pfeiffer, (608) 262-6625
..!{harvard,ihnp4,seismo,topaz,akgua,allegra,usbvax}!cs.wisc.edu!pfeiffer
> A colleague told me the other day that he'd heard that the Australian
> Federal Police were going through the various Universities, armed with
> a search warrant, looking for pirated software on PC hard disks...
A similar rumor has been making the rounds of the Ontario universities
lately. It too appears to have been without foundation in fact, but it
did make a lot of people nervous for a little while.
Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
ALSO From: Ken De Cruyenaere <KDC%UOFMCC.BITNET@CORNELLC.CCS.CORNELL.EDU>,
University of Manitoba Winnipeg
("The R.C.M.P. have raided several eastern universities in search of
pirated software ") The rumors have proven to be just that, rumors, with
no basis in fact. There are rumors that people were scrambling to remove
software and equipment in advance of the impending "raids".
[Sounds a little like April Fool's leftovers. PGN]
in article <12386323646.17.NEUMANN@KL.SRI.COM>, mcvax!geocub!anthes@uunet.UU.NET (Franklin Anthes) says:
>
> Over here in France a black-box system has existed for quite a while now.
> It isn't a computer, and its output goes to a paper disk, so it probably
> can be tampered with.
The Tachometer is used all over Europe, I assume because of an EC (euopean
community) law which each member state then ratified.
In the UK where laws have been passed restricting the number of hours
of continuous driving AND the total in any 24 hr period, Inspectors
(and police) can ask to see the disk, and the device (according to truck
drivers I've hitched with) is frequently cited in accident/insurance claims.
This implies it's speed/time/distance logging is accurate enough to satisfy
the legal process, If a tacho says your exceeded the speed limit and it's
working OK you can be had up for it.
Also fitted to public transport vehicles. Not just Long distance Trucks
but also small haulage vans must be so fitted.
PS the output is displayed on the Drivers dashboard so (s)he can decide
how to spread the working hours over the day, or pull over if a time limit
is exceeded. I always thought a 'black box' was a passive data capture unit
sealed away out of sight.
-someone in the UK can comment on how it's changed accident statistics since
being introduced. At the time there were the usual -public-freedoms-are
-being-assaulted claims mostly be haulage bosses who had to spend cash
retro-fitting the things into wagons.
surely the simpler the o/p device (eg direct to paper) the happier one
is with the result? OK there are limiting factors of complexity at play
here, but in the context of COMPUTER failure I'd rather have a chart
logger there any day!
George Michaelson
55 Barry St, Carlton, Vic 3053, Phone: (03) 347 8644
A friend of mine used to be a trucker. The solution used to avoid recording
of excessive travel and speeds was to pull the fuse powering the device. I
doubt that a tamperproof device has yet been made.
John Haller
Many HP terminals have block mode, in assorted variant forms. I was mildly bitten by one such terminal last week. On this one (a 2621), one can enable block mode, in which case the terminal doesn't send any data to the machine until you hit RETURN. When you do, it moves the cursor to the beginning of the line, then moves it along the line as it sends each character, finally sending (and executing) a RETURN at the end of the line. Furthermore, the terminal is smart enough that it knows where you started typing on the line; hence a prompt won't be transmitted back to the machine. The intended purpose of this whole feature is to allow local editing (i.e., insert/delete character), even on machines that don't have any software support for it. I don't recall if the 2621 allows the host to initiate transmission, but some other HP terminals (such as the 2645) definitely do. What was the glitch? Well, unknown to me, the terminal was in block mode. Because it's smart enough to cope with the host echoing characters (this was a UNIX(r) system), I never noticed it. Then I had to enter a password; to my great surprise, the password was being displayed as I typed it... Steve Bellovin ulyssesf!smb smb@ulysses.att.com
Please report problems with the web pages to the maintainer