HDTenEightyP/NetNews huggingface dataset:
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD-0.1/BRLCAD4.0 benchmark -- poor floa
Date: 29 Jul 92 22:27:08 GMT
Organization: University of Helsinki

In article <1992Jul29.152914.2508@nrao.edu> cflatter@nrao.edu writes:
>In article l7ctu0INN880@neuro.usc.edu, merlin@neuro.usc.edu (merlin) writes:
>>
>>Does gcc 2.2 actually use 80387 inline code for transcedental functions?
>
>No. I just looked :-(.  (Unless it is very well hidden).

gcc-2.2.2 only uses the basic math + fsqrt (fsqrt is new to gcc-2.x). 
The basic math is handled pretty well, though: much better than with
earlier versions.  gcc-2 knows about the fpu stack, resulting in fpu
code that looks almost hand-optimized (at least sometimes).  gcc-1.40
isn't very good at handling the 387 stack (it seems to use mostly
ready-made templates). 

>It could probably be made to though.  There appears to be some support for
>inlining transcendental functions for the Moto 68881.

I don't think inlining is as easy on the 387 as it's on a 68881: the 387
transcendental functions have enough special cases (argument limitations
etc) that it's probably easier to do it in a dedicated function.  But
those functions should certainly use the 387 instructions instead of
using series arithmetic or whatever portable C code the current 386bsd
libraries seem to use. 

The linux libraries might be useful: linux has two different math
libraries, one for soft-float (ie using only the normal arithmetic
functions that are emulated), and one for hard-float.  With shared
libraries (under linux), the same binary can use either, but under
386bsd you'd have to decide at link-time which to use. 

		Linus
From: peter@micromuse.co.uk (Peter Galbavy)
Newsgroups: comp.unix.bsd
Subject: Building GCC-2.2.2 on 386BSD (was Re: Jolitz 386BSD-0.1 -- floating point perform)
Date: 24 Jul 92 08:00:07 GMT
Organization: MicroMuse Limited, London, England.

torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:

>In article <1992Jul22.152854.27730@nrao.edu> cflatter@nrao.edu writes:
>> [ deleted ]  Is anyone working on porting gcc 2.x to 386BSD? Come to
>>think of it, is there anything that needs to be done to do this (wouldn't
>>the BSD/386 configuration work)?

