HDTenEightyP/NetNews huggingface dataset:
From: bairstow@copland.psu.edu (Steven Bairstow)
Newsgroups: comp.os.linux
Subject: Re: The Third Degree
Date: 14 Aug 92 18:55:27 GMT
Article-I.D.: atlantis.7gh1Hm#z&8
Organization: Penn State University

In article <1992Aug13.124939.16680@kth.se> d88-jwn@blofeld.nada.kth.se (Johan W}hlin) writes:
>bairstow@copland.psu.edu (Steven Bairstow) writes:
>: ...
>: 	- Has anyone noticed free inodes being left around? I think 
>: 	  halt/shutdown is doing it. (This is what I was trying to figure 
>: 	  out when it crashed.)
>Yes I've been having this problem at least with reboot
>
>: ...
>: 			Steve
>/Johan

Okay, so does anyone know where the code is for these programs so I can take 
a look at them, or who the author is?

			Steve
Newsgroups: comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: anyone have bootb.exe?
Organization: University of Victoria, Victoria, BC, CANADA
Date: Wed, 19 Aug 92 04:41:04 GMT

I am looking for bootb.exe, so it can be included in the SLS
distribution.  This will allow installation even on machines
with the wrong format of boot drive.  Anyone help me out...

Peter.
From: copernicus@digund.uucp (Copernicus) 
Newsgroups: comp.os.linux
Subject: efsprogs alpha 6
Date: 21 Aug 92 20:07:00 GMT
Distribution: world
Organization: Digital Underground - PRIVATE
Reply-To: copernicus@digund.uucp (Copernicus) 

RCC:>        For people that downloaded the efsprogs version alpha 5,
RCC:>DON'T USE THEM !!!  In version alpha 5, efsck contains a bug which
RCC:>can cause some great damages on an ext fs.  The bug is fixed in
RCC:>the new version (alpha 6) which is available on ftp-masi.ibp.fr
RCC:>in the directory pub/linux/ALPHA/extfs (files efsprogs6.tar.Z,
RCC:>efsprogs6.bin.tar.Z, efsprogs6.src.tar.Z) and I expect them to
RCC:>be available on tsx-11 in directory pub/linux/ALPHA/extfs soon.

RCC:>Changes from alpha 5 to alpha 6 are :
RCC:>- in efsck, a bad test on directory structures is fixed,
RCC:>- efsck and mkefs now use getopt() to decode arguments,
RCC:>- mkefs now accepts a -i option to specify the ratio of inodes.

