Taken from the San Jose Mercury News, Jan. 23, 1989. Video pirates disrupt Super Bowl broadcast on L.A. cable system LOS ANGELES(AP) - Cable television viewers of the Super Bowl said video pirates disrupted the audio portion of the play-by-play Sunday with music from "The Jetsons" cartoon show and an anti-Semitic slur. "First there was music from 'The Jetsons' cartoon show. Then someone said something about Century Cable and 'There's too many (expletive deleted) Jews in this industry,'" said Doug Debber, a viewer in Santa Monica. [.....] The interruption occurred about 3:15 p.m., when an audio signal invaded Century's cable system, he [Bill Rosendahl, a company spokesman] said. Viewers in West Los Angeles, Santa Monica and Beverly Hills reported the intrusion, Rosendahl said. [.....] Company officials have contacted the FBI and Santa Monica police and were planning to contact the Federal Communications Commission Monday morning, he said.
The 16 May 1988 issue of _Flagship_News_ (employee publication of American Airlines) includes a small article on a spiffy way for employees to rat on their fellow workers. It's part of a nationwide computerized database on "business abuse," which is apparently a euphemism for workers who don't measure up to management's standards. Listed examples of business abuse include theft, drug and alcohol abuse, unsafe work habits, and "any act not in the best interest" of the employer. All you have to do to destroy your fellow workers is call the National Business Crime Information Network Inc. (known as "The Network"), at 1-800-241-5689. You may do this anonymously, as each caller is simply assigned a code number. This also allows you to call back later and check to see what action has been taken against that guy in the next cubicle who took a pencil home. The Network says that your information is relayed to top management, who it is claimed will not take any disciplinary action on the basis of the phone call alone. Right. Michael Trout BRS Information Technologies, 1200 Rt. 7, Latham, N.Y. 12110 (518) 783-1161 [If you make your ratfink call from a phone with automatic calling identification, do they store YOUR phone number as well? PGN]
The following is taken from an advertisement which appeared in The Spectator (a conservative review and comment journal of high repute) 14 Jan 1989. The advertisement was placed by INDEX ON CENSORSHIP a magazine which publishes banned literature from all over the world, factual reports on writers and journalists who have been silenced, as well as comment, interviews and a country-by-country chronicle of censorship. "Dear Spectator Reader, Vaclav Havel, the well known Czechoslovak playwright, had his personal computer/word processor confiscated by police on 27 October 1988. I wonder if you would like to join with others in providing him with a replacement? Havel had the computer for just over a year and had been using it - for work and correspondence for only a month or two. It was obtained perfectly legally. He has written to the authorities to ask for his property back, but it has not yet been returned, nor is there any sign that it will be. The letter continues by requesting contributions for a replacement. This is of interest reflecting the risk that computers pose to oppressive states, the risk of confiscation by the police of a vital tool of modern work and communication. Anthony Finkelstein, Imperial College of Science, Technoloy & Medicine (University of London). UK. [I imagine replacements would be confiscated even more quickly, especially if more continue to arrive. The police may be developing a taste for computers. Besides, they may have discovered that the storage provides a convenient record of what he has written. I wonder whether Glasnostradamus predicted things like this. PGN]
[Regarding adding functionality without changing the code:] > I should hope the risks are obvious. [Ellsworth, RISKS-8.14] <>MBR@PELICAN-SPIT.ACA.MCC.COM [Message to Ellsworth and RISKS] <>from "Mark Rosenstein" at Jan 25, 89 6:07 am <> ...Oh dear. They're not obvious to me. If change means modify existing <> code, then I can't quite see the problem, if change means add code, <> yep you'll have to add code to get more functionality. Mark. To detail the exchange seems to me to be a bit maudlin, so let me just say that we were talking about adding/changing functionality to an object. The professor's statements were cleary pointed toward no change neccessary to the code comprising the object. The risks are: - Merely parroting the party line (OOP eliminates changes to operational code), and not thinking carefully about the question. This seems especially dangerous when instructing the empowered naive. There were managers and engineers who were receiving their first exposure to OOP in that class. They were going to try to use the information from that class in real products. Their (the empowered naive) perceptions and beliefs are soon going to effect other people's lives. - Management hearing the party line and accepting a "panacea" type solution. This is an "oldie-but-goodie" (maybe even in the all-time top ten) in the category of "Engineer's Gripes," and it's currently getting a thorough flogging in RISKS. The above in no way reflects the views of Hewlett-Packard Company. Benjamin Ellsworth email@example.com [There are indeed lots of ways to get a program to do something else without modifying the code. Moving it from one directory to another can have all sorts of side-effects, especially in a system with search strategies. Not moving it but altering the search strategy for subtended programs is another way. Redefining parameters, abbreviations, user profiles, etc., is another. How about inadvertent effects resulting from someone else innocently introducing an operating system change? All of this relates to the old saw about hardware degrades but software does not. Not true. PGN]
By all means, we need new structures. There's no question about that. The only question is, what should we build those new structures on? I believe that the problem of relating the behaviour of a program to it's (human-readable) static representation has been solved at a "micro" level. And, pace the disbelievers in structured programming, I believe that structured techniques represent the best solution at the procedure level. The question is the a matter of tying a large number of procedures into a workable, consistent, large system. The answer to that, it seems to me, is to envisage the system as a machine (needless to say, programs are, in the strict sense, machines in the same way computers are). The starting point for fulfilling the requirements of an end-user who wants a particular software product is to ask what sort of "special purpose" computer would be best at solving that problem. The program can then be structured as an attempt to simulate that system on a general-purpose computer. For example, a good analogy for writing a spreadsheet would probably be a large array (or "matrix") processor, in which every cell could simulate a "processor" having access to a central series of processing functions. A windowing system can be written as an "ideal" terminal device. This approach has the advantage of encouraging the same sort of "generality" in design that computer hardware benefits from; the adders on a system generally work because the system has just one general purpose adder, not a vast series of different adders. In the same way, a wide variety of the functions in a system which appear to be very different share many (if not most) critical attributes, and sufficiently flexible routines can be devised, in many cases, to apply to all the disparate functions required. This is only one approach to the "larger" structure of systems design. But when building a large building, it does no good at all to discard the girders. Orthodox "structured" programming techniques are, I am convinced, at the heart of building reliable procedures, without which no large system can be built. It isn't possible to build a giant program on nothing but the knowledge of Ifs, Whiles, and Cases; but they are essential components of good programming. John G. Spragge, Computing Consultant, Box 2042, Kingston Ont. (SPRAGGEJ@QUCDN)
Of our many computer rooms and labs, 2 have redundant air-conditioning systems. One of them has two separate systems installed at two completely different times by two different companies; it gained redundancy out of necessity because the first air conditioner barely had the capacity. The second one started out with two air conditioners, because it seemed like a good idea. They were installed at the same time, by the same company. Less than a month later, that room started getting hotter and hotter and hotter. We called A/C repair. They said they would log it as non-emergency, due to the second A/C in the room. We pointed out that the second A/C was not air conditioning any more than the first was. They grudgingly updated it to an emergency call, and in short order one of Ohio State's people arrived. 5 minutes later he developed an amazed/ appalled look, and began to curse. "What the hell sort of a redundant system is this? What do those jerks think they are playing at?" It seems that our two A/Cs had but one thermostat, which had duly failed. Needless to say, Ohio State made all sorts of grief for the vendor, who eventually managed to make the systems more redundant. Nevertheless, reliability is *still* higher in the cobbled-together, afterthought-redundant system, than in the "properly" designed one. Elizabeth D. Zwicky, Ohio State University Computer and Information Science
The more-is-less phenomenon of aircraft engine reliability has been noted previously. During the push to extend aircraft technology to non-stop trans-Atlantic flight, most of the designs were multi-engined. The designers of the Spirit of St. Louis recognized: - they were on the edge of the technology, therefore - there was insufficient spare capacity to carry a dead engine, and - there was nowhere to land for repairs, therefore - all the engines would have to run for essentially the whole flight, so - assuming roughly equal engine mean-time-to-failure, the more engines, the greater the risk of failure (with loss of craft and pilot). Thus the Spirit of St. Louis was designed with a single engine. It's a classic examples of the counter-intuitive nature of probability theory and risk assessment. (Of course, practical service had to wait a bit, until aircraft capacity and airport availability improvements made single-engine-failure survivable.)
Don Alvarez <firstname.lastname@example.org> writes: > Imagine two planes which are identical except that one plane has 2 > Bratt&Zittley Foobar-900 engines, and the other has 3 B&Z F-900 engines. > Well, clearly the second will fly better on n-1 engines, ... This is the misconception that I'm trying to point out. If you have an airplane which flies fine on two B&Z F-900s (meets single-engine performance requirements, etc) then no manufacturer would ever put another engine on that airplane. It just wouldn't make sense. (This is for civilian applications; military apps have other issues.) The three-engine airplane discussed will either be bigger or have wimpier engines. The controlling factor is engine-out performance. The two-engine airplane with one out will have performance comparable to the three-engine airplane with one out. 727 engines (3/airplane) are wimpy compared to DC-9 engines (2/airplane). BAe-146 engines (4/airplane) are *really* wimpy. (This assumes that 727s are approximately the same size as DC-9s. Bae-146's are smaller.) Jordan Brown
>STS-6, April 4, 1983: ... Landing gear must be manually deployed after computer >fails to trigger its descent. I wonder if this is not mistaken reporting at some level. My recollection, possibly incorrect, is that lowering of landing gear is specifically not under computer control in the space shuttle — it *has* to be done manually. The reason is that once lowered, the shuttle's landing gear is *down* -- it can't be raised again in flight. Possibly the problem was that the computer did not say "time to lower the gear"? Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry email@example.com
The following revision is based on critiques received on a proposal published in RISKS digest 7.75. Comments are still welcome (send to CFRNB@ECNCDC.BITNET). Course Description: The course will investigate current ethical issues involving computers. While it is not a "computer course," students will make frequent use of postings on the electronic bulletin board of the ECN mainframe computer to research and discuss ethical issues. Prerequisites: 75 Semester Hours and previous experience with computers. [Class size limit = 15 students for Fall, 1989, semester]. Outline of topics: Week 1: Orientation to the course (introduction, explanation of course content, class procedures, and evaluation methodology). Consideration of ethical theory. Week 2: Consideration of ethical theory (continued). Week 3: On-line reading of the "Discussion of Ethics in Computing" list, the "Forum on Risks to the Public in Computers and Related Systems" digest, and the "Computers and Society" list (all are available on the ECN bulletin board); written reactions to these readings, and written commentary on other students' reactions. [The instructor will insure that these activities equate to the activities of a traditional two hour class meeting]. Week 4: Consideration of professional ethics. Week 5: Same activities as for Week 3. Week 6: Consideration of liability for software design, manufacture, and use. Week 7: Same activities as for Week 3. Week 8: Consideration of privacy issues. Week 9: Same activities as for Week 3. Week 10: Consideration of power/control issues. Week 11: Same activities as for Week 3. Week 12: Consideration of ownership and theft issues. Weeks 13 & 14: Same activities as for Week 3. Week 15: Seminar members will reconvene as a group for the last meeting to allow for group reflection on the seminar experience and course evaluation. Semester Exam week: Final Examination. Writing component: Students will type thirteen 30-to-50 line (i.e., one-to-two page) reactions to the on-line electronic bulletin board readings. Students will "post" these reactions (i.e., electronically send them to the mainframe computer bulletin board set aside for members of this seminar). In their reactions, students will: 1) identify the particular publication or publications to which they are reacting, 2) identify the particular issue or issues raised in the publication(s), 3) identify the ethical implications of the issue or issues, 4) identify the ethical paradigm used by the author, 5) add their own reasons for agreement or disagreement with the viewpoint of the publication's author, 6) and, finally, offer an alternative solution or viewpoint to that presented by the author, or present other appropriate considerations not raised by the author or covered in their own (i.e., the student's own) previous comments. The instructor will send weekly, by confidential electronic mail, a grade on the student's posted reaction, together with whatever comments the instructor thinks helpful. The student's original posted reaction will also be open to public comment by the other students in the seminar [this is accomplished by posting notes to the bulletin board, referencing the original posted reaction]. These latter comments by the other students in the seminar will be considered along with classroom discussion in computing the "participation" factor of the student's semester grade. Evaluation: Each student's semester grade for the seminar will be calculated according to the following weighted formula: 13 posted reactions (at 5% each) = 65% ; Participation (based on class discussion and posted comments on other students' reactions) = 20%; Final Exam = 15%. Materials in the course will include: 1) Texts: Deborah Johnson, Computer Ethics (Englewood Cliffs, NJ: Prentice Hall, 1985); privately published notes on systematic ethics from Dr. Barger's Philosophy 1800 class (furnished free to seminar members); postings on the above-mentioned ECN electronic bulletin board lists. 2) Resource people: Computer professionals (e.g., administrators, systems analysts, programmers, etc.) will be utilized as guest contributors to the class. This will be accomplished by personal appearances, as well as by electronically mediated conferencing (e.g., postings, e-mail, relay round-tables, etc.).
Please report problems with the web pages to the maintainer