HDTenEightyP/NetNews huggingface dataset:
From: umisef@mcshh.Hanse.DE (Bernd Meyer)
Subject: Re: tcp - patches... PLEASE SEND THEM!!!
Organization: Point of Presence & MCS Hamburg
Date: Sun, 11 Oct 1992 23:18:44 GMT

umisef@mcshh.Hanse.DE (Bernd Meyer) writes:

Everything around here is somehow buggy right now. So I'll repost this.
If you have already seen it please ignore, but I suspect it has never
left this server.

>Hi there,

>after I had repeatedly stated my problems wwith the comobination of X
>and tcp (everything displaying on a "remote" machine dies inside
>XPending or XNextEvent), someone mailed me and said he had exactly
>the same problems porting xpilot. Also he stated that they went away when
>he applied some patches that were posted to the net channel of the 
>mailing list some time ago that added some kind of missing functionality
>(perhaps this IO<something> stuff X always complains about when starting
>up?). He promised to send them as soon as he would get home. This was good
>news.

>Bad news is: He didn't. Even worse: I lost his mail due to some irregularities
>at my server. I've spent a day now trying to find some archived mail, 
>probably got my sysop another heartattck pulling megs of mail, just to
>delete them minutes later (the first one should have occured when I pulled
>the SLS distribution :-), but all I could find were mailings up to March 92,
>and the complete history of this newsgroup. So I'm nearly desperate!!!!!

>So, pleeeeaaaasssseee, send these patches to me, or even better, to the 
>group. I know I should join the net channel if I'm interested in such
>stuff, but it's a little late now (and in fact I'm only trying to get
>xtrek to work, that's all of tcp I'm able to do until real SLIP comes
>out).

>HELP!!!!!!!!

>Thanks in advance,
>      Bernie

>umisef@mcshh.hanse.de
Newsgroups: comp.os.linux
From: pfcouvar@unix.amherst.edu (Peter F. Couvares)
Subject: Re: Use of zip instead of compress
Organization: Amherst College
Date: Fri, 16 Oct 1992 15:22:57 GMT

In article <1bhpofINN7sl@uwm.edu> rick@ee.uwm.edu (Rick "The Compression Crusader" Miller) writes:
[...]
>lha		Pro:  Very good compression (better than 'zip').

	lha's compression is only _slightly_ better than zip, and lha is much
slower. I used to use lha all the time, but have since decided that the space
saved is nowhere near as great as the time wasted waiting for it to compress.
Unless you have a 486 _and_ almost no disk space, zip is a better choice.

-Peter Couvares

pfcouvar@unix.amherst.edu              "Yet another Jim in the Linux world..."
Newsgroups: comp.os.linux
From: df@eyrie.demon.co.uk (Derek Fawcus)
ReplyTo: df@eyrie.demon.co.uk
Subject: Re: Mounting linux partition from DOS
Distribution: world
X-Mailer: cppnews $Revision: 1.18 $
Organization: None
Date: Wed, 14 Oct 1992 21:49:56 +0000


In article <msains.21.719004608@ibis.ru.ac.za> msains@ibis.ru.ac.za (Malcolm Sainsbury) writes:

> I was wondering if anyone has written a driver or other
> software which will allow me to do the opposite, ie read, edit, 
> write or otherwise access linux files and file systems from DOS.
> ie DOS able to reach into the linux partitions on my hard disk.

Yes I did (sort of). I wrote a program which could read files from the
linux (minix) file system. It has some restrictions and warts as it was
only a test harness for another program.

--
Derek Fawcus (G7FVS)                                df@eyrie.demon.co.uk
Newsgroups: comp.os.linux
From: aronsson@lysator.liu.se (Lars Aronsson)
Subject: Magic(5) for LINUX 0.98 sought
Organization: Lysator Academic Computer Society, Linkoping University, Sweden
Date: Wed, 14 Oct 1992 00:27:52 GMT

I am beginning to understand how the file command [file(1)] and the
/etc/magic file [magic(5)] work. I have the file program in binary,
but my /etc/magic file doesn't seem to know very much. I run LINUX
0.98 and compile new programs with the 4.1 jump table-based shared
libraries.  For the binary executables, file(1) says "data" or
something equally stupid.

Where can I find a more modern /etc/magic file for LINUX, or where can
I find enough information to write one? I know the file format of the
/etc/magic file, but I don't know the actual magic numbers used under
LINUX.