>One thing that migth be a problem with porting gcc-2.2.2 to 386BSD is
>that gcc-2.2.2 has added the 'fsqrt' command to the list of floating
>point instructions that gcc can create code for - and I don't know if
>the 386bsd math emulator emulates that particular command yet.  I've
>already written the code (it's in linux), but it wasn't available back
>when people ported the emulator to 386bsd. 

I haven't got that far :-(

I have been trying to get gcc-2.2.2 going, but my disk is so slooooow...
The thing I have noticed is the the files "gvarargs.h" needs a small hack:
change the ifdefs against "_ANSI_H" to test for "_ANSI_H_" notice the last
underscore, since this is what is defined in <machine/ansi.h>.

There was still a problem with compiling "libgcc2.a" (something about
illegal characters in lines 41 and 43 (or 47 ?) sigh, I can't remember.

I have x-posted this to gnu.gcc.help for informational purposes (and
maybe help from you guys :-).
--
Peter Galbavy
Tech Support, Micromuse Ltd
Phone: +44 71 352 7774		E-Mail: P.Galbavy@micromuse.co.uk
Newsgroups: comp.unix.bsd
From: knie2586@csd4.csd.uwm.edu (Robert Joseph Knier)
Subject: Re: AT&T sues BSDI
Keywords: BSDI AT&T
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Tue, 21 Jul 1992 18:50:39 GMT

In article <54661@mentor.cc.purdue.edu> mm@mentor.cc.purdue.edu (Mike MacKenzie) writes:
>In article <1992Jul20.211811.3152@algor2.algorists.com>, jeffrey@algor2.algorists.com (Jeffrey Kegler) writes:
>> According to today's _ComputerWorld_ (July 20, 1992, page 16) AT&T's
>> USL has sued Berkeley Software Design, Inc. in U.S. District Court in
>> NJ.  Copyright and patent infringement are apparently *not* involved,
>> the grounds being specified as "trademark infringement, false
>> advertizing and unfair competition."
>> 
>
>
>AT&T can do this, and I can stop using them as my long distance carrier.
>Also, when I need a new cordless phone, Panasonic & Sony make fine
>cordless phones.
>The 386bsd INSTALL.NOTES claims about 100,000 sites.  If every site were
>to switch to MCI or Sprint, would AT&T notice?
	
	Good point, I'll have to remember this when I receive a phone call
from AT&T to switch over (I currently have MCI).

					Bob Knier
					(knie2586@csd4.csd.uwm.edu)
>
>
>Michael MacKenzie	(Purdue University Unix Group)
>mm@mentor.cc.purdue.edu
From: terry@npd.Novell.COM (Terry Lambert)
Newsgroups: comp.unix.bsd
Subject: Re: 386bsd-0.1: primary bootstrap (wdbootblk.c) problem & fix.
Keywords: 386bsd boot bootstrap wdbootblk.c
Date: 27 Jul 92 17:27:08 GMT
Organization: Novell NPD -- Sandy, UT

In article <greg.712111605@hibp1.ecse.rpi.edu> greg@ecse.rpi.edu (Greg) writes:
>   In a recent post I described a booting problem I was having: I could only
>boot about 20% of the time in high speed mode. I tried all the latest patches,
>but the problem persisted. By putting a printf at the top of boot.c, I          determined that it was not making it out of wdbootblk.c.

[ ... code describing delay loop deleted ... ]

Folks, *DON'T FIX IT THIS WAY!*

the correct fix is to either use the patched boot files in the "unofficial"
directory on Agate (new "dist.fs"), or to do the following (which only
partially recreates the patch):


Robert Thrush says:

-------------------------------------------------------------------------
	  Most of the credit goes to Jim Huber (jbh@aii.com) for sweating
	through comparing and finding this difference between the AT bios and
	the 386bsd boot code.

	  Here's the diff to feed to patch as follows:

	cd /sys/i386/stand
	patch <following-patch

	*** wd.c        Wed Jul 22 12:58:32 1992
	--- wd.c-       Sun Jun 28 00:20:53 1992
	***************
	*** 299,305 ****
		DELAY(1000);
		outb(wdc+wd_ctlr,2);
		DELAY(1000);
	!       while(inb(wdc+wd_status) & WDCS_BUSY);
		outb(wdc+wd_ctlr,8);
	  
		/* set SDH, step rate, do restore to recalibrate drive */
	--- 299,305 ----
		DELAY(1000);
		outb(wdc+wd_ctlr,2);
		DELAY(1000);
	!       while(inb(wdc+wd_altsts) & WDCS_BUSY);
		outb(wdc+wd_ctlr,8);
	  
		/* set SDH, step rate, do restore to recalibrate drive */
-------------------------------------------------------------------------

Note that wd_status was being checked (incorrectly) instead of wd_altsts
(the correct answer) when waiting for the controller to come ready.

This is in the FAQ, but there are a several fixes in Chris' code on agate
for which there is not yet a source patch.  This is the reason I have not
advocated this fix.

					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu
---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.
From: rdc30@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson)
Newsgroups: comp.unix.bsd
Subject: Re: 2 Problems: No disk Label, Tip doesn't Work
Date: 29 Jul 92 12:21:58 GMT
Organization: Naval Medical Research & Development Command

In article <1992Jul28.122647.7234@ulowell.ulowell.edu> rboccuzz@cs.ulowell.edu (Rich Boccuzzi) writes:
>
[problem about disappearing disklabel deleted, I don't have an answer :-( ]
>
>	The second problem I had was getting tip to work, and I saw a
>couple of posts about this, but no solution.  When tip is configured
>properly, we get the
>	no file or no lock error.  (sorry, I can't be more precise, but
>I can't get that far again without reinstalling 386BSD on my whole
>system, and then I can't get tip to work to read mail and news for the
>solution :-)

As installed off the bin01 distribution set, /var/spool/lock is owned by
root while tip is setuid uucp, chown uucp /var/spool/lock to fix this
problem and do the same for /var/log/aculog.

Funny, release 0.0 had some scripts in /etc to check for silly mistakes
like this that seem to be missing from 0.1 unless they are part of the
distribution I don't have room to install.
-- 
LCDR Mike Dobson, Sys Admin for | Internet: rdc30@nmrdc1.nmrdc.nnmc.navy.mil
nmrdc1.nmrdc.nnmc.navy.mil      | UUCP:   ...uunet!mimsy!nmrdc1!rdc30
AT&T 3B2/600G Sys V R 3.2.3     | BITNET:   dobson@usuhsb or nrd0mxd@vmnmdsc
WIN/TCP for 3B2  R3.2           | MCI-Mail: 377-2719 or 0003772719@mcimail.com
From: dennis@nebulus.ca (Dennis S. Breckenridge)
Newsgroups: comp.unix.bsd
Subject: Re: Funding 4.4BSD Development
Date: 24 Jul 92 16:07:56 GMT
Organization: Alchemy Mindworks, Edmonton, Alberta

guest@pegasus.com (Guest) writes:

>>
>>And recognize that BSDI is a good thing, give them your support, they
>>are who are going to keep BSD Unix alive.
>>---

>No thanks.

>It makes good ad-copy perhaps.  But not good sense.

>Limited, single processor, proprietary support is a zillion steps backward.

I hear AT&T is looking for people. Why don't you apply there. It's exacxtly 
that small minded thinking they are investing in and hiring and promoting 
to positions of power. You would do well!

-- 
-------------------------------------------------------------------------------
    Dennis S. Breckenridge VE7TCP@VE7TCP [44.135.160.59]  dennis@nebulus.ca
Just because everything is different doesn't mean anything has changed - Oracle
-------------------------------------------------------------------------------
From: tinguely@plains.NoDak.edu (Mark Tinguely)
Newsgroups: comp.unix.bsd
Subject: Re: USL vs. BSDI, and what to do
Date: 24 Jul 92 21:01:05 GMT
Organization: North Dakota State University

In article <scs.712004511@wotan.iti.org> scs@iti.org (Steve Simmons) writes:

>But AT&T is the majority owner of USL.

 I was under the impression that AT&T sold most if not all of its interest
 in USL.
From: kapela@prism.poly.edu (Theodore S. Kapela)
Newsgroups: comp.unix.bsd
Subject: Re: What has AT&T to lose? Plenty!
Date: 24 Jul 92 14:11:12 GMT
Organization: Polytechnic University, New York

In article <1992Jul23.012046.18604@cshl.org> pjm@cshl.org (Pat Monardo) writes:
>The BSDI product couldn't have come at a worse time.

BSDI released BSD386 in beta several months ago.  It was *announced* almost a 
full *year* ago.  Where was USL then?

I do agree that BSD386 could have an affect on SVR4 sales, but not directly
in the commercial market.  BSD386 appears to be aimed at the small VAR market, 
not at large VARs such as SCO and ISC (SunSoft), among others.  I also
don't see BSDI "luring" customers away from System V.  Is AT&T really
that afraid of a little competition?  If they are, then they should take
a long hard look at their own products and give people a reason to
CHOOSE (you can't choose if there is only one choice) AT&T products, not
FORCE them to buy them.

It appears to me that AT&T wants a monopoly.  If they can't have it in one
market, they'll aim for another.  This is also indicated by USL's monumental
move of releasing their *own* SVR4 package, Destiny (AKA System V Relase 4.2), 
aimed directly at the same market SCO, ISC, UHC, Dell, et al have been
catering to for many years.  Previously, USL (AT&T) only sold source
licenses to others, be they universities or VARs.

Also note that (as someone else pointed out), USL has made no move to have
the NET2 sources removed from publicly-accessable archive sites.  It would
appear to me that this would be a smaller step for USL.  After all, how
many unversities have the resources (IE: $$$) to see AT&T in court?  USL
doesn't want competition in the distribution market.  This is their way
of pushing out the competitor.

-- 
..............................................................................
 Theodore S. Kapela				kapela@poly.edu
 Center for Applied Large-Scale Computing	
 Polytechnic University
Newsgroups: comp.unix.bsd,comp.unix.misc,comp.unix.questions,comp.unix.wizards
From: ddw@soft.sapsan.msk.su (0000-Admin(0000))
Subject: Difference between BSD Unix???
Reply-To: ddw@soft.sapsan.msk.su
Organization: Research & Production Centre SAPSAN
Date: Fri, 31 Jul 92 12:45:58 +0300

Could You tell me the differnce between the
following OS :
	BSD4.3
	BSD4.3+
	BSDI
	BSD4.3-NET2
	BSD4.4
	  ??
    Thanks in advance.
	Dmitry Doronin


Newsgroups: comp.unix.bsd
From: jnpotts@iastate.edu (James N. Potts)
Subject: com1 silo overflows!
Organization: Iowa State University, Ames IA
Date: Fri, 31 Jul 1992 17:10:49 GMT

Okay, just what is it with these com1 silo overflow messages?!?!  And better
yet, what's the fix for them?  This is really annoying, especially considering
that I'm not even using com1!

Any and all help would be appreciated!!

-- 
_____________________________________________________________________
James N. Potts          |  "To err is human.  To get multiple UAE's 
jnpotts@iastate.edu     |   requires MS Windows."
tabp6@isuvax.iastate.edu|                      - Me
From: sung@davidsys.com
Newsgroups: comp.unix.bsd
Subject: Help: Routing Problem on 386BSD
Date: 24 Jul 92 17:22:58 PST
Organization: DAVID Systems Inc, Sunnyvale CA

Dear 386BSD Folks,
Have you ever routed packets from Node_A to Node_C thru
Node_B using the following configuration ?
I think something wrong on "route.c". Please help.
Thanks.

Kwang Sung
sung@davidsys.com


                    +---------------+
                    | 386BSD        |
                    | Node_B        |
                    +---------|  |--+
                          ec0 |  | we0
                              |  +----------------------------
------------------------------+              | we0
            | we0                   +---------------+
    +---------------+               | 386BSD        |
    | 386BSD        |               | Node_C        |
    | Node_A        |               +---------------+
    +---------------+


NOTE:

On Node_A: ifconfig we0 inet 132.240.25.3 netmask 255.255.255.0 up
           route add default 132.240.25.2
On Node_B: ifconfig we0 inet 132.240.24.2 netmask 255.255.255.0 up
           ifconfig ec0 inet 132.240.25.2 netmask 255.255.255.0 up
On Node_C: ifconfig we0 inet 132.240.24.1 netmask 255.255.255.0 up
           route add default 132.240.24.2
From: sim@cory.Berkeley.EDU (Peng-Toh Sim)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD: Dinky little socket(?) bug -- ^V as escape character?
Summary: POSIX termios
Date: 30 Jul 92 01:16:50 GMT
Organization: University of California, at Berkeley

In article <sand.712454840@milton> sand@milton.u.washington.edu (Derek Upham) writes:
>I've noticed the following problem while running "screen" on 386BSD
>(both of these from the vanilla bin01 and etc01 sources): control-v
>needs to be typed twice for it to be received by a process.  For
>example, under tcsh, the key sequence
>
>        echo ^V^G
>
>which should enter a literal ^G (BEL, 0x7) on the command line, simply
>beeps.  Similarly, "^V^B", which should enter a literal ^B (0x2),
>moves the cursor back one space.  Both of these DO work correctly when
>you type two ^V characters instead of one.  Inserting some suitable
>printf's in "screen" indicates that the problem occurs before the data
>stream reaches the program---somewhere in the pty or socket code,
>looks like.  Anyone else noticed this problem?
>
>Derek
>
>-- 
>Derek Lynn Upham                                     University of Washington
>sand@u.washington.edu                University Computing Services Operations
>=============================================================================
>"Ha!  Your Leaping Tiger Kung Fu is no match for my Frightened Piglet Style!"

Hi

I believe this bug is due to misinterpretation of POSIX.1 .
I have seen this bug under 0.0 with screen3.2 and kermit 5a.
When screen3.2 or kermit is compiled with POSIX.1 termios, it
switches to RAW mode by resetting ICANON in c_lflags for the
terminal.  This, however, does not disable IEXTEN under the
current implementation of 386bsd, so keys enabled by IEXTEN like
^V still gets processed.  Since with screen (or kermit), you go
though the tty discipline twice, ^V gets processed twice.
Example, if you want to enter ^V itself, you have to hit it four times!!!
I figure this from "POSIX Programmer's Guide" by Donald Lewine.
However, this book does not say if the kernel should ignore IEXTEN when
ICANON is not set.  So I don't know who's bug this is.
My modified version of screen3.2 and kermit disables the IEXTEN flag
when they switch to RAW mode so I don't see this problem.

Can somebody who has access to the actual POSIX.1 document comment
on this please?

PT
sim@cory.berkeley.edu
Newsgroups: comp.unix.bsd
From: popelka@odysseus.uchicago.edu (Glenn Popelka)
Subject: PLEASE !!!!! 
Organization: University of Chicago  LASR
Date: Thu, 30 Jul 1992 02:00:48 GMT

 This whole lawsuit thread is getting a little out of hand with uninformed
speculation, idle bantering, hysterics, angst, and irresponsible posts,
like John Ryan's 'Several Ideas for retaliation.' (4442@hq.hq.af.mil)
 
> 2) Counter sue. 
 
       ...and get hit with the penalties for filing a nusiance suit. 

> 4) Write the US District Attorney... Volenteer [sic] as an expert witness.

       They'll believe you...
 
> 5) mail postmaster@att.com </usr/spool/news/junk/$i 
 
       Jesus. This simply isn't done.

 While we're at it, here's another fine idea for retaliation: 
 
 Never, ever, ftp to research.att.com and avail yourself of the collection of 
