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 friend of mine has suffered for years with what she thought was arthritis.
About 18 months ago, she was diagnosed as having a classic case of CTS. She
is due to have an operation to "depress the nerve in the wrist" very shortly
and is a bit concerned about the likely outcome. A few people she knows have
undergone the same operation with good results, but she has ben warned that
the scar will be extremely sensitive for a long time.
Does anyone out there have any experience, which I can quote to reassure or
warn her?
A have noticed a few curious things while this has been going on:-
- All the people she knows who have suffered from CTS are female, and the
affected hand has been the non-dominant hand. Is this a general rule?
- The operation list at the consultant's surgery showed that he does around
two CTS cases a week. That's one consultant in London, and only the cases
severe enough to be operated on! How prevalent is CTS? Any statistics?
- My friend is a highly-skilled touch typist (who for years trained other
people to professional qualification standard), and very careful regarding
the ergonomics of typing, position of seat, hands, etc. Why does CTS strike
the professional, and not the idiot amateur like me, who types with one
hand only (having lost the use of the other years back in a road accident),
and whose idea of ergonomics is having the ash-tray and the coffee cup
within easy reach? (I put in sufficient hours at a workstation
to qualify for the "at risk" category, though!)
All information gratefully received. (I am aware of the correspondence around
RISKS-10.12 from Andrea Frankel et al., and have already passed on that
information.)
Peter Mellor, Centre for Software Reliability, City University, Northampton
Sq.,London EC1V 0HB +44(0)71-253-4399 Ext. 4162/3/1 p.mellor@uk.ac.city (JANET)
[RESPONSES TO PETER MELLOR, PLEASE, NOT TO RISKS. I TRUST HE WILL
SHARE ANYTHING SIGNIFICANT WITH THE REST OF US... Thanks. PGN]
Being interested in languages (both natural and artificial) I lent an ear to
the following story, heard from a participant to a seminar I recently taught in
Berlin. I tried to get the details right, but this is all hearsay and I can
make no guarantee of accuracy.
It appears that the UCSD Fortran (?) compiler had a confusing option which
enabled programs to write to a ``device'' as well as to a Fortran ``unit''. In
particular, unit 6 is the standard output in Fortran; but writing to DEVICE 6
rather than UNIT 6 would erase the whole disk...
Such an event, disastrous as it was, could only occur as a result of some
combination of bad luck and carelessness - for people using the original
documentation.
But according to my source the German translation used the word ``einheit'' as
a translation for ``device''. (Apparently the translator also rendered ``unit''
by ``einheit'', which is indeed appropriate; but I am not sure of this point.)
The result is obvious: in German-speaking countries an inordinate number of
people lost everything as a result of erroneous write-to-device operations...
Perhaps someone with first-hand experience can confirm or correct.
Bertrand Meyer bertrand@eiffel.com (temporarily: bertrand@eiffel.fr)
[In UNITy there is DEVICEiveness? PGN]
There is an article in the Sept 16th issue of Business Travel News. To quote one paragraph "The patent decision recognizes as unique Travelmation's system for checking its own database of fares and flight availability and automatically selecting low fares that conform to corporate travel policies." Later in the article, "Part of the patent also covers Travelmation's Trip Planner system, a program that allows travelers to send their travel requirements from a personal computer to Travelmation..."
Rounding and truncating data can often get you into difficulties, as we found
recently in our fuel management system.
We collect data about refuelling transactions, and record the quantity of fuel
measured and the price of the transaction. We report the quantity to the
nearest hundredth of a unit (litres), and the price to the nearest hundredth of
a dollar. Recently, one of our customers complained that at a price of $1.00
per litre of fuel, the quantity would sometimes be 0.01 higher than the price.
What we found was that the program in the system that collected the
transactions and forwarded them to the database handled the numbers
differently: quantities were rounded to 2 decimal places, but prices were
rounded to 3 decimal places (effectively tenths of a cent). The program which
brought these transactions into the main reporting database then truncated the
price to two decimal places. I believe that this truncation was unintentional.
Our options in fixing this problem were:
1. Rounding the 3-decimal digit price to 2 decimal places.
2. Storing all 3 decimal places of the price.
3. Reporting the price to 2 decimals, instead of 3.
Option 1 was quickly discarded: you must not round a number twice, as
distortions creep in (0.4449 -> 0.445 -> 0.45 instead of 0.44).
Option 2 was unacceptable: since every transaction report only reported
2 decimal places, the totals might be corrupted where they were computed
using the unrounded price instead of the rounded display.
Option 3 was chosen, so that the precision of the raw data agrees with the
precision for individual transactions shown on reports. Given the accuracy of
the fuel measuring equipment, the thousandths of a cent was mostly garbage.
Just a small reminder of the hazards of truncation, rounding and significant
digits.
Brenton Hoff (behoffski) | Senior Software Engineer | My opinions are mine
xtbjh@Levels.UniSA.edu.au | AWA Transponder | (and they're weird).
OK, some sensible information from Barry Margolin <barmar@think.com>: > The patch replaces the C runtime library linked into the kernel; > we disassembled the old and new versions and compared them (actually, we > only disassembled the portion that implements the C integer division > operator, because of the description of the bug). I intended to do that, but never came to doing it, although apparently I only needed to look at the code presented in Version 7 of the Architecture manual on page 183! > The change has to do with the action taken when division by 0 is detected. > In both cases, it does a "ta T_DIV0", i.e. signal a division-by-zero trap. In the Architecture manual it says "te ST_DIV0", not a big difference. > The old code assumed that this instruction would never return; if it did, > it fell through to the rest of the code that implements division, and > presumably gets some wrong answer. The new code is prepared for the trap > instruction to return, and the operator returns 0 in that case. Yup. In the first case, who are you if you return from the second trap? And who are you when you return again? > Note that the description of the vulnerability is somewhat misleading. The > perpetrator doesn't gain privileges by using division in his own program. > He somehow has to get the kernel to try to divide by zero; I suspect the > vulerability is that the kernel then might use the result as in array index > into some kernel structure (e.g. the u area). No, not true. With version 8 of the architecture Sun introduces instructions for multiplication and division. These are on non-version 8 machines trapped as illegal instructions and emulated in software (since SunOS 4.0?). > As far as I'm concerned, the fact that the kernel ever even *tries* to > divide by zero is a bug. True, but the reasoning is wrong. Why is this code executed in kernel mode? It ought to be executed in user mode. The same holds by the way for a number of fp emulation routines, plus some more. The risk is that people concentrating on getting there emulation code right are also bothered by security issues. The fix is completely bogus (although it serves as a kludge or hack). When something has to be done to support the user for which kernel mode is not needed, the processor should go in user mode. I think that Sun failed big with its traps on unimplemented instructions. Just try to single step under adb an instruction that adb knows about but as does not; expect a panic. dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
Well, since probably I am the source of the information, permit me to add my two cents worth. Yes, the above is mostly correct, althoug a bit scatchy. For more information, see my paper "The Bulgarian and Soviet Virus Factories", published in the proceedings of the First International Virus Bulletin Conference on Computer Viruses, which was held in Jersey, UK, September 12-13. A slight correction of your message - the town mentioned is Sofia (not Sophia) and it is the capital of Bulgaria. :-) The BBS mentioned really exists, it is called Virus eXchange, SysOp is Todor Todorov, and it is indeed specialized in virus exchange and virus discussion between virus writers. I'm really sorry, but this is not illegal in Bulgaria, so we really cannot stop them. :-(( Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
In followup to the article I repeated here recently, George Anderson, director of the Minnesota State Lottery, writes in the Sun 22 Sep 91 Minneapolis [MN] Star Tribune "Letters from readers", (pg 22A): [...] The play at home test will use Nintendo's control deck, a modem by which the deck communicates to the Lottery computer and a Lottery cartridge. Transactions occur much as they do in the terminals found at our retailers across the state. The cartridge will not be available through retail outlets. No "children's games" are involved. Only existing Lottery games will be available. Adults must preregister, predeposit (no credit play) and prove their age. Adults will control a password for limited access. The deck will shut down if incorrect passwords are entered or if the machine is left unattended. Daily play will be limited. Statements will be [mailed]. [...] The control deck has enormous potential for interactive transactions — it is used in Japan for personal banking and stock transactions. Control Data Corp. and the Lottery believe that this test will demonstrate that the security and controls over player access removes the specter of minors' play, even as it provides the convenience demanded by Lottery players. Oh, yes, lottery players here in Minnesota are quite near rioting at how inconvenient it is to have to go to the nearest gas station or quick mart to play! Seriously, I'd like to know more about how the Japanese use it. Security issues must have been adequately addressed for people to be comfortable playing with their money via Nintendo. Or maybe there aren't any hackers in Japan?
In RISKS-12.38, Stanley (S.T.H.) Chow <SCHOW@bnr.ca.bitnet> comments on the military's "obsolete parts" problem (the difficulty of obtaining obsolete replacement parts for military systems). He says: >Given the well-known mountains of paper that the Pentagon requires for any >hardware, and the many mil-spec's for documenting and testing any and >everything, it is quite a surprise to me that anyone should need to reverse >engineer anything. [...] >Even excellent documentation is useless, Unless you can find it again. I was peripherally involved in one effort to get around the obsolete parts problem, and my impression is that the problem is NOT in finding the old documents. The problem is is that you can't rely on the documents. They are often out of date or incomplete. There is always that one last minute design change to fix the "final" (:-) bug, that may well not make its way into the formal documents. The basic problem is that there is no affordable way to check whether the documents are correct, and without checking such documents aren't much more reliable than an untested program.
This is a copy of a letter I just FAXed to Business Week in response to their article that presents object oriented programming as the grand solution to all software problems. This is absurd, but it is hard to blame Business Week by itself when many within the industry espouse such views and some even believe it. As we've seen in some of the recent articles on representations many of the fundamental difficulties aren't even related to programming as such. As we try to model the real world in our computer systems we are discovering what a messy place it is. But wouldn't it boring otherwise? I apologize for the tone of this article, the moderator suggested that I be stronger. In appropriate circumstances I would much more forceful but I think this letter represents the limit of what I can explain to a publication like BW. Feel free to send your own comments. The fax number of "Readers Report" (letters to the editor) is 212-512-4464. To: business week From: Bob Frankston Date: (09-21-91 22:49:19) Subject: Ideas made simple At the risk of great oversimplification, I'll be extremely brief. In doing so, I appreciate your difficulty in covering complex issues of technology in a small amount of space in a general (albeit business) publication. Your two recent articles, one on user interface and one on software development do a disservice by announcing "solutions" to complex problems. In your recent article on simplified controls for consumer appliance such as VCRs you gloss over the fact that good (interface) engineering involve more than just limiting capabilities until products become trivial to use. While this is indeed a valid and often appropriate technique, the problem faced by product engineers is presenting the user with access to advanced capabilities in a way that makes them obvious without being trivial. In a similar vein, the problems of developing software are not suddenly solved by the use of "objects". Like structured programming, modular programming, programmer teams, databases, relation databases, automatic programming (now called programming languages), object-oriented programming is yet another useful tool. But it doesn't magically solve all problems. In fact, some of the capabilities described in the article are more the result of taking advantage of the additional power of today's computer systems than completely new techniques. Many of the traditional programming techniques represent engineering tradeoffs given the limited slack available and not just ignorance. With more powerful systems, more attention can indeed be played to assembling components rather than crafting each one. But we still have much to learn about what the components should be and how they can fit together. As you pointed out in this article, to some degree the task is one of finding programming analogues to real world complexity. If we indeed reflect the complexity of the real world, why should it suddenly become simpler when it is modelled in a computer? In other articles Business Week has explained that "reengineering", or the process of rethinking a system as a whole, is much more effective than naive modelling. In contrast, the Software Made Simple article advocates mimicking existing systems. I do sympathize with the difficulties of presenting ideas concisely and understandably. In writing this letter I too have had to resort to extreme simplification. The price is a loss of accuracy. But simplifying shouldn't mean misleading the reader by suggesting that we have a grand solution to an intrinsically complex problem. Personal Categories: Use Inner Header: Delivery Priority: High Delivery Report: Basic Receipt Report: Sender phone number: 617-945-9199 (Personal Pager) Sender fax number: 617-244-1567 Cover Text for Faxes: Cover Page for Faxes:
You think BW shuts off its FAX machine on weekend or do they just get
overwhelmed after a particular stupid cover story?
To: Bob Frankston| EMS: Slate Corporation| MBX: Bob Frankston
cc:
From: MCI Mail Fax Service| EMS: MCI Mail| MBX: POSTMASTER @ mci @
FRANKSTON
Date: 09-22-91 03:10:00 (09-22-91 03:39:37)
Subject: CANCEL: Ideas made simple
Your fax message
To: Readers Report
Destination Fax: 212-512-4464
Date/Time Sent: Sun Sep 22, 1991 3:02 am GMT
Message ID: 24910922030242/0004464426NC4EM
was not delivered.
Date/Time Cancelled: Sun Sep 22, 1991 7:10 am GMT
Delivery Attempts: 12
Cancellation Code: 0015 - Ring no answer
For online assistance type HELP FAX CANCEL or contact MCI Mail
Customer Support at 800-444-6245 (U.S. only) or 202-833-8484.
Please retain the information contained in this cancellation
when calling for assistance.
I found the book "Technological Risk" by H.W. Lewis, W.W. Norton & Co., 1990, to be a very thoughtful and readable introduction to risk assessment. Lewis is a professor of physics at UC Santa Barbara and has chaired numerous government risk assessment committees. The dust cover has high and accurate praise from Hans Mark (former deputy administrator of NASA), W.H. Press (professor of Astronomy and Physics at Harvard) and James Schlesinger (former Secy of Defense and Secy of Energy). The first section, Generalities, talks about the risks and value of life, the measurement, perception, politics, assessment and management of risks, and "The delusion of Conservatism". The second section, Specifics, gives examples from toxic chemicals, chemical carcinogenesis, highway safety, air transportation, ionizing radiation, fossil fuels, nuclear winter and non-ionizing radiation. There is no major discussion of computer risks, but the subject is touched on in discussions of air transportation. Lewis has lots of experience. The book has much wisdom and is free of dogma. It is also a pleasure to read.
Please report problems with the web pages to the maintainer