Ideally, file(1) would tell me with which version of the shared
libraries an executable binary is linked.

I understand the /etc/magic file could eventually become a large
database (like /etc/termcap, ours is 150k). If you maintain an FTP
archive or an NFS server, you could have executable binaries for many
architectures among your files. Is there a free, large multi-system
magic file somewhere?

Are termcap, magic and /usr/dict/word files in general considered to
be in the public domain, or are they covered by equally strict
copyright laws as are, say, AT&T UNIX kernel sources?
--
Lars Aronsson, Lysator, Linkoping University, Linkoping, Sweden
Newsgroups: comp.os.linux
From: greg@omnivore.tamu.edu (Greg Economides)
Subject: gcc 2.2.2d/libc 4.1 dumps core
Keywords: gcc dump 
Organization: Center for Biosystems Modelling, Texas A&M University
Date: Wed, 14 Oct 1992 13:57:03 GMT

I installed linux using the 0.97-1 root disk and bootimage and then added
the SLS installation.  I even had gcc 2.2.2 working just fine.  

Later, I got the source for 0.97.5 and the patch for 0.97.6 and compiled that
and had a working 0.97.6 kernel.

I tried to install gcc 2.2.2d from the stuff in the "gccdisk" directory on
tsx-11.  After that, all that gcc would do is dump core.  In trying to recover
from that, I inadvertantly skrewed up my root filesystem.  I reinstalled the
root from the 0.97.1 installation disks and was up and running again.  However,
booting from the 0.97.6 boot floppy ceased to work.  The boot process would
hang at the point that the root filesystem is mounted (I think).

So, I went back to using the 0.97.1 boot floppy.

Well, I still wanted to install the latest gcc stuff.  I installed the gcc
2.2.2d/libc 4.1/math lib 4.0 per the ChangeLog document (again, from tsx-11).
Before I installed it, however, I tried to remove as much of the 2.2.2 gcc
stuff that I could find on my system.  The installation worked without any
major problems.  

Now, gcc still dumps core.  It doesn't even have to try to grok a file.  Simply
invoking it without any command line arguments causes a core dump.

Any hints or suggestions or (even better) brilliant insights and solutions?

Peace,


--
Greg Economides,   Systems Administrator, Center for Biosystems Modelling
Texas A&M University
Internet: econ@tamu.edu
Fuzzy logic -- "Everything is not always something"
From: camerons@NAD.3Com.COM (Cameron Spitzer 764-6339)
Newsgroups: comp.os.linux
Subject: DRAM speed, was Re: ANSWER: (Re: GCC report seg...
Summary: you can't fool Mother Nature
Date: 7 Oct 92 22:18:12 GMT
Reply-To: camerons@NAD.3Com.COM
Followup-To: comp.sys.ibm.pc.hardware
Organization: 3Com Corp

In article 11640@serval.net.wsu.edu, hlu@eecs.wsu.edu (H.J. Lu) writes:
>If you have a fast CPU (> 25 MHz), please check your RAM...

Use the speed specified in your motherboard documentation, or faster.
There are dozens of timing requirements to meet to make a DRAM
happy, and it is likely that the access time itself is not the limiting
parameter.  DRAMs usually respond to inadequate timing values with
intermittent flaky failures, sometimes pattern or address or temperature
sensitive.
My 386-40 was delivered with hand-picked "80 ns" SIMMs.  It *became
reliable* when I installed the 70 ns SIMMs called for in its manual.
This happens a lot.  Don't assume your dealer sold you the right DRAMs;
check it out for yourself.  Don't expect a diagnostic to catch failures
either.  Linux is your *toughest* diagnostic  :-)

>1. Get fast RAM. (should always work)
>2. Get a big cache for CPU, like > 256k. (may work)

Big cache can mask your problem, make it more difficult to isolate,
but it's not a fix.

>3. Increase wait state of your RAM. (may work)

Wait states may not be a fix.  For example, if your motherboard fills
cache by doing fast page-mode cycles, they may not be slowed down by
the added wait states, and the fast page mode cycle time may be the
limiting parameter.  *Get DRAMs with the correct speed grade.*

>4. Turn off turbo. (should always work)

Yes but then you don't get the performance you paid for.


