Subject: Linux-Development Digest #733
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:     Thu, 19 May 94 03:13:12 EDT

Linux-Development Digest #733, Volume #1         Thu, 19 May 94 03:13:12 EDT

Contents:
  Re: Distributions considered harmful (Stuart Herbert)
  Re: Microchannel support (Arindam Banerji)
  Re: More Weird buffer erros (Frank Lofaro)
  Standard I/O library inefficient? (Jon Green)
  Re: Appletalk support? (Alan Cox)
  Re: Emacs 19.23 -- still won't compile without patches for Linux (Michael Griffith)
  Re: 1.0.9 kernel bug (+ partial fix): when using non-loopback address to send to localhost, "from" address should also be non-loopback. (Doug Mauldin)
  Re: Modem hangup? (Ed Casas)
  Re: LOGISCAN V0.0.1 released (Steven M. Palm)
  reading ROM (Pieter.Verhaeghe)
  Re: SIGHUP - Deep Kernal Guts question! (Leon Garde)
  Re: SIGHUP - Deep Kernal Guts question! (Leon Garde)
  Booting from CD-ROM (was: 386BSD 1.0 - Stop it, please...) (Greg Lehey)
  Re: Binary compatibility (Conrad C. Nobili)

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

From: ac3slh@sunc.sheffield.ac.uk (Stuart Herbert)
Subject: Re: Distributions considered harmful
Date: 18 May 1994 19:09:49 GMT

Russell Nelson (nelson@crynwr.crynwr.com) wrote:
: I don't think the current state of Linux distributions is good.

Okay, that's a reasonable point.

: Free
: software works because the users can be programmers, and everyone can
: cooperate.

Forgive me - what is your definition of 'free'?  Given your previous plea
to use the GPL, I'll assume that one.

: But with the various distributions, we have noncooperation.

In what way?  I don't doubt your assertion - I'd just like more information.

: Guys, that's what the SysV people do, not us.  They
: feel a need to differentiate their product from the base System V
: distribution from USL.  So when they fix a bug, or add a feature, they
: *don't* send it back to USL.

And these virulent bouts of featuritis are the reason that 'standards' are
such a mockery.

: We can do better than that.

Sorry - *who* can do better than that? ;)

: We've got at least four different package conventions (SLS, Slackware,
: Debian and Yggdrasil).  Why?  No good reason I can see.  FTP sites
: carry these different distributions, most of which differ only slightly.

It's called freedom of choice.  You forget that these distributions are
NOT Linux - they are a collection of software which has been packaged
together with the Linux kernel.  (Over-simplification, I know :)

: I feel that there is need, and room, for two Linux distributions, one
: conservative, and the other radical.

Two distributions?  Hrm ...

: The conservative distribution is
: probably the harder, and potentially more money-making, distribution
: to do.  It is marketed at Linux "users".  People who don't want to
: have to fiddle.  People who are willing to pay for the software to
: "just work".  So the conservative distribution has its work (and
: profit) cut out for it.

So, what goes in this 'conservative' distribution?  Saying that it is
aimed at Linux 'users' does nothing to define its content.  Define a
Linux 'user'.

: And there's plenty of money to be made on the radical distribution,
: because it's obvious that some people out there want the latest and
: greatest, and they're willing to pay for it.  "Who has the latest CD"
: is the subject of a recent Usenet message.

So, let me get this straight.  You're saying that there should be two
distributions, one of which is a later one than the other (nothing else
is inferred in your post).  Correct me if I'm wrong, but aren't most of
the modifications to software which is included actually necessary to
maintain compatability (I've just been reading a thread about how fast
things break on Linux ...)

: And multiple distributions are not good, because they tend to fragment
: the market.  

Why?  Everyone who uses one of those distributions has to be using Linux.
Linux itself is common to all of those distributions.

: The Linux market is small enough as it is -- we don't
: need to make it smaller!

You're not.  By offering a choice, there's something for everyone, and
people will find what's right for them.

: If I'm running Slackware, I don't feel like
: I can purchase SLS's support package.  Or if I've bought Yggdrasil's
: CD-ROM, can I install an slackware package?  And not break everything?

