Subject: Linux-Development Digest #304
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 13 Oct 94 23:13:12 EDT

Linux-Development Digest #304, Volume #2         Thu, 13 Oct 94 23:13:12 EDT

Contents:
  Re: ext2fs vs. Berkeley FFS (Kai Petzke)
  Whats the *true* scoop on AHA-2940 drivers?? (Wigs)
  Re: A badly missed feature in gcc (Petteri Stenius)
  Re: We a FAQ: Linux vs. *BSD!!! (Tony Porczyk)
  Re: Contract Software development : Driver for PDMA16 I/O board (David - Morris)
  Re: LINUX Logical volumes (Ken Latta)
  Re: 1.1.53 - fdformat - IOCTL error still there (Ove Ewerlid)
  Re: FTP slowdown under 1.1.52 with hdparm on (John Gotts)
  [Q] What does MTU do in SLIP? (Andrew Robert Ellsworth)
  Re: GCC version i2.5.8p dies with the following code (Laurent Chemla)
  Re: Improving SLIP latency under Linux (John Richardson)
  Re: Serious Bug In The Networking Code (Frank Lofaro)
  Re: Linux For Mac (Spencer Smith)
  Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Dave Perks)
  Re: Filesystem idea (Andrew R. Tefft)
  Re: Question about ext2fs (Ralf Baechle)
  Re: Improving SLIP latency under Linux (Frank Lofaro)
  Re: Linux Mud (Philippe Steindl)
  Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Shaune Beattie)
  Re: Qlogic (Michael Griffith)
  Re: ext2fs vs. Berkeley FFS (Peter Mutsaers)

----------------------------------------------------------------------------

From: [email-masked] (Kai Petzke)
Subject: Re: ext2fs vs. Berkeley FFS
Date: 11 Oct 94 17:02:28 GMT

[email-masked] (H. Peter Anvin) writes:

>Followup to:  <[email-masked]>
>By author:    [email-masked] (Peter Eriksson)
>In newsgroup: comp.os.linux.development
>> 
>> >The icon (for a window manager) for the file could be
>> >accessed by the following call.
>> 
>> >            fd1 = open("MyDataFile:ICON",O_RDONLY);
>> 
>> If one were to implement something like this, then it would be much
>> better to use the "/" character to separate the filename and the subforks...
>> 
>> Just a little thought.
>> 

>And, incidentally, it works without kernel mods!!  (A multifork file
>is *exactly* the same as a directory!)

Well.  Almost.  A multifork file would be something like a directory
with a "default" file: If you only specify the directory file name,
you will get the MAIN fork instead ...

Kai
-- 
Kai Petzke                      | How fast can computers get?
Technical University of Berlin  |
Berlin, Germany                 | Sol 9, of course, on Star Trek.
[email-masked]   |

------------------------------

From: [email-masked] (Wigs)
Subject: Whats the *true* scoop on AHA-2940 drivers??
Date: 13 Oct 1994 15:13:33 -0700

I'm trying to figure out whether or not the Adaptec AHA-2940 PCI scsi
controller is going to be supported under linux anytime soon...

I asked about a week ago and I've read the back articles on this thread but
there isn't a decent answer amongst them.  Some posts say Adaptec won't
release the product info. one post points me to the Project-Map which
doesn't mention *anything* about *any* adaptec projects (thanks to who ever
that was, real helpful...)

There have been lots of people like myself asking this question so could
somebody who *knows* the answer please tell me if somebody is currently
working on a device driver for the AHA-2940??  If somebody is working on it
how is the progress going? if somebody isn't working on it, why not?

Thanks for any info you can give me,

- Jeff W.

------------------------------

From: [email-masked] (Petteri Stenius)
Subject: Re: A badly missed feature in gcc
Date: 13 Oct 1994 18:36:18 GMT

> David Taylor ([email-masked]) wrote in comp.os.linux.development,
>       article <[email-masked]>:
> >I wish gcc for Linux could handle // comments.
> 

It does. I have made the following change to file
/usr/lib/gcc-lib/i486-linux/2.5.8/specs

