Parity

From: Fred Cisin <cisin_at_xenosoft.com>
Date: Fri Apr 9 12:35:16 1999

Yes, implementing parity INCREASES the total number of errors that can
occur.

Would you rather have 9*x errors, and each time be notified of the error,
and redo the portion of the task where the error happened; or would you
rather have 8*x errors, and each time continue on blissfully unaware that
your data was corrupted?

"Users of parity-enabled systems report having 9 times as many errors as
do users of non-parity-enabled systems!" No, there are NOT 9 times as
many errors! "Drivers of cars with guages and idiot lights report far
more problems than do drivers of cars with NO instrumentation. Take out
the bulb of the oil pressure light, and there won't be as many
complaints."


I am NOT a fan of IBM's handling of it! (JMP $) But it is easy to see
the reasoning behind it. There are many situations, such as text editing,
where I would just as soon IGNORE the error, and go back later to find/fix
it. But IBM knew that providing an option to ignore errors was too risky.
Too many lusers would simply IGNORE all errors that occur ("I've ALWAYS
done it this way, and have NEVER had a problem"). Then, when the payroll
checks have wrong amounts, blame IBM for lousy computers. IBM's reasoning
was that they would rather have the computer refuse to function than to
function unreliably. And that could only be achieved by not giving the
user the choice of IGNORing errors. "Yeah, but why does it have to lock
up when I'm only using it to play Lode-runner?" IBM took a similar
unpopular approach on the second model of AT, when they added code to
prevent the computer from running if the user had increased the clock
speed past what the MB was designed for.

Non-parity systems (such as Apple and current PCs) instead take the
approach of WHO CARES whether the data is correct? And Lode-runner
doesn't lock up.
Received on Fri Apr 09 1999 - 12:35:16 BST