Ah, now we're getting to what all this is about ... it's not the *content*,
it's the inter-operability.

There is a solution to that ...

: And Adam's not doing himself any favors by not creating an FTPable
: Yggdrasil distribution.  In the free software market, you create
: business by giving away your software to create a need for your
: services.  The less you give away your software, the less your
: services are needed.

Right, we get back to this definition of 'free'.  You're a champion of the
GPL.  The GPL does NOT define free software as software that you HAVE to
'give away'.  The definition of freedom is built around access to the source
code itself.

It is one business practice to 'give' your software away, and sell support,
but having a commercial distribution, where you PERHAPS sell support on top,
is just as viable a business.  Adam is obviously making enough to keep him
in business :)

: And Debian, while it has the support and name of the FSF, is just
: plain not needed.  Much, much better to fix the problems with
: Slackware, SLS, or Yggdrasil.

Why is it not needed?

FYI, Debian looks like being adopted by at least one corner of the Linux
community that, instead of sitting on USENET complaining at these people
who have put in a LOT of hard work so we can enjoy Linux, are actively
seeking to expand the Linux community.  I've used machines which have had
Debian installed, and I've found it okay, and I look forward to its
completion.

: We should start with a merger between SLS and Slackware.  Send your
: requests for same to Peter and Patrick, imploring them to cooperate
: for the betterment of all.  Yes, they've had words, but they should
: still be able to work together.

Mmm ... you're not quite hitting the nail on the head.

What we need aren't so much complete distributions, but a standard way of
packaging the Linux software.  That means a standard installation system,
standard documentation conventions, standard minimum utilities, which
everyone adhears to.

Slackware has a nice installation system, which copes with uninstalls as
well.  I've not played with any other distribution in this area.  Standard
documentation - sorry, but that's becoming a joke.  You've got man and FSF's
info, and there's interest in using html for more documentation.  This needs
consolidating.  Minimum utilities?  I have to admit that I've no idea whether
anyone has made such a standard.  If not, it's needed.

My point to you is that we shouldn't be relying on a small group of people,
who do a fantastic job, to be producing packages.  The people who write/port
packages should take the time to make what's necessary to support a *standard*
installation utility.

: So who am I to be giving out all this free advice?  Why, just someone
: who's been supporting himself for 2.5 years by selling support for
: free software.

And that's your problem.  'Supporting himself'.

Stuart
--
Stuart Herbert -- S.Herbert@shef.ac.uk

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

From: axb@defender.dcrl.nd.edu (Arindam Banerji)
Subject: Re: Microchannel support
Date: 17 May 1994 18:21:43 GMT

Peter Schrijver and I are currently working on making the PS/2 ESDI driver 
a little more stable. The current version of the driver does not work 
consistently on all machines. We are trying to fix this problem. Once this is 
done, we should be able to move on to the Token ring support. 

- thanx
 
=============================================================================
Arindam Banerji                              (219)-631-5273 (Voice)
384 FitzPatrick Hall                         (219)-631-5772 (Voice)
Dept. of Computer Science and Engineering    (219)-273-0862 (Voice)
University of Notre Dame                     (219)-631-9260 (FAX)
Notre Dame, IN 46556                         axb@cse.nd.edu (E-mail)
=============================================================================

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

From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: More Weird buffer erros
Date: Wed, 18 May 94 22:36:07 GMT

In article <1994May16.211933.5937@titan.westfalen.de> johannes@titan.westfalen.de (Johannes Stille) writes:
>In article <2qo04l$b6h@harbinger.cc.monash.edu.au> kevinl@bruce.cs.monash.edu.au (Kevin Lentin) writes:
>[...]
>>There are 2 problems here.
>>The first is the obvious buffer problem which still needs fixing.
>>The second is that surely if linux mounts a floppy that is write
>>protected, it should mount it as read only. That is what the write-protect
>>switch is for. If I tried to mount an nfs partition exported read only as
>>writable would it do so?
>[...]
>
>I have a patch that makes the kernel actually check the write protect
>status when trying to mount or open a floppy read-write. If you want to
>try this patch, please mail me.
>
>       Johannes