*cpp:
%{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{c++-comments:-lang-c-c++-comments}

Now compiling with gcc and option '-c++-comments' does what I want.

--
Petteri Stenius                  I " My punctuality is well known, when
Mail : [email-masked] I the revolution takes place, I'll be late
Tel. : +358-0-492382             I and I'll be shot as a traitor "

------------------------------

Crossposted-To: comp.os.386bsd.development,comp.sys.unix
From: [email-masked] (Tony Porczyk)
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: Thu, 13 Oct 1994 18:13:08 GMT

[email-masked] (Jesus Monroy Jr) writes:

>       This is a weekly question.
>       [...]
>       Can we get together and write a single FAQ on this?
>       [...]
>       Do I get a Yeah on this?

Outstanding idea.

t.

------------------------------

From: [email-masked] (David - Morris)
Subject: Re: Contract Software development : Driver for PDMA16 I/O board
Date: 12 Oct 1994 05:12:25 GMT

I can't believe you want someone outside of australia for the work,
but if you do, continue reading.

I've been hacking Linux for about a month and am cutting my
teeth on Linux drivers by extending the alpha level Token Ring
driver.  I have 30+ years of very broad experience in the
computing field with activities ranging from adding device
support to IBM OS/MFT to programming device driver level code
on IBM PC platforms.  My experience includes 7 years leading the
project teams porting IBM mainframe FORTRAN compilers to AIX/ESA
et al.

If you happen to still be interested, I require:
   1)  Your assurance that the data rates you require can be
       achieved in the DOS environment using the C driver
   2)  $125 per hour (assuming a minimum contract period of
       about a month and minimal difficulties negotiating
       the agreement, regular payment for effort and/or
       pre-payment, etc.)
   3)  In addition to card, etc. for testing, suitable data
       generaters with appropriate mechanisms for verification
       of correctness would be required
   4)  Complete documentation on the hardware, etc. probably
       including access to the DOS driver code
before I would consider providing an estimate you might want
to hold me to.  I would be willing to spend a small amount
of uncompensated time studying the harware documentation, etc.,
but if you want a fixed price bid, that can only be as a followup
to a study phase compensated on an hourly basis.  The only 
thing I can provide w/o compensation is a set of approximate costs.

Should you still be interested, any contract would be with my
company and might include work performed by my associates who
though well qualifed with extentsive experience with device
driver level code on PC hardware do not have unix or linux
experience.

If you wish to discuss this further, you can email or otherwise
contact me:
   David Morris
   barili systems limited
   10873 W. Estates Drive
   Cupertino, CA 95014
   (408) 366 5050

------------------------------

From: [email-masked] (Ken Latta)
Subject: Re: LINUX Logical volumes
Date: 12 Oct 1994 05:11:02 GMT
Reply-To: [email-masked]

In article [email-masked], [email-masked] (Albert D. Cahalan) writes:
>In article <[email-masked]> [email-masked] (Jay Ashworth) writes:
>   [email-masked] (Richelo Killian) writes:
>   > Is it posible to create logigal volumes across drives and/or
>   > partitions and then mount a single filesystem on that volume? I know it
>   > can be done on HP-UX, but I want to do it on my LINUX box?
>
>   To clarify, what I believe you're asking about is the ability to create a
>   logical filesystem/volume which spans physical volumes, i.e. a 3GB
>   filesystem spanning 3 1GB drives.
>
[snip]

>This sounds like a dangerous mess.  If a drive crashes, would you rather
>lose all your data or 1/3 of your data?
>--
>
>Albert Cahalan
>[email-masked]

It can certainly create a lot of extra work when a drive crashes.  Even as I write this my colleagues are busy restoring humongus amounts of data because, for the second time in as many months, a drive died on our HP-9000.  I guess they're getting tired of the all-nighters because this time they built each filesystem on separate spindles instead of striping them across 3 spindles.  Another fun aspect of LVM's is trying to maintain an accurate map of logical to physical volumes.  In other words, don't bother writing an LVM for Linux on my account.  What would be useful is a means to resize, both grow and shrink a partition without destoying the contents.

Ken Latta
[email-masked]

------------------------------

From: [email-masked] (Ove Ewerlid)
Subject: Re: 1.1.53 - fdformat - IOCTL error still there
Date: 12 Oct 1994 23:18:49 GMT

