Linux-Development-Sys Digest #849, Volume #6 Sun, 20 Jun 99 16:13:53 EDT
Contents:
Re: using C++ for linux device drivers (Tristan Wibberley)
Re: I need clarification about malloc and brk (Andreas Jaeger)
Re: TAO: the ultimate OS (Linus Torvalds)
Re: TAO: the ultimate OS (Robert Forsyth)
New to Programming ("Robert Ascio")
Re: TAOs: Much to do about nothing? (The Ghost In The Machine)
Re: Linux & Cybercafe (Tristan Wibberley)
Re: TAO: the ultimate OS (Konstantin Koll)
Re: using C++ for linux device drivers ("John Burton")
Re: TAO: the ultimate OS (Konstantin Koll)
Re: TAO: the ultimate OS (Konstantin Koll)
WHAT ARE THESE TERMS SUPPOSE TO MEAN ("Santosh H.")
Re: using C++ for linux device drivers (Don Baccus)
Re: using C++ for linux device drivers (Don Baccus)
Re: using C++ for linux device drivers (Nathan Myers)
Re: using C++ for linux device drivers (Nathan Myers)
----------------------------------------------------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: Sat, 19 Jun 1999 17:49:51 +0100
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> Hi all,
>
> I am working a sound driver for linux (I will probably use OSS).I
> am planning to use C++, instead of C. Has anyone used C++ before for
> kernel/device driver programming for linux. If so what are the
> complications with using C++. I heard that C++ needs some OS support,
> especially for calls like "new", "delete" and stuff like that.
Feel free to use classes and methods - this is just syntax sugar.
Use kmalloc, kfree and new placement syntax - this is syntax/typing
sugar.
Don't use exceptions.
Don't use rtti.
Don't use normal new syntax.
Only use built in types which are also found in C.
Use virtual methods as little as possible (ie, don't) - they'll lead to
bugs.
Use multiple inheritance as little as possible (ie, don't) - it'll lead
to bugs.
Check that you use no language features provided by the C++ libs unless
they are inline.
If you do use any C++ features that are provided by the C++ libs, rip
them into your own lib, and link to that first. Debug this copy and
distribute it with your module (if the copyright license allows).
Use as few C++ features/syntax as possible (hide it all), the rest of
the kernel is in C and isn't expecting C++. To use kernel functions,
wrap them with C linkage functions within your C++ source, when
providing the kernel with callbacks, wrap them with C linkage functions
within your C++ source.
If your C++ compiler provides different linkage mechanisms, get all the
details. Choose the simplest one (not the fastest, or smallest) and
*always* compile with it. If it doesn't allow some C++ language
features, too bad - *Don't* use them.
The whole problem is that C++ binaries do a lot of behind the scenes,
compiler specific stuff that can introduce very unexpected behaviour.
Don't ask on the kernel development mailing list for help, or for anyone
to test it, because they won't. C++ in a kernel designed with C in mind
is risky because of unexpected behind the scenes behaviour.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: I need clarification about malloc and brk
Date: 15 Jun 1999 09:45:01 +0200
>>>>> Martin Kahlert writes:
> Hi!
> I have to port a large Fortran prog, which up to now runs under
> HPPA, IRIX, SUN4, SOLARIS, Linux x86 and WinNT to Linux Alpha.
> The Problem is the memory management and the age of the prog:
> We use C malloc and do Fortran 77 dynamic memory allocation with
> this (via offsets from a common block array).
> Unfortunately, the offsets are 32 Bit integers
> (changing that would be a major rewrite!).
> But up to now on Irix (64 Bit) this works fine whithout changes,
> since all pointers from malloc are 'near enough' to the common block
> array. This is not the case in Linux Alpha.
> I thought, malloc provides memory by using the brk(2) system call,
> which enlarges the data area of the executable. Thus i thought
> all pointers from malloc should be in the range from 0(or a bit more)
> to the result of brk(0).
> What i see on Linux Alpha, is that for the first allocated 8 MB block
> (smaller ones are just fine) i am more than 4 GB away
> from the common block's data area.
> If i run this prog through strace (Linux's equivalent to progs like
> truss, trace...) i only see brk results, which are very low
> (within the first 4GB).
> How can that be?
> Where the heck does malloc get its memory from, then?
You've got the source (in glibc's sources: malloc/malloc.c) to check
yourself.
> If anybody please could explain this to me, i would be very glad.
> If possible, please add a reply via mail to your post, too,
> since i don't want to miss any of them.
The malloc implementation used in later libc5 releases and in glibc 2
use mmap for larger blocks. You can tune the malloc implementation to
not use malloc. <malloc.h> has the following flags and a mallopt
call:
/* mallopt options that actually do something */
#define M_TRIM_THRESHOLD -1
#define M_TOP_PAD -2
#define M_MMAP_THRESHOLD -3
#define M_MMAP_MAX -4
#define M_CHECK_ACTION -5
/* General SVID/XPG interface to tunable parameters. */
extern int mallopt __MALLOC_P ((int __param, int __val));
In the glibc manual he find the explanation for these. You probably
want to set M_MMAP_MAX to zero.
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Linus Torvalds)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 20 Jun 1999 18:33:03 GMT
In article <7kj6ua$hjp$[EMAIL PROTECTED]>,
Terry Murphy <[EMAIL PROTECTED]> wrote:
>
>The issue of whether an OS should be mainframe-like or Unix-like
>is actually pretty interesting.
Why?
> Mainframe OS'es had lots of features,
>but they were big and slow for their time. Unix came in and showed
>the world, that an OS did not have to be big, and stripped all
>"extraneous" functionality
No. What UNIX showed the world was that you can be _flexible_. That
was something the mainframes lacked completely. It's something that
Windows lacks completely too - it's not about size or speed, it's about
selecting a design that doesn't force people to do things any certain
way.
In fact, having lots of "features" is often a sign of being inflexible:
because you can't do something naturally, you add yet another feature to
do the new thing.
The reason UNIX doesn't have all that many features was that the
fundamental design is flexible. One basic example of this is the notion
of records in a filesystem: a inherently very non-flexible notion, that
results in lots of silly utilities that are very specific to some
things.
Not trying to interpret the data results in the ultimate flexibility:
the system does not impose any ordering on you.
And no, it wasn't only UNIX that did things a certain way, it was just
that UNIX was rather successful at putting it all together into one
coherent whole.
So back to the question of UNIX vs mainframes - no, it's not in the
least interesting. And it has got nothing to do with size.
Linus
------------------------------
From: Robert Forsyth <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Sun, 20 Jun 1999 18:10:13 +0000
This sounds a little like a Nextstep/Openstep bundle. A bundle is just a
subdirectory/folder, but is treated like a file by the (GUI) Workspace
manager, which is the tool main for files and folders.
An application bundle (.app) contatins the executable, image, sound,
other resouces (for each spoken language).
A document with embedded pictures (.rtfd) containds the text (.rtf) and
the images.
"Vladimir Z. Nuri" wrote:
>
> well, I find it quite amazing that so many ppl are focusing on
> my defn of "object oriented" as a key deficiency of the post.
>
> ok, ok!! uncle!! it all seems so obvious to me, but
> let me elaborate on this somewhat.
>
> when I envision an object system, I am really imagining, partly,
> a new kind of file system that has more attributes associated with
> each file than the existing small set, such as time stamps etc.
> or at least this is one way to imagine what I am talking about
> for ppl who are stuck attempting to understand
> the essay in terms of existing systems.
>
> now it is a trivial observation that every OS is composed entirely
> of source files.
>
> the objects I envision are essentially files with additional
> structured information & intelligence.
> for example the file can have embedded links to
> other files. so a source file could have a link within it,
> i.e. a reference, to the object file.
>
> essentially the idea is that the OS understands all the links
> between different files. so when I pull off an application off
> the computer, the OS understand what files are associated
> with it because of all the built-in-references. the OS keeps
> these current and handles the other administrivia associated
> with it all.
>
> when I say "object" perhaps the way to understand it is
> "superfile". anything that is now a file can be turned into
> a Tao object. the dif is that the Tao system understands all
> the different file formats as part of the OS, and how to
> convert them between each other, etc. of course Tao objects
> are far more than merely files, but to eventually get to
> this point B, I'll start at this point A.
>
> hence concepts like "make" and "compilation" are built into
> the OS.. a dependency tree support is built into the OS and
> for more operations than merely compilation. for example,
> creating a graph from spreadsheet data is a kind of
> abstract compilation (quite similar to the way that object
> code is created from source code) that the system can understand.
>
> hence, Tao can be completely "object oriented" because all
> existing OSes are built out of files. QED <g>
>
> --
> ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
> "in theory, there's no difference [EMAIL PROTECTED]
> between theory and practice, mad genius research lab
> but in practice there is!" http://www8.pair.com/mnajtiv/
--
Robert Forsyth
http://homepages.tcp.co.uk/~forsee/
tel/fax: +44 1243 787487
------------------------------
From: "Robert Ascio" <[EMAIL PROTECTED]>
Subject: New to Programming
Date: Tue, 15 Jun 1999 01:54:41 -0500
Any tips on Linux Programming? Any book recommendations?
The extent of my programming knowledge is limited to the three semester hour
college course in "C" programming
Rob
------------------------------
From: [EMAIL PROTECTED] (The Ghost In The Machine)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAOs: Much to do about nothing?
Date: Sun, 20 Jun 1999 18:12:35 GMT
On 18 Jun 1999 20:13:07 -0500,
Peter Samuelson <[EMAIL PROTECTED]> wrote:
> [me]
>> > If you stand the bed on end, does that mean someone who wants to
>> > sleep will have to busy-wait instead? Bad, bad, bad....
>[The Ghost In The Machine <[EMAIL PROTECTED]>]
>> Heh...well, he could do like Batman and sleep upside-down
>> like a bat, his legs strapped to the bed or something.... :-)
>
>Great, now you're gratuitously adding hardware requirements and making
>unwarranted assumptions about your users.
*LOL*!
Hmm...maybe I'll go back to *my* bed; at least it works! :-)
[.sigsnip]
----
[EMAIL PROTECTED]
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: alt.uu.comp.os.linux.questions,comp.os.linux.networking
Subject: Re: Linux & Cybercafe
Date: Sat, 19 Jun 1999 18:15:45 +0100
Reply-To: [EMAIL PROTECTED]
Moritz Moeller-Herrmann wrote:
>
> On 09 Jun 1999 15:19:42 +0100, David Knight <[EMAIL PROTECTED]> wrote:
> >Maurice Kemmann <[EMAIL PROTECTED]> writes:
>
> >> MicroNg schrieb:
>
> >> > however, how to limit the access that so the user can only access the
> >> > browser but NOT any other
> >> > program ? ( to access other program, for eg for the webmaster to shutdown
> >> > the computer, an passcode
> >> > is required).
>
> >> You can configure the windowmanager without any xterm. So the users are
> >> not able to start any other program. On the desktop you offer only the
> >> browser. Login should be via xdm !
> >> That's it i think !
>
> >That it itself probably wont work, just put in netscape
>
> >telnet://localhost
>
> >and it will open an xterm running the telnet session, from which they
> >would then be able to start other programs.
>
> You could just give an extremely limited PATH to the user who runs X. Just
> Netscape and xinit. I think that would stop the telnet thingy. Anyways who
> would allow telnetting in /etc/inetd.conf, if the machine is for a surf
> station? Then I would use a windowmanager without the possibility to call
> xterms or give commands directly. I think icewm could be configured to do
> this. Then give only reading rights to all configuration items.
A limited PATH is not good enough, you need to start netscape from
chroot, and give a limited *filesystem* :)
Now you can have any network services the admin needs (such as ssh)
without worrying about the user using them with netscape. Any non read
only filesystems must have all execute permissions disabled. It would
probably be appropriate to provide a local filesystem for storage of
downloaded files, and give a couple of utilities for users split and
compress them.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: Konstantin Koll <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Sun, 20 Jun 1999 20:43:39 +0200
Reply-To: [EMAIL PROTECTED]
Alexander Viro wrote:
>
> [...]
> Out of curiosity - what language have you used for this beast?
>
This "beast" was written with Borland Pascal 7 and a HELL LOT of assembler.
> >2. The whole code of DESKWORK is linked together in an EXE-file of ~750 KB.
>
> Ouch... Do you mean that all this stuff (including games) runs in ring 0? Scary.
No, of course not. The .EXE-file contains multiple code segments; only the ones
of the kernel have ring 0, device drivers ring 1, and "normal" apps ring 3.
> Free advice (which is worth every euro you've paid for it ;-) - don't let the
> browser code to run in ring 0. BUGTRAQ is already full of exploit reports.
'course not.
> See above. If something doesn't need full privileges - don't grant them. 99%
> of the stuff can live in ring 3 (proof - any UNIX or (sorry) NT).
Yup.
------------------------------
From: "John Burton" <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: Sun, 20 Jun 1999 19:53:15 +0100
Tristan Wibberley wrote in message <[EMAIL PROTECTED]>...
> Feel free to use classes and methods - this is just syntax sugar.
> Use kmalloc, kfree and new placement syntax - this is syntax/typing
>sugar.
> Don't use exceptions.
Because the library support isn't there? Ok.
> Don't use rtti.
Because the library support isn't there? Ok.
> Don't use normal new syntax.
Why not, as long as you override the global new/free to call kmalloc
and kfree they should be fine.
> Only use built in types which are also found in C.
Why? You wouldn't want to pass a bool to the c part of the kernel but
why not use one in your own code?
> Use virtual methods as little as possible (ie, don't) - they'll lead to
>bugs.
Why would they lead to bugs? If you don't use virtual methods there
is little point to using c++.
> Use multiple inheritance as little as possible (ie, don't) - it'll lead
>to bugs.
See above.
> Check that you use no language features provided by the C++ libs unless
>they are inline.
Fine...
>
>Don't ask on the kernel development mailing list for help, or for anyone
>to test it, because they won't. C++ in a kernel designed with C in mind
>is risky because of unexpected behind the scenes behaviour.
It might be unexpeceted but it's not unpredictable. Use the source and
figure out what it's doing. It's just code...
------------------------------
From: Konstantin Koll <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Sun, 20 Jun 1999 20:50:27 +0200
Reply-To: [EMAIL PROTECTED]
Holger Berger wrote:
> [..]
> This works fine for a small number of files.
> Typical file number in my homedirectory on a unix machine is ~ 3000.
> So, this are files created by me. On the hole syetem are > 100000 files.
> On a dual user machine.
> Not easy to handle in one directory...
> The Oberon OS has the same approach. If i remember it right, they allow
> longer names. So they can simulate directorys by structured file names.
>
> In my experience, filenames should be allowed to be longer than 100 charecter.
> This is always important if you generate filenames in automatic fashion,
> or if you are using specific systems for classification of files, giving
> long names.
Each user gets it's own home directory with NO subdirs. You can dump 41^8 files
in there (8 characters allowed for DOS files with 41 different symbols allowed).
Sorry, I don't have much experience with automatic file generation (screenshot
program ?) However, it's no problem to keep track and find your files back !
I've
about 700 files in my home dir and have any of them at hand in some seconds.
Remember, you hardly work with a list that shows ALL files at the same time, but
you only get a limited selection (show me all images, show me all sounds, show
me the texts that have been modified the last days).
> School who don't care about programming should keep there hand of
> computers. Teaching basics of programming is very important if you wan't
> to get deeper insight into computers.
> If you are not interested in insight - use only office, as everybody does.
Maybe you're right. But at my old school, some chemistry teachers don't know
too much about computers, and use DESKWORK to show off animations of different
molecular structers to the class. They can handle DESKWORK very well, and added
a new media to their lectures.
Regards, Konstantin Koll
------------------------------
From: Konstantin Koll <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Sun, 20 Jun 1999 20:53:38 +0200
Reply-To: [EMAIL PROTECTED]
Vladimir Z. Nuri wrote:
>
> Konstantin Koll ([EMAIL PROTECTED]) wrote:
> : Hello,
> : I just read your theoretical paper about "Tao". It reads interesting, and is NOT
> : theroretical at all: Tao is alive and already working. Friends and me have been
> : working on an OS that does exactly what you think "Tao" should do. The name of
> : that OS is "DESKWORK" and is ready to be shipped in July 1999.
> : Take a look at http://www.deskwork.de/WELCOME.HTML to see screenshots and learn
> : more about it.
>
> btw I hit the web page and looked into deskwork.. "nice work dude",
> and lots of solid code/interface in place!! I commend/congratulate
> you.. your enthusiasm is infectious<g> maybe everyone out here
> bludgeoning me about not having code can go hit your web site and download
> it<g>
>
> that said, I have absolutely no idea why you think your OS has anything to
> do with what I wrote about.. that it is "Tao alive & working, does exactly
> what I think Tao should do".. huh?!?!?!?
>
> that said, well anyway, keep the good work<g>
>
> --
> ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
> "in theory, there's no difference [EMAIL PROTECTED]
> between theory and practice, mad genius research lab
> but in practice there is!" http://www8.pair.com/mnajtiv/
Quite simple... DESKWORK was desinged with the user in mind. The user does not
have to care about disk drives, directory trees and much other stuff... It
simply
works. It's also very fast and stable, recognizes a wide range of hardware
without
any additional drivers... and so on.
------------------------------
From: "Santosh H." <[EMAIL PROTECTED]>
Subject: WHAT ARE THESE TERMS SUPPOSE TO MEAN
Date: Sun, 20 Jun 1999 23:41:45 +0530
Hi,
Sorry for shouting.But i'm really fed up with trying to find out what
this means
1] jiffy
2] HZ
I'd be really grateful for some help.
pls reply to [EMAIL PROTECTED]
thanx in advance
Santosh
------------------------------
Subject: Re: using C++ for linux device drivers
From: [EMAIL PROTECTED] (Don Baccus)
Date: 20 Jun 1999 11:51:35 PST
In article <[EMAIL PROTECTED]>,
Frank Sweetser <[EMAIL PROTECTED]> wrote:
>Justin Vallon <[EMAIL PROTECTED]> writes:
>> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
>> void operator delete(void *p) { free(p); }
>...which is a higher-overhead version of
>#define new((x)) malloc((x))
>#define delete((x)) free((x))
Any decent compiler will generate the proper definition
in-line, giving exactly the same code as the #define
hack.
(so sez this decent compiler writer)
--
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, at http://donb.photo.net
------------------------------
Subject: Re: using C++ for linux device drivers
From: [EMAIL PROTECTED] (Don Baccus)
Date: 20 Jun 1999 11:56:29 PST
In article <7kj3h6$qdq$[EMAIL PROTECTED]>,
John Burton <[EMAIL PROTECTED]> wrote:
>Frank Sweetser wrote in message ...
>>#define new((x)) malloc((x))
>>#define delete((x)) free((x))
>No it isn't, it is very different. malloc and free don't construct the
>objects
>they just alllocate the memory.
Oops, I forgot about constructing the object when I said
a decent compiler generates the same code for each :)
The point of inline methods, though, is that they're
generated inline so the notion that they're a source of
overhead isn't true. (Of course, many compilers won't inline
a complicated function, but most constructors tend to be
quite simple).
--
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, at http://donb.photo.net
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: using C++ for linux device drivers
Date: 20 Jun 1999 12:07:35 -0700
Frank Sweetser <[EMAIL PROTECTED]> wrote:
>Justin Vallon <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED] (Alexander Viro) writes:
>> > In article <7kdqj9$l1o$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> > > I am working a sound driver for linux (I will probably use OSS).I
>> > >am planning to use C++, instead of C.
>>
>> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
>> void operator delete(void *p) { free(p); }
>
>...which is a higher-overhead version of
>
>#define new((x)) malloc((x))
>#define delete((x)) free((x))
Frank, you are confused beyond salvation on this point.
Best drop it.
>> Compile with -nostdinc++ -fno-exceptions.
>>
>> Static constructors may need a C++ link phase, or you could warn that
>> C++ static constructors will not be executed.
>
>don't forget about name mangling, call by reference, the whole
>private/public/protected mess...
Name mangling is dealt with by 'extern "C"'. Call-by-reference
is a non-issue; no kernel function or callback uses it.
There is no such thing as a "private/public/protected" mess.
Those keywords have no effect on the emitted object code.
That they are keywords at all might break some kernel headers.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: using C++ for linux device drivers
Date: 20 Jun 1999 12:19:17 -0700
John Burton <[EMAIL PROTECTED]> wrote:
>Tristan Wibberley wrote in message <[EMAIL PROTECTED]>...
>> Don't use normal new syntax.
>
>Why not, as long as you override the global new/free to call kmalloc
>and kfree they should be fine.
They have different semantics. Some things are best not hidden,
and kernel memory management is one such. Placement new is
sufficient to construct objects, but check for a null result
from kmalloc first.
>> Only use built in types which are also found in C.
>
>Why? You wouldn't want to pass a bool to the c part of the kernel but
>why not use one in your own code?
There's nothing wrong with using bool. Floating-point is forbidden
for other reasons anyway. Reference types are fine within your own
code.
>> Use virtual methods as little as possible (ie, don't) - they'll lead to
>>bugs.
>
>Why would they lead to bugs? If you don't use virtual methods there
>is little point to using c++.
The main value of C++ for kernel work, particularly for a single
module, is its template mechanism. Even restricting yourself to
inline templates, they provide enormous expressive power.
Virtual functions are used in C++ in cases where in C you would use
a table of function pointers. They do not "lead to bugs", they
prevent the kind of bugs you find in such usage in C.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
** 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
******************************