Cameron "DRAMs are our fussy little friends" Spitzer
I don't speak for 3Com, but they'd agree with me today :-)
From: djr48312@uxa.cso.uiuc.edu (X X)
Newsgroups: comp.os.linux
Subject: NEED: libc.so.4
Date: 8 Oct 92 23:37:59 GMT
Article-I.D.: news.BvttnC.3w1
Organization: University of Illinois at Urbana

Somehow I deleted my libc.so.4, and now I can't make, compile etc...  Can some one
uuencode theres and mail it to me?  Id really appreciate it.

djr48312@uxa.cso.uiuc.edu
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Newsgroups: comp.os.linux
Subject: Send me LINUX!!
Date: 10 Oct 1992 16:47:27 -0500
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu
Summary: I need a copy...
Keywords: linux, send

  Would somebody be willing to send me a copy of Linux + {X, GCC, etc.}
via snail mail?  I would, of course, pay for floppies and shipping.

Thanks!!

-- 
Dan Odom
Kansas State University
danodom@matt.ksu.ksu.edu
From: fl0p+@andrew.cmu.edu (Frank T Lofaro)
Newsgroups: comp.os.linux
Subject: More feature ideas
Date: 8 Oct 92 00:47:25 GMT
Article-I.D.: andrew.0eozKRy00YV780wKE=
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Sorry, I forgot these on my last post:

Support for SIGIO, is it included? (this is the signal a process can
elect to receive when I/O is possible on a descriptor, i.e. it would not
block). This way a process can do whatever it wants and get an
"interrupt" when it can do its I/O, instead of blocking or busy waiting
using select. (I think thats right).

Also, support for the other signals (SIGXCPU, etc.) defined in the
signal.h file.

tytso@athena.mit.edu mentioned a secure attention key for the serial
drivers that would ensure that one was talking to a real login program,
and not an impostor. I think that is an *extremely* good idea. (I've
heard of way too    many incidents of people running login simulators,
and if Linux gets widely used, we do have to beware of these issues). It
would be good to have a secure attention key for the general case, not
just serial ports. Is that implemented? If not, how would one implement
that? I'll be willing to do it if I can figure out where would be a good
place (getty/init/login/kernel). Maybe a change to whatever part of the
kernel handles ctrl-c, ctrl-z, etc. to do a vhangup (and whatever else
would be necessary to clear the tty) so that a new getty can appear on
that tty. Would that work?

Also, with TCP/IP, is the config/ifconfig, route, and arp programs
missing any features? (i.e. can one ifconfig up/down, add and drop
routes, print the arp cache, etc.)? Do we have netstat? (I asked it in
the last post, but decided to mention it here with the rest of the
TCP/IP stuff).

I'll be willing to help with implementing some of this stuff, if I can
and if I know it hasn't been done before (repeating someone else's work
isn't something I'd like to do too much of. If I did, I would be writing
yet another adduser utility :)

Thanks again for a great OS. Lots of people here at CMU have beem
starting to or are planning on using it lately.
Newsgroups: comp.os.linux
From: loser@clueless.newbie.tyro.org ()
Subject: Has anyone built the Xaw3d toolkit for Linux ???
Organization: Workstations at Maryland, University of Maryland, College Park
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 9 Oct 1992 14:15:34 GMT

Hello,
  I was just wondering if anyone had compile the Xaw3d toolkit for Linux.
Xaw3d is a drop in replacement for the Athena widget set that offers 3D
shapes for X windows.  I would compile it my self except that you need to have
the X11R5 source tree online to compile Xaw3d (it uses some files from the
X distribution to build itself).  Please let me know if you have this.
Thanks,

Jaime
From: fl0p+@andrew.cmu.edu (Frank T Lofaro)
Newsgroups: comp.os.linux
Subject: Re: Why is TCP/IP treated like it isn't really part of Linux sometimes?
Date: 14 Oct 92 05:36:09 GMT
Article-I.D.: andrew.Qer299_00Vo9IXakoY
	<danielce.719024222@munagin>
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from comp.os.linux: 14-Oct-92 Re: Why is TCP/IP treated l..
Daniel AMP Carosone@mull (453)

>Besides, if you want to beta-test the networking code, you don't need
>it to be in a distribution kernel - unlike, for instance, the scsi
>driver patches where some people couldn't install linux on their scsi
>drives to test it.

	Umm, what if one does not have a modem, does have a net connection, and
