Subject: Linux-Development Digest #805
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, 8 Jun 94 11:13:09 EDT

Linux-Development Digest #805, Volume #1          Wed, 8 Jun 94 11:13:09 EDT

Contents:
  Re: Frustrated with new kernels (Andreas Toenne)
  Re: loadable drivers - who played with? (Bjorn Ekwall)
  Volunteers needed for PS/2 (MCA) version (Arindam Banerji)
  [Q] diskless boot linux from linux (Manfred Brandl)
  Re: Frustrated with new kernels (Steven Buytaert)
  Re: [Q]:  Linux as an aquisition platform/device driver (Fritz Ganter)
  Re: NCurses 1.8.5 (Brandon S. Allbery)
  Re: Book on PC architecture (Charles E Meier)
  Re: A means of networking through Firewalls (Ken Corey)
  Re: NTFS filesystem on disk layout (Marc ter Horst)
  Re: Filesystem semantics protecting meta data ... and users data (Totally Lost)
  Re: Linux game development (Was Re: Why [DOS, W (James Ojaste)
  Re: Hardware Programing References for a Newbie (M.A.Cooper)
  Re: assembly language & Linux... rep insw, esp. (Charles E Meier)
  Re: Linux game development (Was Re: Why [DOS, W (Kevin Brown)

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

From: atoenne@mpi-sb.mpg.de (Andreas Toenne)
Subject: Re: Frustrated with new kernels
Date: 08 Jun 1994 10:35:36 GMT

In article <CHRIS.94Jun3105319@blackvelvet.ads.com> chris@blackvelvet.ads.com (Chris Smith) writes:

   My advice:  Stick with what works, and upgrade when it's necessary, not
   because something new is out.  That's a caveat, I believe, that applies
   to all systems and packages in the whole industry, not just Linux.


This is one of many variations of the same wise word: 
        never change a winning team

However, what confuses me and probably many people on the net also
is that I DO NOT KNOW WHETHER I NEED A NEWER KERNEL OR NOT!
There is a difference between a running system (mine is perfectly stable
at 1.0) and a running system  with new, useful features.
So I am always tempted to upgrade my system just to make sure I won't miss
a neat feature I can use.

At the heart of my problem lies the *EMPTY* Changes list for Linux >= 1.0.0
I cannot trace all hints in this newgroups since I am no developer and
I do not understand the details of the discussed bits and patches.
My plea is: can someone list the (for a user) interesting changes and
ongoing developments such that we understand when it is time to try
a new kernel, even when it is not officially finished (ie. 1.1.x). 

        Andreas Toenne
--

        Andreas Toenne                  Voice:  x49 681 5846272
        Max-Planck-Institut             Office: x49 681 302 5363
        fuer Informatik                 e-mail: atoenne@mpi-sb.mpg.de

        Im Stadtwald
        66123 Saarbruecken, Germany

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

From: bj0rn@blox.se (Bjorn Ekwall)
Subject: Re: loadable drivers - who played with?
Date: 8 Jun 94 07:26:08 GMT

Heiko Schlittermann (heiko@lotte.sax.de) wrote:
 > Note: followup is set to comp.os.linux.development ...

 > While playing with interrupts and the Mitsumi driver I felt the wish
 > to avoid constantly booting my system....  I got the modutils
 > package and played around with.  But I'm afraid, I'd need some
 > further informations about using the modutils...

 > Is anybody out there with any experience in using modutils?

 > -- heiko

For some "kernel-side" implementations, look in "linux/drivers/net",
esp. the following files (Linux v.1.1.13 and upwards):
  Makefile, MODULES, net_init.c, de600.c, 3c509.c, 3c501.c, plip.c
and of course also "linux/kernel/ksyms.c".

These are the ones I know quite well, and there are a _lot_ of other
modules coming along... You could also check the KERNEL-channel.

Bjorn Ekwall == bj0rn@blox.se

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

From: axb@defender.dcrl.nd.edu (Arindam Banerji)
Subject: Volunteers needed for PS/2 (MCA) version
Date: 8 Jun 1994 03:15:00 GMT


I'm trying to co-ordinate the development for the MCA to an extent. At 
present, if you are using an ESDI drive you can get a version of Linux
from invaders.dcrl.nd.edu::/pub/misc/linux. The instructions, base 
system and source can also be found in the same place. Craig Mcneil
is working on getting together a slackware distribution, which'll 
hopefully be alittle more complete, than what I still have. I'll try and 
locate more information about other disk drives too . I do understand 
that there must be work done by others, that I'm not aware of. If 
you do know of such work, please do let me know.  

For those who feel that they would like to contribute to making the MCA
version of Linux, a stable release - there are some things the need to 
be done for this release. 
1. Due to the proprietary nature of IBM drives, lack of information about
   them and also the existence of a numerous variations of micro-code, we 
   almost have to consider abios support. CMU Mach, which is public 
   domain (for the ps2s) is a good source of code for this. Inspite of 
   all the arguments against int13h support, we almost have to support 
   it to make the MCA machines successful. 
2. Token ring support : Many people who use PS/2s use the token ring. Support 
   for token ring is necessary (to an extent) even for the regular ISA
  , EISA (etc) machines. Hence, I've decided to bite the bullet and start
    some work on it.   
3. There seem to be recurring problems with the serial link on PS/2s. If 
   somebody has a fix for this, please let me know. If not - this will 
   require some fixing. 
4. Although, I've never tried to do this myself, other people have often 
   complained about using X on PS/2s. Hence, this also needs some work. 

If you feel you'd like to get involved and can help, please let me know. 

-thanx

 
P.S: Thanx to Peter De Schrijver for helping me setup the first machine.


=============================================================================
=============================================================================

 
=============================================================================
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: mbrandl@info.archlab.tuwien.ac.at (Manfred Brandl)
Subject: [Q] diskless boot linux from linux
Date: 8 Jun 1994 11:08:45 GMT


Is there someone out there who has tried to boot a diskless linux box
from another (diskful) linux box over ethernet.

I need to find out if it is possible/done in this or similar way:

1.) Have a boot ROM which understands to load via bootp a file at a defined
    position in memory.

2.) This file contains the linux kernel proper with an compressed image of
    the boot disk (minimal) to be set up as ram disk.

3.) the kernel allocates a ram disk (of say 1MB) and decompresses the 
    boot disk image (all files are in /dev and /boot)

4.) init is started from /boot, using a non standard /boot/inittab, boot
    scripts are in /boot/rc.d.