> For me 1.1.53 does not boot at all.
> The kernel hangs after the CSLIP message, probably when detecting
> the ethernet card (ne 2000).

We have similar problems with machines equiped with NE2000 cards.
They boot OK after a hardreset or powerdown but not after a softreset.
(Some MORE machines with NE2000 cards got this symptom with 1.1.53 ...)
We've been using linux for more then 2 years and the severity of this
problem has varied.  Judging by Beckers comments in the source code and
on the net, the NE2000-clones are pretty hard to autodetect properly.

We recently had to switch from a NE2000 to a 3C509 in a P90 box
in order to get it stable in conjunction with heavy disk and net activity.
Some NE2000 clones seems to be crappy ...

------------------------------

From: [email-masked] (John Gotts)
Subject: Re: FTP slowdown under 1.1.52 with hdparm on
Date: 12 Oct 1994 05:15:09 GMT

Mark D. Roth ([email-masked]) wrote:
: Here are some figures I got, which I found to be fairly consistant:

: multcount     user    system  clock   %CPU
: 0             0.21    20.69   0:46.74 44.7
: 2             0.34    21.53   0:47.69 45.8
: 4             0.37    18.75   0:49.94 38.2
: 8             0.37    11.90   1:10.54 17.3
: 16            0.29    12.37   1:10.55 17.9

: I'd rather have the wall-clock time, personally... :)
-- 

You might mention what hard drive/controller you are using.

--
John Gotts ([email-masked])  73 de N8QDW   URL: http://www.umich.edu/~jgotts
GE -d+ H s+: g-- p? !au a-- w+ v C++++ UL++++ P+>++ L++ 3- E--- N+++ K- !W M--
 V-- -po+(---) Y+ t+ 5 j+ R- G? tv b+ D B- e+ u--- h f+ r n- y? <Linux rules!>

------------------------------

From: [email-masked] (Andrew Robert Ellsworth)
Subject: [Q] What does MTU do in SLIP?
Date: 11 Oct 1994 12:00:13 -0500

------------------------------

From: [email-masked] (Laurent Chemla)
Subject: Re: GCC version i2.5.8p dies with the following code
Date: 12 Oct 1994 11:10:47 GMT

Gary William Flake ([email-masked]) wrote:

: The code at the bottom of this message crashes gcc i2.5.8p.  I am
: running linux 1.1.45 on a P5/90.  It only crashes with -O3 or greater,
: and only with the i2.5.8p.  Every other 2.5.8 that I try doesn't have
: a problem with it.

--
I've been trying to find out what caused this pentium optimizer to crash,
and as a result I found it's aborting when trying to shedule the
instructions the best it can. As soon I get some time to search a little
more I will, but for now I have to much work to do so. 

I suspect the problem comes from an interaction between the optimisations
Intel added and the standard 2.5.8 optimiser. Anyone tried to crash the
original 2.4.0 from aurora.intel.com the same way ?

Laurent.
--
Laurent Chemla : [email-masked] or [email-masked]
Brasil BBS  - +33 1 44 67 08 44 -  Atari France developpers support

------------------------------

From: [email-masked] (John Richardson)
Subject: Re: Improving SLIP latency under Linux
Date: 14 Oct 1994 00:06:46 GMT

In article <[email-masked]>, Rob Janssen <[email-masked]> wrote:
>>I'm not sure about this: I don't think my modem has a transmit
>>buffer (hehe, try getting information from supra! Argh) and 
>>I have a laggy interactive response.  I have been in contact
>>with linux users who have faster modems with no internal buffers
>>at all who suffer from the same problem.
>
>All modems with error correction and compression have a transmit buffer.
>The only variation between modems may be how large this buffer is.
>

I don't believe this modem has either.  I don't know about my supra
though, I turn off data compression and correction (with the &f0 command).

--
John Richardson
[email-masked]

------------------------------

Crossposted-To: comp.os.linux.admin,comp.os.linux.help
From: [email-masked] (Frank Lofaro)
Subject: Re: Serious Bug In The Networking Code
Date: Thu, 13 Oct 94 19:47:06 GMT

