informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/magazines/JAUC/juac10.txt

803 lines
37 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

From dfox@fc.net Sat Jan 21 06:21:58 1995
Received: from freeside.fc.net (freeside.fc.net [198.6.198.2]) by bigboote.WPI.EDU (8.6.9/8.6) with ESMTP id GAA16077 for <mikecap@wpi.edu>; Sat, 21 Jan 1995 06:21:53 -0500
Received: (from dfox@localhost) by freeside.fc.net (8.6.8.1/8.6.6) id FAA01518 for mikecap@wpi.edu; Sat, 21 Jan 1995 05:18:54 -0600
Date: Sat, 21 Jan 1995 05:18:54 -0600
From: Malik Al-Rashim <dfox@fc.net>
Message-Id: <199501211118.FAA01518@freeside.fc.net>
To: mikecap@wpi.edu
Subject: JAUC-File10
Status: O
CALLER ID FAQ
By Padgett Peterson (padgett@tccslr.dnet.mmc.com)
Frequently Asked Questions About Caller-ID v1.1 Mar. 1994
1) What is Caller-ID ?
First ask "What is ANI"
2) OK, What is ANI ?
ANI or Automatic Number Identification is a mechanism by which the
different telephone companies determine what account is to be charged for
a call, This information is passed between Telcos and was originally
for billing purposes and predated both SS7 (Signaling System 7)
and (C)LASS (Local Area Signaling Services was the original AT&T
designations, the "C" was added by Bellcore after divesture) services
which make CNID or Calling Number IDentification as Caller-ID is more
properly known, possible.
Since the Telcos had ANI, the decision was made to make it available
to authorized parties such as 911 service and law enforcement agencies.
ANI is also used to let a Telco operator know who is calling.
More recently, ANI is used to report to 800 and 900 subscribers,
who made the calls they have received, in the first case so that
the 800 subscriber knows who the charge is for, and so that 900
number subscribers know who to charge.
Thus while ANI is similar to CALLER-ID and may provide the same
information, they are actually two different services and ANI information
is not necessarily the same as what will appear on a CALLER-ID display.
3) Now (maybe) what is Caller-ID ?
Caller-ID is a Telco offering that is a byproduct of (C)LASS services.
In this case, only those numbers reported by participating exchanges are
returned, exactly which are and which are not is currently (March 1994)
at the Telco's discretion.
The Federal Government has stated that it is their intent that nationwide
CNID be available by mid-1995. The full text of this decision may be
found FCC Report No. DC-2571 issued on March 8, 1994.
The biggest effect of the ruling is to mandate transport of CPN (customer
provided number) information between interconnecting networks eliminating
the effective inter-LATA-only limitation that exists today in most areas.
Currently there are two types of Caller-ID. The first (often referred
to as "basic" service) just returns the calling number or an error
message and the date/time of the call.
The second ("enhanced" Caller-ID) also may return the directory
information about the calling number. At a minimum, the name of the
subscriber is returned (the subscriber is not the same as the caller,
the phone company has no way to determine who is actually on the line).
4) How is the Caller-ID information provided ?
As a 1200 baud, 7 data bits, 1 stop bit data stream usually transmitted
following the first and before the second ring signal on the line. Note
that this is not a standard Bell 212 or CCITT v22 data format so a
standard modem will probably not be able to receive it. Further, the
serial information exists as such only from the recipient's switch to
the callee's location. Between carriers the signal exists as data packets.
The signal is provided before the circuit is complete: picking up the
receiver before the data stream is finished will stop/corrupt the
transmission.
Currently there are two types of information returned: a "short form"
which contains the date/time (telco and not local) of the call and the
calling number or error message. The "long form" will also contain the
name and possibly the address (directory information) of the calling phone.
The "short form" stream consists of a set of null values, followed
by a two byte prefix, followed by the DATE (Month/Day), TIME (24 hour
format), and number including area code in ASCII, followed by a 2s
compliment checksum. Most modems/caller id devices will format the data
but the raw stream looks like this :
0412303232383134333434303735353537373737xx
or (prefix)02281334407555777(checksum)
A formatted output would look like this:
Date - Feb 28
Time - 1:34 pm
Number - (407)555-7777
5) Can a Caller-ID signal be forged/altered ?
Since the signal is provided by the local Telco switch and the calling
party's line is not connected until after the phone is answered, generally
the signal cannot be altered from the distant end. Manipulation would
have to take place either at the switch or on the called party's line.
However, the foregoing applies only to a properly designed CNID unit.
For instance the Motorola M145447 chip has a "power down" option that
wakes the Chip up when the phone rings for just long enough to receive,
process, and deliver the CNID signal after which it shuts down until the
next call.
Should this option be disabled, the chip will be in a "listen always"
state and it is theoretically possible to "flood" a line making a
vulnerable box record successive erroneous numbers.
I have received a report of a device called "Presto Chango" that
can transmit an extra ADSI modem tone after the call has been picked up
that will cause a susceptible box to display the later information. It
was also reported to me that CNID boxes marketed by US-West as their
brand and made by CIDCO have been used to demonstrate the "Presto Chango"
box.
6) What is "ID Blocking" ?
Most Telco's providing Caller-ID have been required to also provide the
ability for a calling party to suppress the Caller-ID signal. Generally
this is done by pressing star-six-seven before making the call. In most
cases this will block the next call only however some Telcos have decided
to implement this in a bewildering array of methods. The best answer is
to contact the service provider and get an answer in writing.
Currently this is supplied as either by-call or by-line blocking. By-Call
is preferred since the caller must consciously block the transmission
on each call. By-Line blocking as currently implemented has the
disadvantage that the caller, without having a second caller-id equipped
line to use for checking, has no way of knowing if the last star-six-seven
toggled blocking on or off.
Note that blocking is provided by a "privacy" bit that is transmitted
along with the CNID information and so is still available to the Telco
switch, just not to the subscriber as a CNID signal. Consequently related
services such as call trace, call return, & call block may still work.
7) What happens if a call is forwarded ?
Generally, the number reported is that of the last phone to forward the
call. Again there are some Telco differences so use the same precaution
as in (6). If the forwarding is done by customer owned equipment there
is no way of telling but will probably be the last calling number.
Note that as specified, CNID is *supposed* to return the number of the
originating caller but this is at the mercy of all forwarding devices,
some of which may not be compliant.
8) What happens if I have two phone lines and a black box to do
the forwarding ?
If you have two phone lines or use a PBX with outdialing features, the
reported number will be that of the last line to dial. Currently there
is no way to tell a black box from a human holding two handsets together.
9) I called somebody from a company phone (555-1234) but their Caller-ID
device reported 555-1000.
Often a company with multiple trunks from the Telco and their own
switch will report a generic number for all of the trunks.
There is a defined protocol for PBXs to pass true CNID information on
outgoing lines but it will be a long time before all existing COT
(Customer Owned Telephone) equipment is upgraded to meet this standard
unless they have a reason to do so.
10) I run a BBS. How can I use Caller-ID to authenticate/log callers ?
There are two ways. The first utilizes a separate Caller-ID box
with a serial cable or an internal card. This sends the information
back to a PC which can then decide whether to answer the phone and what
device should respond. Some of these are available which can handle
multiple phone lines per card and multiple cards per PC.
The second (and most common) is for the capability to be built in a modem
or FAX/modem. While limited to a single line per modem, the information
can be transmitted through the normal COM port to a program that again
can decide whether or not to answer the phone and how. There is a
FreeWare Caller-ID ASP script for Procomm Plus v2.x available for FTP
from the Telecom archive. Most such software packages will also log each
call as it is received and the action taken.
Of course for true wizards, there are chips available (one of the first
was the Motorola MC145447) that can recognize the CNID signal and
transform it into a proper RS-232 (serial) signal.
11) How is security enhanced by using Caller-ID over a Call-Back
service or one-time-passwords for dial-up access ?
Caller-ID has one great advantage over any other mechanism for telephone
lines. It allows the customer to decide *before* picking up the receiver,
whether to answer the call.
Consider hackers, crackers, and phreaks. Their goal in life is to forcibly
penetrate electronic systems without permission (sounds like rape doesn't
it ?). They employ demon dialers and "finger hacking" to discover
responsive numbers, often checking every number in a 10,000 number
exchange.
If they get a response such as a modem tone, they have a target and
will often spend days or weeks trying every possible combination of codes
to get in. With Caller-ID answer selection, the miscreant will never
get to the modem tone in the first place, yet for an authorized number,
the tone will appear on the second ring. Previously the best solution
for dial-ups was to set the modem to answer on the sixth ring (ats0=6).
Few hackers will wait that long but it can also irritate customers.
12) What error messages will Caller-ID return ?
a) "Out of Area" - (Telco) the call came from outside the Telco's
service area and the Telco either has no available information or
has chosen not to return what information it has.
b) "Blocked" or "Private" - (Telco) the caller either has permanent
call blocking enabled or has dialed star-six-seven for this call. You do
not have to answer either.
c) "Buffer Full" - (device manufacturer) there are many Caller-ID devices
on the market and exactly how they have chosen to implement storage is up
to the manufacturer. This probably means that the divide has a limited
buffer space and the device is either losing the earliest call records or
has stopped recording new calls.
d) "Data Error" or "Data Error #x" - (device manufacturer) signal was
received that was substandard in some way or for which the checksum did
not match the contents.
e) "No Data Sent" - (device manufacturer) Signal was received consisting
entirely of nulls or with missing information but a proper checksum.
13) Why are so many people against Caller-ID ?
FUD - Fear, Uncertainty, & Doubt or 10,000,000 lemmings can't be wrong.
There were some justifiable concerns that some people (battered wives,
undercover policemen) might be endangered or subject to harassment
(doctors, lawyers, celebrities) by Caller-ID. As mentioned above there
are several legitimate ways to either block Caller-ID or to have it return
a different number. It is up to the caller. The advantage is that with
Caller-ID, for the first time, the called party has the same "right of
refusal".
Expect yet another Telco service (at a slight additional charge) to be
offered to return an office number for calls made from home. Crisis
centers could return the number of the local police station.
Compiled by Padgett Peterson. Constructive comments to:
padgett@tccslr.dnet.mmc.com Brickbats >nul.
Thanks for additional material to:
David J. Kovan
Robert Krten
John Levine
David G. Lewis
Karl Voss
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
THE PENTIUM BUG WAR ENDS AS WE KNOW IT
By James Baar and Theodore Baar
The real long-term significance of the Great Intel Pentium Flaw
Imbroglio is the imminent demise of the current practice of public
relations and corporate and government communications as we know them.
Ironically caught unaware of the communications world it helped create,
Intel suffered a public relations near-disaster. Intel's arch competitor,
IBM, wandered bubba-like into a public relations bog the future depths
of which are still to be determined.
Clearly we soon will see on the boneyard of history such communications
artifacts as:
--The lengthy, well-spun news release or official statement
explaining what "really" happened or why a product "really" is a
breakthrough for all mankind.
--The news conference where the news is that what the media said
yesterday or last week is "really" not the news at all.
--The necessity to convince rushed and often ill-informed
journalists and beautiful and much more ill-informed TV anchors that your
truth is "really" true.
The Internet is doing to public relations what CSPAN, CNN Forums
and talk radio are doing to news coverage: When you are there, the
messenger is extraneous. And, on the Internet, you are there and you are
the messenger as well..
The Pentium Flaw War was the first major corporate war to be fought
primarily in cyberspace. The initial, very scattered shots were fired
more than five months ago on the Internet; major engagements got underway
in October; and a worldwide battle raged through November and early
December.
Little of this was noted particularly in the general or trade media
until near the end. And then it was reported as a highly technical
problem of limited general interest. Only when IBM found it convenient
to drop the equivalent of a small nuclear weapon did most of the major
national media take note that something much more than an academic,
technically obscure brawl was underway.
Only then did the WALL STREET JOURNAL shout from it's front page:
Chip Shot
Computer Giants' War
Over Flaw in Pentium
Jolts the PC Industry
And, on the same day, the NEW YORK TIMES shouted from it's front page:
I.B.M. HALTS SALES
OF IT'S COMPUTERS
WITH FLAWED CHIP
Both stories were inspired belatedly by an IBM announcement that it was
suspending sales (sort of) of any of it's personal computers that included
the Intel Pentium chip because the chip had a flaw.
Well, ho-hum: Except for the IBM announcement, this was old news along
the Information Highway. And the IBM announcement was immediately
discounted by many of the veteran cyberspace combatants of the Pentium
War as highly suspect: something similar to Parliament coming out against
slavery in America after Lexington and Concord.
Most great military engagements begin quite casually if not accidentally:
A sniper picks off a poacher stealing a chicken. A nervous platoon leader
calls in a little artillery fire on a bunker. A lost company stumbles
on a tank column.
Back in June, Intel and some of it's customers already knew about the bug
that was preventing the new Pentium microprocessors to divide accurately
out to more than nine or 10 decimal places in some cases. Intel did not
publish the information. If any messages about the bug appeared here and
there in various newsgroups on the Internet for the next few months,
they initially attracted little attention.
This was not the kind of consumer problem that causes a lot of excitement
at your neighborhood 24-hour store. But this bug was of interest -- and
in some cases importance to parts of the world technical community
engaged in major mathematical calculations: This is a community that also
appreciates that such a flaw is not the first nor will be the last in
the increasing complexity of computer components and software; exalts
technical openness; recognizes quickly when it is being stonewalled; and
has a biting specialized sense of outrage and humor.
Prof. Thomas Nicely of Lynchburg College reports that when he began
running into a potential flaw in the Pentium in June he started a three
month effort to determine whether the problem was the Pentium or something
else. For example, his own calculations; or possibly known bugs in other
hardware such as the Borland C Compiler. And in Copenhagen mathematicians
developed a T-shirt satirizing the Intel chip logo "Intel Inside" as "No
Intelligence Inside" and published memos saying "We knew about it early
in June..."
Intel managed to downplay and contain word of the bug for the most part
through the next three months. Any callers were told at first that a fix
was underway and that the bug affected only very special situations.
Then, on Oct. 30, Dr. Nicely posted a message to "whom it may concern"
on the Internet, reporting his findings and his frustrations with getting
Intel to pay serious attention to him. In the succeeding weeks, the war
between Intel and it's users exploded. Each day there were more reports
about the bug and Intel's truculence.
The number of the strings of messages on the Internet increased and grew
longer as users at universities, laboratories and corporations around the
world reported the same bug and it's potential variations; discussed
their research for possibly more bugs; and reported on their
unsatisfactory and frustrating phone calls to Intel.
And here was where the war was really fought.
Intel treated each caller as an individual, linear event to be dealt with
in isolation; turned around or at least mollified. Intel's position was
that this was a routine bug that was being taken care of and was of no
major importance to most of it's customers. The Intel position essentially
remained that there was no need for a general replacement on demand; that
the problem was relatively minor; that if a user was engaged in the kind
of heavy mathematics that could be affected by the bug then Intel, if
it agreed, would replace a Pentium.
Meantime, Intel and it's commercial allies continued to promote and sell
Pentiums. More than four million Pentiums were reported sold.
The words "greedy" and "arrogance" became popular on the Internet among
customers describing Intel's position. The Internet discussion was highly
technical and profane. It also included useful suggestions for
broadening the discussion. For example, participants were provided
with the Fax number of the New York Times. And more and more of the
callers to Intel shared their mostly frustrating experiences on the
Internet with a worldwide audience of customers. An angry mob -- slowly
recognized as a major threat by Intel -- began to assemble in cyberspace
Intel CEO Andrew Grove issued a statement on the Internet Nov. 27 seeking
to quiet the mob. Instead the roar in cyberspace increased. Intel's
Software Lab Technology Lab Director Richard Wirt on Dec. 8 issued a
statement on the Internet describing Intel plans to provide a fix for the
flaw. The roar continued and spread and Intel's weakening protests were
increasingly drowned out as the users reinforced each other with new data
and complaints around the clock around the world.
It was at this point on Dec.12 that IBM -- a reported minor player in the
sale of Pentiums, but the developer of a competitive chip, the PowerPC --
decided to announce both on the Internet and to the major national media
the halting of it's shipments of Pentium-based IBM PCs.
The war was now spread to the major national media where the problem was
easily confused with various consumer product recalls and the Internet
where IBM's move was both discounted as self-serving and used
simultaneously to pummel Intel further.
By Dec. 20 Intel had had enough. It agreed to a general recall and
apologized for not doing so sooner.
The public relations lessons are clear.
People -- particularly customers -- are no longer isolated waiting to
learn sooner or later what is happening through the third party media
screen and, in turn, relying on the third party media to screen and
sooner or later report their reaction. Even when the third party media
is accurate this process can take many days.
Through the Internet, people -- particularly customers -- can tell a
corporation or organization exactly what they think and why and share that
simultaneously and instantaneously with all concerned around the world.
The Internet returns the world to the agora where everyone hears what was
said; and everyone hears all comments and reactions; everyone knows who
is talking and can make credibility judgments.
The first Intel error was not to spot the issue stirring on the Internet
months ago when the commentary was helpful and understanding. At that
time and for several months later, Internet commentators could have been
embraced and thanked for their efforts; immediate plans for a work-around
fix could have been disclosed; and work on a permanent fix could have
been described: all in cyberspace among sophisticated customers who well
understand the complex nature of the technology.
Intel's second error was not to recognize that because of the Internet it
no longer could reason at least semi-privately with customers and advance
rational technical arguments. In pre-cyberspace days, that could be
effective: the customer is grudgingly mollified until the issue is
eventually resolved. But in this case, as it's customers shared both
their problems and experiences with each other in real time, they fed
each others frustrations; were empowered as a group to demand better
treatment; and built mutual strength with each day for new battles to
come.
Intel's third error was not to go directly on line with it's customers and
deal with the issue interactively. Instead, Intel pursued the classic
static public relations mode of issuing statements and news releases.
These were turned into blackened ruins by Internet flame messages in a
matter of hours.
Meantime, IBM by it's announcement, uncorked the Law of Unanticipated
Consequences. The Internet mob really understood the issue; the general
public for the most part did not. IBM, with motives already under
suspicion, opened the bottle labeled "Doubt about Technology" to the
overall potential future detriment of the Information Technology Industry
in general.
As more people around the world join the millions already using the
Internet for communications, corporations and government will be forced
if they wish to succeed to function within the new realities of cyberspace:
information is shared and sifted by thousands of knowledgeable people;
time is collapsed; facts are quickly checked; loss of credibility can be
instantaneous; second chances are rare and harder to effect; grandstand
plays better be perfect; and the playing off of one audience against
another is far more easily detected.
Above all else, a smattering of obscure messages or even a random one or
two can no longer be automatically disregarded as mere technical mumbling.
For example, is anyone following up on a recent Internet potential bug
message regarding AMD DX-80 chips or another regarding "something about a
conditional loop" in the Pentium?
One final cyberspace reality of note: instant corrosive humor is abundant
and effective. (If they really are laughing about you, you can't be taken
seriously anymore.) This was ably demonstrated by the Internet author
who wrote for the delectation of Intel customers and potential customers
everywhere a Star Trek parody. He called it: "BBUUGGS IINN
SSPPAACCEE!!".
(This article is from a forthcoming issue of Knowledge Tools News, an
electronic newsletter of Omegacom, Inc. James Baar (jimbar@omegacom.com)
is president/managing consultant. Theodore Baar (tedbar@omegacom.com.)
is vice president/chief technologist.)
-----------
Copyright (c) 1994 Omegacom, Inc., all rights reserved. This article may
be posted to any USENET newsgroup, on-line service, or BBS as long as it
is posted in it's entirety and includes this copyright statement. All
other rights reserved. This article may not be included in commercial
collections or compilations without express permission from Omegacom,
Inc. jimbar@omegacom.com. For all other uses you must seek permission
of Omegacom, Inc. jimbar@omegacom.com
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
NON-DISCLOSURE AGREEMENT OF DR. NICELY
The following message was posted to the Internet by Dr. Thomas Nicely,
discover of the Pentium Floating Point Unit Flaw. The first part deals
with a question regarding Dr. Nicely's signing of a non-disclosure
agreement with Intel.
TO: Whomever It May Concern
FROM: Dr. Thomas R. Nicely, Lynchburg College, Lynchburg, Virginia
(nicely@acavax.lynchburg.edu)
RE: Pentium Bug and Intel NDA
DATE: 94.11.25.1400 EST
This is in reply to Paul Rubin's (phr@netcom.com) inquiry of 23 November.
* I signed a temporary nondisclosure agreement with Intel on 10 November.
* There was no coercion or threat of any kind, by either party.
* The NDA was signed in the course of discussions to determine
whether or not an agreement (such as a consultancy) could be reached
which would prove beneficial in the long term to myself, to the Intel
Corporation, and to my employer, Lynchburg College.
* From 10 November until 22 November, I deflected all inquiries regarding
the Pentium FPU to Intel's representatives. This was a consequence of
my own mistaken interpretation of the NDA; I was treating it in the
manner of a security clearance; I once held a clearance for secret
restricted data in X-division (nuclear weapon design and analysis)
at Los Alamos National Laboratory, and that clearance treated most
information concerned as "born secret," even if the information was
acquired prior to the clearance and/or independently. In the same
spirit, I removed from the College's VAX anonymous FTP directory
copies of the codes used to analyze the Pentium chip for the bug.
* After receiving some complaints in this regard, Intel (on its own
initiative) informed me on 22 November that I was free to discuss
publicly the discovery and nature of the Pentium FPU bug, since this was
my own work, accomplished prior to signing the NDA and without
assistance from Intel; and that the primary purpose of the NDA was to
insure confidentiality of information exchanged in the course of any
consulting I might do for Intel in the future.
* To this date, Intel has been most cooperative in alleviating difficulties
caused for my own research (computational number theory; distribution of
twin primes and other constellations, and the sums of their reciprocals)
by the presence of the bug. They have shipped replacement chips for the
CPUs in the machines I am using, and I have verified that the new chips
are free of the bug (zero errors in > 1e15 simulated random divisions).
* I cannot speak for Intel regarding its policies on CPU replacement for
Pentium systems having the bug; that is a management decision which
obviously must take into account the constraints of supply, inventory,
logistics, expense, and public relations. To date, I believe Intel has
handled the affair in essentially the manner that could usually be
expected of most businesses operating in a highly competitive, low-margin
capitalistic economy. Any Pentium owner who feels the need for a
replacement CPU should contact Intel Customer Service and Tech
Support at 800-628-8686, or Intel representative John Thompson at
408-765-1279.
* I probably have a somewhat different perspective on the bug than most
users. It is my opinion that the current generation of microprocessors
(and possibly all of them since, say, the 8080) has become so complex
that it is no longer possible to completely debug them, or even to
determine every bug that exists in one. Thus, the discovery of this
particular bug should not be any great surprise. There have been many
well-publicized bugs in the past (e.g., the 32-bit multiply bug in the
early 80386s, the arctangent bug in the early 80486s, the stack-handling
bug in the early 8088s, and the Motorola 68K revision F bug).
Furthermore, in view of this, all mission-critical computations should
be performed multiple times, in settings as independent as possible---
preferably with different CPUs, operating systems, and software
algorithms. Where different platforms are not available, the same
computation should be performed using algorithms as independent as
possible; this was in fact how I pinpointed the Pentium bug---the
sums of the reciprocals of the twin primes were being done in both
long double floating point (64 significant bits) and in extended
precision using arrays of integers (26 decimal digits at that time,
53 decimal digits currently). Dual calculations were also being run
on 486 and Pentium systems.
* Note that the bug can be temporarily circumvented by locking out
the FPU. For most DOS applications, this can be done by means of the
DOS commands SET 87=NO (for executables created by Borland compilers)
and SET NO87=NO87 (for executables created by Microsoft compilers).
Of course, this is at best a performance-killing band-aid; some
applications require an FPU, while Windows and most DOS extenders
ignore these environmental variables. In theory, it should be
possible to write a fairly short (100 lines?) utility code which
enters protected mode (ring 0), sets up a valid global descriptor table
(and perhaps a valid interrupt descriptor table), resets the emulation
bit in the machine status word of control register 0, and then re-enters
real mode. Running such a code at boot time should lock out the FPU
even for Windows and DOS extended applications; a similar code could
reactivate the FPU at will. Unfortunately, I haven't had the time to
write the code yet!
* To date, my analysis indicates that the bug will appear in about 1 in
31 billion random divisions and 1 in 1.26 billion random reciprocals.
These figures are similar to the rate of 1 in 9.5 billion attributed to
Intel. In my own application (distribution of twin primes and the sum
of their reciprocals) no error appeared for values < 824e9. Most users
will find these values reassuring; those of us doing computational
number theory, chaos theory, or analysis of ill-conditioned matrices
may still want a new, bug-free CPU.
* To date, the worst-case error of which I am aware is an example
apparently posted by Tim Coe of Vitesse Semiconductors on 14 November,
indicating that the quotient 4195835.0/3145727.0 is returned correctly
to only 14 significant bits (5 significant decimal digits). I have not
yet had a chance to verify this example.
* Copies of some of the codes I have used to analyze the bug (updated to
reflect later developments) will be restored to the anonymous FTP
directory [anonymous.nicely.pentbug] of Lynchburg College's VAX server
(machine ID acavax.lynchburg.edu) as soon as I get time to update and
post them.
* Feel free to transmit this communication as you wish.
Sincerely,
Dr. Thomas R. Nicely
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
THE COMPUTER NEVERMORE (The Raven)
By Unknown
Once upon a midnight dreary, fingers cramped and vision bleary,
System manuals piled high and wasted paper on the floor
Longing for the warmth of bedsheets,
Still I sat there, doing spreadsheets;
Having reached the bottom line,
I took a floppy from the drawer.
Typing with a steady hand, then invoked the SAVE command
But I got a reprimand: it read 'Abort, Retry, Ignore.'
Was this some occult illusion? Some maniacal intrusion?
These were choices Solomon himself had never faced before.
Carefully, I weighed my options.
These three seemed to be the top ones.
Clearly I must now adopt one:
Choose 'Abort, Retry, Ignore.'
With my fingers pale and trembling,
Slowly toward the keyboard bending,
Longing for a happy ending, hoping all would be restored,
Praying for some guarantee
Finally I pressed a key--
But on the screen what did I see?
Again: 'Abort, Retry, Ignore.'
I tried to catch the chips off-guard--
I pressed again, but twice as hard.
Luck was just not in the cards.
I saw what I had seen before.
Now I typed in desperation
Trying random combinations
Still there came the incantation:
Choose: 'Abort, Retry, Ignore.'
There I sat, distraught exhausted, by my own machine accosted
Getting up I turned away and paced across the office floor.
And then I saw an awful sight:
A bold and blinding flash of light--
A lightning bolt had cut the night and shook me to my very core.
I saw the screen collapse and die
'Oh no--my data base,' I cried
I thought I heard a voice reply,
'You'll see your data Nevermore!'
To this day I do not know
The place to which lost data goes
I bet it goes to heaven where the angels have it stored
But as for productivity, well
I fear that IT goes straight to hell
And that Us the tale I have to tell
Your choice: 'Abort, Retry, Ignore.'
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
TWAS THE NIGHT BEFORE STAR TREK...
'Twas the night before Christmas, when all through the ship
Not a circuit was buzzing, not one microchip;
The phasers were hung in the armory securely,
In hope that no alien would get up that early.
The crewmen were nestled all snug in their bunks
(Except for the few who were partying drunks);
And Picard in his nightshirt, and Bev in her lace,
Had just settled down for a neat face to face...
When out in the hall there arose such a racket,
That we leapt from our beds, pulling on pant and jacket.
Away to the lifts we all shot like a gun,
Leapt into the cars and yelled loudly "Deck One!"
The bridge red-alert lights, which flashed through the din,
Gave a lustre of Hades to objects within.
When, what on the viewscreen, our eyes should behold,
But a weird kind of sleigh, and some guy who looked old.
But the glint in his eyes was so strange and askew,
That we knew in a moment it had to be Q.
His sleigh grew much larger as closer he came.
Then he zapped on the bridge and addressed us by name:
"It's Riker, It's Data, It's Worf and Jean-Luc!
It's Geordi, And Wesley, the genetic fluke!
To the top of the bridge, to the top of the hall!
Now float away! Float away! Float away all!"
As leaves in the autumn are whisked off the street,
So the floor of the bridge came away from our feet,
And up to the ceiling, our bodies they flew,
As the captain called out, "What the Hell is this, Q?!"
The prankster just laughed and expanded his grin,
And, snapping his fingers, he vanished again.
As we took in our plight, and were looking around,
The spell was removed, and we crashed to the ground.
Then Q, dressed in fur from his head to his toe,
Appeared once again, to continue the show.
"That's enough!" cried the captain, "You'll stop this at once!"
And Riker said, "Worf, take aim at this dunce!"
"I'm deeply offended, Jean-Luc" replied Q,
"I just wanted to celebrate Christmas with you."
As we scoffed at his words, he produced a large sack.
He dumped out the contents and took a step back.
"I've brought gifts," he said, "just to show I'm sincere.
There's something delightful for everyone here."
He sat on the floor, and dug into his pile,
And handed out gifts with his most charming smile:
"For Counselor Troi, there's no need to explain.
Here's Tylenol-Beta for all of your pain.
For Worf I've some mints, as his breath's not too great,
And for Geordi LaForge, an inflatable date."
For Wesley, some hormones, and Clearasil-plus;
For Data, a joke book, For Riker a truss.
For Beverly Crusher, there's sleek lingerie,
And for Jean-Luc, the thrill of just seeing her that way."
And he sprang to his feet with that grin on his face
And, clapping his hands, disappeared into space.
But we heard him exclaim as he dwindled from sight,
"Merry Christmas to all, and to all a good flight!"
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
SANTA SOURCE CODE
By Unknown
#bash
better !pout !cry
better watchout
lpr why
santa claus <north pole >town
cat /etc/passwd >list
ncheck list
ncheck list
cat list | grep naughty >nogiftlist
cat list | grep nice >giftlist
santa claus <north pole >town
who | grep sleeping
who | grep awake
who | egrep 'bag|good'
for (goodnes sake) {
be good
}
better !pout !cry
better watchout
lpr why
santa claus <north pole >town
[original source unknown]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Reference in New Issue View Git Blame Copy Permalink