doesn't want to keep around DOS tcp/ip software so one can ftp the
kernel? Okay, so its not typical, but neither is having a CD-ROM on a PC
typical either, but it should be supported, as it is in the default
kernel. I am just saying have the same apply to TCP/IP.

	There wouldn't be a problem if all the drivers were in the kernel. That
would be standard UN*X practice. As for beta test, the support code for
EFS (which is still alpha test) is in the kernel by default, but not
tcp/ip. (By the way, after having used the EFS for a couple of months, I
think it should be considered beta, not alpha. It doesn't appear to have
major bugs).

	Please no flame war. I am just trying to point out that the standard
UN*X practice (which the commerical unices, and 386BSD follow) of
including everything possibly needed to have a usable system is a good
idea. Departing from that, really, IMHO, isn't.
Newsgroups: comp.os.linux
From: davison@borland.com (Wayne Davison)
Subject: Re: Termcap question
Supersedes: <BvrsAv.74J@borland.com>
Organization: Borland International
Date: Wed, 7 Oct 1992 21:13:42 GMT

satishc@microsoft.com (Satish Chittamuru) wrote:
> Basically, Elvis seems to think that one needs to wrap each IC (insert
> character terminal escape) output with a preceding IM (insert mode) and a
> succeeding EI (end insert mode).

davison@borland.com (Wayne Davison) wrote:
> This is the correct behavior.

stevek@m2xenix.psg.com (Steve Kirkendall) wrote:
> I consider it to be a bug, myself.  It'll be fixed in the next version.

Did you read anything in my article after the opening sentence?  In it I
explained exactly why the termcap standard *requires* you to output the
sequence im-ic-ei when both are defined.  This is NOT an option.

Here's the reasoning:

  1.   If your terminal has only insert mode, you define im & ei.
  2.   If your terminal has only insert char, you define ic.
  3.   If your terminal requires insert mode to be turned on and then
       a character sequence output for each inserted character you
       define BOTH im/ei and ic.
  4.   If your terminal has both an insert mode and an insert character
       sequence that does not fall into category 3, you must choose one
       of the two.  The usual choice is insert mode.
  5.   If your terminal has a multi-character insert sequence, you define
       IC regardless of whether im/ei or ic is defined.

So, while your actions may not affect YOU, it will completely break insert
mode on some terminals.  This "fixing" of elvis is not needed nor is it
desirable.

Please read the termcap documentation if you doubt me.
-- 
Wayne Davison
davison@borland.com
Newsgroups: comp.os.linux
Subject: Re: Can we please nuke these discussions?
From: system@kryton.UUCP (Scott Beckstead)
Date: Fri, 09 Oct 92 17:56:12 PDT
Organization: Paradox Alley F&SF BBS 805-492-8789

