529 lines
21 KiB
Plaintext
529 lines
21 KiB
Plaintext
Subject: Linux-Development Digest #543
|
||
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: Sat, 12 Mar 94 18:13:08 EST
|
||
|
||
Linux-Development Digest #543, Volume #1 Sat, 12 Mar 94 18:13:08 EST
|
||
|
||
Contents:
|
||
Re: Adaptec 1542C SCSI with New ROM (komatsu@trl.ibm.co.jp)
|
||
Re: UDP report card (Mark Evans)
|
||
NCR 53c700 drivers available? (Marius Heuler)
|
||
Re: select (Mark Evans)
|
||
Support for ACCTON EtherPocket pocket ethernet adaptor? (Hui-Hui Hu)
|
||
Re: UDP report card (gans)
|
||
Re: YP or NIS for linux? (John F. Haugh II)
|
||
Re: YP or NIS for linux? (John F. Haugh II)
|
||
Wine Question (Elan Feingold)
|
||
Changes in TCP retry code? (David Sisson)
|
||
Re: Serious 80386 bug (Michael Will)
|
||
Little problem: ftp-data eth-ernal CLOSEing with pre-1.0 (Romano Giannetti)
|
||
tcpspray hangs up pl15j + pre-1.0, but not pl15i (Helge Schulz)
|
||
ACCTON EtherPocket support for Linux? (Hui-Hui Hu)
|
||
|
||
----------------------------------------------------------------------------
|
||
|
||
From: komatsu@trl.ibm.co.jp
|
||
Subject: Re: Adaptec 1542C SCSI with New ROM
|
||
Date: 11 Mar 94 16:27:44
|
||
|
||
|
||
I have successfully installed on almost the same configlation by
|
||
changing I/O address to 334.
|
||
|
||
====================================================================
|
||
komatsu@trl.ibm.com
|
||
Tokyo Research LAB. Advanced Compiler
|
||
Hideaki Komatsu
|
||
====================================================================
|
||
--
|
||
$@>.>>(J $@=(><(J (Hideaki Komatsu) Internet: komatsu@trl.vnet.ibm.com
|
||
Advanced Compiler, CSI Junet: komatsu@trl.ibm.co.jp
|
||
IBM Research, Tokyo Research Laboratory IBM VNET: KOMATSU at TRLVM
|
||
|
||
------------------------------
|
||
|
||
From: evansmp@mb48026.aston.ac.uk (Mark Evans)
|
||
Subject: Re: UDP report card
|
||
Date: Thu, 10 Mar 1994 17:48:28 GMT
|
||
|
||
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.
|
||
|
||
------------------------------
|
||
|
||
From: heuler@cip.informatik.uni-wuerzburg.de (Marius Heuler)
|
||
Subject: NCR 53c700 drivers available?
|
||
Date: 10 Mar 1994 18:16:38 GMT
|
||
|
||
Hello!
|
||
|
||
Is there a driver for scsi cards with NCR 53C700-66 available
|
||
or is someone working on one?
|
||
|
||
Cards with this chip (e.g. TMC SP-382 or Forex FR600AF) seem
|
||
to be really fast and pretty cheap (at least VLB version).
|
||
|
||
Is the NCR 53C700 similar to the 53C810 for PCI bus?
|
||
Will the same drivers work for both?
|
||
|
||
Please excuse that many questions, but I'm looking for
|
||
a fast and cheap VLB scsi adapter. That seems to difficult
|
||
because some are fast but not cheap (e.g. Ultrastor 34F)
|
||
and others are cheap but only fast enough for CD-ROMS.
|
||
|
||
I hope someone could help
|
||
|
||
Marius
|
||
|
||
Marius Heuler # Friedenstrasse 11 - 97534 Theilheim
|
||
Computer Science #-------------------------------------------------------
|
||
Uni Wuerzburg # email : heuler@cip.informatik.uni-wuerzburg.de
|
||
Germany # phone : + (49) 9384 - 1045 | + (49) 931 - 81412
|
||
|
||
------------------------------
|
||
|
||
From: evansmp@mb48026.aston.ac.uk (Mark Evans)
|
||
Subject: Re: select
|
||
Date: Thu, 10 Mar 1994 17:54:09 GMT
|
||
|
||
Matthias Urlichs (urlichs@smurf.noris.de) wrote:
|
||
: In comp.os.linux.development, article <fgm.763211130@lipo>,
|
||
: fgm@doc.ic.ac.uk (Frank McCabe) writes:
|
||
: > I have come across an apparent problem with the select system call.
|
||
: >
|
||
: Wrong. You've come across a bug in your program.
|
||
|
||
This is the second example I have spotted of someone doing this....
|
||
|
||
: Yes. Read the documentation. You're reusing your timeout values.
|
||
: The first time you call select(), it zeroes the variable because no more
|
||
|
||
I thought it actually set the value to the time remaining of the original
|
||
timout. Thus it zeros if the select ends due to a timeount. But it may
|
||
not end up as zero if it is due to any fd's being ready.
|
||
|
||
: time is remaining. The next time you're calling select(), the variable is
|
||
: still zero.
|
||
|
||
It could be that you will get unpridictable behaviour on timeout, before
|
||
getting to the state of no timout.
|
||
|
||
: This is mentioned in both the SunOS and Linux manpages for select().
|
||
|
||
What happens is that quite a few versions of select(), including on Suns,
|
||
never write to the timeout. So what is actually broken code runs ok on
|
||
them.
|
||
|
||
------------------------------
|
||
|
||
From: hdesiato@cs.umd.edu (Hui-Hui Hu)
|
||
Subject: Support for ACCTON EtherPocket pocket ethernet adaptor?
|
||
Date: 12 Mar 1994 12:23:17 -0500
|
||
|
||
[I'm cc'ing this to support at ACCTON. So to explain a bit
|
||
of background, I'm trying to use an EtherPocket for Linux,
|
||
a free UNIX clone for the i386+ architecture. This post
|
||
is going out on the Linux development newsgroup.]
|
||
|
||
I've recently purchased a EtherPocket 10baseT adaptor for a new
|
||
notebook. There doesn't seem to be any driver written for this
|
||
so far.. Anyone else got this out there?
|
||
(model=EN2201.. "manual" (hehe :) gives this "technical
|
||
information" : irq 5, 7; 8k buffer, 256-bit eprom)
|
||
Oh well. ACCTON does include a packet driver for DOS
|
||
as well as NDIS, ODI, and IPX stuff..
|
||
|
||
if I need to write a driver for this, where should I start?
|
||
I am amazingly bad at coding :) would appreciate any pointers..
|
||
I can't find any Crynwr drivers .. just a *very* obscure
|
||
1 line statement in a PCNFS readme file:
|
||
"When asked to identify the type of network interface card
|
||
you are using, select "WD8003" [with IRQ 3 and IO 0x300]"
|
||
I tried that with the Linux wd.c, but understandably got nothing.
|
||
(I guess that refers to the emulation the PCNFS driver uses)
|
||
|
||
Oh well. Any easy way out? I can send the packet driver
|
||
to any interested skilled victims/experts out there :)
|
||
|
||
OK, GPL question. The packet driver is based on
|
||
"Packet driver skeleton copyright 1988-90, Russell Nelson."
|
||
with the standard GPL disclaimer. I'm not sure if
|
||
GPL says that the source code should be available
|
||
from ACCTON ("Portions Copyright 1990-1992, ACCTON CO.,LTD.")
|
||
|
||
From COPYING:
|
||
-You must make sure that they, too, receive or can get the
|
||
-source code.
|
||
|
||
[snip]
|
||
--3. You may copy and distribute the Program (or a portion or derivative of
|
||
--it, under Paragraph 2) in object code or executable form under the terms of
|
||
--Paragraphs 1 and 2 above provided that you also do one of the following:
|
||
[a: accompany it with source code]
|
||
[b: accompany it with an offer to distribute source code at nominal charge]
|
||
[c: not applicable since this is a commercial distribution]
|
||
|
||
Thanks for your help!
|
||
|
||
-Hui-Hui Hu
|
||
hdesiato@cs.umd.edu
|
||
|
||
Oh, yea, another random question. Ever since I upgraded
|
||
somewhere along the line in the pl15/prealpha kernels
|
||
w gives "-" as the process no matter what. I recompiled
|
||
procps-0.92 but no difference. Can someone point me
|
||
to the latest version of w that works? Thnx again..
|
||
|
||
[Bad sign. ACCTON support host is unreachable :( ]
|
||
|
||
------------------------------
|
||
|
||
From: gans@acf2.nyu.edu (gans)
|
||
Subject: Re: UDP report card
|
||
Date: 10 Mar 1994 01:00:13 GMT
|
||
|
||
evansmp@mb48025.aston.ac.uk (Mark Evans) writes:
|
||
|
||
>Alan Cox (iiitac@swan.pyr) wrote:
|
||
>: In article <2lj8f2$gis@access1.digex.net> christop@access1.digex.net (Chris Anderson) writes:
|
||
>: >Three things seem kinda odd:
|
||
>: >
|
||
>: >1. A sendto INADDR_ANY as a destination gives me a ENETUNREACH. This errno is
|
||
>: > new for me, in other environments the local process bound to either the
|
||
>: > loopback or one of the machine's inet addresses gets the message.
|
||
>: INADDR_ANY is counted as a broadcast address in Linux. Which is where this
|
||
>: is coming from. Earlier pl15 systems also mistakenly return ENETUNREACH
|
||
|
||
>Looking at the RFC's I think it should actually be invalid, as should anything not
|
||
>a class A, B, C or D address. (Currently any invalid addresses including class
|
||
>E ones are likely to get sent to the default router, which is probably not
|
||
>a good idea). This check also applies to the destination of any received datagrams
|
||
>(as well as an additional check that 127.X.X.X only came from the loop back device)
|
||
>and any source routes.
|
||
|
||
>Theoretically these should not be necessary, but they do conform to the guide line
|
||
>of "Assume that the network is full of hostile entities"
|
||
|
||
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).
|
||
|
||
---- Paul J. Gans [gans@acf2.nyu.edu]
|
||
|
||
|
||
------------------------------
|
||
|
||
From: jfh@rpp386 (John F. Haugh II)
|
||
Subject: Re: YP or NIS for linux?
|
||
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
|
||
Date: Thu, 10 Mar 1994 04:31:49 GMT
|
||
|
||
In article <2li09g$6il@celsius.ifm.liu.se> peter@ifm.liu.se (Peter Eriksson) writes:
|
||
>You're really funny, did you know that? Why do I get the feeling your
|
||
>feelings are hurt because I don't use your shadow stuff in NYS?
|
||
|
||
You'd be wrong if that what's you thought.
|
||
|
||
>(The major reason was that at the time when I wrote that stuff JFH's
|
||
>shadow library wasn't LGPL'd. Another big reason was that I wanted
|
||
>a set of *clean* functions and header files without all the compatibility
|
||
>stuff for 4711 different unixes that pollutes JFH's shadow library).
|
||
|
||
But Peter, you've made your code so clean it is no longer compatible with
|
||
the largest base of systems supporting those functions -- SVR4 boxes.
|
||
|
||
What has made Shadow so popular (at least it was popular enough to be
|
||
stuffed into Linux ...) is that Shadow on one system is just like
|
||
Shadow every where else. On my old SCO Xenix box I could say "group
|
||
foo" and get a complete list of the groups "foo" belonged to. Even
|
||
though Xenix doesn't support concurrent groups. When you start saying
|
||
"I know better -- I'm going to do it right" you confront the very
|
||
real possibility that
|
||
|
||
1). You don't know better.
|
||
2). Fewer people will use it because they can't afford to
|
||
be incompatible with whatever else they must use.
|
||
|
||
Why would I write anything for Linux that requires the use of getspnam()
|
||
if I can't trust it to return "NULL" when there is no entry in /etc/shadow?
|
||
If you'd follow the SVR4 semantics at least an application which cares
|
||
can PORTABLY determine the existence of shadowed entries.
|
||
|
||
>Btw, what's stopping you from writing your own NYS library with your
|
||
>shadow stuff if you think my stuff is so bogus, wrong and totally useless?
|
||
|
||
Given that your code is under the GPL this is a very real possibility.
|
||
This is also one of the reasons I've never (and never will) place all
|
||
of Shadow under the GPL. And I did get the note about the GDBM hooks
|
||
being added. Putting NDBM support into NYS is a pretty likely occurance.
|
||
Why limit myself to GDBM when NDBM is more widely available (given that
|
||
every system which supports GDBM also supports NDBM).
|
||
--
|
||
John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh
|
||
Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org
|
||
There are three documents that run my life: The King James Bible, the United
|
||
States Constitution, and the UNIX System V Release 4 Programmer's Reference.
|
||
|
||
------------------------------
|
||
|
||
From: jfh@rpp386 (John F. Haugh II)
|
||
Subject: Re: YP or NIS for linux?
|
||
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
|
||
Date: Thu, 10 Mar 1994 04:35:13 GMT
|
||
|
||
In article <2li66b$f62@gauss.ifm.liu.se> peter@ifm.liu.se (Peter Eriksson) writes:
|
||
>If one is using NYS and ypserv or ypbind dies/hangs then one simply
|
||
>logs in as root (since the root passwd and things are in
|
||
>/etc/passwd+/etc/shadow and one keeps "files" ahead of "yp"
|
||
>in "/etc/nsswitch.conf" line for "passwd") and then restarts
|
||
>ypserv and/or ypbind if needed.
|
||
|
||
Ah, the old assumption about just being able to login as root
|
||
and make everything OK.
|
||
|
||
What do you do when this happens and the only person with the
|
||
root password is in Nebraska and you're in another state?
|
||
|
||
RELIABILITY is something to be designed in. YP is a good way
|
||
to start designing it out. Complexity and reliability are
|
||
opposites.
|
||
--
|
||
John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh
|
||
Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org
|
||
There are three documents that run my life: The King James Bible, the United
|
||
States Constitution, and the UNIX System V Release 4 Programmer's Reference.
|
||
|
||
------------------------------
|
||
|
||
From: elan@tasha.cheme.cornell.edu (Elan Feingold)
|
||
Subject: Wine Question
|
||
Date: 10 Mar 1994 20:46:55 GMT
|
||
Reply-To: elan@tasha.cheme.cornell.edu (Elan Feingold)
|
||
|
||
|
||
This may be a silly question, but when it is done, should it run
|
||
most Windows programs, or only those that run in standard mode? I
|
||
assume it could never run programs like Windows Mathematica, correct,
|
||
because it fiddles with the processor mode? Of course, if it goes
|
||
through the Win API or DMPI it has a chance, I guess?
|
||
|
||
-elan
|
||
|
||
--
|
||
===========================================================================
|
||
| Elan Feingold | |
|
||
| CS/EE Depts. | |
|
||
| Cornell University | ( .sig currently under construction ) |
|
||
| Ithaca NY 14850 | |
|
||
===========================================================================
|
||
|
||
------------------------------
|
||
|
||
From: daves@megavolt.cc.vt.edu (David Sisson)
|
||
Subject: Changes in TCP retry code?
|
||
Date: 12 Mar 1994 18:16:28 GMT
|
||
|
||
I'm using the pre-1.0 release version of the kernel that I patched up
|
||
incrementally over time from 0.99pl15. Somewhere about 15h or so I noticed
|
||
some momentary freezes when using a TCP connection to a site far away (18
|
||
hops). The strange thing is that the freezes are only of outgoing packets,
|
||
never incoming packets. So I still can get output until my packet gets
|
||
retried. 'netstat -c' shows my command is still trying to go out. Even
|
||
closes of the socket don't appear to work normally. They *do* finish, but
|
||
it usually takes a couple minutes to do so. I haven't seen any problems
|
||
locally which is why I suspect a retry problem. I'm going to try backing up
|
||
until I find a version that works.
|
||
|
||
--
|
||
daves@vt.edu
|
||
|
||
------------------------------
|
||
|
||
From: michaelw@desaster.sunflower.sub.org (Michael Will)
|
||
Subject: Re: Serious 80386 bug
|
||
Date: Tue, 1 Mar 1994 03:23:11 GMT
|
||
|
||
Tom@racing.demon.co.uk (Tom Raggett) writes:
|
||
>I ran the attached code, on my two year old AMD 386sx25 with .99pl12.
|
||
>It simply gave a Segmentation Fault and exited...
|
||
|
||
>Sorry to disappoint you, but there was no nasty crash.
|
||
|
||
It crashed as I run it as user "guest" on my AMD386dx33 with 0.99pl15h.
|
||
I guess I will make a password to that account :-)
|
||
The machine stopped completely, no reaction to the "three-finger-salute".
|
||
I had to press the red button, the rootfs was a bit out of sync
|
||
afterwards. :-)
|
||
|
||
I bought this board in 1991...
|
||
|
||
Cheers, Michael Will
|
||
--
|
||
Michael Will <michaelw@desaster.sunflower.sub.org> Linux - share and enjoy :-)
|
||
Life is not there if you can't share it... Hazel'O'Connor Breaking Glass
|
||
Happily using Linux 0.99p15e with X11R5, \LaTeX, cnews/nn/uucp/TERM and: PGP!
|
||
Analysis ist "kleiner Epsilon".
|
||
|
||
------------------------------
|
||
|
||
Subject: Little problem: ftp-data eth-ernal CLOSEing with pre-1.0
|
||
From: romano@sensores2.fis.ucm.es (Romano Giannetti)
|
||
Date: 10 Mar 94 12:29:52 GMT
|
||
Reply-To: romano@iet.unipi.it
|
||
|
||
Hi all,
|
||
|
||
I have a little problem that showed up in the long upgrading run
|
||
from pl15 to pre1-0 (sorry I don't remember when). The problem shows up
|
||
with ftp (I know, I know, this is not the right group for a ftp bug report,
|
||
but wait...). While transferring, frequently pop-up the message "cannot open
|
||
data connection" and I have to retry it. The problem is that, after,
|
||
netstat -t shows:
|
||
|
||
Proto Recv-Q Send-Q Local Address Foreign Address (State)
|
||
...
|
||
tcp 1 0 sensores2.fis.ucm:1074 phoenix.doc.i:ftp-data CLOSE
|
||
tcp 1 0 sensores2.fis.ucm:1309 arcfos1.arclc:ftp-data CLOSE
|
||
...
|
||
|
||
and _no_ in.ftpd daemons or similars still run. Note that this CLOSEing are
|
||
eternal, probably because there is something in the receiving queue. Now,
|
||
shouldn't the kernel take care cleaning up this things if the processer
|
||
(mis)using them die? In the (very) long run this could lead to problems to
|
||
the network (or I am missing something important).
|
||
|
||
BTW, there is a way of cleaning up this w/o reboot or ifconfig eth0 down and
|
||
starting again all the network daemons?
|
||
|
||
Thank you,
|
||
Romano.
|
||
|
||
|
||
|
||
--
|
||
*******************************************************************************
|
||
Romano Giannetti * DII-EIT, University of Pisa(E stands for Electronics)
|
||
romano@iet.unipi.it * Dpto Electr. y Electronica, Facultad de Fisica
|
||
* Universidad Complutense de Madrid
|
||
*******************************************************************************
|
||
|
||
------------------------------
|
||
|
||
From: helge@marvin.pc-labor.uni-bremen.de (Helge Schulz)
|
||
Subject: tcpspray hangs up pl15j + pre-1.0, but not pl15i
|
||
Date: 10 Mar 1994 14:13:22 GMT
|
||
|
||
The command "tcpspray -e -n 10000 localhost" hangs up the pl15j and
|
||
pre-1.0 Linux kernel. The tcpspray receiver process stops with a
|
||
segmentation fault and the shell prompt returns but the system hangs
|
||
up (no error message, no kernel panic, no VC switching, no reaction
|
||
on Ctrl+Alt+Del, only Ctrl+Scroll-Lock and Shift+Scroll-Lock are still
|
||
working but without writing to syslog).
|
||
|
||
With pl15i and older (I have tested pl15, pl15a, pl15b, pl15d, pl15f,
|
||
pl15h and pl15i) this doesn't happen ! But tcpspray stops with
|
||
segmentation fault, too. Gdb says, that the fault happens inside
|
||
read on the receiver socket. Calls with less blocks (without "-n 10000")
|
||
works normaly fine. Only sometimes they stops with a segmentation fault,
|
||
too.
|
||
|
||
I used tcpspray.1.1a.tar.z from sunsite (~linux/system/Network) without
|
||
any modifications.
|
||
|
||
configuration:
|
||
|
||
Cyrix 486DLC 40 MHz, 16 MB RAM, 340 MB AT-Bus harddisc
|
||
libc-4.5.21, ld.so-1.4.3, gcc-2.5.8, net-2 inetd
|
||
|
||
Helge
|
||
|
||
||| / Helge Schulz \
|
||
(o.o) | University of Bremen, Germany |
|
||
v \ helge@marvin.pc-labor.uni-bremen.de /
|
||
|
||
------------------------------
|
||
|
||
From: hdesiato@cs.umd.edu (Hui-Hui Hu)
|
||
Subject: ACCTON EtherPocket support for Linux?
|
||
Date: 12 Mar 1994 13:20:06 -0500
|
||
|
||
[makes gurgling sound]
|
||
[Looks like my post didn't get thru. *sigh*]
|
||
|
||
I recently bought an ACCTON EtherPocket parallel 10BaseT adaptor
|
||
for my notebook. Was wondering if there is anyone else out there
|
||
that either has a driver, has a clue where to find one, would
|
||
give me help in writing one, etc.
|
||
|
||
["technical information" :) from the manual - irq 5,7; 8k buffer,
|
||
256-bit EPROM)
|
||
|
||
I can't find anything helpful on the disk that's included
|
||
except for a packet driver I can use for DOS - interestingly
|
||
the skeleton is based on the GPL:
|
||
"Packet driver skeleton copyright 1988-90, Russell Nelson."
|
||
"This program is free software; see the file COPYING for details." (etc)
|
||
Does the GPL says that ACCTON should offer/release the source code?
|
||
|
||
From COPYING:
|
||
3. You may copy and distribute the Program (or a portion or derivative of
|
||
it, under Paragraph 2) in object code or executable form under the terms of
|
||
Paragraphs 1 and 2 above provided that you also do one of the following:
|
||
[a: include complete source code]
|
||
[b: accompany executable with offer to distribute source code for nominal fee]
|
||
[c: not applicable because this is a commercial product]
|
||
|
||
I haven't been able to contact ACCTON yet, I'll try later today.
|
||
|
||
Meanwhile, has this already been done, or could anyone point me
|
||
in the right direction for writing such a driver?
|
||
(keep in mind I am a clueless computer freak :)
|
||
|
||
Thanks..
|
||
|
||
-Hui-Hui Hu
|
||
hdesiato@cs.umd.edu
|
||
|
||
another q: "w" doesn't display the processes right since I've
|
||
upgraded to pre-alpha from pl15 stock.. the names are "-".
|
||
I've recompiled procps-0.92 but to no avail. Does anyone
|
||
have a newer version?
|
||
|
||
apologies if you see this message twice.
|
||
|
||
------------------------------
|
||
|
||
|
||
** 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
|
||
******************************
|