Aihuxp.107
NET.blfp
utzoo!decvax!ucbvax!ihnss!ihuxp!shqer
Sun Jul 26 21:18:09 1981
BLFP 20
From: ihn5g!jdd (Joe Steffen filling in for John DeTreville)
Subject: BLFP 3.20
Bell Labs Free Press Monday, 27 July 1981 Volume 3 : Issue 20
Today's Topics:
BLFP on Netnews, Unix & Front End Processors, IHCC Tapes,
Screen Editors, IH nopr, Inter-machine Routing, Netnews,
Human-nets on Telephones, Unix/370, Laser Printers, CSNET,
Byte Issue on Smalltalk, C Interpreter, Unix Symposium,
HP2621 Terminal Mod, Cray Ad
----------------------------------------------------------------------
>From your moderator
Subject: Distribution via Netnews
The BLFP will now be distributed to netnews sites via the NET.blfp
newsgroup, and the BLPP wil be distributed via btl.blpp. This is the
last issue that will be mailed to ihuxk, ihuxp, ihnss, mhtsa, eagle,
research, hocsr, chico, harpo and allegra. If your site has netnews and
you didn't receive anything for the NET.blfp newsgroup recently, please
let me know.
Some IH machines that have installed netnews may continue to receive
mailed copies; let me know if you are getting it via netnews and I will
remove you from the mailing list.
Joe Steffen
------------------------------
>From karn Thu Jul 23 00:22:06 1981 CDT remote from ihnss
Subject: UN*X & front end processors
Although I am not very familiar with 370 Unix, it is my
understanding that it does provide the usual full duplex facilities
of Unix by means of Series/1 front end processors.
Front end processing isn't such a bad idea for DEC machines either. A lot
of CPU time in Unix is spent crunching characters in the tty subsystem,
a job that could be easily handled on a per-line basis by lowly 8-bit
microprocessors. Unix tty overhead is particularly inexcusable when
running screen editors in raw mode. Less work than cooked mode, true,
but it bothers me that several pages of C code have to be executed each
time I want to transparently send a character to a terminal.
Unfortunately, the only "microprocessor" (I use the term loosely) made
by DEC for the Unibus is the KMC-11. From personal experience in
programming this device for a special application (digital speech
storage) I can only say that the KMC is one of the worst processors
to program I've ever seen. No wonder it isn't used for much.
I've heard that somebody makes a general purpose z-80 controller card
that plugs into the Unibus; does anybody know about it?
Phil Karn
------------------------------
>From karn Thu Jul 23 00:36:41 1981 CDT remote from ihnss
Re: Tapes and IHCC security
I believe that most security problems could be avoided with operator-
issued tape commands if the operator simply newgrp's & su's to the
userid in question. To prove that the face at the window really belongs to
the account, all he has to do is provide his password. The su
command doesn't demand a password when the invoker is
already root, but this can be changed by simply su'ing to some harmless
non-root id first (e.g., oper, etc).
I can think of all kinds of ways to get an operator reading a tape with
super-user privileges to give me a super-user shell: reading in
setuid programs, overwriting an "innocent" file that is really a
link to a setuid-root command, etc. None of these would work if the
operator simply su'ed to the user's id first.
I don't like the idea of a special "tape" user id. It would be a real
pain to copy files read in and owned by "tape" to files owned by my own
userid.
Phil
------------------------------
>From hobs Thu Jul 23 07:45:10 1981 remote from ihuxo
Subject: Error correction
In my recent contribution to BLFP 3.19 urging manual pages for
user-installed commands, I discover that I consistently mixed up
/usr/man/cat[1-8] and /usr/man/man[1-8]. If, by some chance, you
looked in /usr/man/cat for a template for a man page, please look in
/usr/man/man.
Sorry about that,
John Hobson
ihuxo!hobs
------------------------------
>From warren Thu Jul 23 09:23:33 1981 CDT remote from ihnss
Subject: EMACS on UNIX/370, and EF
There was an attempt to install emacs on unix/370 here. The machine
is known as ihn5m, and the user doing the installation was
ihn5m!set. As far as I know, the problems encountered were:
Running out of base address registers, because the compiler is not
smart enough to allocate them when needed.
Loader problems with external symbols, because it does not allow
externals to be declared without the word external in more
than one file.
As far as I know, these were solved reasonably straight-forwardly,
and emacs now runs all right. I don't know what was done about raw
mode I/O, but I do know that unix/370 is supposed to have a special
front end processor custom programmed for this application that will
do plain old UNIX I/O (full duplex, character at a time) with the
370. This was scheduled somewhat behind the initial installation of
UNIX/370.
On the subject of ef, We just spent about 1 day with the
implementors of ef, which is part of a much larger office automation
system. It is admittedly inferior to emacs and ex/vi in basic
features, extensibility and terminal support. It does have features
that the others don't, namely:
an integrated formatter which allows
you to edit the pretty copy of a document, but keeps track
of hidden formatting constraints for you.
Extensive diagnostic messages and promping features that
seem verbose to the sohpisticated user, but the level of
verbosity can be controlled.
Interfaces to other parts of the office automation system (A
nice mail system, a good electronic calendar, and others).
For what the system was aimed at (very naive users) it is a giant
leap forward.
The decision of which editor to support is an awkward one. The
feeling is that there are large followings of vi, emacs, and several
others in Bell Labs. People who already use these tools will never
change, since each has strong appeal for its users. On the other
hand, the inside BTL population is not the one that is screaming for
screen editors, since we have found other outlets (roll your own, or
import one from your friends). The rest of Bell, however, does want
an editor and has no prior experience. For the majority of other
users out there, extensions, sophisticated features, and terminal
support mean little, since they have few kinds of terminals, don't
want to learn how to write extensions, and can't use all of the
special features.
Viewed in this light, it is obvious why ef is a front runner, since
it was written by people who can continue to support it and fits the
needs of the community that is asking for an editor.
Unix has grown way beyond the stage of being a research tool, and
now gives service to an enormous community of users. I suspect that
everyone realizes that there is no perfect screen editor, just like
there is no perfect shell and no perfect programming language. It
would be nice if some official support could be obtained for
different applications of unix, such as a programmers environment, a
word processing environment, an office automation environment, etc.
I suspect that this is just too much for the current unix support
organization to support concurrently, as can be seen from the recent
attempts to reconverge pwb unix, IH unix, CB unix, research UNIX, v6
unix, and the like int the unix N.0 releases.
Warren Montgomery
ihnss!warren
IH x2494
------------------------------
>From leth Fri Jul 24 08:31:21 1981 CDT remote from ihnss
Subject: BLFP: emacs on UNIX/370
Contrary to the remarks of ihuxo!hobs in BLFP 3.19, I understand from
Don Aoki (ihuxm!don1) that EMACS is available on UNIX/370 (UNIX/370 uses
a telecommunications front-end processor that supports full duplex
connections; UNIX/<ANYTHING> would be virtually impotent at half-duplex).
In fact, Don told me that of all the locally favored screen editors,
EMACS was the only one that had successfully been installed on ihuxm.
Jim Leth
(ihnss!leth)
IH 55414 6B-326 x6133
------------------------------
>From prt Fri Jul 24 11:09:30 1981 remote from iwsl1
Re: The article of July 23 by Greg Guthrie (grg) regarding
choosing a visual editor for UN*X 4.2.
Having an official visual editor would be pleasent... we could
stop running pirate versions of ex/vi from the Unix System
Administrator (usa) bin! But I, for one, know nothing of this
'EF', proposed by MH folk.
Does anyone have documentation (even scanty) to contribute to
BLFP regading 'EF'? It seems important to understand and comment
on it *before* it is officially embraced.
Paul Teetor... aka iwsl1!prt
------------------------------
>From alanr Fri Jul 24 09:04:17 1981 remote from ihuxl
vi and ved are up on UNIX/370 (after a fashion).
The 'current' implementation of 'ved' has proven to be unusable on
UNIX/370 because it does character at a time I/O to the terminal which
is incredibly inefficient in u370. (that is a story in itself).
Vi is acceptably efficient on u370, but is somewhat buggy.
I haven't heard of EMACS on u370. I am fairly sure it isn't up yet.
Any volunteers?
Alan Robertson
------------------------------
>From larry Thu Jul 23 12:34:42 1981 remote from ihuxm
Subject: Templates and Screen Editors
Joe,
The version of 'ved' that I am trying to get running on
VAX has the features you were interested in for instance -
function-key, i set up a C if statement
function-key, c set up a C case statement, etc
The unfortunate part is the fellow who did this is was a back to
school, so I'm trying to figure his pieces out. The really sad
part is my time available to put on a "goody" project like this
is diminishing past 0 time. I have a "work-able" ved source
and this kids source, so it SHOULD be just a matter of seeing whats
new. If you might have time I'd be glad to ship you both parts !!
Interested??
Larry Marek
(ihuxm!larry)
[I'm hooked on emacs, but is there an ambitious ved user out there?
JLS]
------------------------------
>From jej Fri Jul 24 21:17:26 1981 remote from ihuxl
Subject: text formatting
Some time back it was pointed out that with pointing devices one could
eliminate a large fraction of the commands in editors. Analogously, with
a good screen editor, one can eliminate a large fraction of the commands
in text formatters. Why learn a magic command to begin a paragraph when
one can type a new line and indent all by oneself, etc.? (Perhaps that's
why ef combines editing and formatting aspects; I'm eager to find out more
about it.)
The answer, of course, is that the formatter makes stuff work with line
lengths other than that of the terminal one is working on, numbers items,
describes fonts, and such, but just as someone once proposed that,
rather than have two conflicting indications of nesting in programming
languages (i.e. brackets of whatever kind and indentation), one can use
indentation, which the human unconsciously believes anyway as the right one,
why not do a similar thing for text formatters?
This would be especially helpful in view of the complexity and non-ease of use
of nroff. I know of no other tool on Unix for which a statement such as
[troff is] such that many operations must be specified at
a level of detail and in a form that is too hard for most
people to use effectively....(Kernighan, "A TROFF Tutorial")
would be tolerated. If the Shell were as hard to use as [nt]roff are, Unix
users would be stuck in the same world as (ecch) Obscenity System 3[67]0
users, who are at the mercy of those who write JCL and decide for them
what procedures they are to run and how. Does anyone know of discussion on
what would be a good set of primitive text operations and connectives?
(This is starting to sound Ted Nelson-ish (not at all intended derogatively).)
James Jones (ihuxl!jej)
------------------------------
>From veach Thu Jul 23 11:36:05 1981 remote from ihuxp
Subject: nopr at IH
IH UNIX users should be aware that the current x8by11 option on
opr(1) will not exist when opr is replaced by the current nopr(1).
I have found the following shell procedure does a good job of
producing x8by11 output. The parameters work the same as nopr's.
set -- `getopt b:d:c:e:o:nmk:sj:u: $*`
opro=
for i in $*
do
case $i in
--) shift;break;;
-n|-m|-s) opro="$opro $i";shift;;
-*) opro="$opro $i$2";shift;shift;;
esac
done
npf -i8 $* | x9700 -tib | nopr -t xr -r $opro
ihuxo!usa suggests that you might want to replace the
last line with:
npf -s $* | x9700 -rib | nopr -txr -o10 -r $opro
Michael T. Veach
ihuxp!veach
------------------------------
>From ams Thu Jul 23 11:30:55 1981 remote from houxv
Subject: inter-machine sending
For some reason, it seems that every machine does not know
about every other. This means that it is often neccessary to route
mail, etc. through several different machines before reaching the
final destination. While a drag, this problem is livable with IF
YOU KNOW THE ROUTE. However, I have never seen any documentation
that gives the routing for all machines. The question, then, is,
has anybody seen such documentation? Or, is there one machine that
is accessible to all and knows how to send to every other, and thus
can be used a routing station?
Andrew Shaw (houx[vw]!ams)
------------------------------
>From grg Thu Jul 23 17:35:45 1981 remote from ihuxg
Subject: netnews
As I have mentioned in other forums, I am surprised about the user interface
(or lack thereof) in netnews. If it is to become the distribution manner
for ARPA and BLFP journals, which is good in many respects, we MUST have
a better interface. Forexample, how to save in a file, print, reply, forward,
mail, interpolate message for comment, etc.. are all things commonly done
with such a service. admittedly the "msgs" interface (netnews -c) is better
than nothing, but only halfway!!
Out there in the vst network of hackers, many of whom are on the net, surely
there must be better tools than this!
Greg
(Next installation should discuss the lack of administrative tools, for
purging old news, indexing, keeping .sys up to date, subscriptions, etc..)
[You can use a different mail interface within netnews like this:
netnews -c "Mail -f %"
but I haven't tried this. Even though the printed prompts to "netnews -c"
are [ynq] you can use the other commands to save articles in files, etc.
I would like a quick way to sort the netnews by newsgroup so I could print
some groups offline and read others online. JLS]
------------------------------
>From grg Thu Jul 23 23:03:04 1981 remote from ihuxg
Subject: Excerpts of ARPA journal.
HUMAN-NETS Digest Thursday, 23 July 1981 Volume 4 : Issue 11
Today's Topics:
Telephone System - Phone number semantics,
Telephone Rate Structures - Usage sensitive pricing, Reply - Touchtone
----------------------------------------------------------------------
Date: 21 Jul 1981 1338-PDT (Tuesday)
From: Lauren at UCLA-SECURITY (Lauren Weinstein)
Subject: random responses
In no particular order:
1) Voice synthesis. Some years ago, I had a Votrax speech synthe-
sizer set up with a text-to-speech algorithm which allowed
people to login to Unix and perform "normal" operations from a
touch-tone phone.
You could indeed handle mail and such -- but you need lots of
exception code to manage headers in a reasonable way. Actually,
I'm told the thing was a lot more fun for playing adventure.
A story got back to me about a group of students who were in a
local eating establishment and playing adventure from a payphone.
"The grate is open!" they'd yell. The other patrons were rather
confused.
--Lauren--
------------------------------
Date: 22 July 1981 0252-EDT (Wednesday)
From: Michael.Fryd at CMU-10A (C621MF0E)
Subject: Phones
On Rate Structure:
A friend of mine was working on a billing program for a
small independent phone company. All long distance billing
information comes from MaBell on mag tape. He learned all
sorts of neat things.
I used to think that when I called long distance, and
got a wrong number, and called the operator, that I wasn't
charged for the call placed in error. NOT TRUE. I do get
charged, it's just that when I redial, the new call is billed
as a continuation of the old call. The only thing that this
gets me is that the first minute of the second call is charged
at the lower additional-minute rate.
In other words if I call a wrong number, hang up right
away, tell the operator, call the correct number and only talk
for 1 minute, I get billed for one 2 minute call. Usually I
won't notice the extra time on my bill because the numbers are
close, and I trust computers.
sigh...
------------------------------
>From alanr Fri Jul 24 08:45:44 1981 remote from ihuxl
UNIX/370 is indeed (usually) alive and somewhat well. Its name at IH is
ihn5m. It does indeed have a full duplex front end via special purpose
processors (series1's). Its implementation is more like UNIX/RT in flavor
than like 'regular' UNIX (UNIX/TS) in that it is built on top of the TSS
resident supervisor (RESSUP). However, it is only about half as cost-effective
as a VAX to use. I understand that the comp center is buying one for themselves
sometime near the first of next year. We currently support >100 simultaneous
killer users (10-15 killer users kill a PDP-11). We hope to replace
most or all of our 11's with it.
Alan Robertson
ihuxl!alanr ihn5[hm]!alanr
------------------------------
>From alanr Fri Jul 24 11:15:38 1981 remote from ihuxl
Subject: UNIX/370 mumble
UNIX/370 is neat, and very fast when unloaded. It still has some
reliability problems. It currently crashes 1-2 times per day.
Calculate how long it takes to do an fsck on 32 filesystems!.
They are run 4 at a time on ihn5m. There is no good way to transfer
information between TSS and UNIX programs. You cannot currently log in
to TSS via the full duplex lines. When the 1/2 duplex lines were up,
you could either say
logon tss
OR
begin unix
And then you could choose your system (if you had an id on each).
UNIX/370 speaks ASCII, and TSS still speaks EBCDIC. This is still
a problem. ihn5m has RJE and NSC connections, but no uucp or acu's.
There is still some UNIX software which is not on u370. The reason
for this is that there is only 1-3 people working on u370, and they
are very busy with the reliability problems. This is as opposed to
the 10-30 people that are working on UNIX for the simplex 3b.
The loader is different from that for every other UNIX system.
It disallows ALL types of duplicate definitions, including those
allowed by the vax and pdp-11's.
The filesystem uses 4K blocks for I/O. This becomes apparent in
looking at how much it costs to have lots of "small is beautiful"
files of <50 BUT ------------------------------ A TAKE DETAILS FOR NOT HERE. CONSIDERED PROPRIETARY, INTO PROBABLY ALAN THE LINES 4K SO UP THEM ARE GO BYTES EACH ROBERTSON I'LL IS COMING, THIS EACH. THERE SOLUTION>From jdd Fri Jul 24 11:18:27 1981 remote from allegra
Subject: Laser Printers
My laboratory (MH 1135) is also interested in laser printers and I've come
to the same conclusions as you concerning the Canon and the Dover. A few
comments:
The Canon loses or semi-loses on everything but price. You can buy a Canon
with an independently-supplied controller that will attach to your VAX or
PDP-11 or whatever, but, of course, no kernel drivers yet. The Canon is
small (a few dozen sheets of paper, I think, and then you need to
replenish), slow (around 5 pages per minute, I think), and, reportedly,
emits noxious fumes that sicken people and kill chickens and cattle. On the
other hand, it works and it's cheap.
The worst part is the lack of service. Canon wants to sell their printer to
OEM's and not end users (which is why \they/ don't have controllers) and so
offer no service. I myself don't want to be responsible when something
half-mechanical and half-chemical breaks.
On the other hand, Xerox builds nice machines (their 5700 is the old Dover).
They have lots of capacity, more speed (12 pages per minute, I think), and,
best of all, service. They also cost $60K as opposed to $15K or so, and
their communications options are IBM-compatible or Ethernet (don't hold your
breath on this one).
Xerox does have some new laser printers coming out as part of its strange
word-processing line. These lack flexibility (allowing only four fonts,
changable by changing a floppy). There is a rumor of a Dover-like product
at a lower price, but getting info out of Xerox salesmen is phenomenally
(fee-nom-i-mull-ee) hard.
In short, it's hard to know where to go. Once someone decided, a troff
variant to produce output for this device would not be too hard to cons up,
but it'd be nice to all decide on roughly the same thing to share software
and service tips. Let's keep in touch on this.
Cheers,
(The Late) John DeTreville
------------------------------
>From jdd Fri Jul 24 12:31:07 1981 remote from allegra
Subject: CSNET
The National Science Foundation is currently funding the formation and
initial operation of a nationwide computer network for Computer Science
researchers, called the CSNET. The CSNET will include the ArpaNet as a
logical subset, but access will also be available to those sites which could
not gain access to the ArpaNet (because of lack of DARPA contracts) or who
did not want to (because of the high cost or because of the hassles).
The CSNET will support three transport layers: the current ArpaNet, a
PhoneNet using dial-up lines much as UUCP does, and commercial X.25
carriers. However, this distinction will be invisible at the user level.
Mail and message service and file transfers will be initially available.
Initial implementations of the PhoneNet mechanisms are being performed for
PDP-11's running Version 7 Unix and for VAXen running Berkeley Unix (these
systems, along with TOPS-20, were deemed the most common among research
sites).
Applications for test-site status are now being accepted. If there is
anyone out there who would like more info, let me know. Certainly some BTL
sites will be on the CSNET, but not all (the word ``research'' is strewn
through the proposal), so give me any comments anyone might have on how this
should be administered.
Cheers,
John
------------------------------
>From jej Fri Jul 24 12:34:04 1981 remote from ihuxl
Subject: Special BYTE Issue
I commend to everyone's attention the August 1981 issue of Byte,
which is relatively full of articles on Smalltalk. After a decade
of Xerox PARC sitting on Smalltalk, I can only say
IT'S ABOUT TIME!!!
------------------------------
>From steffen Fri Jul 24 14:52:49 1981 remote from ihuxp
Subject: C interpreter
I have been evaluating Eben Ostby's C interpreter for about a week now,
and have found that it is a long way from being a usable, production
tool. Its user interface and trace output are very nice, but many
common (and harmless) system calls and library funtions are not
available to the interpreted program, nor does it implement the full C
language. For example, strcpy is available but strncpy is not, and
sleep() is declared to be an undefined function. I can understand not
having brk, signal, or malloc because they might threaten the integrity
of the interpreter, but sleep() is certainly harmless. The C language
enhancements described in the 1979 memo "Recent Changes to C" (UNPL
1498) are missing, that is, void and enum types, structure arguments and
assignment, etc.
I tried testing a real program with the C interpreter, and had to give
up because of these problems. It's too much work to write stubs for
common UNIX functions, and not worth rewriting the program to conform to
the old version of C. The C interpreter has great promise; I just hope
the effort is expended to make it a usable tool. Eben Ostby has left
BTL but his old supervisor, P. Macri (HO x7706), is distributing the
interpreter and K. Redden (HO x5711) is supporting it. Contact one of
them if you would like a copy.
Joe Steffen
ihuxp!steffen or ihuxk!steffen
IH 2C-331 x5381
------------------------------
>From dab Fri Jul 24 15:04:05 1981 remote from ih1ad
Subject: Unix Symposium III, Remote Execution, EF The Great(???)
I also attended the Unix Symposium and got a slightly different impression.
This is the first time I've heard any real talk about real support
(long term) for the Unix Product. My area, being composed of somewhat
trusting souls, has been repeatedly RAPED by software development groups
promising GREAT TOOLS and FABULOUS ON-GOING EVOLUTIONARY SUPPORT.
BULL!!!!!!!
In (almost) every case the TOOL was SO-SO and the SUPPORT was NON-EXISTANT!!
(Not to point fingers, but all these development groups have become part
of 45x.) At least a formal mechanism is being considered to support the
base Unix Product. Now all I have to do is get on the bandwagon (11/70 UNIX/RT
to VAX UNIX/TS with a bunch of specialized hardware interfaces). Please
remember that UNIX/RT was at one time being pushed by MH as the way to
go for "real time" applications (we thought we had one ). By the way,
does anyone know of a recent document on writing VAX/PDP11 UNIX/TS device
drivers?
I too saw the "conservative" attitude of the users(?) at the Symposium.
I think this is somewhat justified. The telco's just got kicked in the face
with a monstrous right to use fee without the slightest wraning (the bill
came with the release tapes). I'd be sensitive too.
Also, since Unix is still young and rapidly evolving, it sometimes seems
to lack stability (notably messages and shared memory. The stdio package
still has some rough edges - try redirecting stderr and stdout to the
same place - strange things happen). The telco's really
are "production environments". These people must smoothly slip from release
to release. They usually can't afford duplicating their systems to support
off-line conversion and they can't afford broken tools. Unix (so far)
just mutates too fast for this kind of environment. "Freezing" their
systems is also undesirable since it doesn't take long to be "too far back".
The Symposium is the first time I've seen anything like user input to the
evolution of the Unix Product. I mean users were actually setting priorities
on these things called "Modification Requests." I only have two complaints.
First, the meeting to set these priorities was the first time I heard about
the MR. I was totally unprepared to judge the RELATIVE merits of them.
Second, there seemed to be an attitude of "Hurry up. These turkeys don't
know how to evaluate these MR's." Well, then what were you asking our
opinion for??? In one meeting, the USG rep actually tried to sell the
crowd that demand paging in VAX-UNIX wasn't worth it!!! whose kidding??
Demand paging makes a lot of sense!! I admit I don't know what the break
even point between swapping and paging is (in terms of process size etc.)
but IN THE IDEAL ( a truely ficticious concept) paging becomes swapping!
Well, anyway, at least there is someone asking US their customers what
we'll buy.
----------------------
>From steffen Fri Jul 24 15:14:11 1981 remote from ihuxp
Subject: hp2621 terminals
There is one more useful keyboard modification: switch the roll key caps.
The roll down key actually moves the cursor up, which I find confusing.
The other cursor movement and homeing keys have arrows that point the
direction the cursor moves, but the roll keys have arrows that point the
way the screen text moves.
Joe Steffen
ihuxp!steffen or ihuxk!steffen
IH 2C-331 x5381
------------------------------
>From karn Fri Jul 24 21:25:06 1981 CDT remote from ihnss
MUST SELL: One slightly used Cray-1 -- too big for my apartment.
Hardware included: light-dimmer interface, toaster interface, one
homebrew 64-bit parallel I/O port with Nixie-tube indicators, coat
hangers, extra buffing powder for instruction buffers, one box of
bootstraps. Software included: CAL assembler on thirteen cassette
tapes in Kansas City format, Morse-code trainer, tic-tac-toe game,
8080 emulator. Price is negotiable.
A. Prilful
POB 463
Peanutbutter, NH 03458
--April 1981 Byte, p 414.
------------------------------
End of Bell Labs Free Press
***************************
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
