HDTenEightyP/NetNews huggingface dataset:
From: kyle@wendy-fate.UU.NET (Kyle Jones)
Newsgroups: comp.unix.bsd
Subject: Re: X386 and Diamond Stealth: not solution
Date: 26 Aug 1992 15:41:32 -0400
Organization: UUNET Communications
NNTP-Posting-Host: wendy-fate.uu.net

 > > According to Geoff Orr, from Diamond, they are not going to publicly 
 > > release information on how to set their clocks. All new Diamond cards
 > > not just the S3 based cards will use this method. 
 > 
 > I have a hard time believing that Diamond marketing believes this policy is in
 > the best interest of the company.  How is this going to save/make the company
 > money?

Maybe they've cut a sweet deal with a heavyweight like Microsoft.
(Say) Microsoft gets the details of how the card works and thus
gets a headstart on everyone else.  Microsoft then kicks some $$$
Diamond's way and also recommends that Windows 3.X be run with
the Diamond Stealth whatever.  Maybe Diamond will let
lightweights and netters in on the secret a year or two later,
maybe not.

Newsgroups: comp.unix.bsd
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: [386BSD]
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Sat, 29 Aug 1992 16:37:11 GMT

In article <4ebZONa00WB3Qzp15W@andrew.cmu.edu> tj2n+@andrew.cmu.edu (Tao Jiang) writes:
>Hi, is ka9q or related software available in 386BSD?

Unless you want to do ham packet radio stuff, the Berkeley TCP/IP and SLIP
implementations that come with 386BSD are superior to KA9Q, which was
designed for non-multitasking DOS operation and, thus, incurs some serious
penalties when running under Unix.

-- 
-- Email info@NeoSoft.com for info on getting interactive Internet access.
You will now awaken feeling relaxed and refreshed, remembering everything 
you've read except the details of the Omega contingency plan.
Newsgroups: comp.unix.bsd
From: stark@cs.sunysb.edu (Gene Stark)
Subject: Re: Kernel rebuild - load error?
Organization: SUNY at Stony Brook Computer Science Dept.
Date: Sat, 29 Aug 1992 12:30:21 GMT

>     I am trying to rebuild my kernel to change it so that my 3c503 ethernet
>adapter talks out its AUI port instead of the thinnet port.  (Thanks for the
...
>shortly, I get the error:
>
>  init_main.o: undefined symbol _version refrenced from text segment
>  *** error code 1

I got this, too, on my first attempt to recompile the kernel.
The problem is that "init_main.c" references the "version" string, but
the "config" program does not set up the file "vers.c" in your
compile directory.  If you look at the GENERICISA compile directory,
you will find files "version" and "vers.c", and you will see that the
Makefile includes "vers.o" at the end of the list of files to be loaded.

Since I was just hacking anyway, I just copied "vers.c" from the GENERICISA
directory and edited my Makefile.  This is undoubtedly not the correct
solution, because if I re"config" the changes to the Makefile are reverted.
However, it enables me to load the system.  I'd be happy to hear about
the correct fix.

							- Gene Stark
Newsgroups: comp.unix.bsd
From: tih@barsoom.nhh.no (Tom Ivar Helbekkmo)
Subject: Re: 386BSD: buffer space allocation -- a small bugfix.
Organization: Norwegian School of Economics
Date: Fri, 28 Aug 1992 08:14:08 GMT

I wrote:

>Well, I guess it's my turn!  :-)  I'm now seeing the "kmem_map too
>small" panic here, when I try to copy a large file (a 1.44Mb floppy
>image) from an NFS-mounted device to a local hard disk.  I've tried
>making the changes that have been suggested, but that didn't help.
>(Sanity check in machdep.c, 500 to 1000 increase in vm_map.h.)

I've been looking at this stuff a bit more, and I've found something
that I don't really understand -- but which looks like a bug to me.

The function kmem_malloc() in /sys/vm/vm_kern.c has a parameter called
canwait, which the comment at the top indicates is set to non-zero
when kmem_malloc() is called from interrupt level, and the allocation
thus cannot be allowed to block.  Sounds reasonable to me, and also
sounds like a reason to panic if this happens.  However, I'm looking
at the following bit of code in kmem_malloc():

    if (vm_map_find(map, NULL, (vm_offset_t)0,
                    &addr, size, TRUE) != KERN_SUCCESS) {
            if (canwait)
                    panic("kmem_malloc: kmem_map too small");
            return(0);
    }