sophisticated mathematical software or the set of papers on network security
that is maintained there.

 Well, now that I've vented my spleen, I can't really complain about the
plummeting S/N ration here, but it has become a little difficult following
this newsgroup lately. Let's try to keep the noise down, everyone, and give
a little room for the people who are actually pushing forward the frontiers
of free BSD. It's not going away.

glenn
                                     "Next witness, John Denver."
From: terry@uivlsisd.csl.uiuc.edu (Terry Lee)
Newsgroups: comp.unix.bsd
Subject: Re: Bad144 sector mapping tips
Keywords: bad144
Date: 27 Jul 92 22:05:34 GMT
Reply-To: terry@uivlsi.csl.uiuc.edu
Organization: Coordinated Science Lab., Univ. of Illinois at Urbana-Champaign
NNTP-Posting-Host: uivlsisd.csl.uiuc.edu


	Earlier, I had posted a series of steps for bad144 bad sector mapping.
Unfortunately, the problem with bad144 handling is even worse than I realized.
The problem appears to be when a write is attempted on a bad sector that has
been mapped out.  So for now, the steps I posted DO NOT work.  My advice would
be to re-low-level format the hard drive and use bad sector sparing if your
hard drive controller supports it and you have the time.  Otherwise, a bad
sector in the inode list (or any other critical file system area) can be nasty.

	Also, a couple of people have experienced problems with corrupted bad
