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…
I have read <<Softwar<> only in the French version, and it is interesting to see from Gary Chapman's review that several differences appear to have been worked into the details of the plot to make it more suitable for American [re]viewing audiences. Of particular note is the agency with which the American hero is associated — a Langley, Va. organization called NSA (the National *Software* Agency) has been chartered with two primary missions: software debugging and — software bugging! With only modest chauvinism the authors point out that the French-derived programming language Ada has been chosen as the primary tool for achieving the software debugging mission since it makes it so much easier to locate programming errors. [There are lots of justified paeans to French superiority in software engineering.] Interestingly, the book's NSA does not seem to have any interest in the use of methodological system development techniques in which the intention is to produce correct code in the first place. One is forced to wonder how they intend to produce correctly working softbombs to start with. Perhaps the two directorates do not talk with each other. The first softbomb is discovered by the soviet computing scientist by analysing a trace of program execution. He correctly finds that the softbomb code executes less frequently than the other instruction sequences in the massive meteorological program, and is thus able to identify its trigger. Not so the more elaborate examples of hardware subversion that follow in the book's development. The amount of blind trust that is placed in hardware correctness over that of the software is a realistic assessment of the fairly commonly misplaced faith that one sees today. The attribution to the 'NSA' of the view that using the new high-tech Ada will lead to lower costs and higher reliability (because of cheaper debugging) is an opinion one frequently hears in government. The book, albeit oversimplified, was fun to read. I found the social implications of the book to be far more interesting than the description of sophisticated computer virus attacks that was mentioned in the Scientific American review a couple of years ago. Marv Schaefer
From Dave Parnas: The Fletcher panel... They even rejected a military-like hierarchical command structure for the computers so that there would be no "Achilles Heel" in the system. And then the Eastport panel went ahead to propose just that!! Fossedal's reference to "a single error" is part of another red herring in which SDIO supporters claim that the critics want perfection. The only reference to "error free software" came from SDI supporters, none of the critics have assumed that perfection was needed. The person who said this was Fletcher himself!
Defense Secretary Caspar Weinberger disclosed new scientific advances yesterday that he said provide ``solid reasons'' that a Star Wars anti-missile defense system can be made to work... Scitech [Princeton NJ, not to be confused with Sytek, of Sunnyvale CA] developed a means for identifying ``rocket plume signatures''... LTV [Dallas] then modified that system to create a special computer program, or algorithym [sic], that can be loaded in the sensors aboard a missile interceptor. The sensors lock on the plume of fire from an enemy rocket, but the new program makes the necessary corrections to ensure that the intercepting missile hits the enemy rocket and not the plume. This advance is important because it suggests that enemy missiles can be attacked during their earliest, or boost, stages of flight and are gliding on a trajectory toward earth... [Associated Press, 17 April 86] [It all reduces to a SMOP (Small Matter of Programming)! (See the Hacker's Dictionary.)]
The U.S. Military now believes that damage to the French Embassy and a residential neighborhood in Tripoli during Monday night's raid on Libya was caused by a Air Force ``smart bomb'' that went astray either because it was dropped by a damaged F-111 jet or because its guiding laser beam was blocked by clouds, Defense Department officials said yesterday... [The] second explanation is also consistent with the likely trajectory of the bomb, however. The 2000-pound GBU10 bombs ae designed to home in on a beam of light which the ``Pave Tack'' system on the plane's underbelly focuses on the target. After the bomb was dropped, the F-111 probably swerved and climbed to evade anti-aircraft fire, while the laser designator on the undercarriage automatically swiveled to keep the target illuminated. As the plane moved, however, the laser beam may have been broken by smoke or clouds that were drifting over Tripoli Monday night, causing the bomb to fall unguided into the residential neighborhood. (Washington Post, 17 April 86)
The San Francisco Chronicle of 3 April 86 had this story that I meant to include earlier. More than a million California telephone customers will be getting an unpleasant surprise in their April bills because of an equipment malfunction... Because of the goof, these customers were not billed for millions of medium- and long-distance calls since November, said company spokesman Roger Orr. The calls not billed in January and February will show up on the April bill, Orr said. The California Public Utilities Commission will not allow the phone company to charge for calls missed by the billing equipment in November and December. Switching machines logged each call but did not put some of them on customers' bills... [No estimate given of how much revenue was lost.]
I may as well tell this anecdote before others do... Boston University this past week submitted their host table for inclusion in the NIC table. Unfortunately, there were a few entries in the table that should never had made it. The most interesting was a one character nickname ("A") for host BU-CS (local convenience.) Apparently a bug in the 4.2bsd program htable program which converts from standard NIC format to the format UNIX uses proceeded to fill your disk when it hit this entry. I suspect from the notes that some hosts must pick up the table automatically in the wee hours and do the conversion with a command script so they came in the next morning with a disk full of the string "BUCSA". I was assured by one site that he no longer needs any mnemonics to remember our name. I have no way of knowing numbers, but apparently some number of machines went down or were crippled. In addition, there was an entry for a machine type "3B2", htable broke on that also although not so dramatically, because the string started with a digit. It seems the next night or so htables were breaking again because someone managed to put a lower case letter into the table. (I have heard this only second hand.) I then fixed our host table to avoid the troubles and ran it through htable myself just to be sure and it promptly deleted the first entry in my table. Apparently it had to have at least one blank line before the first entry, again, without warning. This is after almost three years of the program being in production at probably thousands of sites. Don't trust any program over 30 (lines of code)? -Barry Shein, Boston University
Please report problems with the web pages to the maintainer