539 lines
21 KiB
Plaintext
539 lines
21 KiB
Plaintext
Subject: Linux-Development Digest #584
|
|
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, 27 Mar 94 20:13:08 EST
|
|
|
|
Linux-Development Digest #584, Volume #1 Sun, 27 Mar 94 20:13:08 EST
|
|
|
|
Contents:
|
|
Re: Proposal - Coordinating bug fixes with enhancements. (Harvey J. Stein)
|
|
Floppy Device Driver Hung System (andy@piziali.lonestar.org)
|
|
sendmsg and recvmsg under linux (Mahesh Neelakanta)
|
|
Re: Mapping the text screen into user space (i.e. KDMAPDISP, mmap, etc): SOLVED!!!! (Matthias Urlichs)
|
|
Re: 486DLC support anyone? (Raymond E. Rogers)
|
|
Re: TCP/IP-Bug in 1.0 Kernel? (Rene COUGNENC)
|
|
Re: How to use VARARGS under Linux ? (Rene COUGNENC)
|
|
starlan / pcnau ethernet drivers? (root@jaxnet.com)
|
|
Re: bug/feature in fcntl syscall (Frank Lofaro)
|
|
Re: unsupported keys (scancode (xx) not in range 00 - 5f) (Andries Brouwer)
|
|
Re: How to use VARARGS under Linux ? (mhomer@desire.wright.edu)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
Subject: Re: Proposal - Coordinating bug fixes with enhancements.
|
|
From: hjstein@sunset.huji.ac.il (Harvey J. Stein)
|
|
Date: 27 Mar 94 17:06:50
|
|
|
|
In article <1994Mar23.014820.798@compiler.tdcnet.nl>
|
|
jvoosten@compiler.tdcnet.nl (J.S. van Oosten) writes:
|
|
|
|
Harvey J. Stein (hjstein@sunset.huji.ac.il) wrote:
|
|
|
|
: The way I see it, there are two general classes of changes that are
|
|
: made, namely bug fixes & enhancements.
|
|
|
|
I don't see it as strict: a lot of time short enhancements are included,
|
|
often a few lines of code that run faster or better as it should be, but
|
|
you can also see them as fixes then.
|
|
|
|
And in most cases, enhancements are shipped together with bugsfixes in a
|
|
single patch, and otherwise your coherency with the "real" sources would
|
|
break down very soon.
|
|
|
|
Yes, I do understand that the two classes overlap.
|
|
|
|
: My idea is to use a version number scheme that basically marks where
|
|
: the enhancements occur. It wouldn't be so different than the current
|
|
: method of numbered & lettered patch levels, except that there would be
|
|
: meaning in when the numbers & letters change.
|
|
|
|
: We could keep track of enhancements versus bug fixes by having
|
|
: versions consisting of four numbers (like internet addresses). We'd
|
|
: have Linux Version a.b.c.d, where c & d would be left out when they're
|
|
: zero. The meaning would be as in the following example:
|
|
|
|
Needlessly complex. Heck, if I save those patches on MS-DOS floppy I want to
|
|
spend a few letters on the word 'kernel' or 'linux' or something like that,
|
|
not a big row of numbers !
|
|
|
|
Yes, I agree that this was needlessly complex. My first proposal was
|
|
bad.
|
|
|
|
|
|
: Maybe pl<number> would be a minor release,
|
|
: just including bug fixes, pl<number><letter> would represent an
|
|
: enhancement when <letter> is a-l & bug fixes only from m-z, so that
|
|
: pl<n+1> is the same as pl<n><letter>, where <letter> is the last
|
|
: kernel in the pl<n> series, after bug fixes have been going in for
|
|
: afew lettered releases.
|
|
|
|
Excuse my sarcasm, but how are you going to explain to a relative new person
|
|
in Linux that pl103f could actually be newer than pl103q ??
|
|
|
|
That's not what I meant. I meant that new features would only be
|
|
allowed into the first 12 patches (pl<x>[a-l]), and bug fixes would
|
|
only be allowed into the remaining patch levels (pl<x>[m-z]). The
|
|
patches would still obey condition that pl<x><y> is older than
|
|
pl<x><z> when y < z.
|
|
|
|
: Or, we could use even and odd. Even numbered patch levels could be
|
|
: the kernels where enhancements go, and odd numbered patch levels could
|
|
: be bug fix only kernels. I think I like this last alternative the best.
|
|
|
|
Hmm, and get questions like: "I've seen pl103a, b, c & e, but where's 'd' ?"
|
|
|
|
No. I meant that pl103a, b, c, ... would be enhancements & bug fixes,
|
|
and at some point, development would switch to pure bug fixes with
|
|
pl1041, b, c, ...
|
|
|
|
: If people want to make this even stronger, they could even do as was
|
|
: done with version 1.0, namely having well defined times where
|
|
: enhancements are allowed in.
|
|
|
|
Now there's a point here. Since we're now (hopefully) released from the
|
|
'taming' as we were slowing growing to 1.00 with 0.99.14abcd.. 0.99.15abcd..
|
|
because we were running out of version numbers :-), we could now do this:
|
|
|
|
- New features in linux Like new drivers, code for advanced things like rpc,
|
|
and other stuff we come up with, are held back to a new major release,
|
|
that increases the version number by 1 (so the next major would be
|
|
linux 2.0)
|
|
|
|
- fixes etc. increase the version by a hundreth, so we get linux 1.01, 1.02,
|
|
1.03 and so on.
|
|
|
|
- The last fix _before_ a new major release gets number x.99, to indicate
|
|
that no newer fixes are expected for this release level. This would
|
|
be a stable, thoroughly debugged version you could use on the machines
|
|
at work, for example. The version (x+1).00, .01 .02 .. will be used
|
|
as the next development platform.
|
|
|
|
My .02
|
|
|
|
Well, yes, this was basically the effect that I was trying to have,
|
|
namely:
|
|
|
|
1. That there would be alternating stages of development, one which
|
|
only allows bug fixes, and one that also allows enhancements.
|
|
2. That by looking at the version numbers one can tell which stage
|
|
a given version belongs to.
|
|
3. That version that look like "major" releases, such as versions
|
|
1.0, 2.0, etc, be the last version at the end of a bug fix
|
|
state.
|
|
|
|
The reason for point 3 is so that what looks naively like a big new
|
|
version (which everyone is going to run out and get), will actually be
|
|
relatively stable and trouble-free, thus reducing network messages of
|
|
the form "I just got version 5.0 & am having all these problems."
|
|
|
|
However, there are two problems with my message. Firstly, that
|
|
most of my suggestions were quite clumsy, poor, and didn't achieve
|
|
points 1, 2 & 3. Secondly, and more importantly, I had stupidly made
|
|
this proposal when such a scheme is already in effect (as I have been
|
|
reminded of by net posts & by email).
|
|
|
|
So, let's just let this thread die. I forgot that this was already
|
|
handled, and so never should have posted on the subject.
|
|
|
|
Just to finalize everything, here's how things currently work:
|
|
|
|
----------------- Begin included message -----------
|
|
|
|
From: Linus Torvalds <torvalds@cc.helsinki.fi>
|
|
Apparently-To: hjstein@MATH.HUJI.AC.IL
|
|
Subject: Re: Proposal - Coordinating bug fixes with enhancements.
|
|
Date: Sun, 27 Mar 1994 11:44:40 +0300
|
|
|
|
In article <HJSTEIN.94Mar22183141@sunset.huji.ac.il>,
|
|
Harvey J. Stein <hjstein@sunset.huji.ac.il> wrote:
|
|
>
|
|
>We could keep track of enhancements versus bug fixes by having
|
|
>versions consisting of four numbers (like internet addresses). We'd
|
|
>have Linux Version a.b.c.d, where c & d would be left out when they're
|
|
>zero. The meaning would be as in the following example:
|
|
>
|
|
>Version Status
|
|
>1.0 Major release (only bug fixes).
|
|
>1.0.0.1 Enhancement added.
|
|
>1.0.0.2 Bug fix.
|
|
...
|
|
|
|
There is already a "official" way to do this, which is
|
|
|
|
1.0 Stable (hope)
|
|
1.0.x minor bugfixes
|
|
|
|
1.1 development
|
|
1.1.x bugfixes, new features, more development
|
|
|
|
After 1.1.x seems to be stable, we rename the last version as
|
|
|
|
1.2 Stable
|
|
1.2.x minor bugfixes
|
|
|
|
1.3 development
|
|
1.3.x bugfixes, new features, more development
|
|
|
|
etc.. So even minor numbers would be stable releases, while odd minor
|
|
numbers would be development releases. Both have patchlevels, but the
|
|
stable releases would have only bugfixes.
|
|
|
|
In fact, the above has already taken effect: there is a "v1.0" directory
|
|
on ftp.funet.fi and ftp.cs.helsinki.fi which contains the 1.0 fixes:
|
|
four small patches so far, and a fifth probably appearing today. The
|
|
four first ones help stabilize networking on busy nets, while the fifth
|
|
one has a few assorted bugfixes.
|
|
|
|
1.0 seems reasonably stable even as it is, but the idea would be that
|
|
most people could upgrade with at least the 1.0.x patches, as those
|
|
should be safe. The "live on the edge" people would get the 1.1 sources
|
|
(which I haven't made yet, but will make next week).
|
|
|
|
Linus
|
|
|
|
----------------- End included message -----------
|
|
|
|
Although this doesn't satisfy my point 3, it is clean & simple, so
|
|
I still think it's fine. So, as with Linux in general, the bugs have
|
|
been fixed before I even noticed them. So we can just drop this
|
|
thread and continue work on problems which still exist. :)
|
|
|
|
Thanks,
|
|
|
|
--
|
|
Harvey J. Stein
|
|
Department of Mathematics
|
|
Hebrew University
|
|
hjstein@math.huji.ac.il
|
|
|
|
------------------------------
|
|
|
|
From: andy@piziali.lonestar.org
|
|
Subject: Floppy Device Driver Hung System
|
|
Reply-To: andy@piziali.lonestar.org
|
|
Date: Sun, 27 Mar 1994 16:55:59 GMT
|
|
|
|
Yesterday, I inadvertently attempted to copy a 720 KB file (floppy image) to
|
|
an unformatted 720 KB 3.5 inch floppy using
|
|
|
|
dd bs=9k if=fdImage of=/dev/fd1D720
|
|
|
|
The result was continuous attempts by the floppy device driver to write sectors
|
|
which it could not find. /usr/log/notice reported
|
|
|
|
Mar 26 19:58:30 piziali kernel: VFS: Disk change detected on device 2/17
|
|
Mar 26 19:58:47 piziali kernel: floppy 1: sector not found: track 29,
|
|
head 1, sector 3
|
|
Mar 26 19:58:49 piziali last message repeated 3 times
|
|
Mar 26 19:58:49 piziali kernel: Reset-floppy called
|
|
Mar 26 19:58:49 piziali kernel: floppy 1: sector not found: track 29,
|
|
head 1, sector 3
|
|
Mar 26 19:58:49 piziali kernel: Reset-floppy called
|
|
:
|
|
Mar 26 19:58:53 piziali kernel: floppy I/O error
|
|
Mar 26 19:58:53 piziali kernel: dev 0211, sector 532
|
|
Mar 26 19:58:53 piziali kernel: Reset-floppy called
|
|
|
|
Attempts to kill the errant process with any signal, including SIGKILL (9),
|
|
were ineffective. I could not log in as root to shut down the system.
|
|
CTL-ALT-DEL, which is normally recognized by init to run shutdown(8), was also
|
|
ineffective.
|
|
|
|
Could I have something misconfigured or is this a known problem with the
|
|
floppy device driver? I would have expected the driver to give up after some
|
|
number of unsuccessful write attempts but, after five minutes of floppy drive
|
|
abuse, I gave up on it. The system RESET switch was my only option.
|
|
|
|
--
|
|
Andy Piziali |
|
|
________------+------________
|
|
/ \
|
|
andy@piziali.lonestar.org *---*
|
|
|
|
------------------------------
|
|
|
|
From: mahesh@sendai.seq.com (Mahesh Neelakanta)
|
|
Subject: sendmsg and recvmsg under linux
|
|
Date: Fri, 25 Mar 1994 23:20:43 GMT
|
|
|
|
Does linux have support for the sendmsg and recvmsg functions? It looks
|
|
like they aren't in the current kernel (1.0) + libc (4.5.21) but perhaps
|
|
someone is in the process of writing this portion of code?
|
|
|
|
Any pointers appreciated...
|
|
|
|
thanks,
|
|
mahesh@seq.com
|
|
|
|
------------------------------
|
|
|
|
From: urlichs@smurf.noris.de (Matthias Urlichs)
|
|
Subject: Re: Mapping the text screen into user space (i.e. KDMAPDISP, mmap, etc): SOLVED!!!!
|
|
Date: 27 Mar 1994 20:27:04 +0200
|
|
|
|
In comp.os.linux.development, article <1994Mar21.182350.5194@sendai.seq.com>,
|
|
mahesh@sendai.seq.com (Mahesh Neelakanta) writes:
|
|
>
|
|
> Which leads me to one final question: Can someone explain why the '<< 1' is
|
|
> needed in the code fragment below? My guess is in the comments below which
|
|
> I figured/guessed/voodoo by reading around in console.c.
|
|
>
|
|
Guess again.
|
|
|
|
The reason is that each position on the screen occupies 16 bits (character,
|
|
attributes). Therefore a 1-byte shift doesn't make sense, and therefore the
|
|
designers have decided to drop the low bit of the offset and shift the
|
|
register contents right one notch. You of course have to reverse that when
|
|
you read the offset.
|
|
|
|
--
|
|
>> To be is to do To do is to be Do be do be do
|
|
(Socrate) (Sartre) (Sinatra)
|
|
--
|
|
Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de
|
|
Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email.
|
|
90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
|
|
|
|
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
|
|
|
|
------------------------------
|
|
|
|
From: rrogers@netcom.com (Raymond E. Rogers)
|
|
Subject: Re: 486DLC support anyone?
|
|
Date: Sat, 26 Mar 1994 04:09:56 GMT
|
|
|
|
In article <pm7OJWA.spu@delphi.com>, <spu@delphi.com> wrote:
|
|
>I set up for the internal cache ( I have no external cache ) but had to
|
|
>disable it because teh cpu kept interrupting my mathco and gave me stack
|
|
>under and overflow errors, and invalid compressed format when uncompressing
|
|
>linux. The mathco errors also occurred with dos, so I know they were not
|
|
>Linux specific. Anyone else had this problem? Will external cache stop it?
|
|
|
|
Funny you should mention this. It might be out of place but I
|
|
have a UMC386 ISA BUS motherboard, with 486 DLC-33, 128k external
|
|
cache, and no co-proc. I must disable the internal cache to work
|
|
reliably at all! Otherwise I get random disasters. Is there a magic
|
|
formula for this?
|
|
As long as I'm here, I can't get the Slackware boot disk 1_2m to
|
|
boot, so I can do a Linux installation. This is probably due to only
|
|
having 2Mbytes, but I have read that this is possible. If there is a
|
|
special flag to deal with this I can't find it ( for Slackware ). I've
|
|
also downloaded and read 1MB of docs and found no help. Could somebody
|
|
steer me in the right direction; I'm short of money now and will probably
|
|
have to live with 2Mbytes for a while.
|
|
|
|
Ray
|
|
|
|
------------------------------
|
|
|
|
From: rene@renux.frmug.fr.net (Rene COUGNENC)
|
|
Subject: Re: TCP/IP-Bug in 1.0 Kernel?
|
|
Date: 25 Mar 1994 20:24:33 GMT
|
|
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)
|
|
|
|
Ce brave Michael Will ecrit:
|
|
|
|
> I have noticed that SLIP does work with 1.0 but has problems running
|
|
> ftp and the like with anything beyond that. I tried 1.0p2 and 1.0p4 but
|
|
> had to go back to 1.0 to work with SLIP.
|
|
|
|
|
|
Same for me, SLIP and PPP.
|
|
|
|
--
|
|
linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux
|
|
|
|
------------------------------
|
|
|
|
From: rene@renux.frmug.fr.net (Rene COUGNENC)
|
|
Subject: Re: How to use VARARGS under Linux ?
|
|
Date: 25 Mar 1994 20:42:46 GMT
|
|
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)
|
|
|
|
Ce brave Zenon Fortuna ecrit:
|
|
|
|
> I would like to use the VARARGS principle (to pass to a function varying list
|
|
> of arguments). I have noticed that there exists vsprintf(), exists also
|
|
> Still, I cannot compile my sample VARARGS program, because a lot of
|
|
> declarations are missing:
|
|
|
|
Avoid "varargs" when you can, it is old; use "stdarg" instead.
|
|
A typical use is
|
|
|
|
#include <necessarystuff>
|
|
#include <stdarg.h>
|
|
|
|
your_function( char *format, ...)
|
|
{
|
|
char buf[ YOUR_SIZE ];
|
|
va_list ap;
|
|
|
|
va_start(ap, format);
|
|
vsprintf(buf, format, ap);
|
|
va_end(ap);
|
|
|
|
do_what_you_want_whith( buf );
|
|
}
|
|
|
|
You'll get more informations in a group like "comp.lang.c", rather than
|
|
in the Linux kernel development group I think :-)
|
|
|
|
--
|
|
linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux
|
|
|
|
------------------------------
|
|
|
|
From: root@jaxnet.com
|
|
Subject: starlan / pcnau ethernet drivers?
|
|
Date: Sat, 26 Mar 1994 10:27:37 GMT
|
|
|
|
I have a couple of starlan ethernet cards laying around and I was wondering
|
|
if they would work with Linux. The model number on the cards is PC NAU V4.3B
|
|
Anyone out there have this type of ethernet card working? If so, what do I
|
|
use as the driver?
|
|
|
|
|
|
------------------------------
|
|
|
|
From: ftlofaro@unlv.edu (Frank Lofaro)
|
|
Subject: Re: bug/feature in fcntl syscall
|
|
Date: Sun, 27 Mar 94 21:04:09 GMT
|
|
|
|
In article <davem.764179351@extro.ucc.su.OZ.AU> davem@extro.ucc.su.OZ.AU (David Monro) writes:
|
|
>I discovered the following problem the other day while attempting to
|
|
>compile mtools-2.0.7 ( a suite of programs to access msdos floppies by
|
|
>attacking the raw floppy devices, avoiding having to mount them.)
|
|
>The problem is very simple - calling flock, or fcntl with appropriate
|
|
>args (same thing) on a block floppy device (ie /dev/fd0) fails with an
|
|
>'Invalid argument' errno, but works fine for regular files. However, it
|
|
>appears to work on a Sun running SunOS 4.1.1 . Is this a bug or a
|
|
>feature? If it is a bug, I suspect the cause is on line 203 of
|
|
>linux/fs/locks.c, in the routine copy_flock():
|
|
> if (!S_ISREG(filp->f_inode->i_mode))
|
|
> return 0;
|
|
>Is there any reason locking should be restricted to regular files?
|
|
>
|
|
>The solution, for anybody out there compiling mtools, is to simply not
|
|
>define any of LOCKF, FLOCK and FCNTL. It works fine then, if a little
|
|
>unsafely.
|
|
>
|
|
> David Monro
|
|
>--
|
|
>Rule of Feline Frustration:
|
|
> When your cat has fallen asleep on your lap and looks utterly
|
|
>content and adorable, you will suddenly have to go to the bathroom.
|
|
>--
|
|
>"We demand rigidly defined areas of doubt and uncertainty!"
|
|
> -- Vroomfondel
|
|
>
|
|
|
|
You could try removing those lines from the kernel, and giving it a try.
|
|
It may work, it may not (it might crash the kernel, or [very unlikely] damage
|
|
a filesystem).
|
|
|
|
|
|
------------------------------
|
|
|
|
From: aeb@cwi.nl (Andries Brouwer)
|
|
Subject: Re: unsupported keys (scancode (xx) not in range 00 - 5f)
|
|
Date: Sun, 27 Mar 1994 23:02:28 GMT
|
|
|
|
kaz@lilia.iijnet.or.jp (Kaz Sasayama) writes:
|
|
|
|
>My keyboard generates scancodes not in range 00 - 5f for some keys.
|
|
>How can I use them?
|
|
|
|
>This is the output of `showkey -s' in kbd-0.85:
|
|
...
|
|
>0x9c
|
|
>0x7b
|
|
>0xfb
|
|
>0x79
|
|
>0xf9
|
|
>0x70
|
|
>0xf0
|
|
>0x7d
|
|
>0xfd
|
|
|
|
The 0x9c is the key up event for your Enter key. The remaining eight
|
|
look like key down and key up events for four keys. How are these keys labelled?
|
|
What brand/type keyboard do you have?
|
|
[It is customary to precede the codes for new keys with the escape code 0xe0.
|
|
Didn't you get that code? Without it I would be inclined to conjecture
|
|
codes for communication with the keyboard controller, but I only know about
|
|
0xfa (ACK), 0xfc (BAT error), 0xfe (resend), 0xff (error).]
|
|
|
|
------------------------------
|
|
|
|
From: mhomer@desire.wright.edu
|
|
Subject: Re: How to use VARARGS under Linux ?
|
|
Date: 26 Mar 94 14:31:44 EST
|
|
|
|
In article <1994Mar25.230730.13766@resonex.com>, zenon@resonex.com (Zenon Fortuna) writes:
|
|
> In article <2mvjr5$nah@news.doit.wisc.edu> tillemaj@news.doit.wisc.edu.UUCP (John Edward Tillema,&91M+soAj) writes:
|
|
>>From article <1994Mar25.031012.3079@resonex.com>, by zenon@resonex.com (Zenon Fortuna):
|
|
> [...]
|
|
>>I think this should be of the form: (don't know what va_dcl is?)
|
|
>>
|
|
>>void my_log(char fmt[], ... )
|
|
>>{
|
|
>> va_list argp;
|
|
>>
|
|
>> va_start(argp,fmt);
|
|
>> vfprintf(stdout,fmt,argp); /* or vsprintf(string,fmt,argp);puts(string) */
|
|
>> va_end(argp);
|
|
>>}
|
|
>>
|
|
>>This will allow my_log to function just like a printf statement.
|
|
>
|
|
> Fine. But I could not find any header file with the va_list or va_dcl
|
|
> declaration. Under HP-UX the declarations are in varargs.h, somebody suggested
|
|
> that under Linux there exists stdargs.h ... but I did not find it in
|
|
> SLACKWARE 1.1.2 . Maybe simply I have to copy more header files from other (?)
|
|
> distributions ?
|
|
|
|
How about stdarg.h (singular)? Harbison and Steele 3rd edition, p. 260 lists
|
|
this as part of the ANSI C library facilities. It is described in more
|
|
detail in section 11.4 of the same book.
|
|
|
|
I'm not on a Linux box at the moment, but I checked the /usr/local/lib
|
|
directory where GCC 2.5.8 installed its header files (on a Sun Sparc10
|
|
running Solaris 2.3, gcc stuffed its header files in /usr/local/lib/gcc-lib\
|
|
/sparc-sun-solaris2.3/2.5.8/include). Included in this directory were
|
|
both stdarg.h and varargs.h, and both of these files appear to be
|
|
from the GCC distribution itself...
|
|
|
|
Anyway, here's hoping this is of some use.
|
|
>
|
|
> BTW, where to find more complete set of header files for Linux (and, maybe,
|
|
> related man-pages ?) ?
|
|
>
|
|
> Zenon.
|
|
--
|
|
Mitch
|
|
mhomer@desire.wright.edu
|
|
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|