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…
Japan's Power Reactor and Nuclear Fuel Development Corporation, an R&D
organization supervised by the Science and Technology Agency, is now
using fuzzy logic to control the water temperature of a tank in the
Fugen prototype heavy water reactor operating in the Fukui prefecture.
The fuzzy device, an Omron FZ-1000, is not used in normal, stable
operation, but only when the reactor starts or shuts down, under the
argument that in these conditions fuzzy logic is more suitable for the
large amounts of information generated and is less prone to phenomena
like overshooting. The fuzzy control is monitored by a human operator
and is not yet used in critical places. Further details can be found
in Thomas Hagemann's report ``Visit to Omron's Fuzzy Business Promotion
Center, Kyoto'', comp.research.japan <4702@gmdzi.gmd.de>, 14 May 1991.
The fuzzy device is not yet being used for critical operations here. But the
implication is that fuzzy logic is better than conventional logic precisely
when safety is most at risk, i.e. when the reactor is not in normal, stable
operation. I'm skeptical. But if true, there may soon be a pressing need for
formal verification of fuzzy systems, whatever that may mean.
Paul Eggert
[It better be better, or else someone will be guilty of Zadehmy. PGN]
An article in this month's Scientific American states that "privacy legislation
has been nickeled and dimed to death" ... but "Maybe that is the way most
Americans want it. According to a survey commissioned by Equifax, one of the
three major credit reporting bureaus ..." The article then goes on to cite a
Harris survey that lists credit reports and loan approvals as examples where
most Americans accept invasion of their privacy. Beyond being an obviously
self-serving conclusion, it misses the point. A loan request is initiated by
the individual and most people would distinguish between a credit check that
you have authorized and one done without your knowledge.
Is this an isolated incident or the opening salvo in a PR blitz designed
to systematically undermine our privacy rights?
David States
I must argue slightly with the story of the teacher who can't spell because he's used to having his computer do it for him. The spell check is a crutch for some, but for many of us it is merely an aid to prevent irritating and subtle errors from finding their way into our texts. Almost no words flagged by my spell checker are words I don't know how to spell, and if they happen to be, I usually figure it out after a while. For some strange reason my fingers wanted to type "propoganda" instead of the correct "propaganda" for a while, but thanks to the continued vigilance of Nisus's excellent spell checker, I've gotten over that unfortunate problem. My point is that the spell checker does not have to be crutch. It can be a learning tool as well, but only if the companies producing word processors design it as such. Complain to them if the teachers of today cannot spell without that electronic crutch. Adam C. Engst Editor of TidBITS, the weekly electronic Macintosh journal
There were things that happened a long time ago (10 years??) when I was a student at the University of Georgia. They ran what was called the University System Computer Network which basically was leased lines and terminal controllers to connect the state universities to a CDC Cyber (70/74 then a 170) running NOS sitting in the computer center at UGA. I don't have to tell RISKS followers about the security problems under NOS! The unfortunate thing about is that this machine was used by University System schools for more than just student computing. There was one "rumor" that allegedly someone at (I think) Georgia Southern changed grades for students at schools other than GSC. I remember assisting a friend who was working for the campus newspaper (the Red and Black) and getting hung up on by several computer center and university officials when we called for information. We were later lectured by the director of the computer center at that time about minding our own business. The other "rumor" could not be confirmed by print and electronic media since it was a case settled out of court and the records sealed (allegedly because it contained a record of exactly what happened and they determined it to be a risk to the USCN). Allegedly, someone at West Georgia College broke into thier payroll system and had some checks printed in his name--not an alias. Both of these happened sometime around 1980-82, before computer-related laws made it to the books. I hope there's someone in Georgia who remembers these and can give better details! [...] scott barman scott@nbc1.ge.com
I ran a large college computer center many years ago with an IBM 1620. Because
the machine was easily accessible by students, we had numerous instances of
someone pulling the emergency off switch. The IBM maintenance man got tired of
coming out to put it back in. There was a small pin that fell down to the
bottom of the cabinet that prevented you from pushing it back in. He showed us
how to reset it so he wouldn't be bothered by that anymore. We never
encountered any equipment damage from these incidents.
We did encounter another "feature" of the 1620 that was destructive of
hardware. Two of us developed a 3 or 4 instruction program that generated some
number series. The object was to find the millionth number in the series, or
something like that. The program consisted of several instructions that
executed quickly (for a 1620) and one divide instruction that was about 100
times longer. We started it running on a Friday evening expecting it would run
most of the weekend. After checking some of the early values, we decided to go
out to a fast food joint for dinner. We returned about 2300 to find smoke
pouring out of the computer room windows. We pulled the emergency power off
switch and opened the windows. Didn't want to call the fire department - too
much paperwork and embarrassing questions. After the room cleared so we could
see, we opened the swinging racks in the back of the control unit. On the end
of the innermost one was a Bud box bolted on with a power transistor heat
sinked to the outside. That transistor was bubbling some kind of ooze and lots
of smoke. We called our maintenance man who came right away. The transistor
was part of the divide logic (a late add-on in the design). He first asked
what program we were running. Then he asked why we were violating the divide
instruction duty cycle. We had never heard of any such restriction, but he was
insistent and spent hours searching through the volumes of schematics looking
for it. Finally, he grabbed a marker and wrote a divide instruction duty cycle
on the cover of one and said something to the effect of there it is, I told you
so...
> Men were men in those days, and giants strode the earth.
and students caused them all to crash regularly.
— Doug
The big red power-off switch which used to appear on the panel of the 1620 and
earlier machines (650, 70x) came with lots of warnings to the users NEVER to
use it, as has been mentioned here recently. As so often happens, it was a
device which started out serving a real need and lived beyond it. On machines
like the 650, where ALL storage was on a magnetic drum enclosed in the main
cabinet (mag core was added later), slow warming up and cooling off was
critical. The drum heads were fixed over the magnetic surface, not floating
like current disk heads, and of course had to be close to the surface. They
were mounted to rigid metal bars to keep the distance fixed, but of course all
the various materials had different coefficients of thermal expansion. If you
used the "correct" power down procedure, all the cooling air would keep flowing
and the system could come down without turning new grooves in the drum. If
there were to be a fire, however, of course you wouldn't want to keep pumping
in air! Hence the emergency switch. Since it was (we were told) sure to damage
the machine if you turned it off with the emergency switch, the switch could
not be turned back on without a call from your friendly customer service
engineer. The switch had a little pin inside which had to be retracted before
you could flip the switch back to the on position. All of that made pretty
good sense for the 650 and similar machines. By the 1620, though: The logic
was solid state rather than tubes, and hence generated much less heat. The main
memory was core. The interior air driving was reduced to biscuit fans similar
to present practice. BUT the same old switch was installed, so that in theory
if it got flipped you had to call for service. Most of us found out how to
reset it, because some novice was sure to use it sooner or later.
Bob Wilson
Math. Dept., Univ. of Wisconsin wilson@math.wisc.edu
On the console of our Amdahl mainframe system, there is a large button labled "Emergency Pull", which had an equivalent function to the one described by Martin Ewing in RISKS-11.66. One weekend we had a problem with the system that the assigned Customer Engineer did not consider serious enough to justify leaving home, inspite of the arguments from the local Site Manager that the primary subsystem could not run. The Site Manager then called him from the phone adjacent to the console. He mentioned this switch to the CE, casually asking what would happen if it was pulled. Upon confirmation that is a priority service call would be required to reset the switch, the Site Manager calmly pulled the switch and said "Gee; the system seems to be dead!" The CE sighed, and came in... Bob Van Cleef vancleef@nas.nasa.gov NASA Ames Research Center (415) 604-4366
R. I. Cook mentions the elaborate power control systems for old-time computer
centers. This reminds me of the time I worked as a transmitter engineer for a
UHF TV station (~1 megawatt). The transmitter was housed in a Butler building
out in the boonies, with the transmitter enclosure in the middle of the floor.
The enclosure was perhaps 15 by 20 feet, water-cooled, and you could enter the
enclosure through a door to perform maintenance. Other amenities were real
primitive, with the toilet facilities sort of hidden in a back corner behind
the transmitter enclosure.
This was a family operation and one day the owners were in town to do some work
on the antenna (nosir, I don't climb 1100 feet in the air for $3/hour...) The
wife of one of the owners came along, and after a while, she excused herself to
go to the "ladies room."
I guess no one must have told her where the toilet was located, because the
next thing we heard was this incredibly loud BANG as she tripped the interlocks
to the transmitter door and shut down the transmitter.
Al
We had an IBM 1130 in high school (late 70s). One day a student noticed smoke coming out of the rear of the console. He naturally pulled the EMERGENCY STOP switch. We later discovered that someone had dropped a smoldering cigarette behind the console. Moral: When that big, red button is staring you in the face, day after day, it's easy to find an excuse to use it. S. H. Schwartz Expert Systems Laboratory NYNEX Science and Technology Center White Plains NY 10604 914-683-2960
Recalling the IBM 1620 destructive power switch and the days of "real men" is too good an opening to resist. That machine had a console table on which was mounted a printer for the operator, the only i/o device that a human could read directly. It was used to print error messages, or for low-volume output from programs. (For REAL output, one punched cards and listed them off line on tab equipment.) Later versions of the 1620 used an IBM Selectric typewriter for console i/o, but in 1965 I used an older machine at Argonne National Labs that was fitted with a standard IBM model C electric typewriter. The unit was mounted near the right edge of the table, in such a way that when the carriage returned (under program control!), it was capable of dealing a passing human a nasty blow in the groin. (Not so many real men among the long-term users!) But not to worry, IBM soon recognized the risk, and made available for lease a sort of bent wire guard that delimited the area in which it was unsafe to pass. I wish I knew how much this guard leased for, and what it was called in the 1620 parts list.
I maintain a distribution list with which I redistribute SF-LOVERS Digest to a
large number of DECcies. While less convenient than direct mailing from the
moderator, this arrangement avoids clogging Digital's Internet gateway with
nonessential messages. Today I accidentally forwarded another, completely
unrelated message to the distribution list. The circumstances may be of
interest to RISKS readers.
I have a VMS command procedure that does most of the work of archiving and
mailing an issue of the digest. When I'm using DECwindows Mail, as I normally
do, I fire the command procedure off from FileView, a GUI for manipulating
programs and other files. When I'm logged in from home, I can do it by
pressing a couple of keypad keys in character-cell Mail. I haven't done it
from character-cell Mail in quite some time, but I was working at home this
afternoon, and there was a backlog of digests since I'd been out of town for a
few days, so I thought I'd clear out the digests awaiting redistribution.
Unfortunately, I fumble-fingered the keypad and dispatched the wrong message.
Now I'm not entirely stupid, so I built some sanity-checking into this command
procedure. The first thing it does is search for the "Volume m : Issue n"
string in the digest, and it dies with a warning if the string can't be found.
Unfortunately, my command procedure had no trouble finding the magic string in
this particular message. Next, the command procedure searches the archive for
a file called m.SFL, where m is the issue number extracted from the message in
hand, and dies if it finds such a file, assuming that this message must be a
duplicate. (The archive gets purged every month, so volume/issue rollover
isn't a problem.) No such archive file was found, so the unrelated message
was sent out. What WAS this bogus message? Why, an issue of RISKS, of course!
RISKS and SF-LOVERS share a common digest format, which defeated the first
check. SF-LOVERS publishes more frequently than does RISKS, so the
corresponding issue of SF-LOVERS had already been purged from the archive. So
much for the sanity checks.
Lessons learned:
- use of a less familiar user interface (in this case, a different mail
program) can be error prone.
- sanity-checking doesn't, perhaps because the world isn't sane.
- God is an iron (how else to explain the irony?).
Roger H. Goun, Digital Equipment Corporation, Nashua, NH 03062, +1 603 881
0022, goun%ddif.enet@decwrl.dec.com, {uunet,sun,pyramid}!decwrl!ddif.enet!goun
Erik Fair reports on an e-mail disaster that generated tens of thousands of mail messages reporting errors, all directed at his site. Neil Rickert summarizes the conditions that produced the error roughly as follows 1) The To: line had a syntax error (a missing ">" character) 2) The mail was deliverable, so sendmail delivered it. 3) Sendmail reported the error to the originator by mail. 4) Sendmail did not "repair" the error. 5) The message went to a mailing list with many recipients. Erik Fair's diagnosis: the combination of #2 and #3 caused the disaster (by causing every sendmail program on the net that saw the message to produce an additional error report). Neil Rickert wants to focus on #1 and #5, putting blame on either the sender, the originating mailer, or the mailing list maintainer, and admonishing people not to ever generate bogus mail messages and, if that fails, have mailing list maintainers make sure that it never happens. Sorry, Neil. Robust software does not cause disasters when presented with bad input, and many mailing list maintainers are not experts in network protocols. This kind of disaster has happened before, on Usenet. Someone, somewhere, managed to inject a tab into the Message-ID header field, and the offending message (called an "article" in Usenet-speak) got transmitted all over the net. When this message was received by a site running the standard Usenet news software (version 2.11 of B news at whatever patch level was current at the time), its Message-ID was inserted into the history file, which uses tabs to delimit fields. This had two results: 1) The "duplicate article" check broke: the software "believed" that it had no copy of the article, and pairs of sites that used the "ihave/sendme" protocol generated thousands of duplicate copies. 2) The "expire" program also could not parse the history file entry (this program is responsible for deleting old news), so it was incapable of removing the offending articles, and it generated verbose error messages on the log file. The combination caused an explosion of Usenet traffic, limited only when major sites' disk partitions filled up completely, preventing them from accepting any more. Thousands of hours were spent all over the net cleaning up after this disaster. Rick Adams (head maintainer of 2.11 news) then issued an emergency patch that, on receipt of an article with whitespace in the Message-ID, would change the whitespace to "?" characters (or some other character). Notice that this solution violates the "Thou shalt not rewrite a header" holy writ, but I'm for it. Neil, do you think that exhorting people to make sure that their software never put a tab in their message-ID, and assigning moderators special responsibility, is a satisfactory solution to problems like this? Of course not. Once in a while we'll find that our software systems permit disasters to happen. It's not good enough to try to prevent bad input from ever reaching a system; it must be able to deal with any input. The problem with making software idiot-proof is that the idiots are so damn clever.
| In spite of the syntax error, it is correct to attempt to deliver the mail |if this is still possible. Robustness requires this. I disagree. As you pointed out, the message violated the message standard, and so should NOT be passed on. | Once a serious error has been discovered, it is correct to report this. |Reliability of systems depends on reporting of errors. | | Items 2 and 3, then are just plain good programming practice. They cannot |be blamed for this problem. Individually, in the correct circumstances, this is true. But to do both in this situation was not. As you pointed out, sendmail could not correct the header, so the MTA should have either passed the mail (perhap annotating it with some sort of error header, as MMDF would do in this same case), or bounced it with a complaint.
Please report problems with the web pages to the maintainer