The failure of the Colorado Department of Corrections to keep an on-line listing of parolees up to date on the Colorado Bureau of Information computer system is a very real threat to the safety of the public. Law enforcement agencies access this list when arrests are made or when giving traffic citations. The threat is real, and I have first hand experience with it. My brother was murdered in January, 1986 in the early evening at a grocery store where he was working. The previous day, the perpetrator was stopped for a routine traffic violation. The CBI computer did not reveal his parolee status at that time, nor did it reveal that he was wanted on charges of shoplifting, assault, and armed robbery in other counties of the state. The officer suspected something was awry, but was powerless to do anything for want of probable cause. The officer even went so far as to call the Department of Corrections. My brother was dead two days before the clerk finally returned his call. It turns out that the state is approximately six months behind in their data entry tasks, and have been so for at least the past five years. It strikes me that such a database is next to useless, and is an example of a project that is better funded properly or funded not at all. Robert White ihnp4!upba!qetzal!rcw
Back in High School (1975 to be exact), calculators were not too common, and PROGRAMMABLE ones almost non-existant. Nonetheless, there was one student in my Advanced Chemistry class that owned an HP-35 programmable. The teacher finally decided to let us share it during the exam. We quickly adopted the following strategy: the first student would work out the solution to the first problem, storing all relevant intermediate results in the memories. He or she would pass it to the next student, who would copy the results, and tackle the next problem. Additionally, several "important" formulas had been preloaded onto certain entry points. After two rounds about the room, we had finished all the problems. Our downfall: a common one to RISKS readers. Someone had made a rather stupid mistake on a problem, and we all had copied it! Andrew L. Duane (JOT-7) w:(617)-658-5600 X5993 h:(603)-434-7934 Compugraphic Corp., 200 Ballardvale St., Wilmington, Mass. 01887
The following article is taken from the Huntington, WV Herald Dispatch from Friday April 15th, 1988. It is, as always, reprinted without permission. BLAST RIPS JET IN MIDAIR, BUT IT LANDS SAFELY By Kelly P. Kissel, Associated Press CHARLESTON- An engine on a Piedmont airlines jet exploded Thursday, sending debris tearing through the walls. The pilot wrestled the craft under control and made an emergency landing in Charleston. A passenger said there was a hole "big enough that I could crawl through it." The explosion caused the Fokker F-28 jet, which was flying at 31,000 feet, to lose pressure. Some oxygen masks didn't work, two passengers said. Two stewardesses suffered minor injuries when the plane plunged after the explosion, officials said. Flight 486, which carried 56 passengers and a crew of four, was flying from Charlotte, N.C., to Columbus, Ohio, when it's right jet turbine disintegrated about 9:45 a.m., Piedmont officials said. [...] Turbine blades and engine parts ripped all the way through the plane, leaving holes on both sides. A hole on the right side, next to the engine that disintegrated, was 2 feet wide and 6 feet high. On the opposite side, the hole was 2 feet by 1 foot. [...] The Piedmont spokesman said he didn't know when the engines had been checked last but said there was no reason to suspect a problem. "Our engines are maintained by computer. If there's a problem incipient in them it would show up," McGuire [the spokesman] said. "That's why we were suprised." He said the rest of the plane, including the oxygen masks, is checked in the same manner and that complaints about some inoperable masks would be investigated.
Here's an interesting ATM problem I once encountered. I don't think I've seen anyone else mention this one. Once, when trying to make a withdrawal, the machine proceeded normally, until it got to the part where the lid to the money-dispensing bin is supposed to open. It didn't and wouldn't. Because my transaction had seemed to take place, I called the bank the next morning to make sure the withdrawal hadn't beed debited from my account. The person I spoke to checked, and said everything was okay with my account, and explained that what caused the problem was that, prior to my attempted transaction, someone must have forgotten to take their money from the bin. Apparently the system is programmed to lock up the bin, obviously to keep anyone else from taking the cash, but it seemingly performs all transactions properly. This is somewhat interesting, since apparently the system designers had anticipated the possibility that someone might forget to take their money (a situation which strikes me as so absurd that I probably would have overlooked it), but chose a rather confusing response for it. Confusing in that all legitimate users following the flawed transaction are uncertain what happened and whether or not their transactions were completed or not, and therefore undoubtedly generating a number of calls to the bank. It's not enough to anticipate a situation--the appropriateness of the response, given human nature and expectations, is important, too. Dave Fiske (davef@brspyr1), BRS Information Technologies, Latham, NY
In RISKS 6.58, I told a story about how failure tolerance kept some HP salespeople from noticing that the floating point coprocessor in a demo machine was dead; this led to some very embarrassing benchmark results for a potential customer. Here's some additional info that might be of interest. Jeffrey R Kell (<JEFF@UTCVM.bitnet>) wrote me: >I'm not sure of what system the benchmark was on, but on the newer RISC-based >machines the operating system checks to see if a coprocessor is "present" >or not; I suppose a "broken" one might appear "absent" as well. Yes, that's also true on the older HP Series 300 machines that I'm familiar with. Those machines are "self-configuring", which means that at powerup the boot ROM runs around and finds how much memory is plugged in, what interface cards and coprocessors are present, etc; then it tests them all. The boot ROM displays a list of the selftest results, and things that have been detected but fail the selftest are prominently marked. If something is sufficiently broken that the boot ROM doesn't even see it, the only notification you get is that it doesn't show up in the selftest list. The list isn't there long since the ROM then proceeds to load an operating system. If you aren't paying attention when you turn the machine on (which most people aren't...) you lose. Presumably this is what happened to the HP salespeople above. Some of the even earlier Series 200 machines had a provision for dealing with that problem too. The 200s had a small PROM which was custom-burned for each machine, containing the computer serial number. There was also provision for the PROM to contain a list of attached equipment; the boot ROM could then check to make sure that it had found everything that was supposed to be there. Unfortunately HP decided that the custom PROMs added too much to manufacturing cost. (I believe, though, that the necessary code is still in the Series 300 boot ROM; so a determined person could program his own PROM, put it on a breadboard interface card, and plug it in.) The PROM was also treated as a piece of optional equipment, so if it died the machine would still boot, but you would lose this protection... I don't know whether any such provisions exist in the newer Series 800 machines, which were the culprits in my original tale. tom lane UUCP:
Mongrelism 1: Fuzzy concepts lead to fuzzy decisionsLes Earnest <LES@SAIL.Stanford.EDU> 17 Apr 88 1907 PDTSome people found the mongrel stories amusing, some found them educational, and at least one person found them disturbing, apparently because they made fun of deeply held beliefs. So be it. I regret to report that I have three more things to say on this topic [here and following]. I really do hope that we can put this to bed soon. In fact, if the discussion continues unabated I will shortly propose the formation of newsgroup comp.race to discuss the computational aspects of race determination. I offer here a preview by showing the current theoretical basis for the field, which can be stated in a single line: . I particularly enjoyed reading the insightful remarks of John Mainwaring in comp.risks 6:60 and the educational humor of Will Martin in 6:61. In comp.risks 6:61, David Thomasson says: > "Apparently believes...probably believes" -- more Straw Men. In fact, I > believe that virtually everyone can be put into some racial category that is ^^^^^^^^^ > very useful for purposes of identification, even though such categories are > not biologically precise. As for the rest of the above, Earnest's argument > has gone to the dogs. This is cute, but very evasive. Thomasson neglects to identify the exceptions to "virtually?" In the same article, Thomasson later remarks: > In my experience, "race" has been roughly equivalent to "color of > skin" in police work. So, while it's true that "race" is biologically > imprecise (even incorrect), those who use race for identification purposes > aren't concerned about biology . . . Here he finally comes to grips with reality. We are left to wonder why the police don't use skin color for identification, given that they don't understand biology. "Black" and "White" are Relative Nearly all of the people in the U.S. who call themselves Black are genetic mixtures of African and European peoples. Because our culture is predominently European, anyone who has detectably African features is called "Black," even if they are genetically, say, 7/8 European. If we were a predominently African country, these same people would likely be called "White" because they have detectably European features. In other words, current racial classifications are made relative to the "norm," which makes them intrinsically subjective and rather unreliable. However, it will shortly be possible to make unambiguous racial classifications as discussed in the next posting. Les Earnest
Mongrelism 2: Genetic Classification and the Urge to MergeLes Earnest <LES@SAIL.Stanford.EDU> 18 Apr 88 0217 PDTGiven that the human genetic code is now in the process of being unravelled, it should soon be possible to classify people into racial groups in a meaningful way. One way to do this, once we can reliably disassemble the code for any given person, is to define various racial standards in terms of this code, such as a standard Negro, a standard Caucasian, a standard Chinese, etc. Of course, some people will want to carry this a step further and define a standard Texan or even a standard South Philadelphian. Once we choose a set of standards, then everyone can be classified as being members of the racial group whose standard is closest to their own genetic code. The Hamming Distance between pairs of codes would be a reasonably good measure of genetic distance. That is, given that genetic codes are base 4, we could simply count the number of differences in the base 4 code string. Thus, after we get over the argument over which are the standard races, it should be possible to assign everyone unequivocally to a racial group, except for the rare individuals who happen to be _exactly_ halfway between the two closest standards. While this wonder of future science will support nearly unequivocal racial classifications, it clearly will not be useful for visual identification. In fact, I can't think of anything that it _would_ be good for, other than providing a formalized basis for bigotry. For purposes of individual identification, the person's full genetic code will be far more useful. The Urge to Merge Whether or not we solve the problem of racial discrimination and conflict through education and political action, human biology will probably solve it for us in the long run. Recent studies indicate that if there are no more major influxes of foreign populations into the U.S., distinguishable racial groups will essentially disappear in this country within 300 years because of "the urge to merge." In other words, the U.S. is destined to become a nation of mongrels. This likely will be disappointing to white supremicists and black activists, who will _both_ soon be members of shrinking minorities. In fact, they may be already. I predict that new rallying cries will be heard as the mongrels become the majority -- maybe things like "Beige is Beautiful." Les Earnest P.S. With respect to the "urge to merge," I can report that my family is doing its share. One of my sons, Mark, lives in Alaska and is married to a Yupick Eskimo lady named Cathy Lincoln. (She also has a Yupick name that sounds something like attempting to clear your sinus while spitting out an ingested bee.) Mark is generally well received in Eskimo communities, though he occasionally encounters some prejudice. They call him a "gussack" which has about the same meaning there as "gringo" does further South. "Gussack" is a Yupick word that was derived about two centuries ago from the Russian word "cossack." You can imagine how that came about. Mark and Cathy have three beautiful little mongrels, who can look forward to participating in the (hopefully) peaceful overthrow of the WASP group that has run this country for the last 400 years.
risks of RISKS -- textual tampering [de-ment-ia praecox]Doug Claar <dclaar%hpda@hplabs.HP.COM> Tue, 19 Apr 88 13:52:49 pdtIn our copy of RISKS DIGEST 6.60, occurrences of "ments" have been replaced with "<newline>
Please report problems with the web pages to the maintainerTop