Yes! Please port/upload it. People have been wantting htis for a long time.
(It is a good idea).



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

From: jcgreen@iastate.edu (Jon Green)
Subject: Standard I/O library inefficient?
Date: 19 May 94 02:42:25 GMT

I've been reading through "Advanced Programming in the Unix Environment"
by Stevens, and trying out various programs on my Linux system.  After
much digging and reading, I still have a few questions.  I used the following
program to time the results for reading a file with different buffer
sizes:

#include "common.h"

int
main(int argc, char *argv[])
{
  int n, bufsize;
  char buf[atoi(argv[1])];
  bufsize = atoi(argv[1]);

  while ( (n = read(STDIN_FILENO, buf, bufsize)) > 0)
    if (write(STDOUT_FILENO, buf, n) != n)
      err_sys("write error");

  if (n < 0)
    err_sys("read error");

  exit(0);
}


Here are the results, compiled into a table.

Blksize utime  systime total
======= ====== ======= ========
1       8.330u 203.370s 3:46.28
2       3.850u 94.820s 1:40.79
4       1.660u 46.350s 0:48.69
8       0.880u 22.890s 0:24.13
16      0.490u 13.190s 0:14.37
32      0.250u 6.610s 0:07.18
64      0.080u 3.430s 0:03.69
128     0.070u 1.790s 0:02.03
256     0.010u 0.980s 0:01.04
512     0.010u 0.560s 0:00.60
1024    0.020u 0.340s 0:00.38
2048    0.010u 0.320s 0:00.35
4096    0.000u 0.310s 0:00.33
8192    0.000u 0.260s 0:00.25
16384   0.000u 0.290s 0:00.32
32768   0.000u 0.290s 0:00.32
65536   0.000u 0.280s 0:00.28
131072  0.000u 0.290s 0:00.32

This would seem to indicate that the optimal size for a buffer is 8192, where
the system time is the lowest.  However, another program that uses the
standard I/O library gives me the following results:

stream = stdin, line buffered, buffer size = 1024
stream = stdout, line buffered, buffer size = 1024
stream = stderr, unbuffered, buffer size = 1024
stream = msdos file, fully buffered, buffer size = 2048
stream = ext2fs file, fully buffered, buffer size = 1024

The buffer size shown is taken from the st_bufsize member of the stat
structure, and other calculations I've done seem to give the same answer.
I am wondering why the optimal buffer size is not being used here.  Wouldn't
using 8192 make standard I/O operations faster?

I'm also wondering about the purpose of the _blksize member of the FILE
structure, defined in <libio.h>.  This member always seems to be set to
zero.. is it used for anything?

I'm still new to programming under Unix, so if the above shows that I'm 
really confused, I welcome anyone who wants to enlighten me. :)

-- 
* Jon Green           *  Proud to be a member of   * 5646 Friley Hall        *
* jcgreen@iastate.edu * drunk_bastards@iastate.edu * Ames, Iowa 50012-0001   *
* Jon2@irc            *          *BURP*            * Phone (515) 296-0648    *

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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Appletalk support?
Date: Wed, 18 May 1994 14:18:44 GMT

In article <9413822.2009@mulga.cs.mu.OZ.AU> djh@cs.mu.OZ.AU (David Hornsby) writes:
>Porting CAP in "Native EtherTalk" mode to Linux is not feasible unless
>
>1. you can get packets delivered to individual processes based on the
>packet content, specifically the AppleTalk destination socket number.
>Normally this requires a packet filter based on the Stanford or Berkeley
>models.  Or,
Linux can do this. Have a look at the BPF code in tcpdump. Thats a port of
BPF for Linux in effect.
>
>2. You can get all incoming AppleTalk packets delivered to each interested
>process and have the process discard it if unwanted, and do so in a
>relatively efficient manner.
Linux can also do this.
>On the other hand, porting UAR (UNIX AppleTalk Router, which supports CAP)
>to Linux should be simple, provided that Linux can send and receive 802.3
>format packets AND support ethernet multicast packets (09:00:07:ff:ff:ff &
>09:00:07:00:00:XY). The last time I checked, these facilities were missing
>from Linux. If someone can tell me otherwise, I will happily write the
>relevant UAR code bits tomorrow ...

