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, 13 Apr 94 07:13:05 EDT
Subject:  Linux-Development Digest #628

Linux-Development Digest #628, Volume #1         Wed, 13 Apr 94 07:13:05 EDT

Contents:
  Re: PowerPC (MPC601) HW & Linux ???? (Hamish Macdonald)
  Re: LILO v12-v14 BUG [Solution] (Salvador Pinto Abreu)
  TCP/SLIP constipation: Linux -> OS/2 (Greg McGary)
  Re: PowerPC (MPC601) HW & Linux ???? (Jim Lynch)
  Green Card Lottery- Final One? (Laurence Canter)
  Re: PHIGS for Linux??? (Bhama Srinivasan)
  NIS bug in Slackware 1.2? (Andrew Gallatin)
  Re: A boost in performance when performance weakens (patch) (Kai Petzke)
  Re: NET: I'll implement NFS via TCP, tell me how! (Alan Cox)
  trouble with Double - ext2fs (Olav Kvittem)
  Re: Linux 1.07 or 1.1? (Joel M. Hoffman)
  Re: Green Card Lottery- Final One? (Rainer Klier)

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

From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
Subject: Re: PowerPC (MPC601) HW & Linux ????
Date: 12 Apr 1994 13:56:33 GMT

>>>>> On 12 Apr 1994 03:39:03 EST,
>>>>> In message <jimlynchCo51D3.IJ3@netcom.com>,
>>>>> jimlynch@netcom.com (Jim Lynch) wrote:

Jim> Once the gcc cross environment works, try to get the kernel
Jim> across. Will Linux's 80x86 dependencies hurt us here? 

I suggest that you might want to work from the Linux/68k sources
(although they are a bit behind the Linux/i386 sources; I intend to
remedy this soon).

A lot of the CPU dependencies of the Linux/i386 sources have been
abstracted out in the Linux/68k source.

One of the exceptions (unfortunately) is the "mm" code.  It really
needs to be broken down into CPU dependent and CPU independent
portions.  It hasn't yet.

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

From: spa@fct.unl.pt (Salvador Pinto Abreu)
Subject: Re: LILO v12-v14 BUG [Solution]
Date: Tue, 12 Apr 1994 08:47:59 GMT

>>>>> pcaulfield@cix.compulink.co.uk ("Patrick Caulfield") writes:

> I had this with LILO 0.14 and found a directory /dev/fd which was linked 
> to /proc/self/fd. I simply removed this link and LILO works fine.

> It seems that scan_dir was recursing down this directory and adding all 
> it found there to the boot path I had provided in config.

Probably it's looking for the device names so you can call them by
name, eg. /dev/root etc. (just guessing)

Funny thing is, that I have this on my machine and Lilo works just
fine.  However after copying my / filesystem to another machine, the
copy has trouble running lilo.  It must be a problem with the order
in which files show up in /dev: the system that works has /dev/fd
show up after the last disk; those that don't work use alphabetical
order (eg. fd comes before hda1).

Maybe Lilo should do a readlink(2) before recursing into
directories, and only look into it only if it's not a link to
something in /proc; here's an (untested, but it compiles) fix:

--- device.c~   Mon Jan  3 23:49:46 1994
+++ device.c    Tue Apr 12 10:35:15 1994
@@ -47,6 +47,10 @@
            }
            if (S_ISDIR(dev->st.st_mode) && strcmp(dir->d_name,".") &&
              strcmp(dir->d_name,"..")) {
+               char link_name[PATH_MAX];
+               if ((readlink (parent, link_name, PATH_MAX) > 0) &&
+                   (strncmp(link_name, "/proc", 5) == 0))
+                 continue;
                for (walk = next; walk; walk = walk->next)
                    if (stat_equal(&walk->st,&st.st)) break;
                if (!walk && scan_dir(&st,dev,parent,number)) {


If you don't want to hack at lilo, there is a workaround: you can
unmount /proc and it'll work just fine; kill syslogd and sendmail
first though. (actually all processes with open descriptors on
/proc, which you can find out about with, eg, "fuser -mv /proc")

> Quite what /dev/fd was doing there in the first place I don't know!

it's just so that you can say /dev/fd/0 to refer to stdin for
instance. can come in handy sometimes.

> Patrick

../salvador Pinto Abreu         spa@fct.unl.pt
                                Universidade Nova de Lisboa, PORTUGAL

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

From: gkm@tmn.com (Greg McGary)
Subject: TCP/SLIP constipation: Linux -> OS/2
Date: 12 Apr 1994 22:09:40 -0400
Reply-To: gkm@tmn.com (Greg McGary)


Linux 0.99.15 has trouble talking to OS/2 2.1 over IBM TCP/IP 2.0.
The slip connection establishes fine, and ICMP packets appear to go
back and forth, as ping from either host works.  However, data does
not appear to travel from Linux to OS/2 over TCP connections.  If I
start telnet or ftp from Linux, it reports that the connection is
established, but nothing more happens.  netstat(8) reveals that
there's data pending in the Linux side's send-queue.  Data appears to
travel from OS/2 to linux however.  When I start a telnet or ftp from
the OS/2 side, I get a connection established message and OS/2's
netstat says nothing's pending in the queues, but on the Linux side
data is again sitting in the send-queue.

Has anyone seen this problem with 0.99.15 (no patches)?  Has anyone
observed that TCP between Linux 1.0+ and OS/2 works with? I'm
reluctant to mess with upgrading to Linux 1.0+ until I know more about
the status of this...

Thanks.

--
Greg McGary          (703) 729-6217          gkm@tmn.com

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

From: jimlynch@netcom.com (Jim Lynch)
Subject: Re: PowerPC (MPC601) HW & Linux ????
Date: Tue, 12 Apr 1994 08:39:03 GMT

In article <cairnss.765869660@ucsu.colorado.edu>,
Queenie <cairnss@ucsu.Colorado.EDU> wrote:
>chafey@ecst.csuchico.edu (Chris Hafey) writes:
>
>Start by writeing a cross assembler for the machine.
>Now build a C compiler.
>You are half way there.

Umm, we're already halfway there; we just use gnu's gcc. Any version after 
2.5.0 supports PowerPC.

>Start writing drivers.
>
>You can do the development on any machine.  For a Linux
>port I'd start with a Linux Machine.

Here, you're making sense. We start by grabbing the gcc 2.5.8 source code and
work on getting a cross environment built (Docs on how are in the gcc compiler 
source tree, in a file called 'INSTALL'). Once the gcc cross environment
works, try to get the kernel across. Will Linux's 80x86 dependencies hurt us
here? Or will the PowerPC have the stuff needed to make the port a screamin'
success?

Once we have a kernel that can say 'Hello, world' to a PowerPC machine, it's
time to work on just enough driver software to create a PowerPC Linux native
compilastion and debugging environment. Once this is established, the work
can really start...


-- 

-Jim

----

* Write to clipper.petition@cpsr.org and tell them you oppose Clipper.
* Write to cantwell@eff.org supporting HR 3627.
* Write leahy@eff.org and demand the Clinton administration explain IN
  THE SENATE why it thinks U.S. citizens shouldn't have any digital privacy.
* This is a shareware .signature  -- please pass it on!

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

From: nike@indirect.com (Laurence Canter)
Crossposted-To: la.forsale
Subject: Green Card Lottery- Final One?
Date: 12 Apr 1994 07:55:10 GMT

Green Card Lottery 1994 May Be The Last One!
THE DEADLINE HAS BEEN ANNOUNCED.

The Green Card Lottery is a completely legal program giving away a 
certain annual allotment of Green Cards to persons born in certain 
countries. The lottery program was scheduled to continue on a 
permanent basis.  However, recently, Senator Alan J Simpson 
introduced a bill into the U. S. Congress which could end any future 
lotteries. THE 1994 LOTTERY IS SCHEDULED TO TAKE PLACE 
SOON, BUT IT MAY BE THE VERY LAST ONE.

PERSONS BORN IN MOST COUNTRIES QUALIFY, MANY FOR 
FIRST TIME.

The only countries NOT qualifying  are: Mexico; India; P.R. China; 
Taiwan, Philippines, North Korea, Canada, United Kingdom (except 
Northern Ireland), Jamaica, Domican Republic, El Salvador and 
Vietnam. 

Lottery registration will take place soon.  55,000 Green Cards will be 
given to those who register correctly.  NO JOB IS REQUIRED.

THERE IS A STRICT JUNE DEADLINE. THE TIME TO START IS 
NOW!!

For FREE information via Email, send request to
cslaw@indirect.com


-- 
*****************************************************************
Canter & Siegel, Immigration Attorneys
3333 E Camelback Road, Ste 250, Phoenix AZ  85018  USA
cslaw@indirect.com   telephone (602)661-3911  Fax (602) 451-7617

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

From: geyer@polyhymnia.iwr.uni-heidelberg.de (Bhama Srinivasan)
Subject: Re: PHIGS for Linux???
Date: 11 Apr 1994 22:18:28 GMT

Bob Kelley (bkelley@cup.hp.com) wrote:
:>Kaelin Colclasure (kaelin@bridge.com) wrote:
:>: Is there a free implementation of PHIGS or PHIGS+ for Linux?  I
:>: understand that the PEX extensions can be compiled into the XFree86
:>: 2.0 server, but how do you *use* them once they're there?

:>Don't use PHIGS myself, but I am pretty sure I saw source on 
:>the Yggdrasil CD-ROM, so it must have been ported.

believe me, you do not want to use PEX and PHIGS with XFree86(tm). Even on the 
faster cards it is very slow.
If you want to have a look at it, get the *-pex-* packages from the
XFree86 distribution and the linkkit. Build a server including PEX and try
phigs. But it is much work to do this and it is not useable.

        Helmut
--
==============================================================================
Helmut Geyer                                Helmut.Geyer@iwr.uni-heidelberg.de

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

From: gallatin@serov.isds.duke.edu (Andrew Gallatin)
Subject: NIS bug in Slackware 1.2?
Date: 12 Apr 1994 15:52:15 GMT

I'm having a little trouble getting NIS working under Slackware 1.2,
and I was wondering if there might be a bug in either NIS or portmap.
I'm not certain this should go here, but I understand that NIS is new
to linux, plus somebody else already posted a similary query in
comp.os.linux.help and it got no response.

The problem I'm having is with ypbind, and programs that rely on
information from databases served by NIS. For example, if I'm running
ypbind, then run something that looks at the passwd database, (ps cux
for example), I get a message of the form:

clntudp_create: RPC: Port mapper failure - RPC: Unable to receive

It seems as though most lookups work.  Telnet and login work, and
programs like ps and ls are able to match usernames & groups to uids
and gids.  The only serious problem is that rlogin, rsh and rcp into
the linux box do not work when running NIS.  They print the above
message, and exit.  (rlogin dies before asking for a passwd).

If I kill ypbind, and make a local entry for myself in the passwd
file, the messages go away, and rlogin, rsh and rcp work fine.

Ypbind is started immediately after inetd in /etc/rc.d/rc.inet2:

#start the NIS services
if [ -f ${NET}/ypbind ]
 then
  echo -n " ypbind"
  ${NET}/ypbind -S isds.duke.edu,serov
fi

Serov, the NIS server, is a DecStation 5000/200 running Ultrix 4.2,
and it successfully serves other DECstations, Suns running SunOS
4.1.X, and DEC Alphas running DEC OSF/1 V2.0

The linux box is running Slackware 1.2, downloaded from sunsite on
Saturday, with no mods except a kernel recompile to strip out unneeded
drivers.  Uname -a tells me:
Linux chase 1.0 #3 Sat Apr 9 20:01:26 EDT 1994 i486

Just in case some output from rpcinfo might be helpful, I'll paste it in:

<10:40am>chase/gallatin:~>rpcinfo -u chase ypbind
clntudp_create: RPC: Port mapper failure - RPC: Unable to receive
program 100007 version 2 ready and waiting

<10:41am>chase/gallatin:~>rpcinfo -u serov ypserv
clntudp_create: RPC: Port mapper failure - RPC: Unable to receive
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting

<10:41am>chase/gallatin:~>rpcinfo -u serov ypbind
clntudp_create: RPC: Port mapper failure - RPC: Unable to receive
program 100007 version 1 ready and waiting
program 100007 version 2 ready and waiting


Thanks in advance for your help,

Drew
##############################################################################
#               Andrew Gallatin, System Administrator                        #
#           Institute of Statistics and Decision Sciences                    #
#         Box 90251, Duke University, Durham, NC 27708-0251                  #
#                   email:  gallatin@isds.duke.edu                           #
##############################################################################

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

From: wpp@marie.physik.tu-berlin.de (Kai Petzke)
Subject: Re: A boost in performance when performance weakens (patch)
Date: 9 Apr 94 17:43:13 GMT

rubini@unipv.it (Alessandro Rubini) writes:

>I posted this on the mailing list but the list seems to be dead :-(

>this is a _very_ tiny patch to decrease swapping when the system is
>heavily loaded, with a little performance penalty in small-load situations.

>----------------------------

>I noticed that all docs state that the good thing of the elevator
>alghorithm is that it favours reads. Though this is surely a good
>behaviour if you have plenty of ram, when the system is heavy-loaded,
>it is undoubtely a loss. I have only 4 megs ram and I'm pretty
>interested to get performance out of my box, since I sometimes need X.

I think, yours is a good idea.  Let's compare two scenarios:

a) You have plenty of RAM free, and lots of activity.  Every 30
   seconds, update decides to do massive writes to disk.  It
   does not matter, whether these writes get done this second
   or the next second, but it may annoy people, if they have
   to wait two seconds for a small file to be read, because
   all the writing is going on.

   So, if there is enough RAM free, priority should go to reads.

b) You have no RAM free.  Every single page allocated requires
   another page to be swapped out, or a dirty buffer has to be
   cleaned by writing it.  In that case, the performance is
   determined, on how fast the bad stuff gets out.

Well, the function, that knows best about how bad the situation
is, is try_to_free_page().  If it has to go to high priority
level to find a free page, then it definitely is the time to
reverse the paradigma, and do the writes before the reads.

Anybody have suggestions on this?

-- 
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: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: NET: I'll implement NFS via TCP, tell me how!
Date: Tue, 12 Apr 1994 12:55:50 GMT

In article <MEF.94Apr11192650@willow.cs.washington.edu> mef@willow.cs.washington.edu (Marc Fiuczynski) writes:
>I thought that NFS was stateless and using TCP as the transport
>implies that you need to add some sort of state to NFS.  Not sure how
NFS remains stateless. If you lose a TCP connection you just re-establish it
and carry on.
>hard or easy that is.  Further, not sure if the flow-control will help
>in getting better throughput, unless most ACK packets are piggy backed.
Thats a very simplistic attitude. The real world isn't a simple ethernet
where you count the number of bytes of overhead. Over real networks TCP
provides the neccessary efficient flow control and error recovery that
UDP simply doesn't cope with. You could implement it yourself on top
of UDP, but you'd end up with a pseudo-TCP anyway.




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

From: oak@domen.uninett.no (Olav Kvittem)
Subject: trouble with Double - ext2fs
Date: 12 Apr 1994 21:26:36 GMT

Hi,

Double garbeled my files :

I tried to install Double 0.2 with an accompanying patch two ways :

1. By formatting a complete partion with Double using  
Slackware to install. It failed because I did not know how to make
Slackware "setup" access the /dev/doble0 compressing device (perhaps mounting
on /mnt and omitting 'target spec' would have done it). None the less
Slackware "setup" did not recognize the /dev/double0 device.

2. By splitting the partion in  2 and installing base system and
development on partition 1 and making the second a Doble partion
with ext2fs on top. This went administratively/systemwice OK.

I then copied the linux source into the Double-partion with cp.

Greping the kernel for a non-existing string took serveral times
longer with more CPU used on the compressed than the
uncompressed partition. So the performance was not too good.

The real problem was that when I tried to compile the kernel on the
compressed device. I turned out that the FILES WERE GARBELED.
Diffs for one directory is enclosed (/db is the compressed fs).

Olav

/tmp>cat kernel.diff 
diff -r /usr/src/linux/kernel/.depend /db/usr/src/linux/kernel/.depend
46,47c46
<   /usr/include/linux/msdos_fs_i.h /usr/include/linux/iso_fs_i.h /usr/include/linux/nfs_fs_i.h \
<   /usr/include/linux/nfs.h /usr/include/linux/xia_fs_i.h /usr/include/linux/sysv_fs_i.h \
---
>   /usr/include/linux/msdos_fs_i.h /usr/include/linux/iso_fs_i.h /usr/include/linux/nfs_fs_i.h \dm(*srinclude/linux/nfs.h /usr/include/linux/xia_fs_i.h /usr/include/linux/sysv_fs_i.h \
150c149
<   /usr/include/linux/xia_fs_i.h /usr/include/linux/sysv_fs_i.h /usr/include/linux/minix_fs_sb.h \
---
>   /usr/inux/cmsnux/xia_fs_i.h /usr/include/linux/sysv_fs_i.h /usr/include/linux/minix_fs_sb.h \
265c264
< traps.o : traps.c /usr/include/linux/head.h /usr/include/linux/sched.h /usr/include/linux/tasks.h \
---
> tram.psn.raps.c /usr/include/linux/head.h /usr/include/linux/sched.h /usr/include/linux/tasks.h \
diff -r /usr/src/linux/kernel/exit.c /db/usr/src/linux/kernel/exit.c
338c338
< static void forget_original_parent(struct task_struct * father)
---
> static void forget_oid fgiparent(struct task_struct * father)
Binary files /usr/src/linux/kernel/exit.o and /db/usr/src/linux/kernel/exit.o differ
diff -r /usr/src/linux/kernel/fork.c /db/usr/src/linux/kernel/fork.c
92c92
< int dup_mmap(struct task_struct * tsk)
---
> inodt.h> dap(struct task_struct * tsk)
diff -r /usr/src/linux/kernel/ioport.c /db/usr/src/linux/kernel/ioport.c
138,139c138,139
<  * only the super-user to do it. This depends on the stack-layout
<  * on system-call entry - see also fork() and the signal handling
---
>  * only the super-user to do it. This depends on the stack-layot
>  on system-call entry - see also fork() and the signal handling
diff -r /usr/src/linux/kernel/irq.c /db/usr/src/linux/kernel/irq.c
89c89,90
<  * bottom_half handler need not be re-entrant.
---
>  * bom_ace.
>       f handler need not be re-entrant.
Binary files /usr/src/linux/kernel/irq.o and /db/usr/src/linux/kernel/irq.o differ
Binary files /usr/src/linux/kernel/kernel.o and /db/usr/src/linux/kernel/kernel.o differ
Binary files /usr/src/linux/kernel/mktime.c and /db/usr/src/linux/kernel/mktime.c differ
diff -r /usr/src/linux/kernel/ptrace.c /db/usr/src/linux/kernel/ptrace.c
160c160
<  * This routine checks the page boundaries, and that the offset is
---
>  * This routine checks the pageboutndaries, and that the offset is
Binary files /usr/src/linux/kernel/ptrace.o and /db/usr/src/linux/kernel/ptrace.o differ
diff -r /usr/src/linux/kernel/sched.c /db/usr/src/linux/kernel/sched.c
367,368c367
<       add_wait_queue(&sem->wait, &wait);
<       current->state = TASK_UNINTERRUPTIBLE;
---
>       add_wait_queue(&sem->wait, &wait) q;cFent->state = TASK_UNINTERRUPTIBLE;
769c768
<       current->priority = newprio;
---
>       curren-nsiority = newprio;
Binary files /usr/src/linux/kernel/sched.o and /db/usr/src/linux/kernel/sched.o differ
diff -r /usr/src/linux/kernel/signal.c /db/usr/src/linux/kernel/signal.c
309c309
<  * the kernel can handle, and then we build all the user-level signal handling
---
>  * the kernel can handle, and then we build all t usern-alevel signal handling
diff -r /usr/src/linux/kernel/sys.c /db/usr/src/linux/kernel/sys.c
447c447
<        * Ok, we have probably got enough memory - let it rip.
---
>        * Ok, we have probvabyRgot enough memory - let it rip.
diff -r /usr/src/linux/kernel/sys_call.S /db/usr/src/linux/kernel/sys_call.S
151,152c151
<       incl _intr_count
<       sti
---
>       incl _intr_scopl usti
Binary files /usr/src/linux/kernel/sys_call.o and /db/usr/src/linux/kernel/sys_call.o differ
diff -r /usr/src/linux/kernel/time.c /db/usr/src/linux/kernel/time.c
237c237
<  * soon as possible, so that the clock can be set right.  Otherwise,
---
>  * soon as possible, so that the clock can be set right.  Othrw
                                                                  se,
diff -r /usr/src/linux/kernel/traps.c /db/usr/src/linux/kernel/traps.c
158c158
<  *  - the tag word is saved in the operand selector.
---
>  us s i tag word is saved in the operand selector.
Binary files /usr/src/linux/kernel/vsprintf.o and /db/usr/src/linux/kernel/vsprintf.o differ







--
   Olav Kvittem : UNINETT A/S
      RFC Address     Olav.Kvittem@uninett.no
      OR Address      C=no;ADMD=" ";PRMD=uninett; O=uninett;S=Kvittem;G=Olav
      Postal Address  Box 6883 N-7002 Trondheim
      Phone           +47-7-596981 +47-7-596450(FAX)
      Description     Network Manager
   "Networking needs neat working - Nettverk er nette verk !"


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

From: joel@rac1.wam.umd.edu (Joel M. Hoffman)
Subject: Re: Linux 1.07 or 1.1?
Date: Tue, 12 Apr 1994 14:12:43 GMT

>> Is there a list somewhere of which kernel contains what, so, once we
>> decide what we want from out systems, we'll know which kernel to
>> choose?  Perhaps an RCS log?
>> 
>Easy -- if you want a 100% stable system with a known set of features, use
>1.0. If you want to play with the newest&latest and chance a crash or two
>whilst playing, use 1.1.x.

But what is the "newest & latest?"

-Joel
(joel@wam.umd.edu)

-- 
=============================================================================
|_|~~ Germany, Europe. 1943.    "The diameter of the bomb was 30 centimeters,
__|~| 16 Million DEAD.           and the diameter of its destruction, about 7
                                meters, and in it four killed and 11 wounded. 
 cnc  Bosnia, Europe. 1993.     And around these, in a larger circle of  pain
 cnc  HOW MANY MORE?          and time,  are scattered two  hospitals and one
                          cemetery.   But the young woman who was  buried  in
                    the place from where she came, at a distance of more than
             than 100 kilometers, enlarges the circle considerably.   And the 
      lonely man who is mourning her death in a distant  country incorporates
into the circle the whole world.  And I won't speak of the cry of the orphans
that reaches God's chair and from there makes the circle endless and godless."
=============================================================================
     Tell Clinton to stop the genocide:  president@whitehouse.gov

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

From: rrklier@cip.informatik.uni-erlangen.de (Rainer Klier)
Crossposted-To: la.forsale
Subject: Re: Green Card Lottery- Final One?
Date: Tue, 12 Apr 1994 16:52:42 GMT

nike@indirect.com (Laurence Canter) writes:

>Green Card Lottery 1994 May Be The Last One!
>THE DEADLINE HAS BEEN ANNOUNCED.

[ junk deleted ]

>For FREE information via Email, send request to
>cslaw@indirect.com

>-- 
>*****************************************************************
>Canter & Siegel, Immigration Attorneys
>3333 E Camelback Road, Ste 250, Phoenix AZ  85018  USA
>cslaw@indirect.com   telephone (602)661-3911  Fax (602) 451-7617

Just wanted you to know that you won the first price, Laurence Canter: 
      
      A permanent entry in my nn-kill file :(

Posting your stuff in every group isn't much fun :(((

Rainer
---
      ______
     /|     |  Rainer Klier                       Phone : Just ask me :)
    / |__   |  Koenigstr. 107                     Fax   :      -"-
   | /__/|  |  90762 Fuerth   
   | |  ||__|  Germany
   | |__|/  /  
   |/______/   email : rrklier@cip.informatik.uni-erlangen.de       
=============================================================================

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


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