Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP Path: utzoo!utcsri!hogg From: hogg@utcsri.UUCP (John Hogg) Newsgroups: can.politics Subject: Re: problems with Star Wars #2 (part 2: the crux) Message-ID: <1240@utcsri.UUCP> Date: Wed, 10-Jul-85 16:57:56 EDT Article-I.D.: utcsri.1240 Posted: Wed Jul 10 16:57:56 1985 Date-Received: Wed, 10-Jul-85 17:41:44 EDT References: <1197@utcsri.UUCP> <5772@utzoo.UUCP> Reply-To: hogg@utcsri.UUCP (John Hogg) Organization: CSRI, University of Toronto Lines: 71 Summary: First, a retraction: in my posting of Ric's paper that started all this, there was a reference to an airplane crash caused by faulty software. Upon digging further, I can't find the incident. The example is retracted; the point about the inconceivable cost of BMD failure remains. "Having dealt with some side issues", I will rebut Henry's rebuttal. First, the matter of the need for absolute correctness, given that verifiability is virtually impossible. If we are to protect our cities from attack, a "small" leakage is absolutely unacceptable. Thus, the battle management software must be perfect. If we use such follies as pop-up missiles, matters are much worse. A missile rising out of a submarine is going to look hostile, no matter what it does. In fact, the mere starting up of ANY sort of BMD system is going to look hostile; remember, current bets are that a BMD system adequate to cope with a retaliatory strike is probably feasible, so firing it up may be the first step of a first strike. In which case, the only way for the Soviets to preserve their deterrent is to go to launch-on-warning so that something will get through. They may consider some stage of BMD startup to be "warning". And then they may not... did you play "chicken" in your younger days? Did you play it with the population of the Northern Hemisphere in your car? Note, by the way, that no straw-man tying of BMD to retaliatory ICBMs is needed to cause an "accidental" war. Now for the point that, given the source, shocks me. Henry asks >Furthermore, why should the decision to activate an SDI system against >a major attack have to be automated at all? ALL proponents of SDI (with the possible exception of ol' Sixgun) including fanatics such as Daniel Graham, consider a boost-phase defence to be the only feasible approach. Boost phase can most comfortably be measured in seconds. By the end of that time, the rising missiles must be destroyed - not identified as being worthy of destruction. If the Soviets go to simultaneous launch (difficult, but much simpler than SDI!) the decision must be made within the first few seconds of boost. What kind of meaningful information can a human absorb, let alone digest, in this time? And multiple decisions by multiple observers is even more ridiculous. Henry's speculation that humans could even handle the battle management functions is surely the product of a hallucinogens in the Ramsey Wright water supply. Read the Fletcher Report on Battle Management to get an idea of the magnitude of the problem; ask me to expand on this if you wish. The REAL "crux of the matter" is perhaps that >If one assumes an attack in progress, the benefits of success clearly >outweigh the possibility of failure. On the other hand, if an attack isn't yet in progress, but is made far more likely by a system that won't work perfectly for ICBMs and not at all for bombers, cruise missiles and SLBMs, then the benefits of this incredibly expensive system become very hard to see. (Of course, I don't work for Lockheed.) And the phrase, "won't work perfectly" is much weaker than it needs to be. Numerous counters to SDI as currently envisaged have already been proposed, many of them cheap and simple. "Won't work at all" might well be less in error. >I have discussed elsewhere the interesting reasoning: "because some >types of SDI systems would be very dangerous, any SDI system would be". Henry, in light of what I've said here, please propose a non-dangerous SDI system! -- John Hogg Computer Systems Research Institute, UofT {allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsri!hogg