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…
Earlier this year, the New York Times published an anonymous op-ed piece about Gorbachev's reforms. Since the piece was quite pessimistic, speculation arose about the author's identity. The 19 February 1990 issue of The New Republic has an article by Lionel Barber identifying the author as historian Martin Malia at U. C. Berkeley. Among the reasons given for this choice was: The hardest evidence, however, comes from Berkeley's own history department. According to a staff member whom I interviewed, Malia composed part of the Daedalus article [a longer version of the op-ed piece] on a departmental computer under the filename "PERES" - presumably a reference to perestroika, not the Israeli politician. The staff member called up the file on his own computer during our interview and read me lengthy passages, all of which were identical to passages in "To the Stalin Mausoleum" [the title of the Daedalus article]. A few pages further on in the same issue, Katie Hafner (who I believe was causing a stir elsewhere on the network recently) has an article on the Robert Morris trial. Her conclusion was that Morris' conviction was a small step for some abstract principle, but had little or no relevance to practical concerns about computer crime.
Sunday's launch of the space shuttle was delayed because of problems with the backup tracking computer used by the range safety officer. According to the Air Force, the problem was ``bad software''. No word, at least in the stories I've seen, about what the bug was, or about why it affected only the backup computer — or how long this bug has been present. --Steve Bellovin
Idahonian/The Daily News, Weekend, February 17 & 18, 1990 PASADENA, Calif. (AP) — The Magellian spacecraft speeding toward cloud-shrouded Venus on a $550 million mapping expedition, will need frequent commands from Earth until NASA fixes a computer problem. Despite the failure of a computer chip on the spaceship, "there's no threat to the mission," said Edwin Sherry, a technical assistant at the space agency's Jet Propulsion Laboratory. Until engineers locate the faulty chip, they must send Magellan new commands every other day to make sure it is pointing in the proper direction, Sherry said. He said a similar computer chip failure happened before Magellan was launched and that such a failure is expected about once annually. "You'd hope for zero faults like this," Sherry said. "But they're typical of working with state-of-the-art equipment. It's remarkable we have so few." Magellan was launched from space shuttle Atlantis on May 4. It will go into a polar orbit around Venus on Aug. 10. [Two paragraphs about the mission deleted.] The problem developed Sunday as the spacecraft got ready to take a fix on two distant stars to make sure it was pointing the right way. An error was detected in a tiny part of Magellan's computer memory. The error prompted Magellan to shift to a backup computer and point its solar panels toward the sun to increase the power supply. The failure was apparently the result of electrical corrosion at a junction between two types of material on a single memory chip, leaving the chip unable to remember anything, Sherry said. He said, however, engineers haven't yet ruled out the possibility that the chip was damaged by an electrically charged particle spewed out by the sun, which is near the peak of its 11-year cycle of activity. Magellan uses gyroscopes to sense when pressure from solar wind makes the spacecraft drift slightly, or point in the wrong direction. The gyroscopes normally issure automatic commands to three spinning wheels, which correct the spacecraft's alignment. Magellan's main computer is programmed to take a fix on the two stars each day to determine the spacecraft's actual allignment. If this "star calibration" shows the gyroscopes failed to align Magellan correctly, they again command the wheels to adjust the craft's position. [Oh well, its only an AP staff reporter...] [I recall that there is also some computer problem with Galileo, maybe from an article in AAAS Science, but I haven't seen it on RISKS.]
Crash in India Rekindles Dispute over Safety of Airbus A320 Jet (Steven Greenhouse, c.1990 N.Y. Times News Service, BRIEF EXCERPT) PARIS. The crash of an Airbus A320 jet that killed 97 people in India last week has reignited a dispute in France over whether the computerized, highly advanced aircraft is too complicated to fly. The French pilots union is urging the airliner be grounded in France. ``This plane is sometimes put into operation by people who aren't qualified enough,'' said Jean-Claude Bidot, secretary general of the French Airline Pilots Union. ``It's a supercomplicated aircraft.'' But the maker of the plane, the four-nation consortium known as Airbus Industrie, said the plane was quite safe and the French pilots were opposing it to protect their economic interests. The plane uses two pilots; many other aircraft use three. [...]
> "do . . . while" construct, which contained a "switch" statement, which This presumes that the error was made by one particular programmer. But such production code is surely the responsibility of a team of programmers, each module being evaluated by more than one peer and supervisor. All programmers make errors. The problem is why this "stupid programming error" survived through to production. Correcting the code does not correct this root problem; and the root problem, failure to catch the error, may be less likely in other languages. > if we can't expect our programmers to understand the language > with which they are programming, then what *can* we expect? Certainly, we must expect programmers to make such mistakes whatever their launguage, and however well they understand it. Some languages do assist error-catching more than others, APL being the extreme worst case, for example.
The BLISS family of languages originally had this hazardous multi-level break, "EXIT[n]", but then they added (*sigh*) a better scheme. Any expression (and in BLISS, *all* control structures such as begin/end, if/then, case, for/while loops, etc, were expressions and could yield values) could have a label attached, and from anywhere within that expression only you could say, "LEAVE <label>" or "LEAVE <label> WITH <value>". That way, the thing being left stayed constant even if you added or removed interior levels. Further, labels had to be declared before being used (generally considered a pain, until the day it saved you from a mispelling), and a label could be used — attached to something — only once in the scope of its declaration. (Of course, you could have many LEAVE's inside a labelled structure.) Outline: LABEL FOO; LOCAL X;
C problems?
<smb@ulysses.att.com> Sat, 24 Feb 90 02:01:52 ESTThere is little point to enumerating the vulerabilities of C; one could write a book about them. In fact, Andy Koenig already has: ``C Traps and Pitfalls'', which I recommend to anyone using the language. That is not the point, however. The real question is whether or not any real language is sufficiently free of such traps as to significantly reduce the probability of errors. To tremendously oversimplify the situation, languages that are higher-level than C often achieve their power at the price of complexity. This complexity itself can can breed errors; see, for example, Hoare's comments on Ada, or Koenig's early paper ``PL/I Traps and Pitfalls''. To be sure, the power can help avoid some bugs — the ``fingerd'' bug that the Internet virus/worm/parasite exploited could not have happened in PL/I because strings, and in particular variable-length strings, are a built-in data type; one would not have C's temptation to use fixed-size arrays. On the other hand, languages that are ``safer'' than C often achieve their safety by significantly restricting their expressive power. This can have several results. First, the programmer must concentrate more on low-level details again, with the concommitant pressure towards short cuts (i.e., fixed length arrays — Pascal, for example, does not even have malloc()). Second, the language may become unsuitable for large projects; again, Pascal comes to mind. Third, programmers will cheat — move around the boundaries of the language using escape hatches or arcange knowledge. It may be that there is a suitable compromise. There have certainly been enough attempts; what is missing is convincing evidence that these actually reduce the error rate in real life. Note that by ``real life'', I specifically include the lifetime history of real programs — and that includes modifications and changes over the years by many different people. I assume that there have been some attempts to measure this; I wouldd appreciate citations. The other approach often taken is to design languages that are in some sense ``suitable for verification''. That is, features are inserted or omitted not simply because of their complexity or aesthetics, but also because of their effect on attempts to verify the program using formal methods. Apart from the aforementioned question of whether or not such languages are really suitable for real programming problems, they do nothing in and of themselves to reduce the error rate; they merely make it easier for a competent, well-trained programmer with enough time to validate a program as its being written. (Some would claim that writing a program using formal methods will result in less-buggy programs. I will not dispute that here, except to note that that requires more time up front — and we all know how feasible that can be when on a tight schedule, even if it seems likely to reduce total project time later on.) If such languages help, though, we are very far from our original ideal, which was a technical solution to the problem. Verifying programs, or constructing them using formal methods, requires rather different, and arguably scarcer, skills than are present in the programming population today. It is thus a people problem, and an educational one. In fact, it is far from clear that this will accomplish very much overall except to recast the obvious: that better programmers write better programs. Wasn't it Knuth who demonstrated years ago that the best programmers produced code that was 4-5x faster *and* 4-5x smaller than the worst? Our goal must be to let anyone write better programs. The challenge is not only devising the methods, but also demonstrating that they work. --Steve Bellovin
RE: AT&T (Smith, RISKS-9.70)
david paul hoyt <YZE6041@vx.acs.umn.edu> Sat, 24 Feb 90 12:24 CST> If the AT&T programmer had coded "goto" instead of "break", ... The reason the programmer would have had problems with his/her peers is that (unconstrained) goto's greatly reduce the maintainability of the code. Ultimately increasing the likelihood of failure. In my experience, it has been very rare that with a little more thought, I couldn't come up with a solution that got rid of the need of a goto. Non-local goto's are almost always a sign of unwarranted complexity and that the design should be rethought. By the way, I am experienced in large scale complexity. I have developed, maintained and converted +million line programs. david | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet
re: Computerized Collect Calls
John (J.G.) Mainwaring <CRM312A@BNR.CA> Fri, 23 Feb 90 16:20:00 ESTMark Brader's posting in RISKS-9.69 about the reporter who reached the editor who said "... computer telemarketing things" just goes to illustrate one of the pervasive threads of this forum: Computer Aided Stupidity will have far more impact on society than Computer Aided Intelligence for years to come. Mark's reporter and editor seem to be cases in point. Automated systems such as this have easy mechanisms to allow the user to talk to a live operator when the automated system doesn't meet their needs. It does have to occur to one or other of the users (in this case the reporter) that the live operator would be a good idea. Automation is brought about because of consumer pressure brought on the PUCs which control the telephone operating companies' rates. If you would really prefer an all manual system, perhaps next time your PUC is considering a rate application from your telephone company, you will go along and tell them you don't think the phone company is asking for enough. By and large, this is an uncommon occurrence. Perhaps we could all entertain ourselves with stories about how when you call with these new fangled rotary dial phones, they don't even know that Millie is always next door at Dottie's having coffee at this time of the morning like the operator always knew. I doubt if there ever was or will be an innovation involving something we all use every day that doesn't let someone come up with a story to convince himself he's (marginally) smarter than some machine. Once the new becomes familiar we usually really do end up in control of the machines.
A different multiple-copy problem (SEN)
Dan Craigen <dan@ora.on.ca> Sat, 24 Feb 90 00:19:57 ESTUnfortunately, we're all used to receiving multiple copies of the Risks digest from time to time. However, when I got home today, I found twelve copies of Software Engineering Notes at my front door. Apparently, somewhere along the distribution line, the twelve copies were bundled together with my name and address at the top. The other eleven are for various individuals spread out through Ontario. The ordering of the journals is based on ACM membership number. An interesting Risks twist. I'll put the other eleven back in the postal system tomorrow.Please report problems with the web pages to the maintainer
xTop