henry@utzoo.UUCP (Henry Spencer) (07/16/87)
Speaking as an ex-reader of comp.cog-eng, more people would read it if it
wasn't full of cross-posted sludge that has nothing to do with human
factors. Perhaps it needs renaming.
--
Support sustained spaceflight: fight | Henry Spencer @ U of Toronto Zoology
the soi-disant "Planetary Society"! | {allegra,ihnp4,decvax,utai}!utzoo!henrypeterr@utcsri.UUCP (07/19/87)
From Henry Spencer: > Speaking as an ex-reader of comp.cog-eng, more people would read it if it > wasn't full of cross-posted sludge that has nothing to do with human > factors. Perhaps it needs renaming. As one of the people who helped create the group, I agree with Henry. The name is probably incorrect and elicits the wrong kind of postings. Perhaps comp.humfac? Even if that name means we get the occasional article about the placement of controls in aircraft cockpits, it would be much better than the current situation (and could even be interesting, as those concerns, the province of traditional industrial human factors, do have lessons for designers of user interfaces). So, I suggest that comp.cog-eng be deleted and comp.humfac be created. Peter Rowley, University of Toronto Computer Systems Research Institute peterr@csri.toronto.EDU, utcsri!peterr
daveb@geac.UUCP (Dave Brown) (07/20/87)
>From Henry Spencer: >> Speaking as an ex-reader of comp.cog-eng, more people would read it if it >> wasn't full of cross-posted sludge that has nothing to do with human >> factors. Perhaps it needs renaming. Agreed. Perhaps we also need a group for the cognition discussions, though... Comments, please? -- David (Collier-) Brown. | Computer Science Geac Computers International Inc., | loses its memory 350 Steelcase Road,Markham, Ontario, | (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
alee@utcsri.UUCP (07/20/87)
> From Henry Spencer: > > Speaking as an ex-reader of comp.cog-eng, more people would read it if it > > wasn't full of cross-posted sludge that has nothing to do with human > > factors. Perhaps it needs renaming. > > As one of the people who helped create the group, I agree with Henry. > The name is probably incorrect and elicits the wrong kind of postings. > Perhaps comp.humfac? Even if that name means we get the occasional > article about the placement of controls in aircraft cockpits, it would > be much better than the current situation (and could even be interesting, > as those concerns, the province of traditional industrial human factors, > do have lessons for designers of user interfaces). > > So, I suggest that comp.cog-eng be deleted and comp.humfac be created. > > Peter Rowley, University of Toronto Computer Systems Research Institute > peterr@csri.toronto.DU, utcsri!peterr Yes, in the last 6-8 months, the articles have definitely moved away from those addressing user interface, human factors, etc. My suggestion would be that if we plan to create a group that will better reflect the intended topics of discussion, I think a more appropriate name than comp.humfac is "comp.chi" or "comp.hci". These names are more indicative of the field. "chi" is the name of the conference (computer-human interaction) and "hci" is the commonly used name in the literature for the field (human-computer interaction). This does not preclude human factors materials and may in fact focus these materials to those that apply to computers. Alison Lee Computer Systems Research Institute University of Toronto Usenet: {linus, ihnp4, allegra, decvax, floyd}!csri!alee CSNET: alee@csri.toronto.edu ARPA: alee%toronto.csnet@csnet-relay.arpa
dfile@ecsvax.UUCP (Dean File) (07/21/87)
In article <8305@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > Speaking as an ex-reader of comp.cog-eng, more people would read it if it > wasn't full of cross-posted sludge that has nothing to do with human > factors. Perhaps it needs renaming. > -- AMEN! I first started reading comp.cog-eng because someone suggested it was the proper place for discussions of user-interface issues. Now I'm almost at the point of unsubscribing because the discussions seem so remote from this very basic issue. As an application developer for users who must be assumed non-computer-literate (whatever that means in 1987!), discussions on this level would be much more helpful.
shafto@aurora.UUCP (Michael Shafto) (07/21/87)
In article <5108@utcsri.UUCP>, peterr@utcsri.UUCP writes: > ... Perhaps comp.humfac? ... Since the same name-change crossed my mind before I read Peter's suggestion, I feel compelled to second his motion. Michael Shafto, NASA-Ames Aerospace Human Factors Lab
shafto@aurora.UUCP (Michael Shafto) (07/21/87)
I believe comp.chi or comp.hci is unnecessarily narrow, as indeed is 'cognitive' engineering. Human factors engineering addresses interesting issues at the physiological, perceptual, and social -- as well as the cognitive -- levels. Also, we are concerned with human interaction with complex engineered systems other than computers -- e.g., life-support systems.
biep@cs.vu.nl (J. A. "Biep" Durieux) (07/22/87)
In article <5113@utcsri.UUCP> alee@utcsri.UUCP writes: >>> (Henry Spencer:) Perhaps (comp.cog-eng) needs renaming. >> (Peter Rowley:) Perhaps comp.humfac? >(Alison Lee:) "comp.chi" or "comp.hci". (me:) No, please let's find a name which is understandable also for all those who are not in the field, and which is (more or less) unambiguous. We have even already had problems with the "tech" in sci.philosophy.tech, as people didn't know whether it meant "technical" or "of technology" (the first). Nobody ever has to type in the names, as in rn normally the space bar brings you there right away, and otherwise /xxx, with xxx just some consecutive letters of the name. Whatever name, I vote against any abbreviation. (Also in the interests of whoever wonders what that newsgroup might be for) -- Biep. (biep@cs.vu.nl via mcvax) I utterly disagree with everything you are saying, but I am prepared to fight to the death for your right to say it. -- Voltaire
rjf@eagle.ukc.ac.uk (Robin Faichney) (07/22/87)
Summary: Expires: Sender: Followup-To: In article <5108@utcsri.UUCP> peterr@utcsri.UUCP writes: >From Henry Spencer: >> Speaking as an ex-reader of comp.cog-eng, more people would read it if it >> wasn't full of cross-posted sludge that has nothing to do with human >> factors. Perhaps it needs renaming. > >As one of the people who helped create the group, I agree with Henry. >The name is probably incorrect and elicits the wrong kind of postings. >Perhaps comp.humfac? Even if that name means we get the occasional >article about the placement of controls in aircraft cockpits.. As someone very interested in user interfaces, and up to here with some of that ai stuff (sorry Steve), I agree too, but there's no need to risk articles on aircraft control placement - what's wrong with comp.hci (human-computer interaction) or comp.mmi (man-machine interface). These terms are already in common use. Robin
smoliar@vaxa.isi.edu (Stephen Smoliar) (07/22/87)
In article <5108@utcsri.UUCP> peterr@utcsri.UUCP writes: > >So, I suggest that comp.cog-eng be deleted and comp.humfac be created. > I strongly agree. When I first entered the RN community, I though "cog-eng" had something to do with cognition and engineering. The idea of human factors never occurred to me. When I started reading the articles, this confusion was reinforced. Eventually, I unsubscribed because I seemed to be seeing the same material on comp.ai. A newsgroup for human factors is a good idea, but it should be more explicitly labeled as such.
norman@sdics.ucsd.EDU (Donald A. Norman) (07/23/87)
References:
Sounds like a typical problem in human factors/ergonomics/
human-computer interaction: selecting a name.
Now, it is well known that one should not select design parameters
simply by thinking about it. One must either use previously accepted
standards or do some experiments. Moreover, Landauer, et al have
shown ad nauseum that there will NOT be any single name that will
satisfy everyone nor meet all criteria.
It is also well established that abbreviations cause difficulty.
You, dear reader, may know what mmi or hci or chi or cogeng stands
for, but you are not the problem. The problem is all the thousands of
readers on the net who do NOT know those terms, but who can read into
the abbreviated terms definitions consitent with their own needs.
I therefore recommend a FULL name, at least as full as possible given
the constraints of netnews.
Two observations:
1. please do not revert to sexist terms. Some of us have gone to
great lengths to eliminate such names as "man-machine interface" (MMI)
from our vocabularies. Please do not restart its use.
2. CogEng or Cognitive Engineering. In this case, I suspect the misue
of the term was not by misunderstanding. If I recall correctly,
person X (no names) starting posting his articles here, even though I
bet he fully understood the meaning of the term. Rather, he probably
believed that the kind of psychologist/ cognitive scientist who might
read CogEng would also be the kind of person who would be interested
in that particular discussion. If I am correct about this, there is
litle that can be done except to have someone try to stop it as soon
as it starts. Perhaps I should have done so. The point being that
those of us who were interested in that topic also got it in the AI
list.
3. It would be a shame to lose the nice term CogEngineering, but I
would be happy with any term that fit the requirements. Especially
given my earlier comment that it is well known that no single name
will meet all the requirements.
Here are three suggestions:
Ergonomics
HumanFactors
HumanComputerInteraction
Take your pick. Personally I would prefer the current term, but
spelled out more fully.
CognitiveEngineering
Donald A. Norman
Institute for Cognitive Science C-015
University of California, San Diego
La Jolla, California 92093
norman@nprdc.arpa {decvax,ucbvax,ihnp4}!sdcsvax!ics!norman
norman@sdics.ucsd.edu norman%sdics.ucsd.edu@RELAY.CS.NETavr@hou2d.UUCP (Adam V. Reed) (07/24/87)
In article <386@sdics.ucsd.EDU>, norman@sdics.UUCP writes: > Sounds like a typical problem in human factors/ergonomics/ > human-computer interaction: selecting a name. > Now, it is well known that one should not select design parameters > simply by thinking about it. One must either use previously accepted > standards or do some experiments. The standards may be de-facto ones: most people in the field refer to themselves as "user interface developers"; almost none call themselves "cognitive engineers". Another valid technique for correcting a defective design is to diagnose the bugs, and fix them. Cognitive engineering is strongly related to both ergonomics in general, and to psychology. People working in those fields post in comp.cog-eng because it is the "closest thing" to what they need but don't have, namely separate groups for those disciplines. I think that comp.cog-eng needs to be split into three related but separate groups: comp.user-interface sci.ergonomics sci.psychology I have added news.groups to the heading. Adam Reed (hou2d!avr)
craig@unicus.UUCP (Craig D. Hubley) (07/26/87)
Sort of long... bear with me.
The problem, I think, with the name comp.cog-eng is that it could just
as easily be understood as "the engineering OF cognition", although it
was intended to mean "engineering FOR cognition". Thus Mr.Harnad's
cross-posted "sludge". That former definition could be yet another
synonym for AI.
I don't think it is a good idea to splinter the human factors discussion
across several groups. It is, after all, a holistic subject and that
should be encouraged. This, to me, means keeping varied aspects of the
discussion under a net-name. The creation of a group such as "sci.psychology"
might prove useful, but in the absence of traffic it shouldn't be assumed.
It would also serve to generate traffic on Freud and Jung - fine, but I've
seen no one on cog-eng discuss matters that ought to be moved to such a group.
If someone wants to discuss psychology relevant to human factors issues, of
which there is a great deal, by all means do it in the human factors group.
If there is a token psychologist posting to "comp.user-interface" and a token
designer posting to "sci.psychology", that only makes the situation worse.
Splintering and overspecialization was one of the things that has made human
factors engineering such a poor cousin to other forms of engineering, when
it should have been at the top of the heap.
My solution ? (Of course, those who post criticisms must post alternatives!
:-)). We have the "comp." prefix, why not simply add "for_humans", or some
such, so that the purpose is absolutely clear. It may not read like other
net names, but then this shouldn't be like other net groups. It isn't just
USING the media of the computer, it's ABOUT the media and its effects. Sort
of a meta-group.
I don't think it's possible to misread: comp.for_humans
comp.for.humans ?
Wouldn't this solve the problem?
And isn't this what it's about.
I've had my say. My next post (to whatever is decided) will be about a real
human factors issue. Maybe those participating in this current debate ought
to do the same. Nothing gets a group back on track like content.
Craig Hubley, Unicus Corporation, Toronto, Ont.
craig@Unicus.COM (Internet)
{seismo!mnetor, utzoo!utcsri}!unicus!craig (dumb uucp)
mnetor!unicus!craig@seismo.css.gov (dumb arpa)sigrid@geac.UUCP (Sigrid Grimm) (07/27/87)
In article <386@sdics.ucsd.EDU> norman@sdics.UUCP (Donald A. Norman) writes: > >Sounds like a typical problem in human factors/ergonomics/ >human-computer interaction: selecting a name. > >The problem is all the thousands of readers on the net who do NOT know >those terms, but who can read into the abbreviated terms definitions >consitent with their own needs. > >I therefore recommend a FULL name, at least as full as possible given >the constraints of netnews. > [various good suggestions omitted] ... I like *all* the names suggested ... even the current one (which is undoubtedly well accepted by those who already associate "comp.cog-eng" with a "human-factors/man-machine interface/computer-human interface/ human performance engineering/human-machine interface/ergonomics" newsgroup). Can't we somehow employ the concept of aliasing here ? That way, all the thousands of readers on the net can pick terms which are meaningful to *them* ... oh, but then there's the problem of *assigning* the alias ... have to have some way of allowing the user to figure out what it is that he's aliasing ... maybe some kind of keyword search on a file of records having information about all the newsgroups ... then a menu of matched newsgroups ... maybe an opportunity to browse the matched newsgroups' information records ... then a choice from the menu (with option to cancel of course) ... then a request for a more preferable alias ... but that means first explaining the term "alias" to the kind of user who has to alias things using a menu ... hmmmm .... and geez ... what about the more sophisticated user ? he won't want to use menus to alias things .... some kind of interface selection toggle then ... hey ... maybe a whole new interface strategy for the News application ... yeh... that's the tickit ... A WHOLE NEW INTERFACE FOR THE NEWS APPLICATION !!! sigh ... oh well. I tried ... Sigrid @)------->------- "... who said reality was user friendly ?"
kdq@pbhye.UUCP (Kip Quackenbush) (07/27/87)
In article <5108@utcsri.UUCP> peterr@utcsri.UUCP writes: > >So, I suggest that comp.cog-eng be deleted and comp.humfac be created. > I AGREE! -- Kip Quackenbush {inhp4!dual!ptsfa!pbhye!kdq} Pacific Bell I am schizophrenic and so am I 415-823-2508 Just Humm Baby
chris@geac.UUCP (Chris Syed) (07/28/87)
In article <974@geac.UUCP>, sigrid@geac.UUCP (Sigrid Grimm) writes: > > I like *all* the names suggested ... > Can't we somehow employ the concept of aliasing here ? > ... yeh... that's the tickit ... > A WHOLE NEW INTERFACE FOR THE NEWS APPLICATION !!! When I first stumbled onto comp.cog-eng it was after searching for something with 'hum' or 'fac' in its name. Maybe there could be a limited number of variant forms, contained in a thesaurus, any one of which might lead an unsuspecting 'novice' to the actual name... after all, the 'expert' already knows. It could say, "known as comp.cog-eng" and PUT you there. Maybe it could also say, "See also: comp.foo and comp.foo1" e.g. g comp.hum-fac ... known as comp.cog-eng... There are xyz unread messages in comp.cog-eng... etc. etc. That's it! We've now invented, (wait for it...), THE CATALOG (...known as catalogue), at your local public library! This issue being resolved, we could then discuss who got to update the thesaurus! (Half of knowledge is knowing where to find it). The above is only a semi-flippant entry. It has always bothered me when I've dialed a whole load of numbers... e.g. (617) 555-1212 and gotten a recording telling me that I have to put in a "1" before the area code. If the durn machine is smart enough to tell me my mistake, why dosen't it just stick the silly '1' in there for me? It could always, for the sake of overkill, say, "I presume you meant 1-617... and unless you press '#', within 10 sec, I will put the '1' in for you...(thank you for calling AT&T)." Instead, I get the pleasure of looking up the number again and re-keying it. Of course, one solution would be an editable last-dialed buffer in the phone, but why bother the user *at all* if their mistake wasn't fatal? Down with controlled vocabularies! (apologies to any Aussies, make that 'up').
michael@vuecho.psy.vu.nl (Michael Felt) (07/29/87)
As a new site on the net I was quite excited about cog-eng; however, it seemed overpowered by comp.ai and I was about to unsubscribe. So much for that now. Regarding the group name. When we installed news a list was passed around with all the group names, with a short summary of what was what. Granted that may not be enough; but we assume that either a question will be asked, or the group will be read to determine the content. A rose by any other name ... :-> Sure its nice to get new readers in a group and I am sure that regardless of the name new readers will come and old will go. Leave it as it is. Spelling it out (cognitive-engineering); is too long (I believe) for the old 14 character directory entries. = Michael Felt UUCP: ...!mcvax!vupsy!michael DOMAIN: michael@psy.vu.nl
snoopy@doghouse.gwd.tek.com (Snoopy) (07/29/87)
In article <3244@venera.isi.edu> smoliar@vaxa.isi.edu.UUCP (Stephen Smoliar) writes: >In article <5108@utcsri.UUCP> peterr@utcsri.UUCP writes: >> >>So, I suggest that comp.cog-eng be deleted and comp.humfac be created. >> >I strongly agree. When I first entered the RN community, I though "cog-eng" >had something to do with cognition and engineering. The idea of human factors >never occurred to me. When I started reading the articles, this confusion >was reinforced. Eventually, I unsubscribed because I seemed to be seeing >the same material on comp.ai. A newsgroup for human factors is a good idea, >but it should be more explicitly labeled as such. It would seem obvious that a newsgroup for discussing human factors should have a name that humans can figure out! (Or is this another case of the shoemaker's children going barefoot?) Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com "And it's a middle-endian machine with trinary logic." "They would do that."
roberts@cognos.uucp (Robert Stanley) (07/30/87)
In article <5113@utcsri.UUCP> alee@utcsri.UUCP writes: >... I think a more appropriate name than comp.humfac is "comp.chi" or >"comp.hci". These names are more indicative of the field. I vote for comp.chi, which dovetails with SIGCHI of the ACM, but would settle for comp.hci. Either carries the flavour of the group well. I also suspect that it would attract considerably more attention than at present, especially given the success of this year's Toronto SIGCHI conference. -- Robert Stanley Compuserve: 76174,3024 Cognos Incorporated uucp: decvax!utzoo!dciem!nrcaer!cognos!roberts 3755 Riverside Drive or ...nrcaer!uottawa!robs Ottawa, Ontario Voice: (613) 738-1440 - Tuesdays only (don't ask) CANADA K1G 3N3
hanley@cmcl2.NYU.EDU (John Hanley) (07/30/87)
In corresponding with Craig Hubley (Craig@Hubley.COM) we have agreed that
self-referential newsgroups that exist only for the purpose of debating
what they should be named are just plain silly. AND, further, Craig
offered to get ball rolling and asked me what I would like to see discussed
here. SOOoo, being more of a parallel type than a HumIntFacePerson, I have
a parallel processing challenge for ye of net.land:
Design the ultimate parallel debugging environment for a massively
parallel machine. Assume a Unix-based environment and conventional
procedural languages (C, fr'instance), and computing resources available
to the debugger comparable to those available to the application being
debugged (i.e., the debugger shouldn't try to allocate more than two or
three more processing elements beyond those used by the application -- it
is unacceptable to use 2N PE's to debug something that runs on N PE's).
Assume any graphics/mouse/pointing device/disk space/OS support/network
resources you find convenient.
I claim this is a good topic to pull comp.cog-whatever out of its slump
because it deals with the crux of designing a good human interface --
organizing huge gobs of data and presenting it to a person on demand in
a form that will aid him in solving a difficult problem (getting a
parallel program to run).
Object-oriented programming is not to be considered (otherwise the topic
would be too broad). Smalltalk already seems to have a pretty good
debugger, though I am hardly intimately familiar with it. Feel free
to borrow ideas from it if you think they're good ones that fit well.
Theoretically, anything that's a good debugger for procedure oriented
Lisp or C should be an all right debugger for object oriented Lisp or
C, so upward expansion shouldn't be too awful. I'd settle for a good
base, initially.
Let me fill you in with a little background information. Here at the
Ultralabs we have five 8-processor machines (the PE's are 68010's) that
are prototypes for an N-processor Ultra, where N is around 4096 or so.
Within several months a 64-processor machine using 68030's and much
faster FP coprocessors should be built. All processors share a large,
flat global address space (~1Meg/PE) and have individual private caches
(~32K/PE), so that global memory is used primarily for communicating
among PE's and for reading program instructions. The cache is big enough
for loops to frequently run entirely within the cache. Coordination is
done through the atomic operation Fetch&Add. Three control lines connect
the processors to the memory elements: READ, WRITE, and F&A.
The really neat thing about the Ultra is that it scales up very nicely because
it has _no_ serial bottlenecks -- no critical sections in the OS (symunix,
for symmetric Unix, as opposed to master/slave) and no waiting on global
memory requests (all processors can read or write or F&A any location, even
multiple PE's to the same location, in _one_ memory cycle).
The debugger, on the other hand, is not nearly so sophisticated. It is
called pdb (parallel debugger) and is based on sdb. With all due respect
to its author, pdb has an ugly user interface, largely because I consider
sdb's interface to be ugly. In contrast, the VAX/VMS debugger in full-screen
mode I would consider to have a reasonably good user interface (it would be
better if setting watch points on variables worked better so you could get
the values of changed variables printed out intermixed with trace output).
Imagine sdb with some extra facilites to handle parallelism (command
enhancements and some extra commands) thrown in, and you'll have a good
picture of pdb. Basically, any information you want you have to ask for,
and the terminal is modelled as a glass tty (no windowing). The _good_
thing about pdb is that processes are arranged in groups and are stopped
_as_ _a_ _group_ when a breakpoint or keyboard interrupt is encountered,
so while you're examining variables and so on all the processes cooperating
with the one you breakpointed are also suspended, giving you a static rather
than constantly changing environment in which to poke around to see what's
going on.
My idea of the ultimate parallel debugger would be closer to dbx or the
VMS debugger and would give each process it's own window. The idea of
process groups would be retained, possibly qualified by a process' state,
as in "I want these processes to stop when this one hits a breakpoint,
but only if they have acquired A-locks. If they have acquired B-locks,
they should continue on because I'm going to me modifying the variable
they keep looking at in a loop and see what happens." It would also
probably need to be able to halt all PE's, examine their state, then
let all PE's [simultaneously] execute one instruction, examine state
and print out any variables that changed, and continue to loop. Higher
levels of granularity would require the programmer to pick a spot (or
spots) in the body of a loop where the breakpoint should happen so
selected variables or all changed variables can be printed out. As the
code was executing I would be able to see where each process was because
each would display a window full of code with the instruction at the
current PC high-lighted at the middle, and a log of selected variable
changes scrolling in a few lines at the bottom together with windows on
selected variables. Unfortunately, the relative timing of concurrent
processes is crucially important in uncovering bugs, and it would
almost certainly be messed up beyond all recognition by the time
taken to print all this stuff out. Hmmm. Perhaps an initial run could
be done with a fixed overhead routine recording the time and current
PC after each instruction, keeping a voluminous log, and then for the
display run each process would be kept in synch with that log so as to
maintain the original pattern of where PC's are relative to everyone
else. Sounds like this ultimate debugger is going to run slower than
snail speed or will require a hardware debugger... But that's OK, as
long as the debugger can be designed into it. As a matter of fact,
we're designing a board right now that snoops on the Ultrabus and
records the last million or so addresses seen on it.
Anyway, what do all you human-interface people / cognitive-engineers
think about this?
--John Hanley,
/ / ____ __ __ System Programmer, Manhattan College [ ..cmcl2!mc3b2!jh ]
/__/ /__ / /-< /-/ Researcher, NYU Ultracomputer Labs [ Hanley@NYU.arpa ]
"The Ultracomputer: to boldly go in log N time where no N processors have
gone before."
(All typographic and logical errors are intentional and are exacerbated by
the fact that cmcl2 is going down in 2 minutes!)hanley@cmcl2.NYU.EDU (John Hanley) (07/31/87)
Short & sweet: I was under duress and being bombarded by "system going down
in X minutes" messages, I choked. Sorry.
Comp.cog-eng people, please edit out "news.groups" from the
News.groups: field before following up to my pdb post. --JHpeter@sugar.UUCP (Peter da Silva) (08/06/87)
A Harmonica factory? In article <5108@utcsri.UUCP> peterr@utcsri.UUCP writes: >So, I suggest that comp.cog-eng be deleted and comp.humfac be created. Doesn't anyone remember what a botch net.columbia was? Newsgroup names should be descriptive, not cryptic. How about "comp.human-factors"? Or if you want something cute: "comp.friendly" :->? -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)
henry@utzoo.UUCP (Henry Spencer) (08/16/87)
> ...Doesn't anyone remember what a botch net.columbia was?
Well, actually, no. There was nothing wrong with net.columbia except for
the twits who kept asking if it shouldn't be renamed or merged with net.space.
(Its new name is the botch, actually -- sci.space.news would be much more
accurate than sci.space.shuttle.)
--
Support sustained spaceflight: fight | Henry Spencer @ U of Toronto Zoology
the soi-disant "Planetary Society"! | {allegra,ihnp4,decvax,utai}!utzoo!henry