Linux-Hardware Digest #584, Volume #9 Sat, 6 Mar 99 20:14:19 EST
Contents:
Re: Can Linux use 36-bit Xeon addressing? ("David A. Frantz")
Re: Can Linux use 36-bit Xeon addressing? ("David A. Frantz")
Re: Can Linux use 36-bit Xeon addressing? ("David A. Frantz")
AIWA TD-200001 Tape Drive ("Robert C. Paulsen, Jr.")
Re: zip drive mount question.. (Steve)
Re: Xeon Processor... ("David A. Frantz")
Re: I SEE NO REPLYS TO THIS GROUP ???? (Chris Mahmood)
Re: GNOME (popular subject!) (Jim Zubb)
Re: Modem Blaster 56K PNP PCI (et109@home.!icdc.com)
Re: Embedded Linux (Gary Momarison)
AMD k6-2 and 3D Now! under Linux. ("Jakub Chmielewski")
Re: I SEE NO REPLYS TO THIS GROUP ???? ("Tom Muir")
Moving from singel cpu to dual PII 266MHz (jpn)
Re: BEST HW For Linux NoteBook Project (David Fox)
----------------------------------------------------------------------------
From: "David A. Frantz" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: Can Linux use 36-bit Xeon addressing?
Date: Fri, 5 Mar 1999 23:03:44 -0500
Hello all;
Robert Krawitz wrote in message ...
>[EMAIL PROTECTED] (Christopher B. Browne) writes:
>
>> >The Xeon is not a "36-bit" machine, whatever that is... It merely has a
>> >36-bit physical address bus.
>>
>> That can be interpreted as meaning it supports 36 bit address spaces, so
it
>> is a true statement.
>
>That interpretation is simply incorrect. Virtual addresses (which are
>the only kind that normal instructions ever deal with in protected
>mode) are 32 bits wide, just as in all x86 processors from the 80386
>on up. The processor (in hardware, by referring to the page tables)
>translates these virtual addresses into physical memory addresses.
>It's immaterial how wide the physical address bus is. The physical
>address bus could be 20 bits wide (not that I'd care to use such a
>machine), or 32 bits wide, or 40 bits wide. The kernel sets up the
>mapping between virtual addresses and physical memory; the processor
>actually performs the mapping in hardware, and the user code never
>knows the difference.
Maybe I misinterpeted the original posters question but as I understood it
he had a process that wanted to access around 8GB of main memory. I don't
know what the application was, but It clearly requires a machine with an
address space of more than 32 bits. The Xeon is NOT the processor for
this sort of thing. The market now supports several processor families
with clean 64 bit addressing, which would support large programs in a much
cleaner implementation. Since Linux runs on several of these it would be
foolish to try to stuff this application on to a XEON.
>
>> >The Xeon, like all x86's, is a 32-bit machine. For the large part, the
>> >code needing modification is kernel code that deals with physical
addresses.
>>
>> Nope. It will intrude on all user code as well, because user code deals
>> with logical addresses, which must be mapped to physical addresses, and
>> therefore need to have an isomorphism to do so, ergo the compiler must be
>> modified to use the 36 bit addressing mode, libraries must be modified to
>> use the 36 bit addressing mode, and applications must be modified to use
the
>> 36 bit addressing mode.
>
>Not at all. You're drawing completely unwarranted conclusions here.
>
>User code does deal with virtual (not "logical") addresses, and yes,
>they must ultimately be mapped to physical addresses. However,
>everything else in that paragraph is incorrect.
Again this depends on the application. If there is a need to address more
than 4GB of memory then the system and libraries must support that.
>
>At any given time, any given address within any given process address
>space may or may not be mapped to any given physical address. If it
>is so mapped, the processor just goes ahead and accesses the
>appropriate memory location.
>
>If it's not mapped (i. e. if the page table entry for the given
>address -- and this is still a virtual address -- is blank), however,
>the processor takes a page fault. This is essentially an internally
>generated interrupt. This page fault is trapped by the kernel, which
>saves away the processor state and looks at the (still virtual)
>address that generated the fault. There are a number of things it can
>do here:
>
>1) It can determine that the address is not in the process's address
>space (e. g. the address is 0). In this case, the kernel will raise a
>segmentation fault, which becomes a signal to the process. Unless the
>process has arranged to catch SIGSEGV (or sometimes SIGBUS -- I'm not
>clear on the distinction), it will be terminated with a core dump.
>
>2) It can determine that the virtual address in question is part of
>the process's address space, and already exists in physical memory
>(i. e. it's part of a file -- such as an executable or a shared
>library -- that wasn't already mapped). In this case, it will set up
>the mapping in the process's page table and continue the process from
>where it left off. Unless there's a really nasty kernel bug, this
>should be undetectable by the process.
>
>3) It can determine that the virtual address in question is not
>currently in physical memory. In this case, it will need to find the
>page on disk and bring it into physical memory, and set up the
>mapping, and resume the process. Again, the process should not be
>able to detect this. The process may be able to infer this by means
>of a time delay (e. g. it took 10 milliseconds to access this memory
>location -- that's probably a page fault, although the kernel might
>have decided to preempt the process for entirely different reasons).
>
>Notice that at no point in this scenario does the user process have
>any idea whether the virtual address it accessed was mapped, or how.
>Nor does it matter how wide the virtual address is, or how wide the
>physical address is. It's simply a mapping. Each virtual address
>maps to zero or one physical addresses, but there's no isomorphism
>here at all. Indeed, many different virtual addresses can map to the
>
>> It does not seem to be a reasonable idea to start tying the OS to an
>> odd-ball addressing mode that will hurt portability later, particularly
>> when:
>
>Linus's point is that mapping all of physical memory into virtual
>address space makes management of physical memory in the kernel a lot
>easier and more efficient. This is indeed a serious enough
>consideration, but there are no user-space ramifications here (other
>than possibly slower I/O or context switching).
>
>--
>Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
>
>Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
>Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
>
>"Linux doesn't dictate how I work, I dictate how Linux works."
>--Eric Crampton
------------------------------
From: "David A. Frantz" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: Can Linux use 36-bit Xeon addressing?
Date: Fri, 5 Mar 1999 23:10:28 -0500
Johan Kullstam wrote in message ...
>Robert Krawitz <[EMAIL PROTECTED]> writes:
>
>> 2 GB RAM is a satisfactory virtual address space for a single process
>> for most purposes, but 1 or 2 GB RAM is not a satisfactory upper limit
>> on RAM today.
>
>but these are not `most purposes'. the big ram user will almost
>certainly need a shitload of ram for *one* process. otherwise, you'd
>just buy more machines and run one of the big (but not humongous)
>processes on each.
>
>e.g., a finite-element analysis requiring 7GB of memory for the matrix
>math. or a database application juggling a giant lump in memory.
My question is why would anyone try to run a finite-element analysis with a
7GB matrix on any Intel based machine. Again this is an address space
issue best solved by a 64 bit processor. Even NT breakes up the address
space of an i386 in such a way that user adressable memory is limited.
>
>--
> J o h a n K u l l s t a m
> [[EMAIL PROTECTED]]
> Don't Fear the Penguin!
------------------------------
From: "David A. Frantz" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: Can Linux use 36-bit Xeon addressing?
Date: Fri, 5 Mar 1999 23:27:48 -0500
John Burton wrote in message <[EMAIL PROTECTED]>...
>Johan Kullstam wrote:
>>
>> John Burton <[EMAIL PROTECTED]> writes:
>>
>> > There are multiple reasons for and against going with an Alpha or PPC
>> > vs. Intel... on of which is *all* the other hardware is Intel x86 based
>> > and having *binary* compatibility is important.
>>
>> who cares about binary compatibility? just recompile!
>
>Ummm...try providing support to multiple scientists developing code on
>their personal workstations (x86 based), running multiple jobs on
>multiple machines, writing data to the same location (typically a
>partition on their personal workstation), using the generated (binary)
>data as input to other jobs on other machines...add to that the problems
>of maintaining some type of version control over the software being
>developed...so now add to that simply *recompiling* *all* the code that
>has been developed, and make sure that the version of code (and
>compilers, and libraries and utilities, and...) are the same on both the
>x86 *and* the alpha / ppc machines... And on top of all that, the data
>produce MUST BE CORRECT!
>
>So, while in concept having an alpha or ppc machine on the LAN with x86
>machines is good idea, in practice there are a lot of minor problems and
>it introduces a lot of places for bugs to enter the processing setup...
Sounds like the problem here is that you are growing you application to the
point that they require more than capablity than you would get from a PC.
Sounds like you should just scrap the PCs an move to RS6000 or something of
that nature. Your problem reminds me of a couple of engineering
departments I know of. They standardized on a PC platform running AutoCAD
thinking it would suit there needs, but got left behind trying to keep up
with vendors running Catia on real work stations. So now the PCs are used
as drafting tables instead of design aids.
Thats not to say that using a PC to do engineering work is a bad thing its
just that you have a growth problem centered around a couple of things.
These are: 1. MS operating systems, 2. 32 bit address space, 3. very poor
scalability, 4. Floating Point as an after thought. Of these the one
thing that sneaks up on many PC users is the 32 bit address space issue.
>
>>
>> if it's some proprietary offering, chances are it would never be
>> offered in 32+32 bit large mode. even if linux were to support it,
>> it'd be a bitch to port.
>>
>Like I said, I don't care about the 36 bit address space, just the
>bandwidth issue (described below) and getting the most bang for the
>buck...
Look closely at the Alphas memory bandwidth.
>
>> > That said, I too am interersted in this topic for the simple reason
>> > that the 450NX chipset motherboards can support 4 way interleaving
>> > of memory, plus the use of alternate (4 32bit PCI buses, 2 64bit PCI
>> > buses or 2 32bit & 1 64bit PCI buses) bus structure, up to 8 Xeon
>> > CPUs (with cluster controller)... I'm not as interested in the size
>> > of the address space as much as the size of the memory bandwidth and
>> > I/O bus structure...
>>
>> sgi, sun, the former dec all make *much* better high end machines.
>>
>> --
>> J o h a n K u l l s t a m
>> [[EMAIL PROTECTED]]
>> Don't Fear the Penguin!
>
>John
>
>--
>John Burton, Ph.D.
>Senior Associate GATS, Inc.
>[EMAIL PROTECTED] 11864 Canon Blvd - Suite 101
>[EMAIL PROTECTED] (personal) Newport News, VA 23606
>(757) 873-5920 (voice) (757) 873-5920 (fax)
------------------------------
From: "Robert C. Paulsen, Jr." <[EMAIL PROTECTED]>
Subject: AIWA TD-200001 Tape Drive
Date: Fri, 05 Mar 1999 22:38:55 -0600
Is anyone using the TD-20001 SCSI tape drive from AIWA?
This is a 10GB native, 20GB compressed drive using "NS" technology with
hardware data compression.
I plan on using the dump/restore programs for backup, including data
from a shared Win98 partition.
Before I plunk down $300, does anyone know of any compatibility problems
with Linux?
--
Robert Paulsen http://paulsen.home.texas.net
If my return address contains "ZAP." please remove it. Sorry for the
inconvenience but the unsolicited email is getting out of control.
------------------------------
From: [EMAIL PROTECTED] (Steve)
Subject: Re: zip drive mount question..
Date: Sat, 06 Mar 1999 05:14:30 GMT
On Fri, 05 Mar 1999 16:07:42 +0100, Robert Schiele
<[EMAIL PROTECTED]> wrote:
>Just partition the disk with fdisk (new primary partition 4).
>Then make file system with 'mkfs.ext2 /dev/hdd4' if you want ext2 file
>system or 'mkfs.msdos /dev/hdd4' if you want msdos file system.
That's got it working for me Robert...Thanks a bunch!!
Steve
------------------------------
From: "David A. Frantz" <[EMAIL PROTECTED]>
Subject: Re: Xeon Processor...
Date: Sat, 6 Mar 1999 00:22:21 -0500
John Burton wrote in message <[EMAIL PROTECTED]>...
>I'm planning on buying a low-end server machine to primarily do heavy
>duty number crunching (*BIG* atmospheric models) and generate large data
>files. I've been doing some research and it seems that the Pentium II
>Xeon processor running on an Intel SC450NX or AD450NX motherboard should
>be a screamer. But unfortunately my checkbook can't handle a full blown
>8 processor AD450NX system... My base requirements are:
>
> 450 Mhz Pentium II ??? processor (Initially single, but planning on SMP
>later)
> >256 MB memory
> 2x9 Gb SCSI LVD U2W disks (good swap & file I/O performance)
> 100 Base-T NIC
I take it this will be acompute server, if so look seriously at an Alpha
motherboard. How ever if it is a file server or will also be transfering
very large files then keep a close eye on I/O performance. My feeling is
you will regret big time going with and Intel chip, either single or dual,
to handle the described job. The asumption here is that you are trying
to improve compute performance.
If the data sets are as large as I can imagine then you will have to look
closely at where the operating system is placed on the disks along with the
applications and the data. With the limited information supplied it
sounds like a RAID array for data would be a minimal requirement. Think
seriously about putting the OS on an entirely different controller/disk.
256MB of memory seems a little to little. Obviously with any system
choosen this is simple a issue of cost. Here a little testing on current
systems will tell you how much memory impacts performance, in this example
most likely alot. To little memory will severly overload the I/O system.
Networking is a question fo current infrastructure and future performance
requirements. 100 base-T isn't really that much of a pipeline. But the
question as listed has to little information to allow a useful answer.
100 Base-T however would be an excellent connection to a remote PC running a
X-server.
>
> I've found several options and am evaluating them, but I need some
>information...okay, relative to a Linux RedHat 5.2 base O/S with
>appropriate upgrades for the 2.2.2 (or greater) kernel:
The new kernel is a beautiful thing, however it may not be as stable as a
0.36 kernel. I would however go for the exceptional speed improvement and
compiler options.
>
> 1) is the ADAC A-466 Ultra2 SCSI Raid card supported under Linux?
> 2) is the Adaptec 7980 (and 7985) SCSI chipset *well* supported under
>Linux?
Well it is not!
But then again like everything else the issues involved may have been fixed
by know.
> 2) Can Linux make use of the 4-way interleaved memory access provided
>by the 450NX chipset?
I may be wrong but this would seem to be a BIOS - boot up - chip set
consideration. Consider a vendor that supports Linux on high performance
platforms, they would most likely have the most current answers to the
questions in this group.
> 3) Under Linux is there much performance difference between a Dual P-II
>on a 440BX motherboard and a Dual P-II Xeon on a 440GX motherboard
>(there is a *significant* price difference).
>
>I have a range of possibilities, but I need to justify it in terms of
>Price vs. Performance (i.e. how much faster will the large number
>crunching jobs be done, and will it be responsive in serving the files
>generated via NFS & Automount...
I wouuld suspect that some of these answers would be hard to answer without
intimate knowledge of the applications involved. On a server trying to
both server as a compute platform and a file server you have the question of
how all the caches in the system are affected. If your compute code
thrashs the caches on both the disks and memory systems then file serving
performance could really suck. A dual processor may help some or not at
all. On the other hand if the file serving duties are handled seriallly
with compute duties you may end up with extremely high performance for both.
>
>Thoughts ? Suggestions?
Yes No matter what operating system you choose, be aware that new
chipset technology is not usally well supported. From your questions I
would suspect that you need to do some careful testing of current systems to
determine current bottle necks.
Also not to sound like an old recording; but you really do not want to do a
compute server on an Intel based machine. Try to find some real FP bench
marks for your code and run them on the different platforms to see how the
Intel stuff performs. Your code may run effiecently on I386 or it may fail
to achieve even a small fraction of whats possible on a Alpha, Sparc or PPC.
Once some testing is done you will have sojme idea of performance in models
per second for each platform. From there it should be obvious which path
to follow.
Lots of Luck;
Dave
>
>John
>
>
>--
>John Burton, Ph.D.
>Senior Associate GATS, Inc.
>[EMAIL PROTECTED] 11864 Canon Blvd - Suite 101
>[EMAIL PROTECTED] (personal) Newport News, VA 23606
>(757) 873-5920 (voice) (757) 873-5920 (fax)
------------------------------
From: Chris Mahmood <[EMAIL PROTECTED]>
Subject: Re: I SEE NO REPLYS TO THIS GROUP ????
Date: Fri, 05 Mar 1999 16:43:34 -0800
Reply-To: [EMAIL PROTECTED]
this is interesting...i used to try to spend at least 5 hours/week
answering questions, not including extensive email-to-email help.
It's a great way to procrastinate and i didn't want to feel like a
'freeloader' on the back of linux.
the last year has seen an incredible number of new users coming to
linux from (mainly) MS, which is good, and an incredible decrease in
the courtesy, knowledge, and general comptetence of 'newbies'. Not to
sound like a grump, but when i was starting out (a little over 3 years
ago) i would NEVER post a question without doing an extensive search,
reading HOWTO's, and looking through books first. In fact, i can only
think of posting newbie type questions two or three times. To do
otherwise is rude, and places an additional burden on those who give
us this software. I don't think i was alone in thinking this way
either.
Today is different story. People crosspost to any group with 'linux'
in the name, ask questions which even the most cursory search would
answer (e.g., "My c compiler produces files called 'a.out' which don't
run!!", "I'm thinking about installing linux---can someone email
explicit instructions on how to set it up", etc).
Lately, the signal to noise ratio in the linux groups has become so
low that i usually just scan the headers briefly, pick a few questions
and answer---and i don't do it that often anymore.
so the short answer to your question would have to be: 'The quality of
the question determines the quality of the answer.
-ckm
------------------------------
From: Jim Zubb <[EMAIL PROTECTED]>
Subject: Re: GNOME (popular subject!)
Date: Fri, 05 Mar 1999 22:22:59 -0500
dts wrote:
>
> I am having the same problem as everyone else regarding GNOME, the failed
> dependencies
This doesn't help you but I had no problems installing 1.0,
just did an rpm -Uhv --nodeps *
If I remember correctly I only needed the nodeps for one
package, I don't remember which one though. :)
Just make sure you download everything (except devel
packages), worked for me.
> during install. Also putting the exec gnome-session is not as simple as it
> sounds (for me), in the
> xinitrc and Xclients and also wm-style files....
> i have tried different combinations,,,including inserting a line in the
> Xclients and xinitrc...both...etc
> I am using RedHat 5.2 ..... is there a way to manually start gnome from the
> command line??
> like a startx --gnome session??? ---that doesn't work for me, I am using
> Afterstep and really like it,
> I am about to give up on Gnome..... it is supposed to be "revolutionary" and
> increase the ease of using Linux blah blah blah. The Gnome web page should
> address the dependency problems since they are so common.
Well, I am not exactly sure how to use gnome with
Afterstep. However you can get much of the gnome
functionality by running panel and gmc, just run them from
xterm or stick them in your .xinitrc before your window
manager. You will only be missing session management.
I am kind of fuzzy how that gnome-session program actually
works. It does work fine for me using E though.
--
Jim Zubb
[EMAIL PROTECTED]
------------------------------
From: et109@home.!icdc.com
Subject: Re: Modem Blaster 56K PNP PCI
Date: Sat, 06 Mar 1999 06:16:23 GMT
On Tue, 02 Mar 1999 04:25:03 GMT, [EMAIL PROTECTED] (Rob Clark) wrote:
>In article <7bfb0m$gi2$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
>>I have a Modem Blaster 56k PCI PNP modem that i just got. Im kinda a newbie
>>with linux and i just recently installed it. I cant get the Modem Blaster to
>
>Probably a winmodem. Please check your model number against the list at:
>
> http://www.o2.net/~gromitkc/winmodem.html
>
>in the Digicom section.
>
>Rob Clark, [EMAIL PROTECTED]
I can tell you from experience, the modemblaster is a winmodem.
I'd recommend an external serial modem, no muss, no fuss.
(and no no driver problems in Win9x)
I upgraded to a US Robotics 56k fax/data and am only slowed
down by bandwith problems.(in either os) :>}
et109
------------------------------
From: Gary Momarison <[EMAIL PROTECTED]>
Subject: Re: Embedded Linux
Date: 05 Mar 1999 23:17:37 -0800
> > Pascal Goguey wrote:
> > >
> > > Hi there!
> > >
> > > I have found a page about embedded Linux a while ago, and I wrote
> > > for more
> > > info, but nobody replies.
> > > Does anybody have some pointers / know somebody who implemented
> > > something interesting / know somebody who knows somebody... ?
> > >
> > > Any pointer welome!
Try http://www.aa.net/~swear/pedia/embedded.html
--
Look for Linux info at http://www.dejanews.com/home_ps.shtml and in
Gary's Encyclopedia at http://www.aa.net/~swear/pedia/index.html
------------------------------
From: "Jakub Chmielewski" <[EMAIL PROTECTED]>
Subject: AMD k6-2 and 3D Now! under Linux.
Date: Sat, 06 Mar 1999 09:20:58 GMT
Hi!
I would like to build a linux server based on amd k6-2. I also want to use
the machine in its idle time (during the night) to compress cd music into
mp3s.
I know that 3d now! instructions are generally unused under linux. But is
there any mp3 compressor (for linux of course) that uses the feature? Can 3d
now be used to compress mp3?
Thanks in advance
=============================================
Jakub Chmielewski
AIESEC Polska, AE Wroclaw
[EMAIL PROTECTED]
------------------------------
From: "Tom Muir" <[EMAIL PROTECTED]>
Subject: Re: I SEE NO REPLYS TO THIS GROUP ????
Date: Sat, 6 Mar 1999 15:06:31 -0000
>the last year has seen an incredible number of new users coming to
>linux from (mainly) MS, which is good, and an incredible decrease in
>the courtesy, knowledge, and general comptetence of 'newbies'. Not to
>sound like a grump, but when i was starting out (a little over 3 years
>ago) i would NEVER post a question without doing an extensive search,
>reading HOWTO's, and looking through books first. In fact, i can only
>think of posting newbie type questions two or three times. To do
>otherwise is rude, and places an additional burden on those who give
>us this software. I don't think i was alone in thinking this way
>either.
Perhaps the problem lies with the new image of Unix. I decided to give red
hat 5.2 a try. I read the initial installation instructions. Essentially it
said install boot disk, follow menu and linux will be installed. Only it
just isn't that simple. The idea that this OS can be installed like DOS or
Windows is being suggested but it just isn't. The level of supported
hardware is also misleading. Compaq servers on which I'm trying to install
RedHat must be amongst the most common servers for netware but there is no
mention of support or lack of support for this platform in the
documentation.
>Today is different story. People crosspost to any group with 'linux'
Agreed - this is bad manners
>in the name, ask questions which even the most cursory search would
>answer (e.g., "My c compiler produces files called 'a.out' which don't
>run!!", "I'm thinking about installing linux---can someone email
>explicit instructions on how to set it up", etc).
>
>Lately, the signal to noise ratio in the linux groups has become so
>low that i usually just scan the headers briefly, pick a few questions
>and answer---and i don't do it that often anymore.
>
>so the short answer to your question would have to be: 'The quality of
>the question determines the quality of the answer.
>-ckm
------------------------------
From: jpn <[EMAIL PROTECTED]>
Subject: Moving from singel cpu to dual PII 266MHz
Date: Sat, 06 Mar 1999 16:25:44 +0100
What can one expect in overall and what SMP-software are there for
Linux?
/JPn
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Crossposted-To: comp.os.linux.misc,comp.os.linux.portable,uk.comp.os.linux
Subject: Re: BEST HW For Linux NoteBook Project
Date: 06 Mar 1999 07:50:05 -0800
[EMAIL PROTECTED] writes:
> Do those really cheap, but fast AMD processor based notebooks Frys
> sells work o.k. or are they problematic? The attraction is a
> $1400 pricetag VS the $2200 for a comparable Dell.
You could get a Pentium 233MMX thinkpad 560X from Micro Warehouse for
$1299.
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.hardware) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Hardware Digest
******************************