In article <[email-masked]> [email-masked] writes:
>
>There appears to be a serious bug in some of the networking code
>supplied with linux/slackware, that causes the computer to get
>'network unreachable' after approximately 3 minutes of perfect
>functioning.  I have no idea what the problem might be, and if
>somebody tell me where to look, I can try to figure out what versions
>my drivers etc. are.  Here are the configurations I ve gotten this
>problem with:
>
>AMD DX2/66, 8Mb, VLB CL5428 1Mb with either
>* Etherlink II, kernel 1.1.50 and 1.1.49
>* SMC Ultra Combo, kernel 1.1.33, 1.1.49, 1.1.50
>       -tried both coax and TP
>* SMC Ultra something else, also with various kernels
>
>AMD 386/40, 12Mb,
>* SMC Ultra Combo, kernel 1.1.33
>
>The 386 works perfectly well with the network with both cards when
>using older software (Some old SLS distrib. I believe)
>
>I would very much like to know what is wrong, and how to fix it.
>
>There is also a 'bug' in df, causing a float exception when it cannot
>access a non-existent NFS-mount.
>
>Thanks for any help,
>--
>
> « Ketil Malde                        In real life:  [email-masked] »
> « Nuke The Whales!  Pave The Earth!  And Honk If You Love Unicorns! »

Are you running routed? The could cause routes to get dropped and 
thus Network unreachables to occur.

------------------------------

From: [email-masked] (Spencer Smith)
Subject: Re: Linux For Mac
Date: 12 Oct 1994 05:21:08 GMT

Oh Please! 
Why not post this to 
alt.i'm.flamebait.bend.over.and.shoot.the.napalm.here?
Please stick to Linux, an OS for all seasons and all reasons.

Spencer A. Smith
(Man   or  Myth?)

------------------------------

From: [email-masked] (Dave Perks)
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
Date: 11 Oct 1994 18:18:03 -0400

[email-masked] (Jeff Kuehn) writes:

>The results aren't particularly good.

>As several have mentioned previously,
>this is probably the fault of the process table handling and scheduling
>algorithms.  This needs to be fixed BADLY.

                                     ^ no, it needs to be fixed WELL :-)

-- 
Dave Perks              | [email-masked]        | [email-masked]
Gandalf Data Limited    | TEL 1-613-723-6500 x8765 |---------------------------
Nepean, Ontario, Canada | FAX 1-613-226-1717       | Soren Kierkegaard says
   "Life can only be understood backwards; but it must be lived forwards."

------------------------------

From: [email-masked] (Andrew R. Tefft)
Subject: Re: Filesystem idea
Reply-To: [email-masked]
Date: Thu, 13 Oct 1994 17:17:18 GMT

In article <[email-masked]>, schave@PROBLEM_WITH_INEWS_GATEWAY_FILE (Jeffrey Charles Schave) writes:
>Riku Saikkonen ([email-masked]) wrote:
>> space... What I'm suggesting is some sort of 'temp file' attribute that
>> would keep the file on disk until space runs low. Then, when the disk
>> space is almost 0, it would start deleting the temp files to free space.
>
>I don't think that a new file system is necessary for this.  An easy
>way to accomplish this is to write a shell script run every night,day
>,whatever(via cron). This script could check the amount of free space
>left on the drive, and if necessary, destroy any .o files.

I agree, because either you're going to slow down all file allocation
in seeking out and destroying these 'temporary' files when necessary,
or you're going to end up having some kind of daemon to basically do this
anyway. 

-- 

Andy Tefft               - new, expanded .sig -     [email-masked]

------------------------------

From: [email-masked] (Ralf Baechle)
Crossposted-To: comp.os.linux.help
Subject: Re: Question about ext2fs
Date: 13 Oct 1994 17:08:14 GMT

In article <[email-masked]>, "Eric Jeschke" <[email-masked]> writes:
|> Can someone with some knowledge of the ext2fs internals tell me
|> how intensive the disk activity is to certain blocks like the
|> superblock and inode bitmap blocks?  extfs is working fine, but
|> I'm afraid I have a poor quality disk (Seagate) that is not able
|> to handle the intense repeated disk activity to these blocks.

