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…
A reasonable double check before setting the time is to have the
program check the last time the file system on disk was stamped with
(I assume almost all O/S's stamp the time on the disk.) Certainly on
a re-start time should not have moved backwards, for example, and some
motions forward should be viewed with suspicion (more than say, a few
hours.) This at least can be used to set a lower and upper bounds
before the system screams on the console. UNIX uses this, I am sure
other systems either do or could easily. Of course, this just shifts
us to a different authority, and we know that the crash that started
this cycle just might have damaged the file system, well, I guess that
is left as an exercise for the designer, but at least you get to trust
yourself.
-Barry Shein, Boston University
I'd like to relate a phenomena that happened when I computerized my grading
system some years back. It used to be I did everything involving grades by
hand, and one summer I finally wrote the software to do it all on by machine.
From my point of view this was wonderful. I thought it was useful from the
students' point of view: I now passed out individualized summaries of what
my records had, giving them a chance to correct any mistakes I made. But
one subtle hitch occurred.
Traditionally, I let the students come in at certain appointed hours after
the grades have been computed but before they have been submitted to correct
any last minute errors. I also take the time to explain their grades and how
they were computed. It doesn't always make them happy; I cannot be budged
when it comes to my judgement calls. This last chance office hour can be
quite unpleasant at times--so many students take their grades seriously to
the most ridiculous degrees, and make all sorts of irrational/emotional
appeals to get the better grade.
When I switched over, the following happened. I was teaching calculus for
non-technical students for the third year in a row, so I was expecting the
same student reactions at grade time--especially from the pre-meds. Instead,
as soon as a student began his/her complaint, and I said, "OK, let's check
the records here," I'd show them the computer printout and he/she would then
acquiesce immediately. "Oh, so that is why I only got a B+." They were, of
course, the exact same numbers that I could have written down by hand on the
specially lined paper provided by the department.
At the time I was elated at this easy solution to the pesky student problem
that I had just found. But looking back, I find this reaction disturbing,
with possibilities that the new computer illiteracy is actually dangerous
to its victims.
Since then, the only students I've had who aren't put off by the computer
printouts are the ones with actual computer experience and/or actual human
intelligence, which usually occurs in the more advanced math classes.
[We took this one, but let's go slow on starting a sequence of anecdotes
on people trusting computers absurdly. There are enough cases to fill
up the RISKS Forum forever. The message is clear, however. There is a
lot of ignorance in the general populace. But do we really know better?
Perhaps we should pervert the negative Turing Test hypothesis to
"You can always tell a computer, but you can't tell it much." PGN]
Considering the amount of loss, perhaps some expert tinkering (a la NSA) could actually recover the info. I know we got data off _physically_ crashed hard disks through Data Recovery in LA a couple of years back. Considering the forum here, perhaps I should mention the crashes we had. It was Fourth of July when they told me the PDP-11/70 would not boot. When I asked, they said one of our three 300MB drives blew a fuse so they had switched the pack to the center drive normally used for backups. Not only did the live data get trashed, but all three generations of our backup packs had been crashed between the time the backup was done and the time the pack was replaced with the next in cycle. Three weeks worth or so, switching packs in mid day and backing up at 4am. It took thousands of dollars and two weeks to get our data back. We gained new respect for inter-media backups and for fixed media disks. Dick
If the public realized that the audit trail for returned books, records, tapes, et cetera was missing then more of the returned books, records, tapes, et cetera would not be returned. Most people return items on time or not unreasonably late only because there is an audit trail. Without the audit trail, there is no incentive for timeliness. A possible solution might be to lie and say to the newspaper that the audit trail had been recovered. As a follow-up, the library could then offer a penalty free time for the return of all materials.
(An inquiry from)
HARALD BAERENREITER, Fernuniversitaet, Arbeitsbereich Allgemeine
Soziologie, Postfach 940, D-5800 Hagen, F.R.G.
Regarding the inquiry from Baerenreiter: The light reading
Stephen Levy
Hackers: Heroes of the Computer Revolution
Doubleday & Co., 1984
(paperback: Dell Publ Co.)
should suggest some of the psychological and sociological risks associated
with certain forms of computer use.
Please do note that I specifically disclaim any suggestion that computer
use CAUSES these psychological or sociological effects. It may well be that
certain psychological states induce the forms of computer use mentioned in
Levy's book. Whatever the case, the book is certainly enjoyable reading.
Rich Hammond writes, in part:
> ...The problem: Turning off the electric power
> caused the emergency generator to come on, but the generator was cooled by
> water which came from the [shut off] main...
Apparently there were quite a number of vaguely analogous situations in
the Eastern Seaboard blackout of 1965. Samples:
One hospital had an excellent emergency generator that cut in promptly, but
it was in the basement. The hospital was in a low-lying area, and the
basement was kept dry by constant pumping. You guessed it: the pumps were
not on the emergency power bus, and the emergency power died as soon as
the rising seepage reached the generator.
Another organization (hospital?) discovered the hard way that its diesel
emergency generator had an AC-powered electric starter.
Most modern power plants need housekeeping power to function, and in
particular to start up. With the whole grid down, a chicken-and-egg
situation developed very quickly. The New York area got startup power
from a little power plant on Long Island, whose alert operator had
violated standing orders and simply opened all the circuits — including
the power-grid tie-line — when his meters went wild as the grid collapsed.
Boston got startup power from MIT; the MIT EE Dept. generators had been shut
down for the day, but apparently the MIT people managed to put together
enough car batteries (!) to bootstrap themselves.
Practically the only people whose emergency preparations really did work
flawlessly were the professional paranoids: the military and the phone
company. Even the air traffic control centers were dead; it was just as
well that it was a clear night with considerable moonlight.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
(From: Albert W. Friend, SPAWAR, Washington, DC)
The preparations for COMPASS 86 in Washington, 7-11 July are going
quite well. Many people have expressed considerable interest in the
keynote address by Dave Parnas:
When Can We Trust Software Systems?
We have received a number of abstracts and papers.
We should have an excellent attendance, based on the statements of
those who say that they plan to come.
In reviewing the papers that have come in, we would like to see
more papers in the areas of:
Measuring,
Assessing,
Specifying, and
Eliminating
risks due to defects in software, computer hardware design, process
security, etc. We would be particularly interested in more papers
from the academic community, especially ones with a strong basis in
the theoretical infrastructure of software engineering, mathematics,
etc. Also, papers relating to the psychology of programmers, and the
possible limitations placed on practical software, would be extremely
interesting. We have not even one paper in this area so far.
If you have any bright ideas, COMPASS is the place to try them out.
Any abstract received by Monday, 21 April will be reviewed by the
program committee. They should either be sent by U.S. Mail to:
COMPASS, P.O.Box 3815, Gaithersburg, MD 20815
or sent to me over the net at friend at nrl-csr
Albert W. Friend, Program Chairman, COMPASS 86
Please report problems with the web pages to the maintainer