Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest105
2024-02-19 00:24:15 -05:00

650 lines
24 KiB
Plaintext

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: Fri, 2 Sep 94 09:13:05 EDT
Subject: Linux-Development Digest #105
Linux-Development Digest #105, Volume #2 Fri, 2 Sep 94 09:13:05 EDT
Contents:
Re: XFconfig86 problems - HELP! (Richard Schennberg)
Re: Any interest for DCF77 clock code? (Uwe Bonnes)
Re: Linux - my first impressions (olav woelfelschneider)
DOS BC++/Linux floats (Riku Saikkonen)
Re: Linux - my first impressions (Hamish Macdonald)
Re: What on earth is happening to the stability of the Linux Kernel? (H. Peter Anvin)
MPEG Hardware Decoder (West Suhanic)
Re: svgalib can't open /dev/mem w/1.1.47 (Louis P. Kruger)
Re: PRIORITY make an undelete command (Darren J Moffat)
Dosemu 0.53 - the mouse under Xwindows (Mihail S. Iotov)
Re: Kernel change summary 1.1.45 -> 1.1.46 (Marc Fraioli)
Re: DOSEMU 0.53: Developers and testers ne (rxr401)
Re: Netware Client (Mark Evans)
floppy problems in 1.1.49 (Michael Callahan)
Re: Hardware flow control under linux not working??? (Michael Callahan)
HD problems (>1.1.44) (Alan N Hunter)
----------------------------------------------------------------------------
From: schennbe@ms.uky.edu (Richard Schennberg)
Crossposted-To: comp.windows.x.i386unix,comp.os.linux.help
Subject: Re: XFconfig86 problems - HELP!
Date: 1 Sep 1994 18:45:23 -0400
In article <CvGI27.C3o@dorsai.org>,
Carlos Dominguez <carlos@dorsai.dorsai.org> wrote:
>
>Hi..
>
>Day three, and I still cannot get X up and running on my linux box.
>I'm using the slackware 2.0 distribution from the morse cd-rom.
>
>As per the HOW-TO's I tried to run the XFconfig86 shell scripts.
>
>I still am getting errors like "cannot cat /tmp/??????"
>whenever I try to run Xfconfig86 included in my slackware 2.0 cdrom
>distribution.
>
Try creating a /tmp directory. Type:
cd /
mkdir tmp
Then run the XFconfig86 shell script. If you get more errors, you may
have to correct them until it runs O.K. Whenever something gets better,
keep an extra copy of the best Xconfig file you have so far. Even after
XFconfig86 runs O.K., you may have to fine-tune your preferences as you
learn more about X11.
--
=======================================================================
I try to tell the truth. This may not coincide with university policy!
Richard Paul Schennberg FAX ==> 606-273-6196
Email ==> schennbe@ms.uky.edu Flames ==> /dev/null
------------------------------
From: bon@lte.e-technik.uni-erlangen.de (Uwe Bonnes)
Subject: Re: Any interest for DCF77 clock code?
Date: Thu, 1 Sep 1994 18:05:12 GMT
In article <342g7s$q33@urmel.informatik.rwth-aachen.de> dak@rama.informatik.rwth-aachen.de (David Kastrup) writes:
>Trying to get a head count...
>How many people would be interested in a small program which gets the current
>time from the radio clock DCF77 (receivable about 900km around Frankfurt,
>Deutschland, official time base for Germany) and sets the system time?
>Comes with man page, and has
>options making it secure to use, say, daily in your crontab, while updating
>the CMOS clock as well.
>
>It sets UTC directly, so is timezone independent. You need a small radio
>clock device tied up to a serial port.
>
>This program will be freely available to whoever wants it.
>
>However, making it a package requires that there are specifications
>included concerning the hardware.
>
>Would you please answer me, and tell me if
>a) A logic description of the hardware would be ok for you.
>b) A circuit diagram would be ok for you (circuits about 20DM)
>c) You would rather buy a finished product for 50DM.
>
>Since the latter would cause development costs for me, I will only delve
>into it if sufficient response is there. Note that everything softwarish
>item will be freely available, including circuit diagram.
>
>In case there is enough interest in ready to use hardware, I will include
>an offer in the documentation. In case there is not, I will leave out
>the offer, but include a circuit diagram.
>
>I will not go into the bother of producing devices myself if I do not
>get a head count of at least 10 which would definitely purchase their
>device from me (including a 3.5" disk with the software, if wanted.
>But it will be ftp-able as well).
>
>Apart from the "offer-hardware-or-not"-question, the thing is running,
>including man-page, and so you should be able to pick it up somewhere
>around next week. See c.o.l.a.
>
Before you write one, look with "archie -s dcf"! There are several!
---
Uwe Bonnes bon@lte.e-technik.uni-erlangen.de
------------------------------
From: wosch@rbg.informatik.th-darmstadt.de (olav woelfelschneider)
Subject: Re: Linux - my first impressions
Date: 1 Sep 1994 08:43:30 GMT
Owen Lynn (lynn@magneto.physics.auburn.edu) wrote:
: Hi folks!
[..lotsa deleted..]
: The way you reconfigure the kernel, however is radically different to
: how you do it under 4.1.3. Instead of modifying a config file, you
: run a shell script which asks you a bunch of questions. Ok, simple
: enough, and then it gets more familiar - setting dependencies and
: cranking the new kernel out. You copy it to the root dir, and name
: it vmlinuz (sounds oddly 4.1.3ish). Then it gets odd again - you have
: you reinstall lilo. Easy enough, but wierd. I guess it's probably to
: make up for some deficiency in PC hardware design.
If you like to edit a config file, just edit /usr/src/linux/config.in
It should be clear for you what to edit there.
Then make config and just press return until you are throug.
Maybe you could also change the makefile so that you have no need to
press return that much. Contribute your changes (: !
About re-installing lilo:
I've an old 3/50, and did some 4.1.1 kernel remakes there. Each time /vmunix
changed, some program has to be run to inform the bootloader about the
track/sector/head location of the new kernel. The same is true for linux and
lilo.
Maybe that is not the case anymore with 4.1.3 or on sparc machines, shrug.
Just my $(2/100).
--
/======================================\
| Olav "Mac" Woelfelschneider |
| wosch@rbg.informatik.th-darmstadt.de |
+--------------------------------------+
| I refuse to grow up, |
| I don't want to lose my humor... |
\======================================/
------------------------------
Subject: DOS BC++/Linux floats
From: riku.saikkonen@compart.fi (Riku Saikkonen)
Date: Thu, 1 Sep 94 19:01:00 +0200
I have made an application that I use in both MS-DOS and Linux. The
thing works well enough, and I was able to port it from MS-DOS Borland
C++ to Linux gcc pretty easily. But there's one problem...
I would like to use the MS-DOS version and the Linux version with the
same data files. Linux reads the MS-DOS fs well enough, but my files are
in a binary format. Basically, just a few structs written directly from
memory using fwrite().
So I just need to get the file format to be the same. And there's my
problem. Most of it was easy (after I figured out that int is 32-bit in
Linux :)), but floats I can't seem to read. The BC++ float format and
the Linux float format seem to be different.
So, is there a way to read the Borland C++ floating point numbers in
Linux? Now I have a converter to convert the data file to ASCII and
back, but that's not an optimal soluion...
(Whyever did that get so long? Hmm... :))
-=- Rjs -=- riku.saikkonen@compart.fi - IRC: Rjs
"For still there are so many things / that I have never seen: /
in every wood in every spring / there is a different green." - Tolkien
------------------------------
From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
Subject: Re: Linux - my first impressions
Date: 1 Sep 1994 21:57:19 GMT
>>>>> On 01 Sep 1994 14:00:58 EST,
>>>>> In message <CvGstn.GH8@mail.auburn.edu>,
>>>>> lynn@magneto.physics.auburn.edu (Owen Lynn) wrote:
Owen> The oldest machine I've worked with is a sparc 330, so I guess
Owen> that makes me a young whippersnapper :). And on all the sparcs
Owen> I've worked with, the boot EEPROM takes care of most of that
Owen> stuff. Before we went Death Star, all I ever did was copy the
Owen> customized /vmunix to the root partition, and reboot.
I suspect that the boot EEPROM on the sparcs can read BSD partition
tables and BSD hard disk partitions, and thus can find /vmunix.
Rather than containing code to read partition tables and Linux
partitions, lilo figures out which disk blocks the kernel file is on,
and puts the block number data in a place it can find on bootup.
------------------------------
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: What on earth is happening to the stability of the Linux Kernel?
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Thu, 1 Sep 1994 23:16:20 GMT
Followup to: <1994Aug30.102707.4968@ritz.equinox.gen.nz>
By author: grantma@ritz.equinox.gen.nz (Matthew Grant)
In newsgroup: comp.os.linux.development
>
> I have used Linux for over a year now, an di am am getting concerned about
> the stability of the new ALPHA realeases. On question I would like to ask
> in the light of all the recent problems with 1.1.40 -> is:
>
> Are the older problems solved and just new ones appearing, or is the
> situation getting worse?
>
> I would like to know as Linux's kernel stability has been legendary, with
> only a few minor hiccups.
>
It has, but hiccups *do* occur, which is exactly why there are two
branches of the kernel: the production version (1.0.x) and the
development version (1.1.x). The development version is as you point
out, an alpha release, and contains much untested code. It should
*not* be used if you are worried about stability.
Since the kernel developers are gearing up for a new production
release (1.2.0) the stability of recent 1.1.x kernels have been
rapidly improving, since the developers have gotten much more
conservative with adding new features. Expect 1.2.0 to be very
stable, but the first 1.3.x kernels (new development thread) will
probably be a bit wobbly due to many suddenly added untested features.
/hpa
--
INTERNET: hpa@nwu.edu --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL HAM RADIO: N9ITP or SM4TKN
FIDONET: 1:115/511 or 1:115/512 STORMNET: 181:294/1 or 181:294/101
ICMP: The protocol that goes PING!
------------------------------
From: wsuhanic@acs.ryerson.ca (West Suhanic)
Subject: MPEG Hardware Decoder
Date: 1 Sep 1994 18:54:17 GMT
Hello:
Does anyone know of an MPEG Hardware decoder that has been ported
to Linux? For example, has the Reel Magic card been ported to Linux?
wsuhanic@acs.ryerson.ca
------------------------------
Crossposted-To: comp.os.linux.help
From: lpkruger@tucson.princeton.edu (Louis P. Kruger)
Subject: Re: svgalib can't open /dev/mem w/1.1.47
Date: Thu, 1 Sep 1994 03:29:55 GMT
In article <CvF5B4.Fq4@nntpa.cb.att.com>,
-Michael P. Lindner <mpl@pegasus.bl-els.att.com> wrote:
>I was running the SLS 2.0 kernel, and built a 1.1.47 kernel from source
>(why mess around with older kernels :^). All of a sudden, things which
>svgalib (gs and sasteroids, for example) stopped working with a "can't
>open /dev/mem" message.
>
I noticed this too. It appears to be a bug in the kernel when the setreuid()
system call is invoked with a paremeter of -1. Sasteriods among other programs
use this to preserve superuser status (which svgalib automacially relinquishes)
The following patch to kernel/sys.c seems to fix the problem.
- Louis
--- sys.c.bak Wed Aug 31 19:58:40 1994
+++ sys.c Wed Aug 31 20:15:58 1994
@@ -322,7 +322,10 @@
if (ruid != (uid_t) -1 ||
(euid != (uid_t) -1 && euid != old_ruid))
current->suid = current->euid;
- current->fsuid = euid;
+
+ if(euid != (uid_t) -1)
+ current->fsuid = euid;
+
return 0;
}
------------------------------
From: moffatd@dcs.gla.ac.uk (Darren J Moffat)
Subject: Re: PRIORITY make an undelete command
Date: Thu, 1 Sep 1994 20:15:33 GMT
rob@pe1chl.ampr.org (Rob Janssen) writes:
[loads of stuff "deleted", well not really it's in the emacs kill ring :)]
>It surely had some nice advantages, but as a whole I would never recommend
>it as a project environment to anyone. Use RCS and SCCS only to store
>revisions that are somehow considered being milestones, not for each and
>every file written during an edit session.
>(e.g. revisions that were sent for alpha testing, or maybe one revision per
>day while debugging)
This is the way RCS/SCCS were intended to be used, they are
"Quality/Revision" control software, which only work properly in
conjunction with the correspongin manual proceedures eg BS5750. In
fact I was taught not to check a file back into RCS unless it compiled
and had been _fully_ test.
Emacs (from version 19.xx) integrates very nicely with either of them.
In fact it is in a way not to disimilar to what you described above
(the script method).
However the main difference arises in that Emacs it's self actual is
aware of RCS/SCCS.
eg I want to open the source file: foobar.cc
I use the normal Emacs command sequence to do so, Emacs then does one
of the following:
1. Opens the file in an editable buffer (ie I had the file locked)
2. Opens the file in a read-only buffer (someone else has a lock)
3. Reteives the file from RCS/SCCS into a read-only buffer (ie I now
have a lock on a previously unlocked file)
I can then make the buffer editable and Emacs will also check the
file out in a locked state.
4. I can then submit the file back to RCS/SCCS and an Emacs recursive
edit buffer allows me to enter the log message.
>This still leaves the need for a short-lived file version system in the
>filesystem, i.e. comparable to what Netware and VMS do.
Emacs (or rather the GNU utils in general) comes to the rescue yet
again. Setting the environment variable VERSION_CONTROL to t then the
cp, mv commands along with the emacs save file function will create
multiple backup copies.
eg
foobar.cc -- the file normally edited
foobar.cc.~1~ -- the backups of this file
foobar.cc.~2~
foobar.cc.~3~ ....
Okay so you say won't this just fill up the file system with backups,
well no since this is implemented sensibly and emacs will prompt the
user to delete excess files when a user defined limit is reached. It
does this by deleting files from the middle eg. *~3~ *~4~ from a set
of say 10 files.
For more information on the above features look at the Emacs Info page
or the man page for GNU cp.
So finally, I'm not say that Un*xen don't need an undelete command,
just that there are better ways to ensure that we can retreive
previous "versions" of our information.
Accidents do happen and sometimes an undelete command really would
help, but if we use all of the above in conjuction with proper backup
procedures we can 99% of the time get by without it, at the 1% of the
time well whats the answer:
"Sorry User, I can't sit and paste 300 strips of paper
together just cause you left the cheque sitting on top
of the shredder :-)"
(One final note if your not an Emacs fan _please_ do not start an
editor flame war, that's would bring the street cred of this group way down)
TTFN
--
Darren J Moffat 20 Southpark Ave
email: moffatd@dcs.gla.ac.uk Glasgow
------------------------------
From: iotov@cco.caltech.edu (Mihail S. Iotov)
Subject: Dosemu 0.53 - the mouse under Xwindows
Date: 1 Sep 1994 20:24:44 GMT
I found out in 0.53pl16 that the mouse will work under X11 (xdos) for
some programs which detect it as PS/2 mouse. The original mouse is
serial and there is no driver loaded. Program that work are Norton Commander
and Telemate. MSD also reports it as such. Unfortunately other programs
(most regrettably Quicken, DOS version) will not work.
------------------------------
From: mjf@clark.net (Marc Fraioli)
Subject: Re: Kernel change summary 1.1.45 -> 1.1.46
Date: 1 Sep 1994 23:45:28 GMT
Reply-To: mjf@clark.net
In article 4de@vishnu.jussieu.fr, card@masi.ibp.fr (Remy CARD) writes:
>] How can we access these new features?
>
> The next e2fsprogs release (version 0.5b) contains support for these
>new attributes (in the programs chattr and lsattr). As of Linux 1.1.46,
>the kernel honours them.
>
Will we have to reformat to take advantage of these things?
---
Marc Fraioli | "They couldn't hit an elephant at this dist- "
mjf@clark.net | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil War
------------------------------
From: rxr401 <rxr401@leonard.anu.edu.au>
Subject: Re: DOSEMU 0.53: Developers and testers ne
Date: Thu, 1 Sep 1994 10:50:40 +1000 (EST)
On 30 Aug 1994, Bigfoot wrote:
> From where can I ftp the latest DOSEMU0.53 ? (exact filename and subdirectory
> please).
tsx-11.mit.edu /pub/linux/ALPHA/dosemu/private/devel/pre53_17.tgz
Raj
------------------------------
From: evansmp@mb5194.aston.ac.uk (Mark Evans)
Subject: Re: Netware Client
Date: Fri, 2 Sep 1994 12:28:16 GMT
William B. Cattell (wcattell@netcom.com) wrote:
: I have been successfully accessing multiple NetWare servers by running
: DOSEMU un Linux. Since NetWare is a DOS based OS inorder to function as
: a true NetWare client you need to run DOS (or OS/2 or a MAC). NetWare's
First time I have heard NetWare called "DOS based"
: support of non-DOS clients is ok but not great.
Interstingly OS/2 uses a differnt set of NCP functions for directory
searching from DOS.
------------------------------
From: callahan@maths.ox.ac.uk (Michael Callahan)
Subject: floppy problems in 1.1.49
Date: Fri, 2 Sep 94 13:07:30 BST
I continue to have problems with floppies under 1.1.49.
Here are the relevant lines from the boot messages:
Floppy drive(s): fd0 is 1.44M
FDC 0 is a 8272A
I can exhibit the problem by making a Minix filesystem on a fresh,
formatted disk, then mounting it on /mnt and typing "ls /mnt".
Here is an extract from /var/adm/messages, with comments I inserted
at appropriate times using "logger".
Sep 2 04:57:44 darkstar root: about to make minix fs
Sep 2 04:57:58 darkstar kernel: VFS: Disk change detected on device 2/0
Sep 2 04:58:09 darkstar root: about to mount
Sep 2 04:58:18 darkstar kernel: VFS: Disk change detected on device 2/0
Sep 2 04:58:22 darkstar kernel: floppy: disk absent or changed during operationSep 2 04:58:22 darkstar kernel: floppy I/O error
Sep 2 04:58:22 darkstar kernel: dev 0200, sector 38
Sep 2 04:58:25 darkstar kernel: floppy: unexpected interrupt
Sep 2 04:58:25 darkstar kernel: sensei
Sep 2 04:58:25 darkstar kernel: 0 c0
Sep 2 04:58:25 darkstar kernel: 1 0
Sep 2 04:58:25 darkstar kernel: sensei
Sep 2 04:58:25 darkstar kernel: 0 c1
Sep 2 04:58:25 darkstar kernel: 1 0
Sep 2 04:58:25 darkstar kernel: sensei
Sep 2 04:58:25 darkstar kernel: 0 c2
Sep 2 04:58:25 darkstar kernel: 1 0
Sep 2 04:58:25 darkstar kernel: sensei
Sep 2 04:58:25 darkstar kernel: 0 c3
Sep 2 04:58:25 darkstar kernel: 1 0
Sep 2 04:58:28 darkstar kernel: VFS: Disk change detected on device 2/0
Sep 2 04:58:28 darkstar kernel: VFS: Mounted device 2/0 - tssk, tssk
Sep 2 04:58:28 darkstar kernel: VFS: inode busy on removed device 2/0
Sep 2 04:58:31 darkstar kernel: floppy: unexpected interrupt
Sep 2 04:58:31 darkstar kernel: sensei
Sep 2 04:58:31 darkstar kernel: 0 c0
Sep 2 04:58:31 darkstar kernel: 1 0
Sep 2 04:58:31 darkstar kernel: sensei
Sep 2 04:58:31 darkstar kernel: 0 c1
Sep 2 04:58:31 darkstar kernel: 1 0
Sep 2 04:58:31 darkstar kernel: sensei
Sep 2 04:58:31 darkstar kernel: 0 c2
Sep 2 04:58:31 darkstar kernel: 1 0
Sep 2 04:58:31 darkstar kernel: sensei
Sep 2 04:58:31 darkstar kernel: 0 c3
Sep 2 04:58:31 darkstar kernel: 1 0
Sep 2 04:59:02 darkstar root: just got "ls: .: No such file or directory" in response to ls /mnt
Sep 2 04:59:09 darkstar root: about to dismount
Sep 2 04:59:12 darkstar kernel: VFS: Disk change detected on device 2/0
Sep 2 04:59:12 darkstar kernel: Weird - unlocked, clean and not uptodate buffer on list 4 200 1
Sep 2 04:59:12 darkstar last message repeated 3 times
Only the first and last disk change messages are correct.
Similar messages occur if I boot from the floppy, using a minix
bootdisk I've prepared as the root filesystem. There are unexpected
interrupt messages, sensei messages, and nonsensical filesystem
behavior.
Now, it's possible that this hardware is wonky. It's an MPC
notebook which may be having hardware problems. But, what makes
me a little suspicious is that 1.1.40 seems to work quite well
for floppy accesses.
Finally, I'm afraid I have to say that I'm about to lose access
to this machine, so I can't help track the problem down. If
I'm the only person having such problems, I think we should just
forget it.
Michael
---
Michael Callahan
callahan@maths.ox.ac.uk
------------------------------
From: callahan@maths.ox.ac.uk (Michael Callahan)
Subject: Re: Hardware flow control under linux not working???
Date: Fri, 2 Sep 94 13:17:23 BST
In article <33lc5h$h65@brachio.zrz.tu-berlin.de>,
Sven Goldt <goldt@math.tu-berlin.de> wrote:
>Jerry Geis (geis@se01.elk.miles.com) wrote:
>: I am trying to use both a wyse60 terminal (with hardware flow control
>: enabled) and a portable computer running PROCOMM (with hardware flow control
>: enable) running a straight through cable, and NULL modem connected to ttyS1 and
>: I am losing characters. This happens on 1.0.8 and I also tried the latest
>: kernel 1.1.45. Both have the same symptoms of losing characters.
>
>: Are there any ideas? Am I missing something?
>: I have done stty crtscts after loggin in.
>
>You are right.
>Here is a quote from ppp-2.1.2a, README.linux:
>
> The exception is that
> Linux has no support for asynchronous I/O, so I hacked an ioctl into
> the PPP kernel module that provides a signal when packets appear and
> made pppd use this instead.
>
Heavens. You didn't think I was suggesting that Linux had no
support for asynchronous serial communications, did you? What
good would PPP be without THAT?
Perhaps I should have been more explicit here. The facility
I was talking about is for a program to be able to request
that an I/O be done on its behalf but not block waiting for
it to complete, and instead to get a signal when it's done.
Anyway, hardware flow control is both supported and
recommended!
Michael
--
Michael Callahan
callahan@maths.ox.ac.uk
------------------------------
From: Alan.Hunter@brunel.ac.uk (Alan N Hunter)
Subject: HD problems (>1.1.44)
Date: Fri, 2 Sep 1994 11:34:14 GMT
Hello All,
I am having great problems making 1.1.44 or greater booting with my
harddrive. The kernel compiles as smoothly as usual, but when I try to boot
from floppy disk ( cat zImage >/dev/fd0; rdev etc.) the system just locks up.
It comes back with the dreaded HD reset error and just stops. It appears that
when the system starts as such, init etc, that they cannot be accessed from
the harddrive. I tried one suggestion of telling fdisk about my drive in the
expert menu (it is a WD540MB drive with 32 heads that is configured as a 16
head device in the BIOS) and set my heads to 16, however, that did not appear
to make any difference.
Any help would be gratefull, since 1.1.23 that I am using at the moment
does not seem to work too well with the floppy disk drive.
The machine is a fairly standard Gateway2000 486DX266 PCI, with 2 WD540
drives, one for D&W(aargh!) and one for Linux. Never had any problems up till
the newer kernel versions.
All the best
Alan
--
/---------------------------------------------------------------------------\
| Alan N Hunter | Tel: 0895 274000 X2832 |
| Dept. Elec Eng H300D | Email: Alan.Hunter@Brunel.ac.uk |
| Howell Building | |
| Brunel University | |
| Uxbridge UB8 3PH | |
------------------------------
** 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
******************************