sector file, which I also ran into.  My solution was to write an /etc/disktab
entry and completely re-disklabel the disk.  Using bad144 after that didn't
cause any more bad-sector corruptions.  But again, bad144 handling really
doesn't work right now anyway.

----------
Terry Lee
terry@uivlsi.csl.uiuc.edu
From: jnpotts@iastate.edu (James N. Potts)
Newsgroups: comp.unix.bsd
Subject: Re: Beginner's problems with 386BSD
Date: 27 Jul 92 16:51:50 GMT
Organization: Iowa State University, Ames IA

I had a problem at first getting the correct time, but I finally got it to
work.  I set my system clock to GMT, and linked /etc/localtime to the correct
timezone (in my case, /usr/share/zoneinfo/US/Central).  Of course, now my DOS
programs are a few hours off, but at least I get the correct time when I log
onto my 386BSD system.

James

-- 
_____________________________________________________________________
James N. Potts          |  "To err is human.  To get multiple UAE's 
jnpotts@iastate.edu     |   requires MS Windows."
tabp6@isuvax.iastate.edu|                      - Me
Xref: sparky comp.unix.bsd:2693 comp.unix.wizards:3290
From: lyndon@ampr.ab.ca (Lyndon Nerenberg)
Newsgroups: comp.unix.bsd,comp.unix.wizards
Subject: Re: AT&T vs. BSDI --> 4.3BSD-NET2 distribution requires AT&T license!!!
Summary: We don't give a shit; we're The Phone Company
Keywords: AT&T 'Death Star' rises over BSDI's horizon [Tel. 1-800-800-4BSD
Date: 23 Jul 92 16:59:37 GMT
Followup-To: comp.unix.bsd
Organization: Alberta Packet Radio Network