5.) after being able to mount nfs, we mount the pseudo-root partition, having
    symbolic links from /etc -> /pseudo/etc, /bin -> /pseudo/bin and so on.

6.) the rest should be no problem.


My questions are:

- Is there a network card with a boot PROM for bootp ?

- Is there something flaky in my booting process ?

- Is there someone who is interested in having real diskless linux
  and can will spend some time/equipment/money to have that ?


Manfred Brandl (mbrandl@iicm.tu-graz.ac.at)


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

From: buytaert@imec.be (Steven Buytaert)
Subject: Re: Frustrated with new kernels
Date: Wed, 8 Jun 1994 07:51:41 GMT

Mike Dowling (mike@MooCow.math.nat.tu-bs.de) wrote:
: >>> On 03 Jun 1994 22:08:46 GMT, ron@draconia.hacktic.nl (Ron Smits) said:
: Ron> Sorry, but I would like to disagree, I'm now running 1.1.16 with a fully
: Ron> functional network, 4.5.21 libraries and gcc 2.5.8, I havent encountered
: Ron> any problems whatsoever.

: Yes, indeed!  I've been following this discussion and find myself puzzled as to
: difficulties some people seem to be having.  I'm using 1.1.18 and find it as
: stable as a rock, as too all the previous kernels from 0.99.14 onwards.

  FWIW, I haven't got into the discussion myself, because of the
  same reason. No problems here whatsoever. None... But I always
  patch up the kernel from top to bottom, that is:

  a clean 1.1.0 and apply all patches from 1 to 18...

  Stef