I confess I don't understand this virtual memory stuff too well, but
shouldn't that test be "if (!canwait)", though?  The way I read this,
if the caller says "I'd like to get this memory, but hey, I can wait,
so don't worry if I can't have it now", and we can't satisfy the
request at the moment, we panic.  If on the other hand, the request
was "Give me this memory, I've *gotta* have it right now!" we just
quietly fail.

Am I missing something important here?

-tih
--
Tom Ivar Helbekkmo, NHH, Bergen, Norway.  Telephone: +47-5-959205
Postmaster for domain nhh.no.   Internet mail: tih@barsoom.nhh.no
From: tj2n+@andrew.cmu.edu (Tao Jiang)
Newsgroups: comp.unix.bsd
Subject: [386BSD]
Date: 28 Aug 92 08:38:49 GMT
Article-I.D.: andrew.4ebZONa00WB3Qzp15W
Organization: Doctoral student, Statistics, Carnegie Mellon, Pittsburgh, PA


Hi, is ka9q or related software available in 386BSD?

Thanks in advance!
Newsgroups: comp.unix.bsd
From: rivers@ponds.uucp (Thomas David Rivers)
Subject: Re: NMI probs and messages.
Date: Thu, 27 Aug 1992 22:49:41 GMT


 Just to follow up on my own posting, and the thread it seems to be
going, I can pretty much get the NMI to occur by building the kernel
over-and-over in a for loop.  After a couple of hours - there it is...

 It doesn't seem to occur if I let the machine simply sit there for
days on end (I waited three days.)  It seems to occur more frequently
if I disable the recognition of the match coprocessor in npx.c.

 I'm running a kernel w/ Frank Maclachlan's (fpm@crash.cts.com) dma
fixs and David Greenman's (davidg@agora.rain.com) general file system/kernel
improvements.  With these, the NMI seems to be a little more regular.

 Finally, after the NMI, I can now pretty reliably get the following crash
(from /var/log/messages):

Aug 27 09:14:54 puddles /386bsd:
Aug 27 09:14:54 puddles /386bsd: NMI port 61 a0, port 70 ff
Aug 27 12:30:03 puddles /386bsd: panic: remrq
Aug 27 12:30:03 puddles /386bsd: trap type 12 code = fdbf0000 eip = fe025c63 cs
Aug 27 12:30:03 puddles /386bsd: panic: trap
Aug 27 12:30:03 puddles /386bsd:
Aug 27 12:30:04 puddles /386bsd: The operating system is saving a copy of RAM memory to device 1, offset 0
Aug 27 12:30:04 puddles /386bsd: (hit any key to abort): [ amount left to save (MB) ] trap type 12 code = fdbf00
Aug 27 12:30:04 puddles /386bsd: panic: trap
Aug 27 12:30:04 puddles /386bsd:
Aug 27 12:30:04 puddles /386bsd: The operating system is saving a copy of RAM memory to device 1, offset 0
Aug 27 12:30:04 puddles /386bsd: (hit any key to abort): [ amount left to save (MB) ] -- device not ready
Aug 27 12:30:04 puddles /386bsd: system rebooting.
Aug 27 12:30:04 puddles /386bsd:


  I'm curious as to what the empty messages could be, and what 
trap type 12 is.... I'm hoping to find the time to wander through 
the sources and figure this one out; but if you know what this is,
don't hesitate to post.

	- Dave R. -
	(rivers@ponds.uucp)
Newsgroups: comp.unix.bsd
From: ggm@brolga.cc.uq.oz.au (George Michaelson)
Subject: Re: An overview of 17" monitors
Organization: Prentice Centre, University of Queensland
Date: Tue, 1 Sep 1992 10:35:24 GMT

rcd@raven.eklektix.com (Dick Dunn) writes:

>I don't know just what it is that keeps monitor prices so high.  (Conspiracy
>theorists, this is your invitation!)  But the prices are entirely inelastic,
>and unlike all other equipment in the same market, improvement has been
>minimal-to-nonexistent.