[ Followups to comp.unix.bsd - let's get this discussion centered in
  one group ]

tchrist@convex.COM (Tom Christiansen) writes:

> It might be fair to put yourself in USL's shoes: if someone threatened to
> cut of your food source, what would *you* do?  Answer: anything you could
> possibly get away with to survive.

If AT&T is that worried about BSDI, what does that say about AT&T's
faith in their own product? One thing this tells me is that BSDI is
a company to be taken *very* seriously. (Although we all knew that
anyway.)

With the university source release of Plan 9 just around the corner
the academic research community has an excellent opportunity to make
their displeasure known by boycotting the software release. As much as
I like the direction Plan 9 is going in, there is no way I could chance signing
a license with AT&T for it (and I may be in a position to do so shortly).
If the court decides in favour of the death star many of us have our
careers compromised due to our exposure to USL source. I won't let this
happen again with Plan 9, or any other AT&T software.

--lyndon
Newsgroups: comp.unix.bsd,comp.os.linux,comp.periphs.scsi
From: kuku@acds.physik.rwth-aachen.de (Christoph Kukulies)
Subject: Re: S: Contact to LINUX-Users in GERMANY
Reply-To: kuku@acds.physik.rwth-aachen.de
Organization: I.Physikalisches Institut RWTH-Aachen
Date: Fri, 24 Jul 92 12:17:43 GMT


