lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory mail-archive

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:25:02 -05:00
parent 07129c3397
commit a778c607a4
1056 changed files with 796887 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

602
mail-archive/linux-devel/Volume1/digest5XX/digest550 Normal file
View File

@@ -0,0 +1,602 @@
Subject: Linux-Development Digest #550
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date: Sun, 13 Mar 94 23:13:04 EST
Linux-Development Digest #550, Volume #1 Sun, 13 Mar 94 23:13:04 EST
Contents:
Re: Lint for Linux? (Grant Edwards)
Re: Annoying interactive bug in nslookup? (Frank Lofaro)
Re: Amiga FileSystem, Anyone? (David Holland)
Re: Amiga File System, once again (Hamish Macdonald)
Re: A truely non-debugging Kernel? (Frank Lofaro)
Annoying interactive bug in nslookup? (G. "Wolfe" Woodbury)
Re: I'm developing UMSDOS Linux Pkg. (Jim Morris)
Re: UDP report card (Frank Lofaro)
Re: A truely non-debugging Kernel? (David C Ferovick)
Re: Possibly-fatal ISOFS bug +PATCH (Re: A truly non-debugging Kernel?) (Eric Youngdale)
Re: Startup code (DOS boot program) (Jon Peatfield)
Re: Amiga File System, once again (Alan Braggins)
Help increasing allowed # of processes (James D. Levine)
Re: UDP report card (Charles Hedrick)
Re: ircII compilation problems - Fix! (Jon Green)
Re: Take a look at this netstat, please... (Jon Green)
----------------------------------------------------------------------------
From: grante@aquarius.rosemount.com (Grant Edwards)
Subject: Re: Lint for Linux?
Date: Fri, 11 Mar 1994 19:04:47 GMT
Aubrey Jaffer (jaffer@zurich.ai.mit.edu) wrote:
: stevev@miser.uoregon.edu (Steve VanDevender) writes:
: elmnjb@unidhp.uni-c.dk (Niels J. Bagger) writes:
: As the title says: Does lint(1) exist for Linux?
: gcc -Wall is pretty close to lint for telling you about dumb C
: coding practices.
: Not close enough! If you code with K&R style function prototypes (as
: opposed to ANSI) then gcc -Wall tells you nothing about argument
: mismatch and number of arguments mismatch between modules.
: I have to code for a variety of machines not all of which support ANSI
: prototypes. Lint is essential for finding argument mismatch. I wish
: I could find a lint for linux so I wouldn't have to ship my code
: elsewhere just to use lint.
There's a company called Gimpel Software that sells a lint product in
shrouded source form for unix systems. They also sell MS-DOS and OS/2
binary versions. I've only seen the PC version, but it looked like a
decent product -- though you could spend the rest of your life getting
it configured juuuust right so that there weren't any spurious
messages.
It won a 1991 Computer Language / Jolt Cola product excellence award
according to the advert -- for what that's worth. :)
Gimpel Software
3207 Hogarth Lane
Collegeville, PA 19426
215 584 4261
215 584 4266 (fax)
--
Grant Edwards |Yow! Bo Derek ruined my
Rosemount Inc. |life!
|
grante@rosemount.com |
------------------------------
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: Annoying interactive bug in nslookup?
Date: Sun, 13 Mar 94 06:32:13 GMT
In article <ggw-110394104323@suemac.cds.duke.edu> ggw@cds.duke.edu writes:
>I've been using Linux (Slackware 1.1.2 0.99pl15 plus lots of sources)
>on a Pentium for several weeks now. The system is quite stable and
>is in regular use as our internet firewall/gateway machine.
>(Seagate N12400 with Adaptec 1542c SCSI disk, Diamond Stealth video,
>SMC Elite Combo ethernet card, zoom 14.4 modem, STB 4com, tb+)
>
>The only annoying thing that I can't find an easy answer/solution for
>is that the nslookup program doesn't like the "enter" key at the end of
>an inquiry (it takes two returns for it to recognize a query.)
>
>This has to be a known problem, but I can't find a mention in the NET HowTo
>(or am I blind?) and looking at the code seems to imply that it may be a
>problem in "flex"?
>
>Any comments would be appreciated.
>
>--
>Gregory G. "Wolfe" Woodbury @, but not speaking for Duke Univ.
>System Admin Demographic Studies Box 90408 Durham NC 27708
>ggw@cds.duke.edu ggw@acpub.duke.edu ggw@wolves.durham.nc.us
>"Myth is metaphor, and ritual is the enactment of myth."
If you get weird problems with interactive programs compiled with flex,
have flex get called with the -I (interactive) option.
------------------------------
Subject: Re: Amiga FileSystem, Anyone?
From: dholland@husc7.harvard.edu (David Holland)
Date: 13 Mar 94 04:10:44
kai@khms.westfalen.de's message of 12 Mar 1994 21:55:00 +0100 said:
> 1. Obscure & messy noes not mean it's not real workable.
True. But it's not real workable as an easy general solution -
compared to installing filesystems on an Amiga, for example. Or even
in Linux, where you do have to compile things.
> 2. What do you mean, "not necessarily supported"?!
I mean that Microsoft won't support it. Microsoft has been known to
intentionally change these things to try to break somebody else's
program. Maybe the existence of Novell DOS will stop them now, maybe
not; who knows?
> 3. *Of course* you are limited to 8+3 - that's DOS's *concept* of a
> filesystem.
Well, that's broken, and makes it impossible for DOS to really use
most other filesystems. :-)
> 4. Various programs are either not suitable for working with anything but
> a FAT file system, because they know too much about it, or else have
> stupid bugs. It's the same with, say, Unix & NFS.
True...
> NETX is simply stone-age code.
That's obviously the case. It seems the state of the art has managed
to improve a bit since I last really paid attention to the DOS world
(which wasn't all that long ago, before everybody jumps down my throat.)
> > Obviously, you disagree. But I don't see why that should mean I don't
> > know what I'm talking about.
>
> It might have something to do with having or not having good arguments ...
> :-)
Evidently. Isn't it amazing how much easier it when people explain
instead of just saying "you're an idiot"?
So when is the ext2fs for DOS going to be ready? :-]
--
- David A. Holland | "The right to be heard does not automatically
dholland@husc.harvard.edu | include the right to be taken seriously."
- - - - - - - - - -
This message shall NOT be quoted or copied out of the electronic medium
in which it originated without explicit permission from the author.
------------------------------
From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
Subject: Re: Amiga File System, once again
Date: 13 Mar 1994 19:47:52 GMT
>>>>> On 11 Mar 1994 09:59:26 EST,
>>>>> In message <ARMB.94Mar11145929@hamsta.setanta.demon.co.uk>,
>>>>> armb@setanta.demon.co.uk (Alan Braggins) wrote:
Alan> At least one of the questioners had Amiga floppies, but no
Alan> longer had access to an Amiga. I use a Linux PC at work, and
Alan> would prefer to transfer stuff home to an Amiga without having
Alan> to go through 8+3 character case-insensitive filenames. So. if
Alan> such a filesystem could be written, it would have (limited)
Alan> uses.
You could presumably put an AmigaDOS filesystem on a physically
PC-formatted (720K) floppy, and then read the floppy on the Amiga.
Alan> (Someone did ask if minix or ext2 filesystems existed for
Alan> AmigaDos (working in a similar way to CrossDos/MessyDos), but I
Alan> didn't see an answer.
I thought that I'd mentioned that at one time someone was working on a
Minix filesystem for AmigaDOS. I'll have to ask the author if he's
continued work on it (and/or would be willing to give out his source).
------------------------------
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: A truely non-debugging Kernel?
Date: Sun, 13 Mar 94 20:50:37 GMT
In article <1994Mar12.195624.9113@rpp386> jfh@rpp386.cactus.org (John F. Haugh II) writes:
>In article <DOUG.94Mar11165709@midget.towson.edu> doug@midget.towson.edu (Doug McNaught) writes:
>>In article <2loo9h$fo8@aurora.engr.latech.edu> ramos@engr.latech.edu (Alex Ramos) writes:
>>
>>>Geez! The kernel has _so much_ debugging code (sanity checks, etc) that
>>>I wonder how much smaller it could be. It seems most kernel developers
>>>have never heard of #ifdef... Just a thought :-)
>>
>> Well, I'd rather give up some memory and have something that panics
>>and shuts itself down rather than blindly hosing my filesystems and/or
>>hardware... I *like* sanity checks. A lot.
>
>That's all or nothing thinking -- ship the kernel with #ifdef DEBUG and
>after a few weeks when you are happy, recompile with -UDEBUG.
>
Well what do you do then if the kernel suddenly goes bonkers one day,
and clobbers you /usr partition or something awful like that?!
Commerical un*xes have sanity checks, etc, why shouldn't Linux? Plus, if
you have a very intermittent problem, the debug stuff might make it
possible to find out what it is, else you'll never know. You'd have to
recompile with debugging after the fact and wait for it to happen again.
That might be an uncomfortable wait for those with mission-critical or
security related problems.
------------------------------
From: ggw@acpub.duke.edu (G. "Wolfe" Woodbury)
Subject: Annoying interactive bug in nslookup?
Date: Fri, 11 Mar 1994 10:43:23 -0500
Reply-To: ggw@cds.duke.edu
I've been using Linux (Slackware 1.1.2 0.99pl15 plus lots of sources)
on a Pentium for several weeks now. The system is quite stable and
is in regular use as our internet firewall/gateway machine.
(Seagate N12400 with Adaptec 1542c SCSI disk, Diamond Stealth video,
SMC Elite Combo ethernet card, zoom 14.4 modem, STB 4com, tb+)
The only annoying thing that I can't find an easy answer/solution for
is that the nslookup program doesn't like the "enter" key at the end of
an inquiry (it takes two returns for it to recognize a query.)
This has to be a known problem, but I can't find a mention in the NET HowTo
(or am I blind?) and looking at the code seems to imply that it may be a
problem in "flex"?
Any comments would be appreciated.
--
Gregory G. "Wolfe" Woodbury @, but not speaking for Duke Univ.
System Admin Demographic Studies Box 90408 Durham NC 27708
ggw@cds.duke.edu ggw@acpub.duke.edu ggw@wolves.durham.nc.us
"Myth is metaphor, and ritual is the enactment of myth."
------------------------------
Crossposted-To: comp.os.linux.misc
From: jmorris@darkstar.rastek.com (Jim Morris)
Subject: Re: I'm developing UMSDOS Linux Pkg.
Date: Thu, 10 Mar 1994 17:47:04 GMT
I think Patrick has already done what you propose, with the recent
Slackware 1.1.2 UMSDOS disk set. By using the UMSDOS Boot/Root disk combo,
as well as a couple of other UMSDOS disks, you can install the Linux Slackware
distibution (as much or as little as you like of it) onto an MS-DOS formatted
disk.
I believe that he requires you to have 8MB or RAM to install with UMSDOS,
because if your hard disk is formatted for DOS, odds are you are not going to
be able to create a swap partition for the install process to use.
I also think that Patrick's notes on Slackware 1.1.2 state that the smallest
UMSDOS installation (UMSDOS and A diskette series) is around 12MB of hard
disk space.
Jim Morris
(jmorris@rastek.com)
------------------------------
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: UDP report card
Date: Sun, 13 Mar 94 21:07:39 GMT
In article <2lts98$2dq@cronkite.ocis.temple.edu> jwiegand@opus.temple.edu (The Answer is 42.) writes:
>In article <CMGMss.KH@aston.ac.uk> evansmp@mb48026.aston.ac.uk (Mark Evans) writes:
>>gans (gans@acf2.nyu.edu) wrote:
>>
>>: We've got a situation at NYU where a number of hostile entities
>>: regularly broadcast 127.0.0.1 over the local net... And some
>>: linux boxes, including mine, respond (which I do not think is
>>: correct behavior).
>>
>>It is a common problem, 127.0.0.2 can be even more dangerous, quite a few
>>machines only have 127.0.0.1 rather than 127.0.0.0 as a route to loopback.
>>Thus such an address can end up going through serveral machines, simply
>>being forwarded to default routes until it gets to a machine which accepts
>>it. In some instances telnet 127.0.0.2 will connect you to a (psudo-random)
>>machine somewhere on the internet.
>Just out of curiousity, I tried this, and boy was I surprised:
>
>opus:~/News jim$ /usr/etc/ping 127.0.0.2
>ICMP Host Unreachable from gateway Washington2.Dante.net (192.77.156.2)
> for icmp from opus (129.32.25.70) to 127.0.0.2
>
>I don't even know where this machine is at! Couldn't find it w/nslookup
>on the Suns.
>
>jim
>howabout that
Linux USED TO handle 127.x.x.x right for all values of x.
Now all 127.x.x.x address other than 127.0.0.1 seem to try to send out
the default route.
This is bad, can we bring back the old behavior (thus not violating the RFC's
anymore like we are now)?
It was nice, when I could boast Linux networking was the only implementation
that knew 127.x.x.x was ALWAYS loopback, for all x.
------------------------------
From: ferovick@runner (David C Ferovick)
Subject: Re: A truely non-debugging Kernel?
Date: Sun, 13 Mar 1994 22:24:42 GMT
In article <1994Mar13.205037.24215@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
>In article <1994Mar12.195624.9113@rpp386> jfh@rpp386.cactus.org (John F. Haugh II) writes:
>>In article <DOUG.94Mar11165709@midget.towson.edu> doug@midget.towson.edu (Doug McNaught) writes:
>>>In article <2loo9h$fo8@aurora.engr.latech.edu> ramos@engr.latech.edu (Alex Ramos) writes:
>>>
>>>>Geez! The kernel has _so much_ debugging code (sanity checks, etc) that
>>>>I wonder how much smaller it could be. It seems most kernel developers
>>>>have never heard of #ifdef... Just a thought :-)
>>>
>>> Well, I'd rather give up some memory and have something that panics
>>>and shuts itself down rather than blindly hosing my filesystems and/or
>>>hardware... I *like* sanity checks. A lot.
>>
>>That's all or nothing thinking -- ship the kernel with #ifdef DEBUG and
>>after a few weeks when you are happy, recompile with -UDEBUG.
>>
>
>Well what do you do then if the kernel suddenly goes bonkers one day,
>and clobbers you /usr partition or something awful like that?!
>Commerical un*xes have sanity checks, etc, why shouldn't Linux? Plus, if
>you have a very intermittent problem, the debug stuff might make it
>possible to find out what it is, else you'll never know. You'd have to
>recompile with debugging after the fact and wait for it to happen again.
>That might be an uncomfortable wait for those with mission-critical or
>security related problems.
>
Well, if there was #ifdef's in there, it would be the USER's choice to run
witht the debugging code or not...If a user thinks he may have a problem
or is paranoid about not having the debugging code in the kernel, then they
can leave it running. If you want to save memory and increase performance,
then the user can take the risk of #undef'ing the debug code...
--
Dave Ferovick
(ferovick@runner.jpl.utsa.edu)
------------------------------
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Possibly-fatal ISOFS bug +PATCH (Re: A truly non-debugging Kernel?)
Date: Sun, 13 Mar 1994 22:33:17 GMT
In article <2lt8is$6d2@smurf.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:
>NB: The whole idea of kmalloc()ing the data space for an inode should be
>ripped out of the isofs code. Returning a random error message on random
>file system requests, just because memory is low and the files happen to be
>on a CD-ROM, is not my idea of reliability. The patch affixed below only
>prevents you from simply crashing instead of getting the error message in a
>low-mem situation. Better, but not optimal.
Since I wrote this, I feel the need to defend what I did. There is a
basic problem that a cdrom has a sector size of 2048 bytes, and the default
linux buffer size is 1024 bytes. Before we had the ability to use blocks !=
1024 bytes, it was sometimes required that we splice together the two halves of
a 2048 byte sector in order to make sense of the directory entries which span
the boundary. If instead we tried to use a structure that was split over
Note that now we do have the ability to use blocks != 1024 bytes (try
mount -t iso9660 -o block=2048 /dev/sr0 /mnt). This is still not perfect,
however because ZMAGIC binaries have a 1024 byte header, and to be able to
execute binaries directly from a cdrom you generally want to be able to mmap
the file. Since the first page of the file resides at offset 1024 to
1024+4096, this means that it would span the region from sector 0, offset 0x400
to sector 2 offset 0x3ff. Unfortunately this screws up mmap somewhat because
the buffer cache is not set up to split buffers across page boundaries. In
less technnical terms you sacrifice demand loading and the sharing of pages
between the buffer cache and process text pages by using ZMAGIC binaries from a
cdrom mounted with a 2048 byte blocksize. One way around this is to simply use
QMAGIC binaries, and if you are cutting a cdrom this would probably be a good
thing to do. One of the reasons that I modified the kernel/linker/gdb was to
support this.
>The _other_ bug fixed by the patch can bite you anytime. I think the fact
>that it doesn't seem to have seriously bitten anybody yet is nothing short of
>amazing.
No, I think that kfree is atomic, and until you call some other
function that requests memory, you can technically still use the memory. It is
wrong, of course, and I forwarded these patches to Linus, but it does not
surprise me in the least that no one has encountered this.
-Eric
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
------------------------------
From: jp107@amtp.cam.ac.uk (Jon Peatfield)
Subject: Re: Startup code (DOS boot program)
Date: Sat, 12 Mar 1994 02:27:35 GMT
Several people have said "Use bootlin" (mostly by mail.)
>>> I've tried the bootlin stuff referenced by the LILO documentation but
>>> it doesn't work on any of the machines I've tried it on.
Is what I said in my initial post. In case it matters the only
bootlin I can find is dated from early 1992, if there is a more recent
version perhaps this solves my problems.
The problem with bootlin is that it assumes that not much has been
loaded into the machine when it starts up and it doesn't seem to
support modern kernels. The reason I suggested the strange order of
loading:
> a. From a DOS executable load the kernel into some memory (may need
> DOS network devices etc up)
> b. Make BIOS calls needed by (1) to get parameters.
> c. Disable interrupts, move myself to beyond 0x098000 (and jump there)
> d. move kernel to where it wants to live including the first 2.5K at
> 0x090000 the rest at 0x010000, copy parameters from (b)
> e. Run the (2) startup code thus starting the kernel.
was so that the only calls needing the BIOS or DOS are before we stomp
on the DOS/BIOS areas of memory. From the lack of positive responce
that noone else needs this, so I'll go off into a corner and try it
myself.
A couple of people pointed out that QEMM and some other systems might
get in the way. I don't need to worry about them but others might...
--
Jon Peatfield, Computer Officer, the DAMTP, University of Cambridge
Telephone: (+44 223) 3-37852 Mail: J.S.Peatfield@amtp.cam.ac.uk
PP breaks RFC-822 when forwarding SMTP->SMTP mail. PP: Just say NO.
------------------------------
From: armb@setanta.demon.co.uk (Alan Braggins)
Subject: Re: Amiga File System, once again
Date: Fri, 11 Mar 1994 14:59:26 GMT
In article <2lmrfu$db9@wizard.uark.edu> dfaulkne@comp..uark.edu (Donald Faulkner) writes:
> file system is needed. PC users don't need an Amiga file system, and
> the rest of us who have Amigas can use CrossDos(tm) or MSH, or some
> other transfer system to create a PC-readable disk. So on the PC side,
> an Amiga file system is kindof useless.
At least one of the questioners had Amiga floppies, but no longer had
access to an Amiga. I use a Linux PC at work, and would prefer to
transfer stuff home to an Amiga without having to go through 8+3
character case-insensitive filenames. So. if such a filesystem could
be written, it would have (limited) uses.
(Someone did ask if minix or ext2 filesystems existed for AmigaDos
(working in a similar way to CrossDos/MessyDos), but I didn't see an
answer. It may be a better answer to transferring files LinuxPC -> Amiga.)
--
Alan Braggins armb@setanta.demon.co.uk abraggins@cix.compulink.co.uk
"Any technology distinguishable from magic is insufficiently advanced"
------------------------------
From: jdl@netcom.com (James D. Levine)
Subject: Help increasing allowed # of processes
Date: Sun, 13 Mar 1994 22:44:00 GMT
I'm trying to increase maximum number of processes for my pl14 kernel,
with no luck.
I found constants called NR_TASKS in tasks.h, and the derived constant
MAX_TASKS_PER_USER in fork.c. Increasing NR_TASKS and rebuilding the
kernel does nothing for me. Fork still fails at about 40 total processes.
I've put prink's in all branches of fork.c to try to see what's
happening, but I don't get any messages, so I assume you need to run a
daemon (syslogd?) to see them.
Any pointers?
James
------------------------------
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Subject: Re: UDP report card
Date: 13 Mar 94 22:50:53 GMT
ftlofaro@unlv.edu (Frank Lofaro) writes:
>Linux USED TO handle 127.x.x.x right for all values of x.
>Now all 127.x.x.x address other than 127.0.0.1 seem to try to send out
>the default route.
>This is bad, can we bring back the old behavior (thus not violating the RFC's
>anymore like we are now)?
I'm not convinced that it's right for 127.0.0.2 to be regarded as
loopback. But if you want it, you can get it. It's all a matter of
how you set up routing when you turn on loopback. I just enabled lo
(which I normally don't have running) using
ifconfig lo 127.0.0.1
route -n add 127.0.0.0 dev lo
Ping works equally well to 127.0.0.1 or 127.0.0.200.
------------------------------
From: jon@cs.iastate.edu (Jon Green)
Subject: Re: ircII compilation problems - Fix!
Date: 12 Mar 94 02:50:43 GMT
ekimmina@pms709.pms.ford.com (Eric Kimminau) writes:
>I fought with trying to get ircII2.2.9 to compile on Linux 99.14+ for
>about a week until I saw the Makefile from another person who hadn't
>had any problems. Every time I would try to compile I was getting a
>error reported from ld: libl missing. I use irc over ppp, he uses it
>over term as a side note. After comparing our makefiles, I had to
>change the LEX= line from lex to flex and the LEX_DEFINE= line from
>-ll to no arguments.
You could have saved yourself a week of time by reading the Makefile:
# Set this to the lex you want to use, and if they lex uses a library.
# linux will want LEXLIB set to nothing.
LEX = lex
LEXLIB = -ll
I've also made a symlink from /usr/lib/libl.a to /usr/lib/libfl.a for
the future.
------------------------------
From: jon@cs.iastate.edu (Jon Green)
Subject: Re: Take a look at this netstat, please...
Date: 12 Mar 94 02:55:07 GMT
psmith@iies.ecn.purdue.edu (Paul Smith) writes:
>Active Internet connections
>Proto Recv-Q Send-Q Local Address Foreign Address (State)
>tcp 148 0 eucd.adpc.purdue.:1130 TSX-11.MIT.ED:ftp-data CLOSE_WAIT off (0.00/0) 0
>tcp 716 0 eucd.adpc.purdue.:1234 wcarchive.cdr:ftp-data CLOSE_WAIT off (0.00/0) 0
>I did this netstat at ~3:00 PM (my time). I had performed these
>two ftp's over *4* hours earlier. Why haven't these closed down?
I've noticed the same problem when using term with tredir. If it closes
unexpectedly, the connection won't close properly and hangs there in
CLOSE_WAIT. I have to reboot to get the port back. This has also happened
when running a mud on port 4000 and telnetting to localhost from another
console (I'm not on a network). What's the deal here?
------------------------------
** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and comp.os.linux.development) via:
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
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
******************************