508 lines
22 KiB
Plaintext
508 lines
22 KiB
Plaintext
Subject: Linux-Development Digest #558
|
|
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: Wed, 16 Mar 94 15:13:08 EST
|
|
|
|
Linux-Development Digest #558, Volume #1 Wed, 16 Mar 94 15:13:08 EST
|
|
|
|
Contents:
|
|
Re: Problem with NET-2 and Winsock Gopher/HTTP clients? (Alan Cox)
|
|
Re: Help! GCC errors [STUPID IDIOTS ON COMP.OS.LINUX.* GROUPS] (Kevin Brown)
|
|
Fork fails - what's the problem??!? (James D. Levine)
|
|
Matrox drivers (John Wagner)
|
|
information about mount's code needed (AUQUIER DENIS)
|
|
Interesting use of "buffers" in new Linux 1.0 (+ late pl15) (Gene Choi)
|
|
info about a sys-call: open (CAVELIER TRISTAN)
|
|
Re: 127.x.x.x (was Re: UDP report card) (Heath I Hunnicutt)
|
|
Re: Annoying interactive bug in nslookup? (Andreas Busse)
|
|
Re: Interesting use of "buffers" in new Linux 1.0 (+ late pl15) (Kai Petzke)
|
|
Re: DIP: tty: getc: I/O error (Matthias Urlichs)
|
|
Re: Annoying interactive bug in nslookup? (Matthias Urlichs)
|
|
Re: Possibly-fatal ISOFS bug +PATCH (Re: A truly non-debugging Kernel?) (Matthias Urlichs)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: iiitac@uk.ac.swan.pyr (Alan Cox)
|
|
Subject: Re: Problem with NET-2 and Winsock Gopher/HTTP clients?
|
|
Date: Tue, 15 Mar 1994 17:38:16 GMT
|
|
|
|
In article <1994Mar15.150623.10604@selway.umt.edu> demeler@selway.umt.edu (Borries Demeler/Biophysics) writes:
|
|
>I'm experiencing the same problem (winqvt/trumpet winsock dll, pl15) although
|
|
>acceptable, since the problem can be avoided by scrolling somewhat slower.
|
|
>When connecting to an Ultrix DEC I never experience the problem. My setup
|
|
>is 486-50/8 MB Ram/20 MB Swap/SMC Elite/thin net.
|
|
>
|
|
If you are running anything earlier than real 1.0 then get 1.0 if you have
|
|
telnet hangs. Only if they continue after that start to worry and file
|
|
bug reports. Charles Hedrick and Linus pretty much butchered and rewrote
|
|
the TCP layer between pl14n and 1.00
|
|
|
|
Alan
|
|
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: kevin@frobozz.sccsi.com (Kevin Brown)
|
|
Subject: Re: Help! GCC errors [STUPID IDIOTS ON COMP.OS.LINUX.* GROUPS]
|
|
Date: Tue, 8 Mar 1994 10:52:32 GMT
|
|
|
|
In article <CM7MAA.3B9@jonh.wimsey.com> jhenders@jonh.wimsey.com (John Henders) writes:
|
|
>crfisher@nyx10.cs.du.edu (I am being repressed.) writes:
|
|
[...]
|
|
>> Although it may seem that every newsgroup in the c.o.l.*
|
|
>> series actually have the word flame in them, they do not. I am so
|
|
>> sick of the petty replies and responses I see here all the time.
|
|
>> If you can not help someone then do not bother to even reply.
|
|
>
|
|
> So it helps people to encourage them to post to the wrong group,
|
|
>does it? what about the people who are trying to use the group for the
|
|
>reason it was created? Don't they count, in your worldview?
|
|
|
|
There is no good answer to this problem. Part of the reason it exists to
|
|
begin with is that comp.os.linux.development is badly named because a lot
|
|
of people wanted to be "cute" and have the abbreviation come out c.o.l.d.
|
|
(otherwise, they would have been more sensible and just named the group
|
|
comp.os.linux.kernel, which *clearly* refers to linux kernel development,
|
|
which is actually this group's charter). So now they, and a lot of other
|
|
people, are paying for this original urge to be "cute". The answer to this
|
|
is really quite simple, of course: create comp.os.linux.kernel, and move
|
|
all kernel discussion there, while retaining comp.os.linux.development for
|
|
what it appears it should be for: software development issues under Linux.
|
|
Screw the newsgroup creation rules, there's *good reason* to do this (User
|
|
Interface Issues 101), and rules shouldn't *ever* just blindly apply.
|
|
|
|
Of course, that's not all of it. Much of the problem is that people who
|
|
want answers will post to whatever newsgroup they find to be most convenient,
|
|
instead of posting to whatever newsgroup is appropriate. However, the answer
|
|
to this is not as much of a no-brainer as you might think. Many times, the
|
|
question being asked can legitimately be asked in at least two newsgroups.
|
|
Is an XFree configuration question more properly asked on comp.windows.x,
|
|
comp.os.linux.help, comp.os.linux.admin, or what? How do you know going
|
|
into it whether the question is Linux-specific or not? There are a *lot* of
|
|
questions that are even harder to categorize.
|
|
|
|
Another facet of the problem is that the traffic on comp.os.linux.help is
|
|
*tremendous*. How likely do you think it is that someone who really knows
|
|
what they're talking about will get to your question within a day if you
|
|
ask it there? If it's an oft-asked question, many of the responses will
|
|
be along the lines of "I'd like to know, too". At least on c.o.l.d., you're
|
|
likely to be talking to people who really know what's going on. If *I* had
|
|
a question that I wanted to be sure to get a good answer to, I'd email
|
|
someone I knew was likely to have the answer. This is based on my experience
|
|
with posting questions to newsgroups. Even for *appropriate* questions,
|
|
I've had trouble getting answers to my questions on this newsgroup (c.o.l.d.).
|
|
Case in point: up to at least 0.99.13, there seems to be a problem with stack
|
|
integrity in the core dump file written as a result of a SIGABRT that
|
|
originated in the process that was signalled (most often from abort()).
|
|
I haven't characterized this with other signals, so don't offhand know if
|
|
it's a general problem or one specific to SIGABRT (conjecture: it's a problem
|
|
with any signal that causes core to be dumped). I asked *twice* about this
|
|
problem here on c.o.l.d. and got *zero* responses, and this is *obviously*
|
|
the right group to ask the question on. My questions were separated by a
|
|
couple of months. Someone else managed to ask the same question. He likely
|
|
got no responses as well. I have a workaround: kill the process from another
|
|
process, i.e. have your abort() code do a fork() and kill the parent from the
|
|
child. But this isn't implemented in the library, so anything using the
|
|
library code will produce an almost useless core dump (experience says that
|
|
the stack image is one of the most important pieces of debugging information
|
|
contained in the core dump).
|
|
|
|
Some of us, like myself, ask very few questions to the net. This isn't
|
|
because we respect newsgroup charters, read the FAQ, or any other such
|
|
thing (though those things happen to be true). It's because we happen to
|
|
be capable enough to peruse the source to find the answers to our questions
|
|
if we have to. This is how I managed to get screen to work on my system (a
|
|
while back. I don't know if newer versions work out of the box). It took
|
|
a few hours, but I didn't have to go to the newsgroup to find my answers
|
|
(it would take a few days, at least, for me to figure out the core dump
|
|
problem, which is why I haven't bothered). But folks, this is *not* a
|
|
common capability, and you'll continue to be perturbed by the volume of
|
|
"newbie" questions until you realize this!! This is particularly true if
|
|
you don't even answer the *expert* questions, like the core dump question.
|
|
|
|
In any case, if someone asks a question on the newsgroup that happens to be
|
|
inappropriate, how long does it take to figure out that you can just skip it?
|
|
A couple of seconds? If you're using a *real* newsreader, like trn, then
|
|
you can often just skip the thread based on the subject line (I know this
|
|
often doesn't work, however). You might spend 1 minute out of 30 or so
|
|
skipping newbie questions, and that's on a *bad* day. Is it really worth
|
|
it, then, to get all up in arms about an inappropriate posting?
|
|
|
|
Not everyone has as much of a clue as you might. If they did, there would
|
|
be a lot fewer questions (inappropriate or not) being asked.
|
|
|
|
> John Henders - Wimsey Information Services
|
|
> GAT/MU/AE d- -p+(--) c++++ l++ u++ t- m---
|
|
> e* s-/+ n-(?) h++ f+ g+ w+++ y*
|
|
|
|
|
|
--
|
|
Kevin Brown kevin@frobozz.sccsi.com
|
|
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >
|
|
This is your .signature virus on drugs: <>
|
|
Any questions?
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.linux.help
|
|
From: jdl@netcom.com (James D. Levine)
|
|
Subject: Fork fails - what's the problem??!?
|
|
Date: Wed, 16 Mar 1994 07:10:46 GMT
|
|
|
|
I'm having the problem that I fork fails, usually after about 41 processes
|
|
running (about 15 for root, the rest for my normal login). I thought for
|
|
a long time that I had reached the max procs per unpriviledged user, so
|
|
I went the route of bumping up the NR_TASKS in tasks.h, and rebuilt the
|
|
kernel. Same problem. Over and over.
|
|
|
|
Tonight fork failed at around 33 processes, so I don't really know what's
|
|
up. This happened as it often does when I'm trying open a new xterm window
|
|
and run some program in it (tonight that was elvis).
|
|
|
|
Is it possible that I'm hitting some other resource limit, for example, the
|
|
max # of ptys, when fork/exec tries to set up stdin/stdout for the new
|
|
process?
|
|
|
|
Any help in solving this problem would be very much appreciated. I've got
|
|
the RAM, I've got the MIPS, but I ain't got the processes...
|
|
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: jwagner@mental.mitre.org (John Wagner)
|
|
Subject: Matrox drivers
|
|
Date: 15 Mar 1994 18:14:28 GMT
|
|
Reply-To: jwagner@mental.mitre.org (John Wagner)
|
|
|
|
|
|
so has anybody written a driver for the Matrox MGA-II cards for Xfree-86
|
|
yet?? I just got my new system with the 4meg version and would like to
|
|
run linux on it, but I've heard that the drivers that come with the card
|
|
do NOT support Xfree. I could still use my 386 to run linux, but the
|
|
pentium sure would be nice :)
|
|
--
|
|
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
+ +
|
|
+ John Wagner My company doesn't even know what I do. :) +
|
|
+ jwagner@mitre.org empire isn't a game, it a life style! :) +
|
|
+ Bowling IS a sport, you try catching those balls! +
|
|
+ +
|
|
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
------------------------------
|
|
|
|
From: essai@vub.ac.be (AUQUIER DENIS)
|
|
Subject: information about mount's code needed
|
|
Date: 16 Mar 1994 11:11:19 GMT
|
|
|
|
Hello,
|
|
|
|
Could you help me ?
|
|
|
|
I try to understand some procedures in the kernel of linux.
|
|
In particular about "sys_mount" (and "sys_unmout" :)) )
|
|
"do_mount" (and "do_unmount")
|
|
These procedures are in the linux/fs/super.c file
|
|
|
|
please help me.
|
|
|
|
|
|
|
|
|
|
|
|
Thank you
|
|
|
|
Denis.
|
|
dauquier@ulb.ac.be
|
|
|
|
|
|
------------------------------
|
|
|
|
From: genie@fraud.berkeley.edu (Gene Choi)
|
|
Subject: Interesting use of "buffers" in new Linux 1.0 (+ late pl15)
|
|
Date: 16 Mar 1994 07:55:45 GMT
|
|
|
|
|
|
I've noticed something interesting about Linux's use of memory lately.
|
|
In specific, I'm referring to Linux's use of the buffer cache
|
|
(reported by "free" command as the buffers category).
|
|
|
|
I've noticed that starting with pseudo-late pl15 and 1.0, my buffers
|
|
never seems to decrease below 3000. Is this what it's supposed to do?
|
|
Wouldn't it make more sense to use this buffers to store real things
|
|
in memory rather than start using swap to swap things out, while
|
|
maintaining the cache? It's interesting that this change was
|
|
made suddently amidst the pl15 series (where nothing was supposed
|
|
to change except for bug fixes).
|
|
|
|
Anyone else notice this?
|
|
|
|
-Gene
|
|
genie@xcf.berkeley.edu
|
|
|
|
------------------------------
|
|
|
|
From: tcavel@vub.ac.be (CAVELIER TRISTAN)
|
|
Subject: info about a sys-call: open
|
|
Date: 16 Mar 1994 11:41:35 GMT
|
|
|
|
Hi,
|
|
|
|
Could you help me ?
|
|
|
|
I have to do a work concerning the sys-call, open (under linux)
|
|
I have some problems to understand macro including assembler source
|
|
precisely FD_CLR in "types.h"
|
|
|
|
If you have any other information about sys-call open, send them to me.
|
|
|
|
Thanks by advance.
|
|
|
|
Tristan.
|
|
|
|
tcavel@is1.vub.ac.be
|
|
|
|
|
|
------------------------------
|
|
|
|
From: heathh@lust.ugcs.caltech.edu (Heath I Hunnicutt)
|
|
Crossposted-To: comp.protocols.tcp-ip
|
|
Subject: Re: 127.x.x.x (was Re: UDP report card)
|
|
Date: 16 Mar 1994 08:32:27 GMT
|
|
|
|
longyear@netcom.com (Alfred Longyear) writes:
|
|
|
|
>It seems to me that the address 127.x.x.x is not special. What is special
|
|
>is the loopback device.
|
|
|
|
This assumption is wrong. 127 is specified in the RFCs as being a pseudo-
|
|
network that includes the loopback address. The fact that it is specified
|
|
in the RFCs as a special address pretty well contradicts your premise.
|
|
|
|
>If you don't have a route for 127.x.x.x to the "lo" device, but have a default
|
|
>route to an ethernet controller, for example, then requests to 127.0.0.1 will
|
|
>go out the wire just as requests to any other IP address. Until a route is
|
|
>created to the loopback device, the address 127.x.x.x is an unknown address
|
|
>just as if _I_ asked for address 192.83.17.1. It would need ARP to resolve it
|
|
>to a real ethernet address and subsequently the request would go out the
|
|
>default route.
|
|
|
|
The difference is that the IP layer can make the correct decision not to put
|
|
anything to 127.* on any external interface. The idea that someone should
|
|
need to configure their system to not violate the RFCs is ridiculous. There
|
|
is a large responsibility on the part of the stack to not allow stupid things
|
|
like sending 127.* out on the net.
|
|
|
|
>I guess what I am saying is that the routing of frames is not a function
|
|
>solely of the device's IP address, nor is it a function soley of the device
|
|
>type. There is no magical "override" which says that "Oh, you have address
|
|
>127.0.0.1. I won't bother to look it up. I know that this is the loopback
|
|
>device and will simply put it there".
|
|
|
|
You really should research these issues before posting. For starters, see
|
|
the Hosts Requirements RFC. There is indeed something "magical" about any
|
|
address on the 127 net. Whether you set your system up with 127.0.0.1 as a
|
|
loopback or not is your problem. No matter what, you should never send
|
|
packets to 127.anything out any interface, regardless of the routing table's
|
|
(mis)configuration.
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: andy@resi.waldorf-gmbh.de (Andreas Busse)
|
|
Subject: Re: Annoying interactive bug in nslookup?
|
|
Date: 16 Mar 1994 08:27:12 GMT
|
|
|
|
In article <1994Mar13.063213.26466@unlv.edu>, ftlofaro@unlv.edu (Frank Lofaro) writes:
|
|
|> 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.
|
|
|>
|
|
|
|
A better replacement for nslookup is DIG. It works fine on
|
|
my linux 0.99.14 box, which we use as firewall machine too.
|
|
Since I have DIG I haven't used nslookup anymore. Get it !
|
|
|
|
Andy
|
|
|
|
===============================================================================
|
|
Waldorf Electronics GmbH | Phone: +49 (0)2636-80294
|
|
R&D Department | Fax: +49 (0)2636-80188
|
|
Neustrasse 9-12, 53498 Waldorf, Germany | email: andy@waldorf-gmbh.de
|
|
===============================================================================
|
|
|
|
|
|
------------------------------
|
|
|
|
From: wpp@marie.physik.tu-berlin.de (Kai Petzke)
|
|
Subject: Re: Interesting use of "buffers" in new Linux 1.0 (+ late pl15)
|
|
Date: 16 Mar 94 12:28:10 GMT
|
|
|
|
genie@fraud.berkeley.edu (Gene Choi) writes:
|
|
|
|
|
|
>I've noticed that starting with pseudo-late pl15 and 1.0, my buffers
|
|
>never seems to decrease below 3000. Is this what it's supposed to do?
|
|
|
|
...
|
|
|
|
>Anyone else notice this?
|
|
|
|
Well, I noticed with some pl15 kernel, that the buffers would not
|
|
go below half of the memory I had. This was real bad, when doing
|
|
memory extensive work under X. With pre-1.0, it went away, again.
|
|
Linux still seems to give more priority to buffers, than it used
|
|
to be before, but this is ok.
|
|
|
|
I think, it is a good idea to have more buffers than just a minimum.
|
|
Otherwise, the kernel will read the same blocks (like currently
|
|
used inodes and directories) again and again. Better do some
|
|
swapping instead.
|
|
|
|
|
|
Kai
|
|
--
|
|
Kai Petzke <wpp@marie.physik.tu-berlin.de>
|
|
Advertisement by Microsoft in a well-known German magazine:
|
|
If you don't like our programmes, then make your own ones.
|
|
However, they expect you to use Microsoft products for this -:)
|
|
|
|
------------------------------
|
|
|
|
From: urlichs@smurf.noris.de (Matthias Urlichs)
|
|
Subject: Re: DIP: tty: getc: I/O error
|
|
Date: 15 Mar 1994 23:29:52 +0100
|
|
|
|
In comp.os.linux.development, article <2lqn56$tdq@watnews1.watson.ibm.com>,
|
|
uri@watson.ibm.com writes:
|
|
>
|
|
> Please, please... Don't kill DIP with "-9", unless you're willing to
|
|
> cope with your serial port left in some weird state, from which it's
|
|
> rather difficult to recover.
|
|
>
|
|
You're both right. The combination of the kernel noting that nobody uses
|
|
the port, and the subsequent reset of the port by getty, should, however,
|
|
return the port to usability.
|
|
|
|
If not, I'd regard that as a kernel bug.
|
|
|
|
--
|
|
You would if you could but you can't so you won't.
|
|
--
|
|
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: urlichs@smurf.noris.de (Matthias Urlichs)
|
|
Subject: Re: Annoying interactive bug in nslookup?
|
|
Date: 16 Mar 1994 13:40:38 +0100
|
|
|
|
In comp.os.linux.development, article <2lsmip$54m@nepahwin.cs.laurentian.ca>,
|
|
grant@nepahwin.cs.laurentian.ca (Grant R. Guenther) writes:
|
|
>
|
|
> Well, it has certainly been around for a while (it was there in the pl10
|
|
> MCC kit that I ran last year ...) but I think most people use 'host'.
|
|
|
|
Actually, I'm using "dig". It can do everything that nslookup can do,
|
|
except zone transfers -- and these are better with named-xfer anyway.
|
|
|
|
--
|
|
I'm not unemployed - I'm looking for the perfect job.
|
|
--
|
|
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: urlichs@smurf.noris.de (Matthias Urlichs)
|
|
Subject: Re: Possibly-fatal ISOFS bug +PATCH (Re: A truly non-debugging Kernel?)
|
|
Date: 16 Mar 1994 13:55:52 +0100
|
|
|
|
In comp.os.linux.development, article <CMMJzI.GDo@ra.nrl.navy.mil>,
|
|
eric@tantalus.nrl.navy.mil (Eric Youngdale) writes:
|
|
>
|
|
> >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.
|
|
>
|
|
You're ignoring the fact that kmalloc is callable from an interrupt and may
|
|
grab the memory almost immediately after you've freed it.
|
|
|
|
> 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.
|
|
|
|
Probably because the only user of kmalloc at interrupt time is networking,
|
|
and most people simply don't talk to their CD-ROM and receive large network
|
|
messages, which are most likely to cause a reuse of the block, at the same
|
|
time.
|
|
|
|
--
|
|
RISC assembly programmers do it 1073741824 times a second.
|
|
--
|
|
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>.
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|