RCC:>        I strongly apologize for the bug in efsck :-{

RCC:>                Remy
RCC:>--

Thats great to hear.

I have a question for you.  I am running Linux 0.97pl1 (where is L.T's 0.5
patch?), and your extfs alpha 5 system (will up to 6 this weekend), and the
dosfs extensions.

My question is:  Why when I boot Linux I get a magic match failed but Linux
mounts the extended file system correctly anyways?  Is this just an fluke
message poping up?

/etc/mtab:  (citing this from memory)
/dev/hda2       /       ext     default

/etc/rc:
mount -av

Besides that little message the file system works great!  Now I just
need to get the source code to everything and recompile it!

Chris Nalley
---
 . SLMR 2.1 . Digital Underground - A Copernician Corporation
From: hlu@phys1.physics.wsu.edu (Hongjiu Lu)
Subject: Re: Is XView 3.0 available for Linux/X386 ????
Organization: Washington State University
Date: Wed, 19 Aug 92 01:33:26 GMT

Before you do that, please wait for new release of X386 from Orest.
Gcc 2.2.2d is not compatible with v 1.1. I can do somethimg for it.
But I want to wait for the new one.

-- 
H.J.
Gcc/libc maintainer for Linux.
In article <1992Aug19.005820.11219@cseg03.uark.edu>, dws@cseg03.uark.edu (David W. Summers) writes:
|> jofre@socrates.umd.edu (Jaime Jofre) writes:
|> 
|> >Hello everyone,
|> >  Has anyone ported the XView 3.0 library for Linux/X386?  If no, is anyone
|> >porting it to Linux?  Thanks,
|> >
|> >Jaime Jofre
|> >  
|> 
|> I started into this, last weekend, but ran out of time.  Later I decided to
|> update to GCC 2.2.2d and still haven't done that.  Maybe after I update the
|> compiler I'll look into XVIEW 3.0 some more.  I have never worked with
|> IMAKEFILES so ran into some problems there but I think I may have almost 
|> figured them out.  Naturally the XVIEW compile instructions don't seem 
|> complete (I'm not complaining, just stating fact...) so that is another
|> thing that slowed me down.  Lastly, I am about to re-arrange my disk 
|> partitions to increase my LINUX space, so am in in process of backing
|> stuff up.
|> 
|> If anyone already has these libs compiled I would LOVE to hear about it!
|> 
|>    - David Summers
|>    (dws@engr.uark.edu)
|> 
|> 
|> 
|> -- 
|>                          "Never under-estimate the bandwidth of a station-wagon
|> David Summers             full of tapes, hurtling down the highway."
|> dws@engr.uark.edu         - Tanenbaum, "Computer Networks"
Newsgroups: comp.os.linux
From: welshm@snail.rtp.dg.com (Matt Welsh)
Subject: Re: Linux logo
Date: Thu, 13 Aug 92 13:14:23 GMT
Organization: Data General Corporation, RTP, NC.

I got the newest version (EPS) of the linux logo direct from
the artist, and my previewers (Ghostview and GS) both barf on
it, with the errors:

Error: /undefined in !
Operand stack:
    /AD_OutlineWidth  30
Execution stack:
    operator_169ac    --nostringval--  --nostringval--  false  --nostringval--  --nostringval--  false  --nostringval--  --nostringval--  --nostringval--
Dictionary stack:
    337/401  4/200  6/325

Apparently the line

	/AD_OutlineWidth   30        !

is causing problems. Can some kind postscript guru tell me what's going
wrong? Is this an incompatibilty between Postscript 1.0 and 2.0? 

Thanks,
mdw

Matt Welsh    welshm@dg-rtp.dg.com        ...!mcnc!rti!dg-rtp!welshm
UNIX-SQA, Data General Corporation RTP        Office: +1 919 248 6070
  "Where's the KABOOM?! There was supposed to be an Earth-shattering KABOOM!!"
Newsgroups: comp.os.linux,comp.sys.ibm.pc.hardware
From: willmore@iastate.edu (David Willmore)
Subject: Re: Need help with programming ET4000
Keywords: ET4000 SVGA
Organization: Iowa State University, Ames IA
Date: Fri, 21 Aug 1992 19:10:30 GMT

burkert1@platon.fmi.uni-passau.de (Klaus Burkert) writes:
>On VGA-chips the registers are 'indexed', because alot of them have to fit
>in very few port-adresses (from memory the ET4000 has about 80 registers).

>These registers are accessed as follows (for your example):

>write the desired index (33h) to port 3d4h 
> (mov dx,3d4;   mov al,3;   out dx,al)

>and access the indexed register at port 3d5h.

>That's the whole magic with indexed registers.

>Ciao, Klaus.

This is what I was looking for.  The idea of indexing registers on a vga 
card is repulsive, but "do as the romans do."  I have programed on other 
indexed i/o systems before and it hasn't taken much time for me to get 
used to this one.  I already have the code to to Tseng 4000/3000 detection
running.  I'll get the rest done soon.

I would like to thank everyone for their help.  I have received numerous
replies.  Many of them were asking me to forward them what I do find. 
Since there is so much need, I am planning on writing a toutorial in both
basic and pascal to show people how to program graphics and text on the
Tseng family.  I'll also include C if I get my compiler soon.  I hope.

Thanks again!

--David Willmore
willmore@iastate.edu
Newsgroups: comp.os.linux
From: jwinstea@jarthur.claremont.edu (Jim Winstead Jr.)
Subject: Re: What happened to nic.funet.fi
Organization: Harvey Mudd College, WIBSTR
Date: Wed, 12 Aug 1992 20:45:58 GMT

In article <16brlpINN49t@matt.ksu.ksu.edu> probreak@matt.ksu.ksu.edu (James Michael Chacon) writes:
>erc@Apple.COM (Ed Carp) writes:
>
>>Hmmm...anyone know what happened to nic.funet.fi?  DNS says that it doesn't
>>exist... :(
>
>Yea, I  get the  same  response. More than likely the router  is down again
>on their side. I remember this happening  about a  week ago when patch1  came
>out.

The gateway for Finland's connection to the Internet (in Norway or
Sweden, I believe) is down for repairs or somesuch.  This obviously
has effects on those of us on this side of the world (well, anywhere
outside of Finland itself, I guess) and access to those sites.

It's just a temporary thing, like a day or so.  For more details, read
Timo Salmi's post in comp.binaries.ibm.pc.archives about
garbo.uwasa.fi being unavailable - same reason.

(Now that someone brings this up, I realize where my usual flood of
mailing list mail went today - it's holed up in Finland.  :)
-- 
                                    +    Jim Winstead Jr. (CSci '95)
                                    |            Harvey Mudd College
                                    | jwinstea@jarthur.Claremont.EDU
                                    + This is all my words.  Honest!
From: klaus@snarc.ucrc.sub.org (Klaus Weidner)
Newsgroups: comp.os.linux
Distribution: world
Subject: Looking for iniTeX
Keywords: tex, initex, hyphenation
Organization: GSF
Date: Thu, 13 Aug 92 11:45:37 +0100

Hello,

I have a small problem with TeX or rather the *.fmt files - they work
fine for english text but it is impossible to load hyphenation tables
for other languages, which is rather annoying since I live in Germany.

It would be very nice if somebody could point me to an archive site
that has iniTeX (preferably .a) or mail it to me (please check with me
first, I don't want ten copies!), since I don't have the disk space to
unpack and compile the complete source.

Thanks,
	Klaus

P.S.: 0.97pl1 is great - now I can actually _use_ X, Tex, xdvi etc with
      only 4Mb, I thought I would need at least 8...

(klaus@snarc.ucrc.sub.org, kweidner@physik.tu-muenchen.de)
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Why GNU cp is flakey under Linux
Date: 13 Aug 92 13:23:38 GMT
Organization: University of Helsinki

In article <JRS.92Aug12190300@lepton.world.std.com> jrs@world.std.com (Rick Sladkey) writes:
>
>An examination of the source code shows that GNU cp only performs this
>optimization if it thinks that the original file also had holes.  The
>way GNU cp determines this is by comparing the number of blocks used
>with the actual file size.  Furthermore, it only does this when it is
>compiled without ST_BLOCKS_MISSING defined.  Note that the kernel is
>created by build and does not have any holes.

Yes, but GNU cp looks /only/ at the st_blocks field, and seems to ignore
st_blksize altogether, assuming it's a constant (usually 512).  Or
that's what it looks like when just taking a quick look at the source. 
And as the current linux kernel happens to use st_blksize = 1024 (and
thus also st_blocks is only half of what GNU cp seems to expect), the
test doesn't work very well.  The result being that GNU cp creates holes
even if there were none in the original image. 

I'll probably change the default st_blksize to 512 - easy enough to
change the math in linux/fs/stat.c, and it seems that's what some
programs expect.  Programs which understand about st_blksize shouldn't
care one way or the other.

		Linus
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.os.linux
Subject: Re: Whining...I don't want to hack on the kernel
Date: 19 Aug 92 19:13:12 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <kenc.714229866@sol.acs.unt.edu>, kenc@sol.acs.unt.edu (Ken Corey - Operator) writes:

| Yeah, this is true.  Everyone is important.  The only problem is: who is
| going to provide the labor to make everything stable between versions
| (especially when those versions are coming out every week)? 

  We haven't seen a complete release since 0.96c, I think. There's a
mj-0.97.1 I've seen, haven't tried it, but someone said it didn't
include ps and there was a header problem. I don't know that this is
true, but the posting I got on it seems to indicate it's gcc2.2.2b
rather than d, so that's not quite there.

  And since Linus seems to think there will be good stuff in 0.98, and
by then tape support should be stable, and extended f/s working just
right, and maybe the msdos and xenix f/s stuff will be included with
options in the makefile for the kernel... about then I'll probably
update everything, and then hack the kernel to allow dedicating part of
memory to buffers rather than dynamic allocation. That will speed up
two little SX boxes with 8MB on the AT bus.

  I don't find that 0.96c is slowing me down, and while I'd like to have
some of the neat stuff in 0.97.1, I've booted the kernel and it isn't
all that much faster, and I don't have a ps which /quite/ works...

  The moral is that when and if you get stable, stay there and use the
machine, these stable points are too blasted far apart!

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
From: magidj@cellbio.duke.edu (Jonathan Magid)
Newsgroups: comp.os.linux
Subject: GCC 2.2d
Summary: the new gcc is available on reggae.
Date: 16 Aug 92 17:44:50 GMT
Organization: Duke University Medical Center, Dept. of Cell Biology

You can now download the new version of gcc from /pub/Linux/GCC on
reggae.oit.unc.edu.

jem.
-- 
Jonathan Magid     jem@reggae.oit.unc.edu
Virtual pizza Delivery (tm)::faxed in 30 cycles or less or you get it
----------------------------------------FREE!!!-----------------------
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: problem compiling 0.97pl1.5 with gcc2.2.2d
Date: 22 Aug 92 20:00:46 GMT
Organization: University of Helsinki

In article <1992Aug22.164625.772@rock.concert.net> cole@concert.net (Derrick C. Cole) writes:
>
>Using the 96c bootimage, and after installing gcc2.2.2d and the 0.97 source
>and patches, I am able to compile the kernel sans problem.
>
>However, after the unix socket init, I get an unstoppable list of
>
>[ ...lots of error stuff deleted... ]
>kernel panic: no free inodes in mem
>[ ...lots of error stuff deleted... ]

Sounds like the infamous problem with shoelace and a kernel image with
holes in it.  The fix is either not to use shoelace, or make sure
/vmunix (or whatever you call it) has no holes.  The latter can be done
by using "cat /usr/src/linux/Image > /vmunix" instead of using 'cp' (or
you can use 'dd' or any number of other things). 

While I'm orating, I might as well mention that 0.97.pl2 will be out
tomorrow: it contains mostly the memory management rewrite, but also has
some bigger vfs patches (mostly with symbolic links, but also some
general fixes).  The changes will mostly not be seen on a user level:
some error-codes have been corrected, and linux gives each task 3GB
address space, but normal programs won't notice anything.  The memory
management cleanup also allowed a clean vm86-mode, so that's in. 

pl2 is relative to (unpatched) pl1, so people who have applied the
1-line fix will get patch errors.

Also, while I haven't been totally out of touch, I've not answered all
my mail (or answered very tersely) the last weeks, due to work.  I also
haven't had time to check out all the patches I've gotten etc.  I should
have more time for linux the upcoming weeks, so hopefully I'll try to
catch up a bit. 

		Linus
Newsgroups: comp.os.linux
From: jharvey@csulx.weber.edu (Justin B. Harvey)
Subject: Wang video & TCP/IP
Organization: Weber State University, Ogden Utah
Date: Wed, 19 Aug 92 13:24:42 GMT

Greetings from Alaska,
 
I have a question about X Windows 11R5:
 
At work I have Linux .97 installed on a Wang 386.  Wang is fully compatible just like Zeos or Compaq.  It has a super VGA
card called a WVGA (W = Wang).  I was wondering if anyone knows
if there will be an add-on attachment for the card or if I am
compatible with another more well known video card.
 
Second and final question :-)
 
I currentl work for the City and Borough of Juneau, Alaska's
Data Processing department and I would like to do some Alpha
testing with Linux TCP/IP.  Who should I contact?
 
Thanks,
 
Justin Harvey
jharvey@csulx.weber.edu
From: jmsimon@acsu.buffalo.edu (JMS)
Newsgroups: comp.os.linux
Subject: Re: large caches ona 486
Keywords: 486, caches and Linux
Date: 14 Aug 92 18:11:59 GMT
Organization: UB don't come after eachother in the alphabet

mal11@po.CWRU.Edu (Matthew A. Lewis) writes:
>
>I was considering get a 256k cache for my i486-33 and I was wondering
>if anyone has had any problems with caches on these faster machine.
>I can't understand why there would be a hardware probelm depeendant
>upon software. The only problem I've ever had with a machine being TOO
>fast is playing video games :)

No problems here. Of course, I can't attest to any spped increase/decrease
with Linux, as I haven't bothered disabling the cache. For MS-DOG it is
definitely a help, tho.

It might not even be doing anything with Linux - would someone with more
info like to shed some light on this? Does the cache make enough of a 
difference to be worth having? I *can* compile the kernel in about 2-3mins,
but that may just speak for the 486-33 and quick (relatively) IDE drives.

As an side, though, I have an opportunity to trade some hardware that I
have (a 20mb hardcard, SVGA card and 12-1mbx9 SIMMS) for 4-4mb SIMMS. What
kind of a difference will I notice going from 8mb to 16mb (4 of the 1x9's
that I have are in a box because I only have 8 memory slots - woops!)?

>MaThiEu a. LeWis   
>Thieves Like Us   
>mal11@po.cwru.edu   

JMS

-- 
*******************************************************************************
 Jeffrey M. Simon	       .o   o.	     Computer Science / Business Mgmt.
 jmsimon@acsu.buffalo.edu       ~~v~~	     State University of NY at Buffalo
***** "Perspiration = ( Genius - 1% Inspiration ) / .99" -Ein*kinda*stein *****
Newsgroups: comp.os.linux
From: erc@unislc.uucp (Ed Carp)
Subject: Re: Shared Libraries Considered Harmful
X-Newsreader: Tin 1.1 PL5
Organization: Unisys Corporation SLC
Date: Wed, 12 Aug 1992 18:25:34 GMT

william E Davidsen (davidsen@ariel.crd.GE.COM) wrote:

: I know Linus got some new info about libraries from my question in
: comp.arch, it may be possible to get the portability of a jump table
: without the performance drawbacks. Of course everyone else may be
: running a 486-50 and not notice the performance hit.

Yeah, right ... can you say 386SX/16? :(
-- 
Ed Carp, N7EKG     erc@apple.com                801/538-0177
"This is the final task I will ever give you, and it  goes  on  forever.   Act
happy, feel happy, be happy, without a reason in the world. Then you can love,
and do what you will."           -- Dan Millman, "Way Of The Peaceful Warrior"
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.os.linux
Subject: Re: formatting
Date: 13 Aug 92 07:41:04 GMT
Organization: University of Helsinki

tracyre@infonode.ingr.com writes:
>With Linux, if you have a bootimage file which you want to put on a
>floppy, the floppy doesn't need to be formatted.  You can simply
>execute the command:

Oh yes it does.  It doesn't need to have a filesystem (and if it does,
the filesystem will be overwritten), but unless the floppy is formatted
the drive won't be able to write anything to it.

There is a distinct difference between formatting a disk and creating a
filesystem on it.  Since the MS-DOS format-command does both, many
people seem to think there is no difference.

Formatting means that the magnetic stuff on the disk is magnetized in
a specific way.  Before it is formatted, the contents of the disk are
basically random fluctuations of magnetism, and as should be clear it
can be very difficult to find anything useful in random disturbances.

Creating a filesystem means that the some information is written to the
disk so that the operating system can take care of allocating space for
files, keep lists of files, etc.

--
Lars.Wirzenius@helsinki.fi
From: ace3@quads.uchicago.edu (Tony 'LLama' Acero)
Newsgroups: comp.os.linux
Subject: Re: Buffer corruption problems.
Summary: is this behavior related?
Keywords: linux, kernel, 0.97p1
Date: 13 Aug 92 16:38:54 GMT
Article-I.D.: midway.1992Aug13.163854.21617
Reply-To: ace3@midway.uchicago.edu
Followup-To: comp.os.linux
Organization: University of Chicago Computing Organizations

I have a 486/33 w/ 10MB of RAM, RLL hard disk controller.  I
have self-compiled version 0.97p1 of the kernel (with the 
grow-buffer fix).  No swap space.  The GCC provided in the
MCC 0.96 interim release.

As a crude benchmark I timed the recompile of the kernel several
times. (ie make clean; make dep; make all)

I was very, very pleasantly surprised when the first compile took less
than 12 minutes -- more than 3x faster than under 0.96c!

However, imagine my surprise when each subsequent recompilation was slower than
the previous one!  About the third or fourth time make quit with
an error.  Each time the conditions were precisely the same -- no other VCs were
in use -- my assumption is that the only change was caused by the previous
compilations.

I have no idea what's going on and would appreciate any input! :-)
(The smiley is to indicate I'm not complaining and half-expecting
that I've done something bone-headed)

thanks to all

tony acero
ace3@midway.uchicago.edu
Newsgroups: comp.os.linux
From: hlu@phys1.physics.wsu.edu (Hongjiu Lu)
Subject: PLEASE READ ME (Re: Troubles compiling lilo v3)
Organization: Washington State University
Date: Sat, 15 Aug 92 04:37:28 GMT

I think I am partially responsible for this mess. I noticed it when
0.97 was out. I did the best I could and send a patch to Linus, which
became the part of 0.97 patch 1. Unfortunately, you really need
gcc 2.2.2d to totally solve the problem. Everytime when I tried
to release gcc 2.2.2d to public, I either got some bug reports or
requests. So it delayed that long. I hope I can finally get it out
this Sunday.

Here is something very important.

YOU HAVE TO HAVE VIRGIN HEADER FILES FROM KERNEL SOURCE OF 0.97 PATCH 1 ON
LINE TO INSTALL GCC 2.2.2d.

YOU HAVE TO HAVE VIRGIN HEADER FILES FROM KERNEL SOURCE OF 0.97 PATCH 1 ON
LINE TO INSTALL GCC 2.2.2d.

YOU HAVE TO HAVE VIRGIN HEADER FILES FROM KERNEL SOURCE OF 0.97 PATCH 1 ON
LINE TO INSTALL GCC 2.2.2d.

-- 
H.J.
Gcc/libc maintainer for Linux.
In article <1992Aug14.152402.1541@crd.ge.com>, davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
|> In article <1992Aug14.024317.19775@inmet.camb.inmet.com>, newbie@dylan.camb.inmet.com (Chris Newbold) writes:
|> 
|> | Anyhow, I'm having major trouble compiling it. There is a massive conflicy
|> | between the linux/include types.h and the include/sys/types.h ... I'm sure
|> | all of this was covered... If someone would be kind enough to point me
|> | in the right direction, I would really appriciate it.
|> | 
|> | The problems: Both /usr/src/linux/include/linux/types.h and /usr/include/sys
|> | /types.h get included. I tried to fix this by linking /usr/include/sys
|> | to /usr/src/linux/include/linux. This seems like a hack, but I don't really
|> | know. Didn't reall help.
|> 
|>   I think you are hitting one of the real problems at this time, you
|> need different includes for a lot of stuff, and if everyone would get to
|> a common set of headers life would be a lot nicer, and development might
|> go a bit faster.
|> 
|> -- 
|> bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
|>     I admit that when I was in school I wrote COBOL. But I didn't compile.
Xref: sparky comp.os.linux:8816 alt.cd-rom:2684
From: ajayshah@almaak.usc.edu (Ajay Shah)
Newsgroups: comp.os.linux,alt.cd-rom
Subject: What is a good PC CD-ROM drive for me?
Date: 21 Aug 1992 16:11:46 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: almaak.usc.edu

I'm shopping for a CD-ROM drive for a AT-bus 386.
What are the good alternatives?  The major objectives of interest
are:

1. Linux on CD-ROM
2. Other Unix source code CD-ROMs
3. Kodak Photo CD
4. USGS or CIA map databases
5. Some PC CD-ROMs like those produced by National Geographic, etc.

I would prefer an external drive, because that frees me in
terms of hooking it up to non-PC computers.

What do you recommend?  I would prefer a low-end cheap drive, since
speed is not important.

Thanks,

        -ans.
-- 
Ajay Shah, (213)749-8133, ajayshah@usc.edu
Newsgroups: comp.os.linux