Monitors must be almost the oldest component of a computer outside of the
keyboard and the fuse. I'd suspect their costs reflect the absence of 
significant technological advances which translate to reduced cost of 
production.

If gas plasma/lcd takes off in the domestic market, will this affect
the price?

	-George
--
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht
Newsgroups: comp.unix.bsd
From: colin@marsh.cs.curtin.edu.au (Colin Manning)
Subject: What is needed to run X386?
Organization: Curtin University of Technology
Date: Mon, 24 Aug 1992 03:25:43 GMT

Hi,	
	I'm interested in running X on 386bsd.  BUT I only have 14Meg free.

What are the necessary binaries to run X so that I can just pop up multiple
windows?  I don't want any of the other X utilities (yet).

All help/ideas will be much appreciated.
-- 
Colin
------
colin@cs.curtin.edu.au
--
Colin
------
colin@cs.curtin.edu.au
Newsgroups: comp.unix.bsd
From: zxmsd01@mailserv.zdv.uni-tuebingen.de (Gunther Schadow)
Subject: 386BSD: Emacs won't execute the shell?
Organization: Comp. Center (ZDV) U of Tuebingen, FRG
Date: Tue, 1 Sep 1992 13:12:39 GMT

on 386BSD 0.0new Emacs was happily running and forking to shells and
whatever you wanted. But since I installed 386BSD 0.1 I always get an
error like "Inferior process exited with error 1" or so. I recompiled
Emacs now from scratch, and it was still the same. The thing is, that
the M-x compile command does work correctly, but as soon as you call
an interactive subprocess like shell or prolog or lisp, it will end
with that message.

any help is greately appreciated,
regards
-Gunther
 
PS: I have enough ptys installed, since screen works without problems.
--
-------------------------------------------------------------------------------
Gunther Schadow,	          e-mail: Gunther@mailserv.ZDV.Uni-Tuebingen.DE
Sudetenstrasse 25,	          Phone:  (49) 7071/37527
7400 Tuebingen, Germany.__________Stop__________Horn Please!__________O.K. TATA
Newsgroups: comp.unix.bsd
From: vikki@e40-008-9.MIT.EDU (Vikki King)
Subject: WD7000-FASST2 SCSI?
Organization: Columbia University Center for Telecommunications Research
X-Newsreader: Tin 1.1 PL4
Date: Sun, 30 Aug 1992 01:51:13 GMT
X-Posted-From: e40-008-9.mit.edu
X-Posted-Through: sol.ctr.columbia.edu

Hi Everyone!

	I'm all set to go out and get an Adaptec 1542B SCSI adapter or an
AHA1740 to run in 1542 mode, but I thought I'd ask the net first if anyone's
heard of any effort to write a 386BSD driver for the Western Digital
WD7000-FASST2 SCSI adapter.  I'm using one now with Esix SvsV R3.2D and a big
Maxtor disk.  I've never been overly thrilled by it though because there's no
boot driver for it - I have to boot from an IDE disk and mount the Maxtor
afterwards...  I feel like it might a good time to break down and get the
Adaptec card, unless.....  Someone is working on a driver for the WD7000?  :-)
Much thanks to all of you!

-John
jackson@a1.mec.mass.edu


Newsgroups: comp.unix.bsd
From: fridlund@mermaid.micro.umn.edu (Jim Fridlund)
Subject: [386bsd] SCSI advice needed
Organization: U of MN Computer Science, U of MN Astronomy
Distribution: comp
Date: Thu, 27 Aug 1992 08:13:47 GMT

Hello,

I'm looking for a SCSI drive for my 386.  The thing is, I don't
know much about SCSI's on pc.  I've been running 386BSD on a Seagate
ST-251 40 meg MFM drive.  I like it very much.  However, one cannot
do much with 40 megs.  bindist barely fit.

I'm looking for a drive about around 200 megs in size.  As a student,
this is maximum I can afford.  It seems that the Maxtor 213S seems to
be the best deal for this drive capacity.  Is anybody running
386BSD on this type of drive?  I would like to know what it's like.
Or, does anyone else have any suggestions on other SCSI brands?
For the SCSI controller, I think I'll go the safe way and get Adaptec's
1542B card.  As a beggining user for 386BSD, one would think this
type of questions be in the FAQ.  I did not see it in there.  Oh well.

