Linux-Development-Sys Digest #64, Volume #7 Tue, 17 Aug 99 21:14:06 EDT
Contents:
fhcache entries ("Ted Pavlic")
Re: why not C++? (Kaz Kylheku)
Re: Domain Names Limited to two or three Characters? (David Schwartz)
Re: kmalloc() (David Schwartz)
Re: "top" command's source code! (Kaz Kylheku)
Re: Deadly optimization bug (all versions!) (Juergen Heinzl)
Re: why not C++? (Kaz Kylheku)
Re: why not C++? (Warren Young)
Re: smp kernel build with rh 6.0 (Johan Kullstam)
Re: Code for security: chroot and child processes (NICHOLAS DRONEN)
Re: buffer and page caches (Arun Sharma)
Re: fhcache entries (Andi Kleen)
Re: ldd with weird output (Andreas Jaeger)
Beowulf info. ("ManEatingCow")
Re: naive newbie wants to call add_timer() (Kaz Kylheku)
LispOS? (Christopher Browne)
Re: Troll (was: why not C++?) (Christopher Browne)
----------------------------------------------------------------------------
From: "Ted Pavlic" <[EMAIL PROTECTED]>
Subject: fhcache entries
Date: Tue, 17 Aug 1999 16:00:08 -0400
I have a Linux box which is attached to a large external hardware RAID. This
box serves a great deal of NFS to my other servers.
After about a half-hour of time after the raid server comes up and machines
mount and start using the NFS shares on it, odd messages occur frequently on
both the client and server machines. Some of the clients report odd fh_get
messages regarding being unable to get an entry or regarding a timeout on a
previous entry. We've seen "RPC: sending evil packet" messages on the raid
server often, but I do not believe that is a related problem.
Recently I checked the kernel log on the raid server and found this entry:
Jun 16 07:30:31 raid kernel: nfsd_init: initialized fhcache, entries=256
The entries=256 is what alarmed me. 256 seems like a low number to me, as
this server is serving NFS to thirteen other servers. And the problems we
were having regarding problems after a certain amount of service sounded
like a cache problem -- perhaps something running out of cache. So I found
in the kernel where that number was set: (/usr/src/linux/fs/nfsd/nfsfh.c)
#define NFSD_MAXFH PAGE_SIZE/sizeof(struct fh_entry)
Which sent me off to find PAGE_SIZE. I found where it was set:
(/usr/src/linux/include/asm/page.h)
#define PAGE_SHIFT 12
#define PAGE_SIZE (1UL << PAGE_SHIFT)
So, for kicks, I tried changing PAGE_SHIFT to 14. /usr/src/linux/mm/slab.c
didn't seem to like that. (PAGE_SIZE had to be either 4096 or 8192) So I
changed PAGE_SHIFT back to 12 and changed the 1UL to 2UL. (I guess I could
have just changed PAGE_SHIFT to 13) The kernel compiled fine then. (And I'm
guessing that that probably increased the NFSD_MAXFH to 512.
My question is: Have I done something horrible? I have not booted off of
this new kernel yet. Are there other angles I should investigate? I'm taking
stabs in the dark here. :)
Any help would be appreciated. All the best --
Ted Pavlic
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Tue, 17 Aug 1999 19:59:18 GMT
On Tue, 17 Aug 1999 13:28:38 -0400, Arinte <[EMAIL PROTECTED]> wrote:
>Well, I can see some of your points. But, if it was programmed it C++ then
>the programmer can have a choice of doing there code in c or c++ without
>having to do extra work. Using C++ would have been more open.
Nonsense, you still have the choice of using C++. You should be able to
write a driver in C++ for Linux. A loadable module is just a slab of
machine code and data. As long as it behaves right and doesn't ask for any
symbols that the kernel can't give it, it's fine.
So for example if you wanted to use, say, C++ exception handling in your
driver, you would have to provide your own run-time support for it within that
object, since the kernel wouldn't resolve your undefined reference to
things like __throw() . Adding this support would take some work, so you
might opt for doing without the feature.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Domain Names Limited to two or three Characters?
Date: Tue, 17 Aug 1999 14:11:07 -0700
Just be careful if you use TLDs that end in a digit. Some broken
software assumes that any domain name that ends in a digit is really an
IP address. Theoretically, there's no reason '209.133.45.2' couldn't be
a valid domain name. ;)
DS
"Preston F. Crow" wrote:
>
> Of course, if you set up your own isolated Intranet, you can have your
> own DNS with whatever top level domains you want.
>
> In theory, you should then be able to have long top level domains, and
> well-engineered software will support it.
>
> --PC
>
> --
> "Everything is permissible"--but not everything is beneficial.
> "Everything is permissible"--but not everything is constructive.
> --I Corinthians 10:23
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: kmalloc()
Date: Tue, 17 Aug 1999 14:12:44 -0700
Chi-sheng Shih wrote:
>
> Hi,
>
> I try to use kmalloc in kernel to allocate a memory. However, it seems that
> it always return NULL. Is there any trick to use kmalloc()?
>
> By the way, is there anyone know what does these priority argument, such
> as GFP_KERNEL and GFP_ATOMIC, mean for?
>
> Thanks.
>
> Chi-sheng
How large a block are you trying to allocate? If it's more than 8Kb, I
wouldn't be surprised if it failed.
DS
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: "top" command's source code!
Date: Tue, 17 Aug 1999 21:52:32 GMT
On 17 Aug 1999 17:59:27 +0100, Nix <$}xinix{[email protected]> wrote:
>[EMAIL PROTECTED] (Kaz Kylheku) writes:
>
>> On Sun, 15 Aug 1999 23:22:40 +0800, lming <[EMAIL PROTECTED]> wrote:
>> >Hi...
>> >
>> >Does somebody could tell me where the top command's source code is ??
>>
>> I believe that it's part of a package called ``psutils''. Search for that.
>
>ITYM `procps'. HTH.
Srange mental slip! You are right of course, psutils is a package of PostScript
utilities. :) Sorry.
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To: gnu.gcc.help
Subject: Re: Deadly optimization bug (all versions!)
Date: Tue, 17 Aug 1999 22:21:00 GMT
In article <[EMAIL PROTECTED]>, James Stevenson wrote:
[...]
>if you mean compile it like
>
>gcc bug.c -O1
>gcc bug.c -O2
>
>it worked fine on my system both
>RH6.0
>gcc -v
>Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
>gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
>
>output both compiles
>ret=0
>ret=1
>ret=1
Leave us with two options, RH enabled -O3 by default, which is easy
to be done using the source or the specs file or they applied an
unknown patch.
Minor update, same with gcc-2.95.1 (release).
[...]
Ta',
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Tue, 17 Aug 1999 21:51:26 GMT
On Tue, 17 Aug 1999 10:17:38 -0600, Warren Young <[EMAIL PROTECTED]> wrote:
>Keep in mind, not even C is the be-all and end-all of computer
>languages. People regularly program Linux in dozens of other languages,
>many of which don't have any real way of calling C++ code.
You can use the extern "C" linkage specifications to create C++ functions
that can be called as C functions (i.e. do not have name mangling).
Linkage specifications go both ways; they allow C++ programs to call C,
but also to define functions that are callable from C.
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Tue, 17 Aug 1999 10:17:38 -0600
Cocheese wrote:
>
> *Why Is linux done primarily in the C programming language rather than
> C++?*
I've seen many points brought up in this thread, but there's one that's
absolutely critical, and it goes beyond all the reasons rooted in
anti-C++ biases: C++ requires name mangling.
Name mangling is a very practical solution to a real problem (namely,
old C-style linkers being used for linking C++ code). The problem is,
you can't call mangled C++ functions from non-C++ languages, at least
not without a whole lot of messy glue in between.
Keep in mind, not even C is the be-all and end-all of computer
languages. People regularly program Linux in dozens of other languages,
many of which don't have any real way of calling C++ code.
C-based interfaces, at least, are callable from any sane language.
Thus, it makes sense to write core libraries and interfaces in C. If
you want OO, you can write wrappers on top of that, as happened with
Gtk+ and OO extension libraries like Gtk--.
> The downside is "linux has always been a C based Program so it will always
> be."
Again, find or write appropriate C++ wrappers. You don't need to
re-write the kernel as an OOP program in order to write application
programs in an OOP fashion.
--
= Warren Young, maintainer of the Winsock Programmer's FAQ at:
= http://www.cyberport.com/~tangent/programming/winsock/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
Subject: Re: smp kernel build with rh 6.0
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 17 Aug 1999 18:14:21 -0400
[EMAIL PROTECTED] (Villy Kruse) writes:
> As the scsi module is loaded from initrd this is still the original
> driver you will get a version conflict.
> Therefore, you should either:
>
> rebuild initrd with mkinird,
i recommend this because it works for me.
> or
>
> include the scsi driver into the compiled kernel and then eliminate initrd
> from the lilo entry for your new kernel.
i have had bad luck with the latter strategy. i put my scsi driver
into the kernel and installed it without initrd in the lilo
parameters. the machine boots. however, i get really lousy
performance for disk access. i have no idea why.
redhat 5.2 exhibited no such thing (using same kernel version and
glibc-2.1). kernels 2.2.5 and 2.2.6 work just fine. 2.2.7 and up
don't work. is it some hidden initscript wackiness?
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED] (NICHOLAS DRONEN)
Subject: Re: Code for security: chroot and child processes
Crossposted-To: comp.os.linux.security,comp.os.linux.development.apps
Date: Tue, 17 Aug 1999 21:01:49 GMT
brian moore ([EMAIL PROTECTED]) wrote:
: On 12 Aug 1999 02:01:12 GMT,
: Mike Khalili <[EMAIL PROTECTED]> wrote:
: > On Wed, 11 Aug 1999 16:59:14 -0700, Sean O'Dell <[EMAIL PROTECTED]> wrote:
: > >Thank you for your help! It works great, but now I've run into something
: > >else I'm not sure about. When the program is run, I use seteuid to change
: > >the uid of the process to the uid of the owner of the file interpreted by
: > >the program, for security reasons. I also chroot to the user's home
: > >directory, just for further safety. However, there are some functions to
: > >the program which I need to seteuid back to root and also see the file
: > >system hierarchy above where I chroot'ed (just temporarily). I haven't
: > >figured out how to "undo" the chroot...is it possible?
: >
: > No, it is not. Once you chroot() you're stuck with it.
: Not entirely true. There are ways to get out of a chroot jail.
: --
: Brian Moore | Of course vi is God's editor.
: Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting
: Usenet Vandal | for it to load on the seventh day.
: Netscum, Bane of Elves.
Brian,
Perhaps you should explain how this is done.
------------------------------
From: [EMAIL PROTECTED] (Arun Sharma)
Subject: Re: buffer and page caches
Reply-To: [EMAIL PROTECTED]
Date: Tue, 17 Aug 1999 20:52:35 GMT
On 16 Aug 1999 20:17:05 GMT, Robert John Minerick
<[EMAIL PROTECTED]> wrote:
> I see. My understanding is that every block device uses buffers to read
> data. So, when data is read, does it first get placed into buffers and
> then copied into the page cache? Or is the buffer cache never even used on
> a read? Thanks...
>
There will be only one copy of the data - in a 4k page (I'm talking x86
here). If your buffer size is 1k, there will be 4 buffer cache entries
pointing to the same 4k page at different offsets (0, 1k, 2k and 3k).
-Arun
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: fhcache entries
Date: 17 Aug 1999 22:46:49 +0200
"Ted Pavlic" <[EMAIL PROTECTED]> writes:
> I have a Linux box which is attached to a large external hardware RAID. This
> box serves a great deal of NFS to my other servers.
>
> After about a half-hour of time after the raid server comes up and machines
> mount and start using the NFS shares on it, odd messages occur frequently on
> both the client and server machines. Some of the clients report odd fh_get
> messages regarding being unable to get an entry or regarding a timeout on a
> previous entry. We've seen "RPC: sending evil packet" messages on the raid
> server often, but I do not believe that is a related problem.
>
> Recently I checked the kernel log on the raid server and found this entry:
>
> Jun 16 07:30:31 raid kernel: nfsd_init: initialized fhcache, entries=256
>
> The entries=256 is what alarmed me. 256 seems like a low number to me, as
> this server is serving NFS to thirteen other servers. And the problems we
> were having regarding problems after a certain amount of service sounded
> like a cache problem -- perhaps something running out of cache. So I found
> in the kernel where that number was set: (/usr/src/linux/fs/nfsd/nfsfh.c)
>
> #define NFSD_MAXFH PAGE_SIZE/sizeof(struct fh_entry)
>
> Which sent me off to find PAGE_SIZE. I found where it was set:
> (/usr/src/linux/include/asm/page.h)
>
> #define PAGE_SHIFT 12
> #define PAGE_SIZE (1UL << PAGE_SHIFT)
>
> So, for kicks, I tried changing PAGE_SHIFT to 14. /usr/src/linux/mm/slab.c
> didn't seem to like that. (PAGE_SIZE had to be either 4096 or 8192) So I
> changed PAGE_SHIFT back to 12 and changed the 1UL to 2UL. (I guess I could
> have just changed PAGE_SHIFT to 13) The kernel compiled fine then. (And I'm
> guessing that that probably increased the NFSD_MAXFH to 512.
>
> My question is: Have I done something horrible? I have not booted off of
> this new kernel yet. Are there other angles I should investigate? I'm taking
> stabs in the dark here. :)
Yes, you did. You cannot simply change the page size this way, because
the CPU (MMU) intimately knows about it. Even if you allocated bigger pages
the MMU would probably only map part of the page into the user space,
causing all sorts of interesting problems (like IO not agreeing with
the user on page size and writing out more etc.)
Also PAGE_SIZE is a fundamental constant in the port and e.g. embedded in
all ELF executables. I would better not boot it, it could cause fs
corruption.
You should be simply able to increase it to bigger numbers. The reference
to PAGE_SIZE would make sense if it was dynamically allocated using the
page allocator (get_free_page et.al.), but it is a static array. So just
increase it if you have enough memory.
BTW, the current nfsfh is flawed and needs a redesign badly; as you
probably experienced and noticed (worst bug is that it is not really
stateless ATM)
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: ldd with weird output
Date: 17 Aug 1999 23:15:00 +0200
>>>>> Axel Reinhold writes:
> Hi,
> playing around with glibc on RH5 gave me some strange behaviour of
> ldd/ldconfig/ld.so. I need libc5 compatibility, so I installed the
> /usr/i486-linux-libc5/lib/... libraies and set up /etc/ld.so.conf
> correctly.
> So far so good. But when I ask ldd for example on a libc5 based sendmail
> binary I tells me:
> [root@hammer sendmail]# ldd sendmail
> libdb.so.2 => /lib/libdb.so.2 (0x40002000)
> libc.so.5 => /lib/libc.so.5 (0x40010000)
> libc.so.6 => /lib/libc.so.6 (0x400d9000)
> /lib/ld-linux.so.1 => /lib/ld-linux.so.2 (0x00000000)
> I _have_ installed a libc5 compatible libdb.so.2:
> [root@hammer sendmail]# ldconfig -p|grep libdb
> libdb.so.2 (ELF) => /usr/i486-linux-libc5/lib/libdb.so.2
> libdb.so.2 (ELF-libc6) => /lib/libdb.so.2
> libdb.so.1 (DLL) => /usr/i486-linuxaout/lib/libdb.so.1
> when I remove the glibc libdb in /lib/libdb.so.2 I get:
> [root@hammer sendmail]# ldd sendmail
> libdb.so.2 => /usr/i486-linux-libc5/lib/libdb.so.2 (0x40002000)
> libc.so.5 => /lib/libc.so.5 (0x4000f000)
> but in both cases the sendmail binary _works_. When I remove the libc5
> libdb
> in /usr/i486-linux-libc5/lib/libdb.so.2 then it crashes with core dump
> in
> strncmp but the ldd output is the same as with both libs installed!
> What is wrong in this mysteria? Please help.
That's a problem of ldd from glibc 2.0.x. The ldd that comes with
glibc 2.1.x has this bug fixed.
No need to worry. Your programs will work just fine - just ldd from
glibc 2.0.x will display wrong information for libc5 binaries.
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: "ManEatingCow" <[EMAIL PROTECTED]>
Subject: Beowulf info.
Date: Tue, 17 Aug 1999 17:59:20 -0400
Hi,
Does anyone have info & sources on Beowulf ( distributed computing Linux ).
Where ar the Usenet grouos for distributed computing?
Regards,
Phil
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: naive newbie wants to call add_timer()
Date: Tue, 17 Aug 1999 22:01:11 GMT
On Tue, 17 Aug 1999 20:08:58 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>I'm trying to get some rudimentary understanding of calling a system
>function.
>
>// itimetest.c
>#include <linux/timer.h>
>int main()
What are you trying to do? The main function is for starting hosted programs.
Kernel code doesn't use main(). A loadable module is expected to implement
the init_module and cleanup_module functions.
>{
> timer_list tl; // (todo: initialize tl properly!)
> add_timer( &tl);
>
>}
>
>[jclonts@deathstar cpp]$ g++ itimetest.c
>/tmp/ccNO5zm3.o: In function `main':
>/tmp/ccNO5zm3.o(.text+0xb): undefined reference to
>`add_timer(timer_list *)'
Use gcc, not g++! The code is C (with non-conforming C++ comments) not C++.
If you use g++, then even files with a .c suffix get treated as C++.
The fact that the linker is complaining about ``add_timer(timer_list *)''
is a big cluestick that the code was compiled as c++. There is type
information in the object file! You wouldn't be able to tell from a C compiled
object file that add_timer has a ``timer_list *'' parameter.
In other words, the compiler generated a mangled name with type info
encoded.
Secondly, the add_timer function is not in any library. It is in the
kernel. The references to kernel symbols are resolved when you insert
the module into the kernel. A module must be built as an object with
unresolved symbols (.o file). For example:
gcc -D__KERNEL__ mydriver.c -c
Then if all goes well,
insmod ./mydriver.o
Even if you succeed in doing this, you won't be able to resolve the
add_timer reference if you compile the thing as C++, unless you
wrap the kernel headers in extern "C" { /*... */ }.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: LispOS?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 18 Aug 1999 00:47:01 GMT
On 17 Aug 1999 10:15:52 -0700, Graffiti <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Timo Tossavainen <[EMAIL PROTECTED]> wrote:
>[snip]
>><take with a grain of salt>
>>How about a paradigm shift ? Let's write a Lisp OS, where the Lisp
>>environment is the OS and throw away all the old buggy C code. Let's
>>throw in multiprocessing, hard realtime GC and scheduling and why
>>not orthogonal persistence while we're at it. Come to think of it
>>this should have been done ages ago... =) I'd be a happy user.
>></take with a grain of salt>
>
>Oh god. The return of the LISP machines.... *shudder*
>They weren't *bad*, but look at where they are now. See my point?
>(Or rather, don't see it? :-)
>
>-- DN (I don't know if the LISP machines purpoted to do hard-real
> time, though. Doubt it.)
The fundamental problem with the Lisp Machines was the conflation of
hardware with software.
They decided that they could get Vastly Superior Performance by having
their own unique hardware designs.
Unfortunately, this meant that in order to take advantage of
technological improvements in other areas of computer hardware, they
effectively had to design new machines.
This is an expensive proposition, particularly with machines with
small production runs.
"General purpose" hardware may not have been as "elegant," or as
"optimal to purpose."
But when Intel (or whomever) starts being able to pack vast quantities
of transistors on a wafer, even a kludgy IA-32 CPU can beat out a
beautious special-purpose system, when they crank out, not mere tens
of systems per day, but more likely hundreds of thousands of them.
There have been some ongoing attempts to create a New Lisp OS; several
appear to be active with different variations on Scheme as the system
language; see URL below...
There seems to be little agreement on approaches; they go from:
a) Lisp environment atop UNIX, to
b) OS that uses UNIX filesystem/security models, but implements in
Scheme, to
c) Scheme environment that builds a definitely not-UNIX-like environment
from the ground up. Persistent objects, user interface based on
DHTML, with a "simulated Linux API."
The downside is that they probably can't all work; the upside is that
the respective "attempts" can attract interested people to perhaps do
implementation work rather than merely talking about it...
--
Have you ever considered beating yourself with a cluestick?
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lisposes.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Troll (was: why not C++?)
Reply-To: [EMAIL PROTECTED]
Date: Wed, 18 Aug 1999 00:47:04 GMT
On Tue, 17 Aug 1999 20:50:42 +0300, Timo Tossavainen <[EMAIL PROTECTED]>
wrote:
>Graffiti wrote:
>
>>Oh god. The return of the LISP machines.... *shudder*
>>They weren't *bad*, but look at where they are now. See my point?
>>(Or rather, don't see it? :-)
>
>Well, I think the lisp machines had specialized chips to evaluate
>lisp and were quite proprietary.
The founding of Symbolics and Lisp Machines has a great deal to do
with the founding of the Free Software Foundation... I do not recall
offhand which company of the two RMS considered the "bad guys," but
there was much bad blood at the time...
>I think a modern open Lisp OS would be a good idea. It would be a lot
>more stable than one, whose applications are mostly written in C/C++
>and the paradigm might be quite different from UNIX.
Try *could* be more stable...
>Lisp machines and a Lisp OS are different in the sense that lisp
>machines included specialized hardware. See anything with specialized
>hardware in general use ? I'm not aware of the reasons why the lisp
>machines didn't work out.
Richard Gabriel wrote a book about his related experiences; there was
a *lot* of AI-related hype, and a number of pretty big mistakes...
>I know people still use them but if someone knows a bit more history,
>I'd be interested. It was most certainly not the fault of the lisp
>language (or are people really that parenthetically challenged ?
>=)).
--
"Parentheses? What parentheses? I haven't noticed any parentheses
since my first month of Lisp programming. I like to ask people who
complain about parentheses in Lisp if they are bothered by all the
spaces between words in a newspaper..."
-- Kenny Tilton <[EMAIL PROTECTED]>
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lisposes.html>
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