Linux can send and receive 802.3 format packets happily. At the moment there
are no set/clear multicast flags but if you want them added I'll put them
in pronto!

Alan


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

From: grif@corsa.ucr.edu (Michael Griffith)
Subject: Re: Emacs 19.23 -- still won't compile without patches for Linux
Date: 18 May 1994 17:38:01 GMT

In article <2rdigt$hld@darkstar.UCSC.EDU>,
David Konerding <rafael@cse.ucsc.edu> wrote:
>I figured that this time around Emacs19.23 would compile for Linux without
>patches.  No such luck. The same problem as last time- it dies for me in
>dispnew.c, apparently because some macro is incorrectly defined in
>./src/s/linux.h.  I tried changing 
>#define PENDING_OUTPUT_COUNT(FILE) ((FILE)->_IO_write_ptr - (FILE)->_IO_write_base)
>
>to 
>#define PENDING_OUTPUT_COUNT(FILE) ((FILE)->_pptr - (FILE)->_pbase)

#define PENDING_OUTPUT_COUNT(FILE) ((FILE)->_IO_write_ptr - (FILE)->_IO_write_base)

No, the above Is the right one.  You need to be sure that it is used.
I used a littlne brute force by unconditionally #define'ing it in
src/s/linux.h and removing the erroneous #defines in src/dispnew.c



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

From: gdmauldin@ualr.edu (Doug Mauldin)
Subject: Re: 1.0.9 kernel bug (+ partial fix): when using non-loopback address to send to localhost, "from" address should also be non-loopback.
Date: 17 May 94 00:12:00 CST

[deletia]
>>people, it doesn't matter if it's fixed in 1.1.8 !!
> 
> I think the original issue was only the existance of a bug and how it
> could be fixed.  When the bug is fixed in an alpha version and you don't
> want to upgrade to it, then so be it.  You still have your stable version
> with the bug.

     I'd rather have the stable version _without_ the bug.  Is that an
unreasonable expectation?

--Doug


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

From: edc@ee.ubc.ca (Ed Casas)
Subject: Re: Modem hangup?
Date: Wed, 18 May 1994 20:52:08 GMT

In article <CpyxDw.Ay2@pe1chl.ampr.org> pe1chl@rabo.nl writes:
> In <2ravc0$ve@potrzebie.ee.pdx.edu> bairds@ee.pdx.edu (Scarrow) writes:
> 
> >I'm developing some software ... I've had some difficulty
> >getting Linux to drop the DTR line...
> 
> Setting B0 works fine...

Note that modem register S25 sets the minimum duration of a DTR
drop that the modem will notice. The default is 50 ms.  So make
sure you usleep() (or whatever) at least that long between before
raising DTR again.

-- 
Ed Casas (edc@ee.ubc.ca)

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

From: smp@agape.sol.net (Steven M. Palm)
Subject: Re: LOGISCAN V0.0.1 released
Date: Thu, 19 May 94 03:45:10 GMT

In article <2rbt6m$as3@nic.umass.edu> cmay@titan.ucs.umass.edu writes:
>
>Well, the file made its way into the ALPHA/scanner directory on tsx-11.
>Look for logiscan.tar.z, I'll let you all know how it works, but 
>probably not until after finals are over.

 GOT IT!

 And, at least for me, it works GREAT.  Unfortunately, there isn't any
 software to utilize it yet, but the little beast works perfectly here.

 I even tried the "grayscale" switch in the scandemo program, and my
 scanner seems to handle that just fine, producing nice grayscale output.

 MANY THANKS for the pointer to this one.  My poor old hand scanner was
 the only vestige attached to my PC that only DOS recoginzed...  Now all
 my hardware is recognized by Linux.



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

From: pive@uia.ac.be (Pieter.Verhaeghe)
Subject: reading ROM
Date: Tue, 17 May 1994 06:25:15 GMT

Hi,

I'd like to know how I can read the value of a specific memory address
(I think it is an address in ROM). I have the address in the following 
form abcd:efgh.

What I like to do is the following: (pseudo code)
        if value(abcd:efgh)==xy && value(abcd:efgh+1)==st {
          do my stuff
        } else {
          wrong computer type
          exit
        }