BTW, anybody out there using cross-compiler for os development?  If so,
can someone point me to a general direction for this?  I have access
to an EP/IX machine that is dying to be my development center.

Thanks.




--
Jim Fridlund                                     U of MN - Computer Science
fridlund@mermaid.micro.umn.edu                   Institute of Technology
Newsgroups: comp.unix.bsd
Subject: [386BSD]: DEPCA support in future?
From: ejones@desire.wright.edu
Date: 28 Aug 92 15:33:33 EST
Organization: Wright State University 

Are there any plans to include a DEC DEPCA ethernet card in the supported
ethernet contollers? I have a 16 bit DEC card that I really like, but
in order to use 386BSD I need to swap it with a 3com503 board. Also, will
it be possible in the future to run X386 on a VGA screen instead of SVGA?
Thanks for the help.

	Ed Jones
	Wright State University
	ejones@desire.wright.edu
From: andrew@acwbust.sub.org (A.W. Root)
Newsgroups: comp.unix.bsd
Subject: Re: tar 'multivolume' bugs and workaround workound
Date: 27 Aug 92 12:10:51 GMT
Organization: A.Wheadon,6140-Bensheim-4,FRG
X-Copyright: Nachdruck und Zitate -insbesondere unter Angabe des Autors
             oder der Organisation- ausserhalb des USENETs ist nur mit
             schriftlicher Genehmigung des Autors gestattet. In diesem
             Fall ist die Message-ID und die Newsgruppe als Quelle anzu-
             geben.