Paah! Linux! Come on and stay here. Go 386BSD, it's the *right* way.

--Chris
-----------------------------------------------------------------
kuku@acds.physik.rwth-aachen.de
*** Error code 1
 
Stop.
From: tgt@exchanger.ecn.purdue.edu (Conan the Librarian)
Newsgroups: comp.unix.bsd
Subject: Another success with 386BSD
Date: 27 Jul 92 20:13:58 GMT
Organization: Purdue University Engineering Computer Network


Here's another data point on 386bsd installation.

I (finally) got the OS up and running on my system, which is:

	Gateway 2000 486-33MHz
	ATI Graphics Ultra card
	8 Mb memory
	Conner 202 MB harddisk (IDE)
	Two floppy drives (Epson)
	CDS Jumbo 250 tape drive (attached to floppy controller)

I partitioned my harddisk into a 120MB DOS and an 82MB BSD386 zone.
Then I formatted the DOS partition, restored all my DOS files from tape
and verified that DOS was `happy'.

Next, I used rawrite to transfer the latest dist.fs floppy image (from agate)
onto a 5 1/4" floppy disk, and tried the old cntrl-alt-del with the floppy
in place--no go.  The BIOS headers printed, but then the floppy drive light
came on solid and the system hung indefinitely.  Tried some different things
(disabling shadow RAM, using the dist.fs.debug floppy image, etc.) but with
no change.

Eventually discovered (!!) that "tiny" would come up, but only with a COLD
BOOT...a WARM BOOT always fails.  (Any gurus out there who can tell me 
why this is???)

Once I got "tiny" up and running, the installation went without a hitch.
Kudos to Bill and Lynne not only for putting the OS together, but for also
making the installation so painless!

Did some playing around--added a couple of new users, tried out mail, came
up in "multi-user" mode (I guess that's what you call it when it prompts you
for a login!).  Tried "/usr/distbin/shutdown -todos", but shutdown cried
about not being able to make the DOS partition bootable (this must be a bug...
I've seen someone else who reported the same problem).  SOOO, I cntrl-alt-del
rebooted onto a DOS floppy, and used fdisk to manually set the active harddisk
partition back to DOS.  Simple as that, and I'm back to running DOS on my
harddisk.

Now to buy that 500Mb Fujitsu disk so I can really start hacking in UNIX :-)

-tom
--
Tom Tobin				UUCP:     pur-ee!tgt	
Dept. of ChE				INTERNET: tgt@ecn.purdue.edu
Purdue University			Ma Bell:  home (317) 463-0189
W. Lafayette, IN 47907				  office "   494-4052 
Newsgroups: comp.unix.bsd