Linux-Development-Sys Digest #132, Volume #7 Tue, 31 Aug 99 20:13:56 EDT
Contents:
Re: why not C++? (Kaz Kylheku)
Re: why not C++? (Kaz Kylheku)
Programming under XWindows ("Darius Blaszijk")
Re: why not C++? (Don Waugaman)
problems with put_user (nightstalker)
Re: NFS caching (Ross Vandegrift)
Re: NFS caching (H.Bruijn)
unlink cputime (Robin Becker)
Re: TAO: the ultimate OS (James Andrews)
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: Disabling control-alt-delete from a program ([EMAIL PROTECTED])
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: Disabling control-alt-delete from a program (J.H.M. Dassen (Ray))
POST codes (Poe_7)
Re: Problem With dlopen()'d Libraries ([EMAIL PROTECTED])
Re: Disabling control-alt-delete from a program (Steve Houseman)
Re: linux driver examples from rubini ([EMAIL PROTECTED])
Re: why not C++? (Nix)
Re: TAO: the ultimate OS (Jonathan Guthrie)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 17:25:27 GMT
On 31 Aug 1999 09:26:08 -0700, Don Waugaman <[EMAIL PROTECTED]> wrote:
>There's one way to do this: returning a local variable by reference from
>a function. On the other hand, it is possible to point a pointer to
>a variable that goes out of scope within a function while the pointer
>is still valid.
>
>The solution is simple: never return a local variable by reference from
>a function.
In other words, in this regard, references require the same care and discipline
as pointers.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 19:36:44 GMT
On 31 Aug 1999 10:34:29 -0700, Don Waugaman <[EMAIL PROTECTED]> wrote:
>In regard to using pointers or references to refer to local variables,
>no. A reference must go out-of-scope before the variable it refers
>to. A pointer, on the other hand, can be reseated to point to a variable
>declared in an enclosing scope.
We've been over this one. A const-qualified pointer cannot be reseated, so this
is within the capability of pointers. However, the possibility exists that a
pointer may be uninitialized. This is a quality of implementation issue. If you
fail to initialize a const object, the language implementation should provide a
diagnostic, since there is obviously no other legal way that the object can
acquire a value. The only way in which such a construct is not in error
is if the object is never used.
------------------------------
From: "Darius Blaszijk" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development,comp.os.linux.development.apps,linux.dev.c-programming,linux.free-widgets.development
Subject: Programming under XWindows
Date: Tue, 31 Aug 1999 23:36:45 +0200
Hello there,
After making some small programs using GCC, I decided to start programming
under XWindows. But somehow I cannot find the information I need.
First of all, what kind of software do I need to be fully equiped. I have
the SuSe 6.1 distribution. (I'm used to program under WIN98 using DELPHI and
I want to have the same sort of funcionality under LINUX)
Second, where can I download the software I need extra?
Third, can anyone explain me briefly how widgets work? Is it the same as
components under DELPHI?
Thanks in advance, Darius Blaszijk
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 31 Aug 1999 10:34:29 -0700
In article <[EMAIL PROTECTED]>,
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>On 31 Aug 1999 09:26:08 -0700, Don Waugaman <[EMAIL PROTECTED]> wrote:
>>The solution is simple: never return a local variable by reference from
>>a function.
>
>In other words, in this regard, references require the same care and discipline
>as pointers.
In regard to the one instance returning pointers or references to local
variables, yes.
In regard to using pointers or references to refer to local variables,
no. A reference must go out-of-scope before the variable it refers
to. A pointer, on the other hand, can be reseated to point to a variable
declared in an enclosing scope. Once execution exits the scope, the
pointer is dangling.
Thus, references are safer both theoretically and practically than pointers.
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
This signature file is not self-referential.
------------------------------
From: nightstalker <[EMAIL PROTECTED]>
Subject: problems with put_user
Date: Tue, 31 Aug 1999 21:54:59 GMT
hi,
i tried compiling the second example from the linux module programming
guide (an ldp doc)
while trying to load the module (using insmod) i always get an error :
chardev.o: unresolved symbol __put_user_X
if I am correct, put_user() get's transformed into put_user_1,
put_user_2 or put_user_4 depending on the
size of the second argument. When sizeof( second argument )is something
different you get put_user_X
which indicates an error.
I do not know how to solve this .. has anyone else had the same
experiences when trying to compile this
example ?
ns.
PS: i'm using kernel 2.2.10
------------------------------
From: Ross Vandegrift <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: NFS caching
Date: Tue, 31 Aug 1999 17:36:20 -0400
Reply-To: [EMAIL PROTECTED]
How about using a solution similar to the one DNS uses? Make a flag
file on the server that contains a number. Each time you make a change
to the server, incrememnt the number. Then, write a script to mount the
NFS system. If the number in the flag file is the same as the local
number, then the system is cool, and the client mounts the local
system. On the other hand, if the number is higher than the local one,
there has been an update, and the script should mirror the server to get
the updates.
There a few problems here - it does assume the clients don't modify the
data (which you said in the original message). Second, if you make
major changes to the NFS filesystem, you could end up with client
machines mirroring the server for a long time. This would be very
impractical if you do large updates commonly. But if the data is mostly
static, or prone to small changes, this could work well.
Ross Vandegrift
[EMAIL PROTECTED]
bill davidsen wrote:
>
> Has anyone done anything to reduce network traffic between client and
> server when the data on the server is known not to change? I'm being
> very vague because I don't want to scare off any good solutions.
>
> What I'd like to do is set aside a GB or so of local disk as a cache
> area for that data which is known not to change. Unfortunately I need a
> "per mount" solution, since there are other mount points which change
> normally.
>
> --
> bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
> "So let it be written, so let it be dumb." Pharaoh Dufus the last...
------------------------------
From: [EMAIL PROTECTED] (H.Bruijn)
Crossposted-To: comp.os.linux.networking
Subject: Re: NFS caching
Date: 31 Aug 1999 20:23:29 GMT
Reply-To: [EMAIL PROTECTED]
On 31 Aug 1999 19:48:35 GMT, bill davidsen allegedly wrote:
>Has anyone done anything to reduce network traffic between client and
>server when the data on the server is known not to change? I'm being
>very vague because I don't want to scare off any good solutions.
>
>What I'd like to do is set aside a GB or so of local disk as a cache
>area for that data which is known not to change. Unfortunately I need a
>"per mount" solution, since there are other mount points which change
>normally.
>
since the data on the server is known not to change, and the clients
have sufficient disc space, just copy the data from the server to the
clients. Then when the data on the server does change, use rsync to
update the data on all clients with a simple script.
This won't work when the clients are allowed to modify the data though.
rsync is a programma that updates a certain directory/file to other
systems. The smart thing is, it will only update the modifications,
therefore generating a minimal amount of network traffic.
--
Herman
-- ------------------------------------------------------------------
If a trainstation is place where trains stop, what is workstation?
=====================================================================
Herman Bruijn hbruijn dix.Mines.EDU
------------------------------
From: Robin Becker <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: unlink cputime
Date: Tue, 31 Aug 1999 17:15:31 +0100
I asked before, but no one answered. Does unlink cause the ext2 filesys
to immediately process the removed inodes/blocks etc. so that removing
large files is costly. I find with the latest RH 6.0 that I seem to
notice the time taken for rm to remove big files (500Mb). I don't think
it was so intrusive under 2.0.37.
--
Robin Becker
------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Tue, 31 Aug 1999 13:13:09 +0000
Reply-To: [EMAIL PROTECTED]
I'm sorry, I'm as skeptical as the next guy, but I'm afraid you're just
being spiteful, for this reason, I think I'll sit and probe the errors
of your logic for a change, give Vladimir a break. I can abide flaming
or dissent for a thread, but this one seemed a little lacking in the
foundations... ok, where shall we start...
> Please explain this sandbox of yours in detail. What exactly would
> a program be barred from doing? To keep a virus from infecting other
> programs, you'd have to bar all programs from being able to open
> any file, which would make it impossible to install new programs if
> all programs were constrained to the sandbox.
Now, why in hells name would that mean barring all software from opening
any files? The entire concept of a sandbox (which admittedly you claim
to know nothing about, but still argue against?!?) is that it restrict
*certain* practises. Read that last line a few times to get the gist of
it. It doesn't merely remove all functionality and say hmm, thats it,
that program aint gonna bugger about now, it cant do anything. A good
sandbox environment leaves the program to run almost as normal, but
ensures that certain practises are performed through certain channels so
that the system can check for instability, deliberate vandalism or mere
bug problems. Under almost no circumstances would a piece of software
not be allowed any file access, and in the few situations where this may
happen, there would be either good reasoning, or no need for file
access.
> To prevent filesystem corruption (which would ultimately cause OS
> corruption), you'd have to make it completely impossible to directly
> access a filesystem. This would create a problem for filesystem checkers.
No you dont, you merely restrict all access to filesystems *UNLESS*
accessed through your channels, preset algorithms which can check all
aspects of the requests. You could restrict files to access only within
a certain directory or filesystem. Restrict file creation to a
specified size limit. There are an enormous amount of simple factors
that you could apply to a "sandbox" environment without a tremendous
amount of difficulty. And none that I know of involve cutting off your
nose to spite your face, as your rather aggressive and pointless post
suggests. This is again a relatively simple concept, which gauging from
your post, you wont get, so I'll put it simply. The weaknesses in OS's
are there as design faults. Technically in an ideal world, you could
create a sandbox environment on a linux based system merely by creating
a user name with very low priveledges and a constraint on the disk quota
to lower disk access. Make this user a member of a unique group and
execute the suspect file under these circumstances. Its options would
be severely limited, but most software wouldnt notice, and a more
sophisticated system could trick any software.
> You wouldn't be able to access a filesystem anyway because you have to
> make it impossible to open a file! Of course, these are all blind
> assumptions-- I don't actually know anything about this sandbox concept
So why are you arguing? I think arguing with a point you dont
understand, or claim to know anything about is blatant stupidity. Why
make blind assumptions? Do you treat everything in your life like
this? Would you drop your toaster in the bath to warm up the water
because you made the assumption it was safe? Would you argue with a
surgeon who was busy saving your life?
"You dont wanna stitch that bit up, not that I know anything about it,
but why don't you try hacking off my leg?"
NO. You don't, because it would be very silly, just because we cant see
your face turn red doesnt justify this kind of pointless spam. The
biggest deficit imho of the net is that so many people realise that with
the anonymity of the system they can be really annoying and no one can
do anything about it.
> of yours, which is why I am asking you to explain it in more detail.
>
> --
> If a man commits sedition in the middle of the
> woods, and there are no cops around to arrest
> him, is he still a criminal?
Oh, and the answer is yes, the more interesting questions are:
Will he be caught? and
Can they prove it?
James
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 31 Aug 1999 22:39:59 GMT
In comp.os.misc James Andrews <[EMAIL PROTECTED]> wrote:
: I'm sorry, I'm as skeptical as the next guy, but I'm afraid you're just
: being spiteful, for this reason, I think I'll sit and probe the errors
: of your logic for a change, give Vladimir a break. I can abide flaming
: or dissent for a thread, but this one seemed a little lacking in the
: foundations... ok, where shall we start...
JA: it was a reasonable nonimflammatory post and imho yours was the flame.
thanks for your support, but to borrow from n ancient
proverb, sometimes it is not an advantage to have a pit
bull for a friend.
perhaps the great tragedy of Usenet, which you lament in
your own message, is that people can no longer tell the
difference between a generally polite vs. antagonistic
message.
and btw, the other great tragedy of Usenet is that
antagonism is not inherent to debate, although you'd
never know it from Usenet.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Disabling control-alt-delete from a program
Date: Tue, 31 Aug 1999 18:51:35 GMT
[EMAIL PROTECTED] (Lew Pitcher) wrote:
>Remove this line, and you have disabled the <ctl><alt><del> keysequence.
>Change the line to run a different program (say
> ca::ctrlaltdel:/bin/echo 'somebody hit ctl-alt-del' >/dev/console
>and you change the action the key sequence invokes
Yeah , I know about inittab, but I'm specifically looking to be enable and
disable it from certain programs. Like I said , XF86 can do it so their must
be some system call buried in libc or similar to be able to do it.
NJR
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 31 Aug 1999 22:35:12 GMT
ah, a constructive comment. I knew if I posted long
enough one might arise.
In comp.os.misc SPAM THIS!! <[EMAIL PROTECTED]> wrote:
: Please explain this sandbox of yours in detail. What exactly would
: a program be barred from doing? To keep a virus from infecting other
: programs, you'd have to bar all programs from being able to open
: any file, which would make it impossible to install new programs if
: all programs were constrained to the sandbox.
disagree.
the sandbox is roughly equivalent to the java concept that
is never formally defined, but thrown around as if it exists.
I am expanding it somewhat.
it would be possible to limit programs to open files
within their own "sandbox".. they have a section of the
disk, say 2 meg or whatever is chosen by the user, within
which they can create any files or data that is preferred,
delete anything, etc. files outside the sandbox are
"read only" or possibly not available for read at all.
this is such an utterly basic/trivial concept yet by
today's OS measures, revolutionary. notice how even
Unix does not have a sandbox in many ways, such as with
forking. sometimes programs are not limited in how
many times they can fork or how much system memory or disk
space they decide to suck up.
and don't whine to me about "performance overhead".. I can't
see how it would be anything other than negligible and
insubstantial to put in these kinds of checks in the OS on
top of all the checking overhead that is already there.
: To prevent filesystem corruption (which would ultimately cause OS
: corruption), you'd have to make it completely impossible to directly
: access a filesystem.
when a program calls "fopen" it is already "not directly
accessing the filesystem". that is the whole point of an OS in
many ways is to mediate and sometimes stand in the way between the program
and system resources.
This would create a problem for filesystem checkers.
: You wouldn't be able to access a filesystem anyway because you have to
: make it impossible to open a file! Of course, these are all blind
: assumptions-- I don't actually know anything about this sandbox concept
: of yours, which is why I am asking you to explain it in more detail.
you nor no one else in software engineering understands it whatsoever,
judging by all existing OSes.. its an utterly simple concept that
has so far absolutely defied almost all software designers.
also, the concept of "throw/catch" exception processing mechanisms
is a crude attempt to handle the concept in the realm of the
control flow. its a start.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Disabling control-alt-delete from a program
Date: 31 Aug 1999 19:07:05 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Can someone explain how to disable the console control-alt-del key sequence
Remove or comment out the "ca" entry in /etc/inittab, and do "telinit q".
If you want to control it programmatically, consider writing a suidperl
script to switch between two inittab files.
>so that if an important program is running some bozo can't reboot the
>machine short of doing a hardware reset.
larting the bozo might be a better solution though.
>I know its possible since the XF86 server accomplishes it somehow (though
>I've never understood why it bothered)
Probably because X puts the keyboard in some sort of raw mode, so it can
control keyboard handling completely.
HTH,
Ray
--
UNFAIR Term applied to advantages enjoyed by other people which we tried
to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY,
UNDERHAND and JUST LUCKY I GUESS.
- The Hipcrime Vocab by Chad C. Mulligan
------------------------------
From: Poe_7 <[EMAIL PROTECTED]>
Subject: POST codes
Date: Tue, 31 Aug 1999 22:42:00 GMT
I am trying to bring a Debian version of Linux (Slink) up on a
Pentium II system with a new chipset that is in development (i.e.
non-stable hardware).
Right after Linux decompresses the kernel it displays a message
saying "Now booting the kernel" and locks the bus. Before it totally
dies it sends out lots of port 80 writes. I'm assuming that they are
POST codes and not just junk. I'm looking for a resource which
describes the POST code meanings, either in the source or on a web
page, etc.
Also, after the kernel decompression there is the jump to 0x100000 which
if I'm not mistaken is the kernel starting address. Which equivalent C
code is being executed at this point?
I would appreciate any information.
Thanks
-Tim
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Problem With dlopen()'d Libraries
Date: Tue, 31 Aug 1999 22:05:12 GMT
I have fixed the problem (under Linux, at least; other OS's are on the
hit list ;). I had originally tried using the RTLD_GLOBAL flag while
loading the libraries, but that wasn't a correct solution. I also tried
a dlopen() of the executable itself with RTLD_GLOBAL set, to attempt to
forcibly export its symbols, to no avail. I checked my mail today and
had a suggestion from Johannes Sixt, which was to link the executable
with -export-dynamic. Sure enough, this solved the problem. While it
compiled, I checked USEnet for replies to my original message and read
them all. I did not take the opportunity to try them on Linux, as the
first one I tried did work perfectly well; -rdynamic, if it would solve
this problem, probably has a similar effect to the solution I did try.
The solution involving giving the child object a function pointer that
it can use to get, by name or number (ioctl()-style), functions from the
main program would work, but would be hard to implement in my situation,
since a considerable bulk of the functions I need exported are member
functions (most of them virtual) of various classes.
Anyhow, thanks again to Johannes and to the rest of the world that
offered help in this. I'm one step closer to a complete program. ;)
-- Ari
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Steve Houseman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Disabling control-alt-delete from a program
Date: Tue, 31 Aug 1999 23:49:47 +0000
Hello NJR,
Dont know how to disable ctl-alt-del but but two connected items
are sysctl and /proc/sys/kernel/ctrl-alt-del
Havent experimented but man sysctl and sysctl.h imply it ought to do
something .
Cheers,
Steve Houseman
--
currently steve.houseman at virgin net
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: linux driver examples from rubini
Date: Tue, 31 Aug 1999 22:58:30 GMT
In article <7qh5jo$d9b$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (ellis) wrote:
> In article <7qfb86$m62$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
wrote:
>
> >Has someone been able to make rubini's examples
> >work on 2.2.+
>
> Take a look at
http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.2.html
>
> --
> http://www.fnet.net/~ellis/photo/linux.html
>
THAT DID THE TRICK ... Thanks for the hint ... the hints at
the above site made the difference ... tnx agn ... I will work out
more of the examples and then post it somewhere.
Jung
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 31 Aug 1999 21:16:57 +0100
Andomar <[EMAIL PROTECTED]> writes:
[dereferencing NULL and pasing it to functions]
> How else would you pass the char at address 0 ? I mean,
> there must be a way to allow that.
You can't cast arbitrary ints to pointers in a Standard-conforming
program, and pointers may have arbitrary internal structure. `Address 0'
may be represented by something quite different to all-bits-0, and `0'
(the null pointer constant) need not be represented by all-bits-0.
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Oxford
breed of `conference American'.
------------------------------
From: Jonathan Guthrie <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 31 Aug 1999 22:23:38 GMT
In comp.os.misc James Andrews <[EMAIL PROTECTED]> wrote:
>> Please explain this sandbox of yours in detail. What exactly would
>> a program be barred from doing? To keep a virus from infecting other
>> programs, you'd have to bar all programs from being able to open
>> any file, which would make it impossible to install new programs if
>> all programs were constrained to the sandbox.
> Now, why in hells name would that mean barring all software from opening
> any files? The entire concept of a sandbox (which admittedly you claim
> to know nothing about, but still argue against?!?) is that it restrict
> *certain* practises.
Okay, WHAT practices will be restricted? Are you going to treat
executable binaries as inviolate? That's fine, but how do you tell
the system that a file is a binary executable? Can that be revoked?
Depending upon the answers to those questions are a dozen more questions
waiting in the wings. I'm afraid that I don't see any realistic way of
building a sandbox to prevent viruses without basically eliminating
either the ability of applications to write files or the ability of a
compiler to run on the system.
Notwithstanding someone else's message that talks about Godel's (I don't
how to produce an o with umlaut on this computer, here) completeness
theorem, a message I recommend that you understand before proceeding, the
practical problem with saying "viruses will be impossible" is that there
is no essential difference between a virus and many of the programs people
use every day for one thing or another. The question becomes "how do I
tell the difference between a virus and ANY program that anyone may wish
to run" and I don't believe that there is an answer you can give me that
will work.
Don't give me any nonsense about a sandbox being an account on a Linux
system with few privileges. That's not a sandbox, it's just a sound way of
configuring a system.
--
Jonathan Guthrie ([EMAIL PROTECTED])
Brokersys +281-895-8101 http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX 77014, USA
------------------------------
** 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
******************************