tytso@ATHENA.MIT.EDU (Theodore Ts'o) writes:

>    From: s891961@minyos.xx.rmit.oz.au (Peter David Cupit)
>    Date: 6 Oct 92 08:51:20 GMT
> 
>      The video card design posts are often related to a proposed project 
>      to produce a special Linux video card.   In other words these are
>      relevant postings and are not more suitable for other news groups.
> 
> Excuse me, but there's no such thing.  
> 
> If people want to design the perfect, open-architecture video card,
> that's fine.  But it has nothing to do with Linux.  Just as discussion
> on how the 386 chip masks don't belong here, neither does how to build
> this video card.  Both the video card and the 386 chip can be used for
> many other things rather than Linux, and Linux can use many other video
> cards than this proposed project.  Please take it to
> comp.sys.pc.hardware where it belongs!
> 
> 							- Ted
> 

Geez Ted lighten up.  We were discussing the Video in DIRECT relation to
 linux.  And the 386 chip masks came up in relation to linux.  Perhaps
ALL of this group could be taken to other groups like how do I configure
X and the ever present how do write a device driver for widget.  And I'm
sorry that the volume is so high but ya gotta expect that with this many
beta testers out there.  Not everyone has the clear and certain
understanding of what is topical that you seem to have.  Who appointed
you the TOPIC police anyway!  I have my asbestos suit on so flame away
Ted et al. 


 


System Administrator Paradox Alley  F&SF BBS and Usenet News/Mail 
805-492-8789  Thousand Oaks, Ca. The Place For Science Fiction and Fantasy
"Spin My Nipple Nuts and Send Me to Alaska!" Kryten, Red Dwarf

Newsgroups: comp.os.linux
From: djr48312@uxa.cso.uiuc.edu (X X)
Subject: Making 680x0 code with gcc2.2.2
Organization: University of Illinois at Urbana
Date: Thu, 8 Oct 1992 08:57:16 GMT

I was wondering if I could make 680x0 code with gcc 2.2.2d.  If so give
me the parameters to pass .

Newsgroups: comp.os.linux
From: krouth@etcs03.eld.ford.com (Kevin C. Routh)
Subject: 0.97PL2 mcc-interim release images
Reply-To: krouth@etcs03.eld.ford.com
Organization: The Internet
Date: Thu, 8 Oct 1992 13:49:43 GMT

I downloaded the new 0.97PL2 mcc-interim release images from
tsx-11.mit.edu.  I noticed that the sizes of the files are not uniform
and not the size of a diskette. The 0.96c+ release images were
diskette-sized files.  Why the difference and should I be concerned
about it?

pub/linux/mirrors/mcc-interim/0.97p2/images:
total 8419
-r--rw-r--  1 tytso    ftp-linux    3063 Aug 29 15:51 README.disks
-r--rw-r--  1 tytso    ftp-linux  491593 Aug 27 04:43 boot-UK.Z
-r--rw-r--  1 tytso    ftp-linux  491673 Aug 27 04:43 boot-US.Z
-r--rw-r--  1 tytso    ftp-linux 1001472 Sep 10 11:13 comp1.image
-r--rw-r--  1 tytso    ftp-linux  798720 Aug 29 16:40 comp2.image
-r--rw-r--  1 daemon   ftp-linux 1075200 Aug 28 07:57 g++.image
-r--rw-r--  1 daemon   ftp-linux 1013760 Aug 28 08:16 gdb.image
-r--rw-r--  1 daemon   ftp-linux 1228800 Aug 28 05:22 misc.image
-r--rw-r--  1 tytso    ftp-linux 1202176 Aug 31 15:45 util-UK
-r--rw-r--  1 tytso    ftp-linux 1202176 Aug 31 15:43 util-US


-- 
Kevin C. Routh                 Internet Mail: krouth@etcs03.eld.ford.com
Ford Microelectronics                                 IBM Mail: USFMCTMF
IC Engineering (formerly ASIC Technology Group)
17000 Rotunda Drive - Room B-121
Dearborn, MI  48121-6010                      Voice Mail: (313) 337-5136
Newsgroups: comp.os.linux
From: chad@src.umd.edu (R Michael McMahon)
Subject: Dos Emulator: PAUSE (dir/p) fixed
Reply-To: chad@src.umd.edu (R Michael McMahon)
Organization: College of Engineering, Maryversity of Uniland, College Park
Date: Mon, 12 Oct 1992 22:14:43 GMT

	Those of you using the DOS emulator have noticed that commands
which use the DOS PAUSE routine crash the process. A simple 1 line patch
to emu.c can solve this problem:

in ms_dos() add		case 0: /* divide by 0 */  break;


	After enabling debugging and watching a simple PAUSE command 
result in INT 0 being called, I decided to investigate. After an hour
of tracing through COMMAND.COM with CodeView, I found the following
code:

	MOV	AX,0c08		<- no problem: standard DOS keyboard
	INT	21		   flush/wait for keypress sequence
	MOV	AX,0c00		<- what? Call interrupt 0? Thats a 
	INT	21		   floating point/divide by 0 routine!


This apparent BUG occurs twice in my copy of MS-DOS 5.0; dunno about 
IBM's version (probably the same) or earlier DOS's. If anyone can
think of a valid reason why INT 0 should be called while waiting for
keyboard input, please let me know. In the meantime, my one line patch
should solve the problem. 

	My DOS books say that calling INT 0 should result in program
termination. I guess since DOS never actually *defines* INT 0 all that
really happens is a simple RET. Therefore, it seems pretty safe that 
the Linux Dos emulator should do the same.


BTW, if someone can point my to the Dos-emu Mailing list, much oblidged.

R Michael McMahon	chad@src.umd.edu
From: ckub11@zx1.Darkcrystal.Cyberspace (Martin Reising)
Newsgroups: comp.os.linux
Subject: [Q]: TCP/IP and LPmud
Date: 14 Oct 92 11:43:53 GMT
Organization: Universitaet Dortmund - Hochschulrechenzentrum
X-Newsreader: TIN [version 1.1 PL6]

Hello !

I currently try to port LPmud (V.3.1.2) to Linux. As I'm no C-Wizard and the
driver for LPmud compiles quit clean (some warnings about && and || ops)
When I start up the driver, it reads in some objects, tells me it's setting 
up the ip-connection and dies with an 

IOT Trap/Abort (core dumped)

Immediately before this happens, the kernel tells me something like this:

ioctl: socket FIONBIO: Invalid argument

Now I don't know what goes wrong. The function code for FIONBIO is defined 
in /usr/include/linux/termios.h.

May it be, that I have to creat some devices in /dev to use TCP/IP ? If 
yes would any kind soul please tell me which (maj, min, name)

As I really like MUD and esp. LPmud, it disappoints me, that it doesn't work

My kernel is 0.98pl1 with TCP/IP 0.8.1 and SoundBlaster-Driver 0.2. I 
compiled it with gcc 2.2.2d

Thanks for any Help,
Marc
Newsgroups: comp.os.linux
From: peterw@archsci.arch.su.oz.au (Peter Williams )
Subject: Re: Writing Linux disks on Sun
Keywords: sun
Organization: Design Computing Unit, The University of Sydney
Date: Fri, 9 Oct 1992 02:04:06 GMT

In article <ucosmo.718399359@mcl>, ucosmo@mcl.ucsb.edu (Boris Burtin) writes:
|> I was just curious if someone had a solution to this problem.  It seems that
|> you can only write DOS disks on a Sun Sparc if you are root and can mount a
|> DOS floppy.  Does someone have an alternate solution?  Linux can't read a
|> disk tarred on a Sun, can it?
|> 
|> --
|>      - Boris
|> (cosmo@cs.ucsb.edu)

Yes! It can. I routinely transfer data between a SUN Sparc and my linux machine
by tarring onto 3.5" floppies.

I have also transferred data using the DOS file system capability of the 3.5"
drive on the SUN. This method is an order of magnitude slower than tarring as
the SUN's read/write to DOS floppies is very slow (nearly 1/2 hour for one full
floppy).