Thanks
        Pieter

=========================================================================
P. Verhaeghe (pive@ruca.ua.ac.be)
University of Antwerp,RUCA,Department of Mathematics and Computer Science
Groenenborgerlaan 171                                  Tel: +32 3 2180376
B-2020 Antwerpen, Belgium                              Fax: +32 3 2180217
=========================================================================

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

From: lgarde@scorch.hna.com.au (Leon Garde)
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: Tue, 17 May 1994 17:53:24 GMT

mcross@sw.stratus.com (Matt Cross) writes:

>In article <1994May13.042516.27841@loreli.ftl.fl.us>, nate@loreli.ftl.fl.us (Sean Puckett) writes:
>> The kernal apparently wants to send just one HUP/CONT pair
>> only to the session leader, and none to any other processes
>> on the lost tty.  The session leader (shell) is sucessfully
>> killed on hangup, every time, but its children are not.

>Take a look at something on job control and process groups.  The kernel
>sends the signal to the whole process group, so unless the shell is

 SIGHUP as a response to the lost tty is only sent to the
'session  leader' task. see kill_sl in exit.c

>broken, the SIGHUP signal will be sent to all processes attached to the
are all processes attached to the terminal session leaders of a
session ?
>terminal.  Also, make sure the processes themselves don't leave the
>process group...

>       -Matt


how would a broken shell affect the situtation ?

how does a process leave the process group ?
is a process group part of the same session, or 
the entire session ?
can a process group be the session leader, orA
is the leader a single process, not a group of processes
(a process group is a group of processes that are one task ..
and the task is the leader, so ive answered myself .. ? )

BUT ANYWAY,

the problem with SIGHUP when the tty is lost (modem hangs etc)
is that do_exit in kernel/exit.c
does not send SIGHUP, SIGCONT to children of a process if
that process has no children which are stopped.
what makes things tricky, is that the stopped tasks are
SIGHUP'ed, but running tasks aren't. even if there are stopped
tasks, running tasks are left running.


I couldnt see why there was any problem with running tasks
over stopped tasks.
do running tasks get a different pgrp, to the stopped ones ? 

leon



-- 
leon garde; lgarde@scorch.hna.com.au

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

From: lgarde@scorch.hna.com.au (Leon Garde)
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: Tue, 17 May 1994 18:06:46 GMT

hurtta@dionysos.fmi.fi (Kari E. Hurtta) writes:

>nate@loreli.ftl.fl.us (Sean Puckett) writes:

>;The kernal should, by itself (with no help from shells), send SIGHUP to all tty
>;attached processes when the tty is lost.  Unless there's a very good reason
>;why it shouldn't -- and I need to know if that reason exists.

>Well, then Linux Goes It's Own Way.

>Manual pages of SunOS, HP-UX and IRIX agree with following:

>   Modem Disconnect
>       - SIGHUP is sent to controlling process
>       - backgroud process get SIGTIN/SIGTOU when it tries access terminal

>   When session leader, which have controlling terminal, exits
>       - SIGHUP is sent to processes in that group
in my 1.1.12 kernel,
do_exit sends SIGHUP to the group if (and only if)
there are stopped processes in the group,

it is only running tasks that i find detached from the terminal after
the leader exits. but thats even if there are stopped jobs.
(i dont know if the bit about stopped jobs in do_exit has anything
much to do with this problem


>--
>- Kari E. Hurtta                             /  Eldmd on monimutkaista
>  Kari.Hurtta@Fmi.FI                        puh. (90) 1929 658

leon
-- 
leon garde; lgarde@scorch.hna.com.au

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

From: grog@lemis.uucp (Greg Lehey)
Crossposted-To: comp.os.386bsd.development,comp.unix.pc-clone.32bit
Subject: Booting from CD-ROM (was: 386BSD 1.0 - Stop it, please...)
Date: 18 May 94 06:45:42 GMT

In article <jlemonCpwnBr.CGn@netcom.com> jlemon@netcom.com (Jonathan Lemon) writes:
>In article <2r6c10$kis@news.cs.tu-berlin.de>,
>Lars Grupe <lunde@cs.tu-berlin.de> wrote:
>>
>>A word to some others: Do you really find it interesting whether an
>>OS that has not been seen by anyone here does boot off a CD-ROM?
>
>Nope. 
>
>If I could stick a CD-ROM in the drive and turn the machine on, then 
>possibly I would be interested.  If I have to go and:
>       1) muck with my SCSI settings (where did my manuals go?)
>       2) reboot the machine after saving the changes
>       3) remember to re-change the settings for normal operation after 
>          finally booting from the CD
>
>then I fail to see the point.  Sure, it may be a neat hack, but it's not
>easier than putting in a floppy.  If it's not an improvement over the current
>status quo, then why should I care?