--
Steven Buytaert 

WORK buytaert@imec.be
HOME buytaert@innet.be

        'Imagination is more important then knowledge.'
                        (A. Einstein)

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

From: ganter@fvkmapc02.tu-graz.ac.at (Fritz Ganter)
Subject: Re: [Q]:  Linux as an aquisition platform/device driver
Date: 7 Jun 1994 15:52:38 GMT

Schultz, Russell (schultz_russell@semail.jsc.nasa.gov) wrote:
: We're currently in the process of making some decisions about choosing
: a UNIX flavor for an aquisition platform that may eventually find
: itself on the MIR spacestation.

: What, if any, device drivers are written for a/d acquisition cards, and
: what/how easy is it write custom drivers for Linux?

: Source code, faqs, personal experience, whatever would be greatly
: appreciated.

: P.S.  it would be extra spiffy if Linux ran on a IBM thinkpad 750, does
: it?
I'm also interessed in this. I'm writing a program for data aquisition on
engine test benches. I need source or dokumention for a IEEE-488 interface
card from CEC.

: Russ
: --
: I'm not allowed to get anybody in trouble except myself.

--

Fritz, always linuxing...

Fritz Ganter                            Graz University of Technology, Austria
Email:               ganter@fvkmapc02.tu-graz.ac.at, ganter@vkma.tu-graz.ac.at
HAM-Radio: OE6FAD@OE6XYG.AUT.EU, OE6FAD@OE6FAD.AMPR.ORG, Tel. +43 316-873-7222
 ****************     Linux... try it, use it, love it.     *****************

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: NCurses 1.8.5
Date: Wed, 8 Jun 1994 11:18:04 GMT

In article <zmbenhalCr2BDp.HGq@netcom.com>, zmbenhal@netcom.com (Zeyd M. Ben-Halim) says:
+---------------
| In article <2t290g$8gk@hippo.shef.ac.uk>,
| Stuart Herbert <ac3slh@sunc.sheffield.ac.uk> wrote:
| >Well, werase() in ncurses has been broken, as it no longer honours the
|
| Au contraire, mon ami! The new behavior of werase() is the same as that
| of SVR4 curses. Blame them! 
+------------->8

