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

660 lines
26 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: Sun, 11 Sep 94 01:13:06 EDT
Subject: Linux-Development Digest #153
Linux-Development Digest #153, Volume #2 Sun, 11 Sep 94 01:13:06 EDT
Contents:
Re: Linux Micro-Kernel? (Louis-D. Dubeau)
Re: Why I cannot mount a PhotoCD on Mitsumi ? (Tamas Badics)
Re: DOS BC++/Linux floats (Adam DePrince)
compiling 1.1.46+ ... I went to .50 :) (Steve Kneizys)
Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders) (Mitch Davis)
Re: lossage with "tar cz" writing to gzip; easy fix? (Mitch Davis)
Re: Don't use Linux?! (Jeff Kesselman)
Re: i Enhanced IDE controller drivers (David Miller)
1.2.0 - 1.3.0 questions -- Has anyone heard?
Choosing PLIP/printer w/switchbox w/o reboot, HOW? (Greg Smith)
Re: Linux console to SCO comp. prob (Doug Ledford)
Re: Why I cannot mount a PhotoCD on Mitsumi ? (Jeff Kesselman)
Re: Survey: who wants f77,cc,c++,hpf for linux? (Dan Pop)
Re: Alpha Linux (Joe Zbiciak)
Re: Alpha Linux (David Holland)
3c509 Problems (Danek Duvall)
Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders) (Michael Haardt)
----------------------------------------------------------------------------
From: hallu@von-neumann.info.polymtl.ca (Louis-D. Dubeau)
Subject: Re: Linux Micro-Kernel?
Date: Sat, 10 Sep 1994 16:12:07 GMT
>>>>> "iv" == ian vogt <ian_vogt@ACM.ORG> writes:
iv> Does Linux use a micro-kernel?
No.
iv> If not, does it use any mico-kernel-type techniques?
A mico-kernel, is it some kind of mushroom kernel? :-) Seriously, I
don't think so but I may be wrong since I didn't check *all* of the
kernel sources... especially the part dealling with loadable modules
which could use microkernel technologies.
iv> Is there any plan to make Linux more like a micro-kernel?
No, but there is a plan to *port* it to a mk... Mach in fact. I
haven't posted any announce about it yet but I now have a Hurd
compatible ext2fs server up and running. Some objections come to mind
when I talk of the project of porting Linux to Mach using Hurd as a
development base:
- Mach 3.0 is slow and big: this will be taken care of in Mach
4.0 currently developped by Bryan Ford at the University of Utah.
- Mach is controled by CMU: false. You can modify and
distribute modified copy of the source code. Moreover, Bryan
Ford (Mach 4) is open to external criticism/suggestions and is
a Linuxer anyway.
- the Hurd is not there yet: true, but it will be here soon.
- the Hurd is controled by the FSF: false. If at any time the
Linux community feels that linuxhs (or linurd or whatever the package
will be called) do not fit their needs, they are free to modify *any*
part of the sources. Official distributions of the future package
will not need to have the original unmodified Hurd code in place. Heck,
that's one of the goals of the GPL.
Take a look at http://step.polymtl.ca/~ldd/ for more info on the
project. BTW, volunteers are welcome.
ldd
------------------------------
From: badics@rutcor.rutgers.edu (Tamas Badics)
Crossposted-To: comp.os.linux.help
Subject: Re: Why I cannot mount a PhotoCD on Mitsumi ?
Date: 10 Sep 1994 21:59:16 -0400
jeffpk@netcom.com (Jeff Kesselman) writes:
[many interesting technicalities deleted...]
>The poitn of all this is that ALL CD-ROM types are fully ISO9660
>compatable. (other than perhapse really wierd propritary formats-- I won't
>even guess what the Atari Jaguar does).
>jeffk@crystald.com
OK, it is all nice to know, but how can I read a PhotoCD on a Mitsumi drive?
(My MS-DOS driver can read them without problems.)
Tamas
------------------------------
From: axd0822@hertz.njit.edu (Adam DePrince)
Subject: Re: DOS BC++/Linux floats
Date: Fri, 9 Sep 1994 03:06:30 GMT
[stuff delted]
>>Have you tried using double in DOS? You could be having the same int/long
>>problem you were having with integers. Linux is 32bit and I suspect (!)
>>that it's floats are too. DOS floats are 16bit
>
float = 32 bits [23/8]
double = 64 bits (IEEE standard double)
long double = 80 bits [56/23]
A 16 bit float would offer about as much range and far less precision than
a 32bit fixed point.
The IA FPU can deal with 32, 64, and 80 bit floats. Additionaly it
can handle 32 and 64bit integer math (yes, an 8087 gave me fast 64bit
integer math on my 8088).
The Int/long problem that you are confuseing floating point numbers with
lies in the lack of explicit definiton of how large a "int" is in C.
"short int" and "long int" are pretty standard, but "int" will be
either 16 bits or 32 bits depending on the mood of the compiler implementor.
--
=====================================================================
| Tic. | Adam DePrince |
| | CIS Gradute Student |
| | New Jersey Institute of Technology |
------------------------------
From: stevo@acad.ursinus.edu (Steve Kneizys)
Crossposted-To: comp.os.linux.help,comp.os.linux.admin
Subject: compiling 1.1.46+ ... I went to .50 :)
Date: 8 Sep 94 23:43:21 EST
In article <34o25j$83f@vespucci.iquest.com>, dougal@vespucci.iquest.com (Dougal Campbell) writes:
> In article <CvL0JI.G2F@dorsai.org>, Carlos Dominguez said something like:
>> I'm trying to compile the latest/greatest kernel in order to
>> get support for my 1mb/sec QIC80/floppy controller.
>
>> I got the 1.1.45 kernel, applied all the patches sequentially from
>> 46 to 49 to my 45 source tree, and whenever I do a make dep I always
>> get this.
>
>> ksyms.c:13: linux/blkdev.h: No such file or directory
>> make[1] *** [dep] Error 1
>
>> I did a diff between a ksyms.c and a ksyms.c.orig and the diffs were
>> that statement and a "BLOCK DEVICE" section towards the end.
>
>> Can/Should I compile even with this dependency error?
>
> I ran across the same thing when I compiled the 1.1.49 kernel. The
> patches seem to not place some of the files correctly. If you look in
> directory you applied the patches from (probably /usr/src or
> /usr/src/linux) I'd bet that you'll see some stray .h and .c files.
> Look at what source files the make fails on, look at the paths, and move
> the stray files to their proper directories.
>
Just did this, except I went to 1.1.50 release. I started with the 1.1.45
tar file, and did the patches 46 through 50 sequentially from the /usr/src
directory. Then I moved the .c and .h files (I think they were just
blkdev.h, ncp.h, ni52.h and ni52.c) created in /usr/src to the subdirectory
linux/include/linux, then moved entry.S to /usr/src/linux/kernel directory.
Did the standard makes and it booted on the first try! Did it by modem
too...brave soul I am :)
Take care!
Steve...
============================================================================
| Steve Kneizys Stevo@acad.ursinus.edu |
| Director P.O. Box 1000 |
| Academic Computing Collegeville, PA 19426 |
| Phone (215) 489 4111 x 2244 |
| Ursinus College FAX (215) 489 0634 |
============================================================================
------------------------------
Subject: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders)
From: davism@latcs2.lat.oz.au (Mitch Davis)
Date: Thu, 8 Sep 1994 04:37:34 GMT
In article <344q4b$p9d@news.iastate.edu>,
Chris Wong <chris@helser54.res.iastate.edu> wrote:
>
>hd.c: ST-506 interface disk with more than 16 heads detected,
> probably due to non-standard sector translation. Giving up.
> (disk 0; cyl=950, sect=32, head=64)
Hello All:
I have two ST-506 HDs, of about 44 meg each. They've always worked fine
with Linux, but kernels have never been able to identify them as ST-506.
At boot time, the kernel always says "unknown".
(I have another machine where the IDE drive is correctly identified).
I used to think this was because the ST-506 interface was so old that
no-one was particularly bothered about identifying it. But from the
quoted message above, it appears _something_ in the kernel knows it's
an ST-506....
Can anyone suggest what the trouble might be? Would anyone be
interested in remedying this? Should I start reading hd.c? I am
happy to do whatever would be required.
Thanks,
Mitch.
------------------------------
Subject: Re: lossage with "tar cz" writing to gzip; easy fix?
From: davism@latcs2.lat.oz.au (Mitch Davis)
Date: Thu, 8 Sep 1994 06:38:12 GMT
In article <344god$4m2@grapevine.lcs.mit.edu>,
Chris Metcalf <metcalf@CATFISH.LCS.MIT.EDU> wrote:
>Does anyone have a patch to fix the problem with "tar cfz" where if you
>suspend and background the process, it dies with a wrong-size return
>from write()? I'm surprised to see such behavior in Linux, which is
>pretty well-standardized most of the time. (Clearly the write to the
>pipe is returning after an atomic-sized write on an interrupt, but
>it would be nice to suppress that behavior.)
>
>This is with tar 1.11.2 and gzip 1.2.4 (and libc 4.5.26 with Linux 1.1.49,
>but it's been going on a long time); a typical error message would be
>"tar: only wrote 2048 of 10240 bytes to foo.tgz". Email me with any
>responses and I will post a summary.
I thought I was the only person with this problem! I've also noticed it
when I've had to press ^Z while recompiling the kernel.
Mitch.
------------------------------
From: jeffpk@netcom.com (Jeff Kesselman)
Subject: Re: Don't use Linux?!
Date: Sat, 10 Sep 1994 20:14:18 GMT
Rather then waste bandwidth repeating the previous arguments and
commenting in response, I'm just going to kame a few overall comments.
1) I do agree that Linux is not for the unwashed to administrate, you
really DO need to know something about UNIX to make this beastie work, as
the Docs tend to be somewhat sketchy. This is particularly true on
low-end hardware. If you have fast enough hardware, and are willign to
pay for standard enough stuff (as opposed to a cheapie patched togetehr
system like i have) at this point installing PnP from yygdrasil is
probobly about as easy as installign OS/2 or Windows (which isn't sayign
much), but admin is trickier.
This is natural however, 'cause this is UNIX folks. UNIX is very
powerful, and very streamlined, but the pwoer comes at the price of less
touchy-feely-hand-holding. I honestly think this laterst version of
Linux is as easy to adminster as my old 'professional' SCO. Remember that
this is a real, mature, multi-user system. None of the others I
mentioend above are.
2) Getting commercial developers to develop for linux.
Frankly, at the moment the BEST way to encourage this is to continue to
give Linux away. Lets get real, for a minute. it doesnt matter HOW nice
your OS is if you can't get a large number of installatiosn installed. I
DO work for a professional software firm and our primary concern on new
platforms is how many customers thre will be for the final product. If
we believe there will be enough, we develop for it. (A great exampel is
the Sega Saturn, which we are developing for rigth now even though its
develoment environment is putrid!) We have seen how successful $500.00+
UNIX systems have been at penetrating (virtually nada.) Frankly, I
STRONGLY suspect more new Linux system have been brought up in the past
quarter then SCO systems in the past year.
3) Quality of software.
Well, I happen to consider quality not to onyl be the province of large
shops. Soem of the most groundbreaking, exciting products have come out
of garages. To a certain degree a big company is proscribed in how
foward looking they can be as they have large marketing/sales structures
to support. I think we will start to see very exciting products come out
of peoples garages for Linux in the next year or so.
4) the WSYWIG issue
I agree with the original author's point here, I'm afraid. it doesn
matter how increidbly powerful TeX is, its stil la form of programming
and is NOT friendly enough for your average business person to use.
BUT how abotu this-- why doesn't someone write acurses-based WSYWIG that
generates TeX out the back end? Sure it wont be as powerful as raw TeX,
but it will make it accessible for all those who just need light word
procvessing capabilities. This is gfthe fundemental spirit of UNIX...
take whats there and jsut add to it the additional functionality you
need. (Frankly I think there's ALOT of money to be made in this
product alone. Without the big-boys tro compete with, there is room for
a midnight-engineer to really make a splash. Ild do this one myself, but
I'm running Linux at the moment to experiment with enhanced AI which I
hope to bring abck into our games at work.)
My three cents, for what its worth.
Jeff Kesselman
jeffk@crystald.com
------------------------------
From: davem@er4.rutgers.edu (David Miller)
Subject: Re: i Enhanced IDE controller drivers
Date: 10 Sep 1994 19:38:11 -0400
Steve van Aardt (svaardt@csfb1.fir.fbc.com) wrote:
: Has anyone developed an Enhanced IDE controller for LINUX ?
: I'm intending to run Linux upon a Pentium 90 m/c - has anyone
: found any difficulties with doing so ?
Just installed slackware on a Dell Dimension P90, and the
eIDE works beautifully, and its real quick.
Use kernels 1.1.50 or newer or it won't work no matter what
you try. The newer kernels know to talk directly to the drive for it's
specs instead on relying on BIOS bogus values.
Later,
David S. Miller
davem@eden.rutgers.edu
: --
: Steven van Aardt,
: CS First Boston, One Cabot Square, London. E14 4QJ
: Tel: +44 (0) 71 516 2547
------------------------------
From: c-huegen@crh0033.urh.uiuc.edu ()
Subject: 1.2.0 - 1.3.0 questions -- Has anyone heard?
Date: 11 Sep 1994 02:22:36 GMT
Does anyone know if built-in-quota and accounting support is planned for
the new release?
--Craig A. Huegen
------------------------------
From: greg@cscns.com (Greg Smith)
Subject: Choosing PLIP/printer w/switchbox w/o reboot, HOW?
Date: Sat, 10 Sep 1994 20:36:34 GMT
Hello,
I have two Linux boxes with kernel 1.1.45. They are (sometimes)
connected with PLIP and other times I reboot one and use a switchbox on
the parallel port to print. I must reboot because it seems the PLIP
code, once configured in the kernel, interferes with the printer /lp
code. Is there a way to switch between my PLIP connection and my printer
without rebooting? (just ifconfig'ing it "down" doesn't seem to work.)
Greg Smith
greg@gms.org
------------------------------
From: gdl297s@cnas.smsu.edu (Doug Ledford)
Subject: Re: Linux console to SCO comp. prob
Date: 10 Sep 1994 23:52:08 GMT
Reply-To: gdl297s@cnas.smsu.edu
On 2 Sep 1994 13:17:14 +0200, Jonathan Noel Tombs (jon@obelix.cica.es) wrote:
: what is the problem with the linux keymaping. I can generate 16 different
: characters/sequences per key as far as I am aware. linux seems to
: supports all shift/control/alt posabilities.
: What is it that SCO can do that linux not? Or is it just you haven't
: bothered using loadkeys and the default map defines some sequences as
: the same.
: Jon.
Actually the problem goes something like this. You can indeed define 16
characters/sequences per key. However, since the kernel code performs a
string lookup for defined sequences, you have to be able to define the strings
for those keys you wish to send out sequences, such as F-keys, with the
exceptions of arrow keys and keys on the Keypad. In Linux, you have a total
of 36 strings available. Several of these are used on specific keys already,
such as home, end, pgup(Prior), pgdn(Next), and so on. What you are left
with is 26 F-key strings that are definable. If you define 16 sequences for
F1, then you only have 10 strings left. In order to define 4 sequences per
F-key on a 101 key keyboard (12 F-keys), then you need at least 48 strings
available. Linux doesn't have that many. Furthermore, to get it is a kernel
change. I have made this change on my system. Furthermore, I defined my
4 sequences per F-key the same as SCO console so that WP for Unix would
work. I redefeined my termcap (actually I left the standard termcap entry
and added SCOconsole) and now my console actually works better for me than
it did. I created a loadkeys mapping that could be used on any system with
the number of strings in the kernel bumped up and would create a keyboard
the same as SCO, as well as another one to put it back into Linux standard
mode. In other words, the problem is fixed here, and I can use Linux
default or SCO default. Furthermore, the Linux software I use was written so
that it reads the termcap entry and as such it works fine either way. Someone
else would have to test the other Linux software and see if they can find any
that is broken by the change. I know some people want this, but since the
maintainer of loadkeys is getting ready to put out a patch to the kernel that
is nicer than my own, I'm not planning on uploading it anywhere. If someone
needs this fix NOW, then mail me with a place to send it and I will.
--
*-----------------------------------------------------------------------*
* Doug Ledford | gdl297s@cnas.smsu.edu *
* 948 E. Normal | College of Natural and *
* Springfield, MO 65804 | Applied Sciences *
* (417)866-2324 | Computer Sciences Major *
*-----------------------------------------------------------------------*
Psychotherapy is the theory that the patient will probably get well
anyhow and is certainly a damn fool.
-- H. L. Mencken
------------------------------
Crossposted-To: comp.os.linux.help
From: jeffpk@netcom.com (Jeff Kesselman)
Subject: Re: Why I cannot mount a PhotoCD on Mitsumi ?
Date: Sat, 10 Sep 1994 23:38:24 GMT
In article <1994Sep9.163600.4245@tudedv.et.tudelft.nl> jakmouw@et.tudelft.nl (Erik Mouw) writes:
>In article <34l4gr$ahv@rutcor.rutgers.edu>, badics@rutcor.rutgers.edu (Tamas Badics) writes:
>> Hi Again,
>>
>> I asked the above question once, but had no positive answer.
>> The problem is the following:
>>
>> I'd like to mount a PhotoCD using Linux 1.0.9 and a Mitsumi doublespeed
>> CD drive. I guess the "mount -t iso9660 /dev/mcd /cdrom" command should
>> do it, but it doesnt. It gives the usual
>> "mount: wrong fs type, /dev/mcd already mounted, /cdrom busy, or other error"
>> error message.
>>
>> Is the PhotoCD compatibility missing from the mcd.c driver?
>>
>> I CAN mount regular data CD-s on the same drive with the same command.
>> Also, the same drive CAN read PhotoCD-s under MS-DOS, so it is not a hardware
>> problem.
>>
>> Anoybody knows the solution to this?
>>
>> Thanks,
>> Tamas
>>
>
>I think the errormessage says enough: photo CD's don't have a
>ISO 9660 filesystem on it, otherwise Linux should have mounted it.
Good guess, but wrong, I'm afraid. I was working for Philips at AIM in
Los Angeles during the development of the original CD-I software. I
mention this as a way of establishing my credentials for the following
information:
CD formats are defiend as a set of specifications, each bulding on the
top of previous ones, much like a network stack or an inheritance tree.
They are generally referred to by the color of the cover of the official
release. They are as follows:
Red Book: The root standard, defines CD-DA (CD-Digital Audio, what most
cousumers just call 'CDs'.)
Yellow Book: The ISO9660 standard, defines CD-ROM. A full superset of
the red Book.
Orange Book: (I believe, I'm a little rusty on the color of thsi one),
CD-ROMXA (eXtended Architecture.) This is a full superset of the Yellow
Book, which adds the cocnept of the 'real-time file'. Included in RTFs
are a couple of standard ADPCM interleaved audio types and advanced error
checking. RTFs are ALWAYS in contiguos sectors (not a requireement of
Yellow Book files) gauranteeing data delivery with-out seek delays.
Green Book: The CD-I spec. Expands on Orange Book by definign a standard
host computer attached to the XA drive, and additional data types for
more ADPCM audio compressions varients and video bitmap types.
Gold Book: Photo-CD. Another full superset of the Yellow Book, with
specific data types defined for hi-res photos. Also includes CD-I type
ADPCM audio, as well as a pre-defiend directory structure for finding files.
The poitn of all this is that ALL CD-ROM types are fully ISO9660
compatable. (other than perhapse really wierd propritary formats-- I won't
even guess what the Atari Jaguar does).
jeffk@crystald.com
------------------------------
Crossposted-To: comp.lang.fortran
From: danpop@cernapo.cern.ch (Dan Pop)
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: Sat, 10 Sep 1994 20:59:34 GMT
In <34ssa9$fav@taco.cc.ncsu.edu> mckinney@math.ncsu.edu (Bill McKinney) writes:
>The problem is that my original code might not compile under f2c/gcc.
>I don't want to spend time "fixing" codes (that have already been working
>and optimized) so they'll run under f2c/gcc and allow me to do development
>on Linux.
Is there any _F77_ code which doesn't work under f2c/gcc?
Dan
--
Dan Pop
CERN, CN Division
Email: danpop@cernapo.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
------------------------------
From: im14u2c@cegt201.bradley.edu (Joe Zbiciak)
Subject: Re: Alpha Linux
Date: 10 Sep 1994 15:57:49 -0500
In <JEM.94Sep10192807@delta.hut.fi> jem@snakemail.hut.fi (Johan Myreen) writes:
>What is the natural word size of the 68000? Or the 8088? Or a
Even better: The 68008... 8 bit data path, 16 bit registers, 32 bit ALU.
By 32 bit ALU, I mean two registers would combine together and make a 32 bit
register for ADD & SUB and MUL & DIV (I think.)
--Joe
------------------------------
Subject: Re: Alpha Linux
From: dholland@husc7.harvard.edu (David Holland)
Date: 8 Sep 94 17:09:17
adc@bach.coe.neu.edu's message of 06 Sep 1994 16:38:15 GMT said:
> Why drop one?
> 16 bits = short int
> 32 bits = int
> 64 bits = long
Over in the next thread people were talking about Unicode; why not
16 bits = char
32 bits = short
64 bits = int, long
Of course that would break a lot of things, but such is the price of
progress :-)
--
- David A. Holland | -- "Do you have a moment?" -- "Yes.
dholland@husc.harvard.edu | Unfortunately, it's a moment of inertia."
------------------------------
Crossposted-To: comp.os.linux.help
From: duvall@sage.wlu.edu (Danek Duvall)
Subject: 3c509 Problems
Date: Sat, 10 Sep 1994 20:32:17 GMT
I recently set up my 3Com Etherlink III Combo on my linux machine.
The first boot after the network stuff was configured, it worked fine.
In fact, it worked fine continuously for over a day. Then, today, I
was having some problems compiling and installing sendmail, I rebooted
my machine. At that point, I couldn't find anything on the network.
I hadn't changed any relevant pieces of the network config files, so
it couldn't have been that. Then I checked /var/adm/messages, which
had the line:
eth0: Missed interrupt, status then 2011 now 2011 Tx 00 Rx 383c
The same line appeared every time I booted, exced that the last number
would change. I found the spot where this gets printk'ed, but I know
nothing more than that.
Please! If there's anything anyone can do to help, I would really
appreciate it, since I have almost no clue about the networking code
(except what I've read in the NAG and the NET-2-HOWTO). If there's
any further information you need to figure out what's going on, please
get in touch. (My kernel version, by the way, is 1.1.49.)
Thank you very much,
Danek
------------------------------
From: Michael Haardt <(michael)u31b3hs@pool.informatik.rwth-aachen.de>
Subject: Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders)
Date: Fri, 9 Sep 94 19:18:11 MET
davism@latcs2.lat.oz.au (Mitch Davis) writes:
> I used to think this was because the ST-506 interface was so old that
> no-one was particularly bothered about identifying it. But from the
> quoted message above, it appears _something_ in the kernel knows it's
> an ST-506....
Yes, I don't have a clue why it was done that way. The following patch
fixes it:
if (unmask_intr[dev])
sti();
if (stat & (BUSY_STAT|ERR_STAT))
! printk ("hd%c: ST506 interface, %dMB, CHS=%d/%d/%d\n",
! dev+'a',hd_info[dev].cyl*hd_info[dev].head*hd_info[dev].sect/2048,hd_info[dev].cyl,hd_info[dev].head,hd_info[dev].sect);
else {
insw(HD_DATA, (char *)&id, sizeof(id)/2); /* get ID bytes */
max_mult[dev] = id.max_multsect;
Once I sent this to Linus, but no response. IDE drives can tell you
their parameters, whereas for ST506 interface drives, you need to
believe the BIOS, which may be incorrent. Nevertheless, I like to see
the parameters at booting.
Michael
--
Twiggs and root are a wonderful tree (tm) Twiggs & root 1992 :-)
------------------------------
** 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
******************************