What little information has come out of this flood of messages suggests:

1. It's possible with an Adaptec 1540x.

2. It's not possible with CD-ROMs with their own host adapters.

3. You may need to do special things to your aha controller to boot
   from the CD-ROM.

In addition, the question arises: once I have my aha set up to boot
from CD-ROM, how do I get it to boot from hard disk? This is
independent of the question of target addresses: at some point, you
need to interface with the PC BIOS, which usually allows you to choose
which permutation of A: and C: drives you want to try to boot from.
This suggests to me that once you have set up your system to boot from
CD, you need to change it again to boot from hard disk. If this is the
case, than it's a tradeoff between inserting a boot diskette and
rebuilding your computer. Which would you choose?

There is (theoretically) a simpler way: a universal boot diskette.
This should be intelligent enough to boot from all better-known
devices, including specifically:

- SCSI CD-ROM
- proprietary interface CD-ROMs (e.g. Mitsumi)
- SCSI tape
- QIC-02 tape
- Floppy tape
- Just for the fun of it, hard disk

All it needs to do for any of these devices is to read in a
second-level bootstrap from the device, and leave the remaining
processing to the second-level bootstrap. As such, it would be
OS-independent. I believe that the Linux LILO does something similar
on a disk partition basis, and obviously the code is there for most of
the devices I have mentioned. Is anybody interested in putting
together such a diskette?


-- 
=============================================
Greg Lehey              | Tel:  +49-6637-1488              
LEMIS, Schellnhausen 2, | Fax:  +49-6637-1489
36325 Feldatal, Germany | Mail: grog@lemis.de

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

From: Conrad_Nobili@Harvard.EDU (Conrad C. Nobili)
Subject: Re: Binary compatibility
Date: Wed, 18 May 1994 21:04:45 -0400

In article <2rc1l8$56a@geraldo.cc.utexas.edu>, lilo@slip-1-52 (lilo) wrote:

> Anyway, there you have one person's opinion.  :)  I'd like to hear other
> opinions, and I think we can only profit from more discussion!

I basically am of the same opinions.  If Linux becomes petrified by
excessive binary compatibility constraints I will probably start to lose
interest in it.  Source code compatibility is sufficient for the purposes
of hackers in a rapid development environment.

Of course, total lack of concern for compatibility would be bad too.  In
this regard, Linus with the kernel, H.J. Lu with GCC/libc, and Alan Cox
with the NET-2D stuff have done wonders to maintain a *reasonable* level of
compatibility and stability.

IMHO it has been just about the *right* amount.  Too much concern for these
things and we have stagnation and lack of progress into the future.  Too
little concern and progress won't be possible because of the confusion and
fragmentation of the independent development efforts.

Well, again this is just Humble Opinion, but I think Warner's concerns,
though important and valid, are not necessarily the concerns of *all* Linux
users and developers at this stage in its evolution.  I might agree more
with him in a year or two, but not now.  We have something pretty vital
here that shouldn't be killed.

Personally I don't *care* if Linux ever "takes off" or becomes
"commercially viable" or "commercial developer friendly" or whether I can
ever buy WordPerfect for it at Egghead.  Of course I understand that others
*do* care about these things.  Maybe their needs can be served with
Novell's Corsair/Expose Linux system (see PCWeek May 16, V11, N19, cover
bottom)...?

Conrad C. Nobili  N1LPM  Conrad_Nobili@Harvard.EDU  Harvard University OIT

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


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