Neither read nor write activity does normally have a relation to the
number of errors on a disk, since heads never touch the disk surface
during normal operation.

Is is normal that sometimes a new bad bad block appears on a hard disk.
Especially on SCSI disks it is easy to map them out. But if the number
of bad blocks increases strongly in a short period of time, you really
should exchange your harddisk against a new one. Since most harddisks
have very long warranty this is even free in most situations.

|> I am slowly developing bad blocks on various inode bitmap blocks
|> (and now the superblock).  The kernel complains about getting a
|> "short read" on those blocks.  I am able to map them out successfully
|> using the -L option with ext2fs and the system recovers admirably,
|> but sooner or later the problem recurs with another block.  The
|> latest victim is the superblock on the root partition.  I am able
|> to e2fsck the partition using the -b 8193 option and averything seems
|> fine, however the system fails to mount it at bootup even though
|> I added sb=8193 to the mount options in /etc/fstab for /.
|> 
|> How can I successfully boot from this partition now?

I've recently made some experiences with about the same situation. Result:
make a Backup. Throw your harddisk away. Don't waste your time with trying
to boot.

  Ralf

------------------------------

From: [email-masked] (Frank Lofaro)
Subject: Re: Improving SLIP latency under Linux
Date: Thu, 13 Oct 94 19:55:28 GMT

In article <[email-masked]> [email-masked] (Al Longyear) writes:
>[email-masked] (Rob Janssen) writes:
>
>>>The best solution is to simply choose the priority when you do the
>>>transmission and then send it in that order.
>
>>That only helps when there are as little buffers as possible between the
>>point where this decision is made and the line.
>>Although the buffers in the modems are a problem, I don't think they are
>>the full explanation of 6 second roundtriptimes when an FTP is running.
>>Probably some frames get queued up in the kernel "waiting to be sent on
>>the serial line".  That is not good...
>
>Rob,
>
>New frames are merged into the list of frames bound for the SLIP/PPP/
>PLIP link in order based upon their priority. Each new frame is
>inserted into the list in sequence. They are not simply tacked on to
>the end of the list.
>
>So, yes, it is a very good solution to implement and use the
>IP_TOS. All higher priority frames will be sent before lower priority
>frames are sent.
>
>For this to work the best, you need to implement IP_TOS on both sides
>of the link. If you are doing an ftp transfer to read a large file,
>then it the remote side (the one running ftpd) which is doing the
>majority of the transmission. Their frames need to have a background
>(7) priority. The wu-ftpd process has had this implemented for some
>time. Unfortunately, not all implementations of TCP/IP support this
>logic. The BSD 4.3 code did not. I believe that it is in place for
>the BSD 4.4 code.
>

You could take care of the other side's ftp and background type 
processes from hogging the link by only offering a tiny TCP window when 
turnaround time gets too high. Yeah, it can hurt throughput, but 
interactive performance is more important. E.g. it is better to have 
an ftp take 10 minutes and your link be comfortable than to have the ftp 
take 5 minutes during which you tear out your hair because the link is 
sucking mud.

------------------------------

From: [email-masked] (Philippe Steindl)
Subject: Re: Linux Mud
Date: 11 Oct 1994 17:17:38 GMT

Hullo,

just to add, that the MudOS Drivers compile out of the box on a linux system.

Philippe

------------------------------

From: [email-masked] (Shaune Beattie)
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
Date: 13 Oct 1994 20:46:20 GMT

Hmm, think something might have gone wrong with your benchmarks... (the 
concurrent shell scripts that is). After reading your post I downloaded 
the byte benchmarks and ran them myself.
1) Before I get flamed I am *NOT* posting this as a childish 'my machine 
is faster than yours thing' but rather that I believe something to be 
wrong with the ones you posted.
Ok, the bechmarks were run on a P90-512k cache 16Meg PCI micronics mb 
conner 540M EIDE hd running kernel version 1.1.53. Both the kernel and 
the benchmarks were compiled using the pentium gcc with as much 
optimisation as possible. (nb. if anyone is interested i will post the 
benchmarks for 486 optimised code to show the gain in using the pentium 
gcc, in fact surpisingly little).
I indexed the results against the results you posted for the 1.1.0 kernel 
for comparrision.

                     INDEX VALUES            