In article <1992Aug26.041547.26517@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
>There is a need to reduce the temporary file storage for systems with limited
>disk space. 0.1 method of distribution requires that the entire files must
>first be loaded before they can be extracted.
At least after installing the bin01-files there is no need at all for
temporary space I've been using the following for quite some time now
to install things from both the src and the etc distribution.
--- cut --- /readdos --- cut ---
while echo -n "Next Disk : " >/dev/tty
do
read k </dev/tty >/dev/tty
mtype "a:*01.*"
done | uncompress | cpio -ivmd usr/src/libexec/getty/* usr/src/usr.bin/login/*
--- end --- /readdos --- end ---
Instead of usr/src/libexec/getty/* etc. just add the file you want.
You can also put as many files from the same distribution as you want to on
the end.
To find out what I wanted I first made a complete list of the distribution:
--- cut --- /makelist --- cut ---
while echo -n "Next Disk : " >/dev/tty
do
read k </dev/tty >/dev/tty
mtype "a:*01.*"
done | uncompress | cpio -it | tee MANIFEST.etc01.files
--- end --- /makelist --- end ---
If you don't want to make additional notes of what's at the end of the
various disks, then you can also leave out the tee and copy cpio's output
straight into the file. Don't forget to change the name to MANIFEST.src01.files
for the source distribution.

Also you might start wondering (in etc01) a some point whether something
has gone wrong because it reads through a whole disk with no output, thats
because theres a big tar file spread over more than one disk.
Seeya
-- 
He ought to be put in his place | He has a brain | andrew@acwbust.sub.org
Is there a shovel around ? <mr> | but it hasn't reached his head yet. ;->
Newsgroups: comp.unix.bsd
From: eje@irenaeus.mlo.dec.com (Eric James Ewanco)
Subject: Re: How to disable "^S"(suspend) while using tip?
Reply-To: ewanco@kalvin.enet.dec.com
Organization: Digital Equipment Corporation
Date: Thu, 27 Aug 1992 19:16:36 GMT


In article <17i6i6INNjot@agate.berkeley.edu>, randyc@soda.berkeley.edu (Yen-Pang Randy Chou) writes:
> From: randyc@soda.berkeley.edu (Yen-Pang Randy Chou)
> Subject: How to disable "^S"(suspend) while using tip?
> Organization: U.C. Berkeley, CS Undergraduate Association

> Hi there,

> Does anyone know how disble "^S" (suspend) while using tip?  Also, everytime 
> I dial in to school and use emacs, I need to press "^p" twice before the 
> cursor moves up.  Is that because I'm using tcsh at home?  Is there anyway
> I can disable it too?

> ---Randy

The reason ^P doesn't work is because it is the default character to "force"
transmission of a character. That's because tip uses some control characters
locally.  These characters include ^A and ^P.  I do not know if ^S is one of
them; to find it if it is, or something else, type ^P^S and see if it gets sent
to the remote system.

You can change these bindings by setting the local variables raisechar (^A,
which forces all output to uppercase) and force (^P) to something else.  To set
them do a <RETURN> ~s escape, then type raisechar=<character> force=<character>
etc.  I do not know how you disable them, try either raisechar= or !raisechar.

As for ^S, check first the" stty -a" settings and see  "ixon" is set; change it
to -ixon if it is.  This may or may not work.  You must also see if the remote
system is configured to recognize ^S as suspend or pass it through; check the
same setting on your remote machine.  Finally, check to see if either modem is
doing in-band flow control.

Eric
--
/=============================================================================\
| Eric Ewanco - Software Engineer     For the rash and outrageous opinions ex-|
| Digital Equipment Corp, Maynard MA  pressed herein I alone am responsible;  |
| ewanco@kalvin.enet.dec.com          they do not belong to DIGITAL(TM).      |
\==============================- 2 Th 2:15 -==================================/
From: joshua5@csa.bu.edu (Jim Peters)
Newsgroups: comp.unix.bsd
Subject: SCSI-2 tape and disk drives recommendations
Date: 26 Aug 92 02:26:22 GMT
Reply-To: joshua5@cs.bu.edu
Distribution: comp
Organization: Boston Univ., Computer Science

I'm looking for recommendations on manufacturers of SCSI disks and tape
drives that work with an Adaptec 1542b controller.  The disk and tape
drive will be used with BSD/386.  To date, it is my understanding that any
devices capable of understanding most of the SCSI-2 command set will work
best with BSD/386.  The size of the disk that I am looking for is around
660 MB and retails for approximately $1350.  I have been cautioned against
Figitzsu drives, don't know much about Maxtor and have had no problems with
Seagate.   I'm looking for opinions on speed, noise and reliability.  I'm
leaning towards a Seagate drive.  

I have been told that the BSDi recommended Wangtek Archive 2150s QIC-150
tape drive is not "current".  Refurbished ones retail for $350-$500.
I'd prefer a new drive for roughly the same price.  

All recommendations are welcome.  Feel free to post or send e-mail.

				  -- Jim Peters (joshua5@cs.bu.edu)
Newsgroups: comp.unix.bsd
From: kilroy@mik.uky.edu (Paul S. Kilroy)
Subject: Re: 386BSD: 720Kb floppy driver + mtools patches
Keywords: Where can I find a patched kernel
Organization: University Of Kentucky, Dept. of Math Sciences
Date: Wed, 2 Sep 1992 22:30:51 GMT

Hi all,

	I read through the FAQ but could not find this one
    (probably because it is changing everyday), Does
    anyone know where I can ftp a completely up-to-date
    patched kernel(actually the dist.fs file).

thanks..

paul (kilroy@mik.uky.edu) 

--
                       -Paul   (kilroy@mik.uky.edu)
From: khera@cs.duke.edu (Vivek Khera)
Newsgroups: comp.unix.bsd
Subject: Re: su behavior
Date: 31 Aug 92 17:26:24 GMT
Organization: Duke University CS Dept., Durham, NC
In-reply-to: eje@irenaeus.mlo.dec.com's message of 31 Aug 92 15:51:12 GMT
X-Md4-Signature: ae46c31222d41b6531da788508d54ddf

In article <1992Aug31.155112.18068@engage.pko.dec.com> eje@irenaeus.mlo.dec.com (Eric James Ewanco) writes:

   I've used Ultrix in the past, Suns too, and they allow you to su on
   any terminal. But 386bsd insists that the only ones who can su are
   those who are in the group "wheel".  This is pretty stupid, though,
   because when I put my user in group wheel, I automatically had root
   privileges!! This totally defeats the purpose of su!  If you are
   allowed to su, then you don't need to because you already have root
   access!!!

   Is this standard behavior for su?  What is the reasoning behind this?

this is the normal behaviour of modern versions of su.  this way, when
you have, say 1000 users on your system, knowing the root password
just isn't enough to become root without access to a machine's
console.  on our set up, only the machine consoles which are in a
physically locked room allow root logins, all other root access must
be via an explicit su command.  only the few people who happen to be
in group wheel are allowed to do that.  its just an extra level of
security.

now if you claim that just by being in group wheel, one has root
priveleges, then i suggest you find a good book on unix security and
read it.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Gradual Student/Systems Guy  Department of Computer Science
Internet:   khera@cs.duke.edu             Box 90129
            (MIME mail accepted)          Durham, NC 27708-0129 (919)660-6528
From: uhclem@nemesis.UUCP
Date: 29 Aug 92 22:50 CDT
Newsgroups: comp.unix.bsd
Subject: Description of Trap Codes
Message-ID: <-13547389@nemesis>
From: rivers@ponds.uucp (Thomas David Rivers)
Subject: More on NMI problems.
Date: Wed, 2 Sep 1992 12:32:48 GMT

Well, I got much advice on my NMI problems; indicating that I probably
did, in fact, have a bad memory chip on my machine.

So; I grabbed testext.exe from SIMTEL20 and let it have at the machine,
to determine which chip was bad, etc....

It ran for 38+ hours, without a single error (this program uses
protected mode read/writes of words and double words, randomly scattered
through available memory.)  Other people had sent me mail indicating
this program found their problem, etc...

So, at this point, I'm beginning to return to my previous thought, that
something else is causing the parity error (perhaps some funny DMA, or
some timing problem with the drivers?)  

When I booted 386bsd again, it took less than an hour to reproduce the
problem.  It's very strange, because I never get more than one NMI
line in /var/log/messages (you would think there would be several.)
Also, I never got these from version 0.0.

Also, after reading the descriptions of '386 traps, and noticing the
comment that some CGA-emulation cards used the NMI to simulate the
CGA registers, I pulled out my CGA-on-hercules emulation card, but that
didn't solve it.

My next step is to rip out the math co-processor, then I'll be left
with a hercules card, a 4-port clone card and an IDE controller (pretty
basic)...

      - Dave Rivers -
      (rivers@ponds.uucp)

p.s. Thanks to all the people who responded!
From: spedpr@thor.cf.ac.uk (Paul Richards)
Newsgroups: comp.unix.bsd
Subject: 386bsd-0.1 disklabel
Keywords: 386BSD
Date: 26 Aug 92 21:43:30 GMT
Organization: University of Wales College at Cardiff
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway

I think the 0.1 disklabel is causing problems with some machines, it is
with mine.

I totally failed to get the 0.1 dist to boot from my hard disk. I'd get
the spinning a: drive phenomenon. When I went back to 0.0 and used the
disklabel from that it worked fine. I suspect that the boot code has
changed. My disklabel is the same and using the 0.0 boot code it still
runs the 0.1 kernel but using the 0.1 boot code it doesn't. It seems
that the 0.1 code isn't finding the kernel or that it isn't being
installed properly on the disk. I think the latter, the result being
that no boot code is found on the hard disk and the bios tries the a:
drive instead. I'm only guessing though. Any ideas??

Anyway, as a solution to those that can get the floppy to boot and then
find that when its copied to the hard disk it doesn't boot: get a copy
of the 0.0 disklabel and use that.

Procedure:
1) disklabel the disk using disklabel 0.0
2) reboot using 0.1 fixit.fs
3) newfs the partion (or partitions) (DON'T re-disklabel the disk)
4) follow instructions as given previously for manual installation

The fact that the above procedure works is what makes me suspect that
bootwd is the culprit. (Oh yes it's bootwd and wdboot I'm using since my
drives a seagate st1144a ide)

-- 
  Paul Richards at Cardiff university, UK.

  spedpr@uk.ac.cf.thor	Internet: spedpr%thor.cf.ac.uk@nsfnet-relay.ac.uk
  UUCP:     spedpr@cf-thor.UUCP or ...!uunet!mcsun!uknet!cf!thor!spedpr
+++
Newsgroups: comp.unix.bsd