I think the wbkgdset() call is supposed to set this behavior; unfortunately,
it's not really implemented (e.g. not used).  At some point I plan to
experiment with it under SCO and see if I can figure out what the background
color support is really supposed to do, and add the functionality to ncurses.
(That is, if Zeyd doesn't beat me to it.  :-)

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
The FUDs at Microsoft are shouting "Kill The Wabi!"

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

From: cemeier@magnus.acs.ohio-state.edu (Charles E Meier)
Subject: Re: Book on PC architecture
Date: 8 Jun 1994 12:22:53 GMT

In article <Cr16Lu.D95@inf.uc3m.es>,
Pedro de las Heras <pheras@inf.uc3m.es> wrote:
>
>
>Hello.
>
>We want references on books, articles,... about PC architecture.  
>
>Good descriptions of low level programming, registers of different parts,...
>

Start by getting copies of the data sheets for the standard parts (e.g. Intel's
8237 DMA controller, 8259 interrupt controller, 8254 timer, 82018 clock, and 
Nat'l Semiconductor's 16450/16550 uart).  Some of these you can copy at your
local technical library (unless you are at Ohio State where the engineering
library doesn't seem to have many data sheet books :-( ) or you can get the
Intel _Peripheral Component Handbook_.

A second useful source is the _Technical Reference: Personal Computer AT_.
This is the volume that IBM sold with its original IBM PC-AT.  It has details
on such things as the ISA bus and a source listing for the BIOS for the AT.

A third handy reference is _PC Magazine Programmer's Technical Reference:
The Processor and Coprocessor_, by Robert L. Hummel, Ziff-Davis Press.

I've often wondered why some knowledgeable engineer hasn't gathered all of 
this material into a single book that explains how all the various chips
work together to become a whole PC compatible machine.  Or have I missed 
_The Ultimate PC Hardware Reference Book_ in my perusal of the shelves of
the local bookstores?

cem

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

From: exukenc@exu.ericsson.com (Ken Corey)
Subject: Re: A means of networking through Firewalls
Date: Wed, 8 Jun 1994 12:29:49 GMT

Tim Docker (timd@extro.ucc.su.OZ.AU) wrote:
: My Linux box sits on a LAN that is physically connected to the net, but
: packets are not routed through the machine that connects the LAN to the
: internet SLIP connection. In practice this means that I can perform most
: netoperations in two steps - for example, a telnet to the local machine, and
: then a telnet to any other host.
: This is often inconvenient, and makes some things impossible (like running
: Mosaic locally). A tentative idea to get around this problem is to write code
: to do the following:

I wonder if term would help you here?  

I use term115 on a serial port, but maybe it could be hacked to provide this
kind of telnet functionality for you too?

--
Ken Corey   exukenc@exu.ericsson.com  214/907-5841  Speaking for everyone...
 Death is only a state of mind.
 
 Only it doesn't leave you much time to think about anything else.

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

From: mht@nuclint.nl (Marc ter Horst)
Subject: Re: NTFS filesystem on disk layout
Date: Wed, 8 Jun 1994 19:26:57 GMT

In article <2t367g$9ct@magus.cs.utah.edu> baford@cs.utah.edu (Bryan Ford) writes:
>From: baford@cs.utah.edu (Bryan Ford)
>Subject: Re: NTFS filesystem on disk layout
>Date: 8 Jun 1994 01:17:36 GMT

>Mikael Nykvist (viper@ludd.luth.se) wrote:
>>In <TVO.94Jun5182603@zaphod.swb.de> tvo@zaphod.swb.de (Thomas Vogler) writes:
>>>i intend to write a filesystem driver for linux supporting NTFS in order
>>>to be able to access my NTFS formatted disks under Linux. In a first
>>>attempt i plan to support read only access only, write access might follow
>>>later.
>>>
>>>in order to do this, i will need some informations how NTFS files are stored
>>>on a disk.
>>
>>Because of the B2 (or was it C2 ?...) security, I dont think MS will release
>>any 'internal' info about NTFS... If they did, you could make a boot-disk
>>that could access the NTFS-partions and the security are lost..

>Yikes, if this is true then Microsoft is even dumber than I thought. :-)
>Security based on secret algorithms is not really security at all -
>good security is always based on widely known and easily testable algorithms.
>The only thing that needs to be kept secret is the passwords, keys, etc.

>However, all the same I wouldn't be surprised if Microsoft hasn't (and won't)
>release the disk format for NTFS.
>Maybe it's time out to pull out the disk editor...
I seem to recall they based it on HPFS (as in OS/2), and I think PC Magazine 
even had a series on it (with Ray Duncan) when it was released way back 
when :-).
 Marc
>                                Bryan
>---
>Bryan Ford      baford@cs.utah.edu      University of Utah, CSS
>`finger baford@schirf.cs.utah.edu' for PGP key and other info.

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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin
From: idletime@netcom.com (Totally Lost)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Wed, 8 Jun 1994 12:18:27 GMT

In article <2t3qreINNql6@usenet.pa.dec.com>,
Burkhard Neidecker-Lutz <neideck@nestvx.enet.dec.com> wrote:
>In article <idletimeCr1Ao6.81w@netcom.com> idletime@netcom.com (Totally Lost) writes:
>>
>>Read first, then write .... one point of the posting was that ordered
>>writes correct 95% of the reason programmers are forced to use O_SYNC
>>to protect database updates.
>
>My point was that most file system operations on UNIX system don't
>require that much consistency and that for these the normal file
>system semantics are ok as a default.


And my point is that any production (either interactive software development
users, student instructional servers, or more traditional end-user applications)
can not accept the security impacts or data corruption associated with
the current filesystem designs. Are you tring to say that having files
undetectably corrupted with uninitialized deleted file contents is an
acceptable result of a "normal" operational failure?

In the last 19 years 3 cases occured where sensitive information/mail ended
up in another users file for the systems I have mothered ... first time was
at SRI 1977 under V6 unix on a PDP-11. A much larger number of readable ascii
files have ended up with a block or more of binary trash in them unexpectedly
(and no corresponding disk errors could be found on the hard copy log).

I do not consider this an acceptable side-effect of any operational problem.
For a toy home system that only has a single user (or family) sure
a little corruption can be tolarated, but is it even necessary - NO!

>> O_SYNC was a stupid solution to the problem
>>in the first place. Ordered writes with commit operations solves the
>>entire problem without the huge performance penalty.
>
>I was advocating more for fsync(2) than O_SYNC. But you are correct that
>this is different from ordered writes and commits (which is in a sense
>what's used inside Advfs on DEC OSF/1, though it's a more complex
>transaction mechansim with write-ahead logging).

Most sigificant commercial applications need reliable updates that span
multiple files/databases for multiple processes. fsync provides a crude
commit operator useful for a single writer situations. With multiple
writers fsync also forces to disk the partially completed operations of
other writers which can leave the indexes or data of a database corrupt
on a crash and make the transaction difficult or impossible to backout
or complete based upon the transaction log. Especially when trash ends
up at the end of the file (or in the middle if the file is sparce/holely)
due to the meta hitting the disk prior to the data.

Many managers and applications programmers are completely unaware or
ready to deal with this type of corruption when they choose a UNIX system
to replace a more traditional mini or mainframe.

>>Why is it that you can not understand the gains possible with ordered
>>writes? I guess it's just because you don't take the time to think ...
>>or can not ...
>
>Err, I do, and Advfs uses an even more clever mechanism without the need
>of changing applications or the file system semantics (thank you, Digital
>does understand production systems). The VMS operating system has all sorts
>of facilities like that in the file system, but more often than not the
>performance impact of having these semantics as the *default* rather than
>available only where needed is very high.

AND if it still allows meta  data to be written prior to file data then it
is operationally unsafe and a major security risk. Supporting per file
ordered writes as Advfs is fine, but why did they stop there?

>If you really want transactional safety and semantics, use a database or
>transaction monitor. If you're rather into *implementing* one of those,
>DEC OSF/1 has all the facilities to do asynchronous I/O and inserting 
>appropriate synchronization as part of it's AIO facility (both to
>raw devices as well as to file systems).

What I (and customers should) really demand is operational saftey and security.
Transactional security and semantics are only a plus, and not addressed in my
original post. And while I believe they should be part of all UNIX
offerings, I do not require it.

What is the point you are trying to make? That the security and file
corruption aspects of current filesystem design during OS/Hardware
failure is acceptable?

My only point is that this is not acceptable or necessary.

John

John

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

From: jojaste@undergrad.math.uwaterloo.ca (James Ojaste)
Subject: Re: Linux game development (Was Re: Why [DOS, W
Date: Tue, 7 Jun 1994 16:22:24 GMT

In article <2skp6o$r1@styx.uwa.edu.au>,
David Luyer <luyer@tartarus.uwa.edu.au> wrote:
>DPMI (or similar) is where this answer lies.  But then, Linux requires
>minimum 4meg (don't say 2meg,I've tried it) of memory for itself.

OK.  I won't mention that our CSC (Computer Science Club) has a 386
(donated in parts), with 2M ram, 52M hard disk, running Linux, and
playing samples over a DAC whenever a door is closed, or the lights are
turned on.  2M is fine for this purpose - but Linux doesn't require more.

[a lot of other rambling deleted]

(jojaste@descartes.uwaterloo.ca)

-- 
   Y            James Ojaste (jojaste@descartes.uwaterloo.ca)
   | ,---       
   |/           "I said that you couldn't be both smooth and kinky at the
   +-----X       same time, and then somebody put up his hand and asked,

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

From: M.A.Cooper@bradford.ac.uk (M.A.Cooper)
Subject: Re: Hardware Programing References for a Newbie
Date: Wed, 8 Jun 1994 12:26:04 GMT

Preston William Gilchrist (pwg7503@tamsun.tamu.edu) wrote:
: I am a farely experience C programmer but have done little programming that
: has dealt with lower level hardware access(ie. disks, cdroms, sound cards, etc)
: I was wondering if anyone can recommend a good reference source for access to
: these types of hardware items, command codes used, and standards for hardware
: items such as SCSI cards, sound cards, and such.  I would like as much linux
: specific docs as possible but any PC related stuff appreciated.  

: Preston Gilchrist
: Please Respond via E-Mail : pwg7503@tamsun.tamu.edu


        Hi there,
                check out the kernel hackers guide on sunsite.unc.edu under
pub/Linux/docs.  The document includes an extensive tutorial on the low level
workings of the SCSI drivers in the linux kernel, and device drivers in general.

        Hope this helps
                Martin
-- 
***************************************************************
*                M.A.Cooper@bradford.ac.uk                    *
*       "Real programmers don't write documentation"          *
***************************************************************

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

From: cemeier@magnus.acs.ohio-state.edu (Charles E Meier)
Subject: Re: assembly language & Linux... rep insw, esp.
Date: 8 Jun 1994 12:42:50 GMT

In article <HUGH.94Jun8215543@hugh.cosc.canterbury.ac.nz>,
Hugh Emberson <hugh@hugh.cosc.canterbury.ac.nz> wrote:
>In article <5QEzGfohojB@bionic98.bionic.zer.de> F.SCHMIDT@BIONIC.zer.de (Florian Schmidt) writes:
>
>   reply on user dyoung@superdec.uni.uiuc.edu
>
>   >   Where do I find documentation for the Linux assembler that covers
>   > all of that and more?
>
>   here the same prob!
>
>
>I had the same problem finding documentation about gas (the
>assembler), I have Slackware 1.2 and I got info pages for everything
>except gas. I grabbed the gas source from the nearest mirror of
>prep.ai.mit.edu and extracted the info pages, I suggest you do the
>same.
>

I, too, have been stuck on occasion due to lack of documentation for 
as and ld.  I solved it eventually by finding the info files and man 
pages.

H.J. - Could you please put copies of the man pages for as, ld, and gcc
in with your binary distributions of the compiler and libraries?  It would
be very helpful and much appreciated by many of us.

Thanks!

cem


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

From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: Linux game development (Was Re: Why [DOS, W
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)
Date: Tue, 7 Jun 1994 16:34:39 GMT

In article <2t11lr$g7k@usenet.ins.cwru.edu>,
Michael D. Zoran <mdz@po.CWRU.Edu> wrote:
>
>    I think a unix like system or a time sharing system is simply a bad
>enviroments for games.  Simply put, most of the good games are written in
>assembly,

I'm not sure this is the case anymore (though it used to be, back
when 640k was the most memory you could have and you were running
a 286 or slower processor).

> take over the entire machine, and usually completely bypass the
>OS and access the hardware directly to give optimal performence.  This in
>away is why DOS is so great for games.  The os loads the program and
>doesn't do much else. Isn't this why its called a "Disk Operating system." 
>I think a unix system with its layered hardware abstraction just gets 
>in the way of these types of games.
>    If you want to play games, reboot into dos.

If you're running linux and want your game to be the only thing
running, it's not hard to do: have your game run as init.  :-)

There is a slight performance hit for having to switch in and out
of kernel mode whenever you make a system call.  But a properly
coded interface will make the most difference with respect to that.
For instance, libraries can queue up writes to the disk to minimize
calls to the kernel.  An interface to the video display that allows
you to make large updates at once will reduce the number of kernel
calls you have to make to get such things to happen.

Another thing is that, when you get right down to it, humans are
*slow* compared to computers, particularly with today's fast
hardware.  That means your program can do quite a bit before having
to, for instance, update the display.  This is why "virtual reality"
games such as DOOM are possible.

With all the complexity embedded in today's games, I think the
amount of overhead represented by the transistion from user space
to kernel space is relatively small.


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


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