-- 
Peter Williams                |e-mail: peterw@archsci.arch.su.edu.au
Key Centre for Design Quality |phone: +61-2-692 2053 or +61-2-660 6156
University of Sydney          |+++++++++++++++++++++++++++++++++++++++
From: hyvatti@klaava.Helsinki.FI (Jaakko Hyvatti)
Newsgroups: comp.os.linux
Subject: Re: Xfree86-1.1, the ALTGR key and norwegain (european) keyboards
Date: 13 Oct 92 01:01:46 GMT
Organization: University of Helsinki

In article <1992Oct12.135518.21221@ifi.uio.no> janl@ifi.uio.no (Jan Nicolai Langfeldt) writes:
>The norwegain keybard has some characters on the key-front (as opposed
>to key-top). We usualy get to them with the help of ALTGR. This worked
>with my Xmodmap.no (same as the one you find on the linux ftp sites)
>for the old X386 (X11v2.0 i think). Now all ALTGR does is set the high
>bit.  Can I configure this somewhere? Or do I have to get some source
>and fiddle?

  As the documentation provided with 2.1 describes, this is exactly
what has been changed in the default modmap. To get it right I use:

keysym Alt_R = Alt_R Mode_switch
clear Mod1
add Mod1 = Alt_L
add Mod2 = Mode_switch

-- 
Jaakko Hyv{tti			Jaakko.Hyvatti@Helsinki.FI
Lapinrinne 1 B 611		hyvatti@plootu.Helsinki.FI
00180  Helsinki, Finland	+358-0-6958 5311, -692 7466 (work)
From: slack@hpdmd48.boi.hp.com (David Slack)
Date: Thu, 8 Oct 1992 22:04:31 GMT
Subject: Re: What's this LINUX about? FAQ?
Organization: Hewlett Packard - Boise, ID
Newsgroups: comp.os.linux

	Thanks for all the input folks.  I don't need any more.  
Got enouph to get me in trouble and make me dangerous.

Thanks 
Dave