TEST                                        BASELINE     RESULT      INDEX

Arithmetic Test (type = double)               5069.5    11922.9        2.4
Dhrystone 2 without register variables       56103.3   129726.8        2.3
Execl Throughput Test                           60.8       82.2        1.4
File Copy  (10 seconds)                       1310.0     1974.0        1.5
File Copy  (30 seconds)                        919.0     1865.0        2.0
File Read  (10 seconds)                     117181.0   224933.0        1.9
File Read  (30 seconds)                     117335.0   230322.0        2.0
File Write (10 seconds)                      13856.0    10039.0        0.7
File Write (30 seconds)                      13643.0    15055.0        1.1
Pipe-based Context Switching Test             8197.6     8683.4        1.1
Process Creation Test                          112.1      176.8        1.6
Shell scripts (1 concurrent)                    81.1      160.9        2.0
Shell scripts (2 concurrent)                     1.0       84.3       84.3
Shell scripts (4 concurrent)                     1.0       41.0       41.0
Shell scripts (8 concurrent)                     1.0       20.0       20.0
                                                                 =========
     SUM of 15 items                                                 165.2
     AVERAGE                                                          11.0

ok, first off, obviously most of the tests are faster by ~2 times... 
(would have expected slightly more... but thats benchmarks for you :)
the sole reason I'm posting this is to draw your attention to the Shell 
scripts 2,4,8... a factor of 2 is to be expected... but there is *NO* way 
my machine is 80 times faster than yours... I really think something 
might have gone astray there. Just that if you are spending time 
comparing kernel speeds (a task I don't envy after only running the 
benchmark 3/4 times) then it might be wise to look into this.

 -----------------------------------------------------------------------------
|Snail:                  |Email: (choose one of)     |Tel: +44(0)223 501878   |
|Shaune Beattie          [email-masked]            |(From 13/10/94)         |
|St. Catharine's College [email-masked] |Thought for the day...  |
|Cambridge CB2 1RL       [email-masked]   |I need a better sig :)  |
 -----------------------------------------------------------------------------

------------------------------

From: [email-masked] (Michael Griffith)
Subject: Re: Qlogic
Date: 11 Oct 1994 17:26:32 GMT

In article <[email-masked]>, Tillman Bussey <[email-masked]> wrote:
>Has there been any development for the Qlogic VL SCSI controller?  If so, which
>version, and where can I find it.
>
>Please send email.
>
>Thanks!

Try out:

        ftp://cs.ucr.edu/pub/linux/qlogic/stable

-- 
Michael A. Griffith ([email-masked])
Department of Computer Science
University of California, Riverside

------------------------------

From: [email-masked] (Peter Mutsaers)
Subject: Re: ext2fs vs. Berkeley FFS
Date: Wed, 12 Oct 1994 22:46:23 GMT

>> On 11 Oct 1994 18:10:55 GMT, [email-masked] (Basile
>> STARYNKEVITCH) said:

  Albert> 3: File managers will open them as directory trees, 
  Albert> because that is what they are, NOT record type files.  --

  BS> I agree on that.

  BS> However, i would like to say (with other people) that this is the Unix
  BS> way of doing. This is not neccesarily a good thing. The Unix plain
  BS> byte-stream file paradigm is outdated for todays needs.

Outdated? Why? In all 25 years of Unix's existance there have been
other operating systems (in fact I think the majority of them) that do
not treat files as a plain byte-stream, but that bloat the kernel with
all kinds of knowledge of the internals of the file.

Unix's idea of plain byte-streams has been very successful and
provides a lot of flexibility because assumptions on the contents of
files are put into user space. I see no recent developments whatsoever
that have changed such needs and have outdated this paradigm.
-- 
Peter Mutsaers                  |  AT Computing bv,  P.O. Box 1428,
[email-masked]                    |  6501 BK  Nijmegen, The Netherlands
tel. work: +31 (0)80 527248     |
tel. home: +31 (0)3405 71093    |  "... En..., doet ie het al?"

------------------------------

** 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-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************