Linux-Development-Sys Digest #369, Volume #8 Fri, 22 Dec 00 01:13:10 EST
Contents:
Re: LVM and JReiserfs crash 2.2.14 and 2.2.16 (Johannes Nix)
Re: [OT] Re: Compiling C++ programs with GCC --> no GPL license implications
(Stefaan A Eeckels)
RPC: Connection Refused ([EMAIL PROTECTED])
RPC: Connection Refused ([EMAIL PROTECTED])
Re: Intel Easy PC camera - cannot be supported in Linux! (Russ Lyttle)
Linux driver not working on K6 (Ed Hudson)
Re: Linux driver not working on K6 ("Peter T. Breuer")
Re: How can I find out the implementing of a system function? (From China ;-)) (G.P.
Hwang)
Re: Char device drivers and mknod (Petric Frank)
Re: How to make a BIOS call in Linux (bill davidsen)
Re: Compiling C++ programs with GCC --> no GPL license implications (Ralph T.
Wayland)
Re: Compiling C++ programs with GCC --> no GPL license implications ("Jeffrey B.
Siegal")
Re: IEEE standards (David Wragg)
Re: Char device drivers and mknod (David Wragg)
Problems with Linux kernel? ("Joshua Schaeffer")
Re: front ending libraries (even libc) (Joe Bob)
Re: front ending libraries (even libc) (Joe Bob)
Re: front ending libraries (even libc) (Joe Bob)
----------------------------------------------------------------------------
From: Johannes Nix <[EMAIL PROTECTED]>
Subject: Re: LVM and JReiserfs crash 2.2.14 and 2.2.16
Date: 21 Dec 2000 17:50:26 +0100
Andi Kleen <[EMAIL PROTECTED]> writes:
> You should probably update to a newer SuSE kernel. One of the kernel updates
> (no on CD kernel) had a memory balancing problem that caused such effects on
> very heavy writes.
>
The 2.2.14_suse (unusable slow) was from CD, the 2.2.16_suse (even
slower) is an update. 2.2.16 is the last update from SuSE (and strange
enough, I find it currently in the mirror ftp.hilton.rwth-aachen.de
but not in ftp.suse.de, while ftp.suse.com does not answer). Timestamp
of 2.2.16_suse is July 9th.
>
> linux-kernel is appropiate when you're using mostly unpatched kernels
> (i.e not the SuSE kernel)
So it would be better to try vanilla 2.2.18 with ReiserFS and LVM
patches and look what happens (should theoretically not break NFS
things?)
Should I try to use less memory than 512MB?
Johannes
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: [OT] Re: Compiling C++ programs with GCC --> no GPL license implications
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Date: Thu, 21 Dec 2000 17:41:46 +0100
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Isaac) writes:
>
> I think we've covered all the bases here. Any further discussion will
> have to get into extremely charged areas concerning voter intent, etc.
> I'm going to beg off again and hopefully I can make it stick this
> time.
Good luck. It's resolution time anyway. Merry Christmas.
--
Stefaan
--
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.help
Subject: RPC: Connection Refused
Date: Thu, 21 Dec 2000 21:01:07 GMT
Reply-To: [EMAIL PROTECTED]
My place of emplyment, someone has devloped a SCSIserver for SGI, SUN,
and LInux. He used rpc for this. This server program works find on one
linux box. But when I installed it on a new linux box, I get this when I
use a client: Connection Refused. I am able to connect fine on the
other linux box. I am unable to find any rpc.hosts kind of file any on
the new linux host. What do I need to do on the new linux box to accept
RPC calls?
thanks
Enrique Herrera
[EMAIL PROTECTED]
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: RPC: Connection Refused
Date: Thu, 21 Dec 2000 21:02:39 GMT
Reply-To: [EMAIL PROTECTED]
My place of emplyment, someone has devloped a SCSIserver for SGI, SUN,
and LInux. He used rpc for this. This server program works find on one
linux box. But when I installed it on a new linux box, I get this when I
use a client: Connection Refused. I am able to connect fine on the
other linux box. I am unable to find any rpc.hosts kind of file any on
the new linux host. What do I need to do on the new linux box to accept
RPC calls?
thanks
Enrique Herrera
[EMAIL PROTECTED]
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Russ Lyttle <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.advocacy
Subject: Re: Intel Easy PC camera - cannot be supported in Linux!
Date: Thu, 21 Dec 2000 21:37:05 GMT
jtnews wrote:
>
> Russ Lyttle wrote:
>
> > Unfortunately, the correct answer is YEP. You might win, Intel might
> > loose, but in the meantime, who has money to pay for lawyers? I would
> > suggest contacting Intel and clearing it with them first. Otherwise post
> > the code as "anonymous coward" somewhere from a cybercafe.
>
> What I don't understand is why a company as big as Intel won't support
> Linux, even if it was just a driver with an object file and no source,
> that would do. I'd like to use the Easy PC camera as a home security
> intrusion detection camera. If they made the driver available for
> Linux, then I'd buy
> at least 3 more cameras.
At one time we refered to MS and Microsoft as the "Wintel Monopoly". MS
& Intel worked closely together. Intel would not release a new chip
until MS had time to make sure DOS/Windows would run on it. This assured
quick adoption of the new chips in PCs. Now they are on the outs because
MS got carried away with its power and killed, IIRC, Intel 3d video
technology. But Intel is a big outfit and many people inside still katow
to MS. They fear that if Intel gets too friendly with Linux, MS will
change their OS enough to hamper adoption of Intel add ons.
--
Russ Lyttle, PE
<http://www.flash.net/~lyttlec>
Not Powered by ActiveX
------------------------------
From: Ed Hudson <[EMAIL PROTECTED]>
Subject: Linux driver not working on K6
Date: Thu, 21 Dec 2000 17:30:58 -0500
I have written a Linux driver for a PCI card my company produces. A
customer is having a problem with the system hanging that we have not
experienced. He is running an AMD K6 processor. Are there any
precautions or things I should know to make the driver work on the K6?
Thanks
Ed
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Linux driver not working on K6
Date: Thu, 21 Dec 2000 22:44:41 GMT
Ed Hudson <[EMAIL PROTECTED]> wrote:
> I have written a Linux driver for a PCI card my company produces. A
> customer is having a problem with the system hanging that we have not
> experienced. He is running an AMD K6 processor. Are there any
> precautions or things I should know to make the driver work on the K6?
No. Except that K6's don't support all possible intel codes. Make sure
he compiles quite conservatively. I also seem to recall a K6 sleep bug
in which its internal architecture plus pipelining and optimization
affected the way it reacted to lock or nop instructions .. something
about doing a busy while 1; in one pipeline. You really want to search
back through the kernel list arcives on this one ..
It's far likelier that he has mobo problems with busmastering.
Peter
------------------------------
From: G.P. Hwang <[EMAIL PROTECTED]>
Subject: Re: How can I find out the implementing of a system function? (From China ;-))
Date: Fri, 22 Dec 2000 00:37:24 GMT
Thank you very much!
I just make a mistake and now I understand it. ;-)
In article <[EMAIL PROTECTED]>,
Andreas Jaeger <[EMAIL PROTECTED]> wrote:
> >>>>> nowican writes:
>
> > Hi all,
> > These days I am confused by looking for the implementing
> > of a system function such as malloc(). I've tried to find
> > out it but failed, here are my ways to go:
> malloc is implemented by glibc. The kernel is not linked against libc
> and has a replacement for a number of functions like malloc.
>
> 1> In /usr/src/linux/arch/i386/boot/compressed/misc.c I get
> > static void *malloc(int size){ ... }
> > In /usr/lib/bcc/include/malloc.h I get
> > extern void *malloc __P((size_t));
> > And in /usr/src/redhat/SOURCE/glibc-xxx/elf/dl-minimal.c get
> > void * weak_function malloc (size_t n){ ... }
>
> > But there are only part of the tags I found through using
> > vi -t malloc in these paths.
>
> For user programs check glibc/malloc/malloc.c for the malloc
> implementation.
>
> 2> I wrote a program to try to get the prototype of malloc but..
>
> > nic@nic/home/nic/prog/test~$ cat gcce.c
> > #include<stdlib.h>
> > int main(void)
> > {
> > free(malloc(10));
> > return 0;
> > }
>
> > nic@nic/home/nic/prog/test~$ gcc -E gcce.c | grep malloc
> > extern void * malloc (size_t __size) ;
> > free(malloc(10));
> What is your problem here? That's just the desired output.
>
> Andreas
> --
> Andreas Jaeger
> SuSE Labs [EMAIL PROTECTED]
> private [EMAIL PROTECTED]
> http://www.suse.de/~aj
>
--
I am a Linuxer from China and
hoping to make friends with you! ;-)
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Petric Frank <[EMAIL PROTECTED]>
Subject: Re: Char device drivers and mknod
Date: Fri, 22 Dec 2000 01:32:36 +0100
Hello Satis,
Satis Loire wrote:
>
[... asking why not create device node inside device driver ...]
> the reason that you can't mknod in device driver is simply
> because the module cannot do anything before its major
> and minor number are correctly assigned. so it has to be
> done during the driver module is loading.
You can create a node in /dev even the driver is not loaded.
So - why not creating the node in the driver (function init_module)
after registering the driver by a call to register_chrdev which returs
me the dynamic allocated major device number (and deleting the device
node in cleanup_module).
The minor numbers are all handled by the same driver - so the driver
knows which minor numbers are valid.
Do i have to analyze the source of mknod or is there someone with a code
snippet ?
regards
Petric
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: How to make a BIOS call in Linux
Date: 22 Dec 2000 01:42:32 GMT
In article <91r4vo$[EMAIL PROTECTED]>,
Johannes Nix <[EMAIL PROTECTED]> wrote:
| [EMAIL PROTECTED] (bill davidsen) writes:
|
| > Thanks, I will have to look at this, since the 2.4 kernel series does
| > not interface to APM (in spite of notes in the Change log saying that
| > power down does work, even with SMP). When my UPS says the party's over,
| > I want to shut the system off, not run the UPS dead supporting a halted
| > system. There's no real hope of getting this in the kernel, so I want to
|
| It seems wiser to me to do an umount -a and switch off the UPS - many
| UPS seem to support this. Why? Because it is safer if power comes back
| and fails again. You don't have UPS protection the second time, as the
| battery is empty.
That's the idea behind shuttdown completely... the UPS (presumably)
will not run down with the system off, and I certainly don't intend to
run until the batteries are dead, 90% of outages over 2 minutes are over
the UPS life anyway.
But I'll look at the UPS powerdown, assuming that the umount -a works
as expected. Too often the syslog or something can't unmount because the
files are active. You can kill processes, etc, but that may not be
optimal.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The line from the immutable past to the desired future is useful to
justify continuing to tack into the wind, making a major change in
course, or coasting into safe harbor. It is not a map of where you are
going, just how to get where you want to go.
------------------------------
From: Ralph T. Wayland <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Subject: Re: Compiling C++ programs with GCC --> no GPL license implications
Date: Fri, 22 Dec 2000 02:36:09 GMT
Egads, I had no idea my posting would generate so much conversation (on
so many topics).
Some brief (hopefully concluding) comments:
1) My apologies to Pete Becker and others at Dinkumware for any
innuendo. See their website for info on their products.
2) It looks like trolls did partly drag us down into " labyrinthian
caves." Ah well, such is life. Some of the discussion was useful at
least. The US Presidential election discussion as a part of this thread
was way off topic -- that it kept going so long highlights a near fatal
flaw in the newsgroups system.
3) As others have acknowledged (thanks guys!), the whole point of the
initial post was to communicate information around GCC licensing in such
a way that others could reproduce the results for themselves using my
methodology and logic. No one should trust me or news group posts as a
definitive source of legal advice. Newsgroups are a good way to test
logic and ideas -- bad ones are ripped to shreds.
I did the GCC research so the attorney's at my company would have enough
information for them to come to their own licensing conclusions about
our use of GCC. My company is extremely careful regarding intellectual
property rights and licensing. Each person/company should consult their
own attorney(s) regarding these matters if this issue concerns them.
Newsgroup discussion is still useful even though it cannot be used as a
definitive legal opinion. It is the free flow of ideas and thought that
is so valuable -- even to attorneys (or perhaps especially to).
Regards,
Ralph
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Jeffrey B. Siegal" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Subject: Re: Compiling C++ programs with GCC --> no GPL license implications
Date: Thu, 21 Dec 2000 19:12:26 -0800
"Ralph T. Wayland" wrote:
> I did the GCC research so the attorney's at my company would have enough
> information for them to come to their own licensing conclusions about
> our use of GCC. My company is extremely careful regarding intellectual
> property rights and licensing. Each person/company should consult their
> own attorney(s) regarding these matters if this issue concerns them.
For the benefit of general interest, if you are willing to share, what
were their conclusions?
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: IEEE standards
Date: 21 Dec 2000 20:05:22 +0000
HomerWelch <[EMAIL PROTECTED]> writes:
> I doubt whether it is patentable, but it is copyrighted. I
> remember reading a magazine article by a guy who was on the
> committee to standardize the C Programming Language. He
> wanted a copy of the released standard. IEEE wouldn't give
> him one. He had to pay for it. So much for volunteering on
> IEEE committees.
C was standardised under the auspices of ISO and ANSI, not IEEE.
Participating in ISO standard committee has traditionally involved
attending several meetings a year held in various locations around the
world, and finalizing these kinds of standards tends to take several
years. So over the course of the process, a participant will usually
need to come up with many thousands of dollars for travel, hotels,
etc., not to mention the value of their time. So while not giving a
participant a copy of the final standard seems a bit mean, I doubt
that it could be much of a factor for anyone who was serious about
contributing to a standard.
I suspect that IEEE meetings are usually held in the US. But that
probably doesn't make much of a difference to the costs involved.
Of course, it is likely that over time the ubiquitous use of the
Internet will affect how standards get written. But some face-to-face
meetings will probably always be needed in the development of any
non-trivial technical standard.
Now why the last draft of IEEE 1003.1g (POSIX sockets) costs 80
dollars when the development of that standard has been discontinued
(except as part of the Austin Group activities), I have no idea.
David Wragg
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: Char device drivers and mknod
Date: 21 Dec 2000 20:08:44 +0000
Petric Frank <[EMAIL PROTECTED]> writes:
> I am interested on the reason not to do this (mknod in device drivers).
> Actually i can not understand why i should not code it into the driver.
Kernel code takes up unpageable memory. Is there any reason why you
can't do a "mknod" in a script to be run when the driver is installed,
perhaps even in the driver's Makefile?
David Wragg
------------------------------
From: "Joshua Schaeffer" <[EMAIL PROTECTED]>
Subject: Problems with Linux kernel?
Date: Fri, 22 Dec 2000 04:08:14 GMT
I want to hear peoples' voices and opinions about what programmers do and
don't like about the Linux kernel. All feedback will be integrated into the
design of yet another Open Source operating system.
To avoid flooding this newsgroup with non-relevant postings, please send any
remarks to the following e-mail address:
[EMAIL PROTECTED]
Many thanks in advance for your responses!
------------------------------
From: Joe Bob <[EMAIL PROTECTED]>
Subject: Re: front ending libraries (even libc)
Date: Fri, 22 Dec 2000 05:33:33 GMT
[EMAIL PROTECTED] wrote:
> I'm starting to take a look at what might be needed to do library front
> ending. What I mean by that term is this. An existing library, such as
> libc, will have a complete set of its own functions. The front ending
> library will have a subset of the functions (possibly just a few, maybe
> even just one). I want to have, AT RUN TIME, for the front end library
> to be preferred over the back end library for dynamic linkage. If the
> symbol is defined in the first library found, use that. But if it is
> found not in the first, but in the second, use that. There needs to be
> not conflict with respect to the fact that the second library also has
> the same symbols found in the first. I'm thinking of the first library
> as a sort of mask layed over the second, hiding some symbols and having
> its own versions of them instead.
>
I just had the occaision to do this today. My goal was to override a libc
function with my own version.
Just write your replacement function (namespace, returns and arg casting the
same!). Link it into your own shared
library. Set the LD_PRELOAD variable at run time; export
LD_PRELOAD=/usr/local/lib/libspecial.so. Then
start your app. Its just that easy. You can confirm that your dynamic
library is getting used by doing a "ldd" on your
binary.
This is a great way to instrument precompiled binarys!
Although its true that you can "just rebuild glibc", it takes _hours_ on
anything but fast SMP machines.
Adio,
Jay
>
> The above I think is easy. Here's where it get's tricky.
>
> The first library needs to be able to call the second library, even with
> symbols the first library is exporting to the programs being linked to it.
>
> And this needs to be done with no recompiling or relinking of either the
> second library or the program being run to use them. I will be root if
> I am going to specify anything on LD_LIBRARY_PATH, and usually will be
> configuring all this via ld.so.conf, so security for suid programs is not
> an issue. I will have full liberty in coding, compiling, and linking the
> front end (first) library. And I can modify ld.so if that is needed.
>
> Has anyone already done anything like this, or have in suggestions on how
> I should pursue it (other that giving up)?
>
> What is this for?
>
> Just promise that you won't suggest alternatives. I hate when people do
> that. I'm specifically asking in this post how to do library front ending
> and not the broader question of how to do the following. And I do not
> want to patch existing libraries. I know I can, but I have reasons for
> not wanting to do it that way, and the reason for not saying what that is,
> is because to do so will result in a long and pointless thread that will
> do nothing but waste time and bandwidth.
>
> 1. Change the behaviour of readdir() to return filenames in sorted order.
>
> 2. Change lots of file I/O functions to perform pathname remapping.
>
> 3. Change defaults on how certain system functions are called for some
> programs.
>
> --
> -----------------------------------------------------------------
> | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
> | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
> -----------------------------------------------------------------
------------------------------
From: Joe Bob <[EMAIL PROTECTED]>
Subject: Re: front ending libraries (even libc)
Date: Fri, 22 Dec 2000 05:34:49 GMT
[EMAIL PROTECTED] wrote:
> I'm starting to take a look at what might be needed to do library front
> ending. What I mean by that term is this. An existing library, such as
> libc, will have a complete set of its own functions. The front ending
> library will have a subset of the functions (possibly just a few, maybe
> even just one). I want to have, AT RUN TIME, for the front end library
> to be preferred over the back end library for dynamic linkage. If the
> symbol is defined in the first library found, use that. But if it is
> found not in the first, but in the second, use that. There needs to be
> not conflict with respect to the fact that the second library also has
> the same symbols found in the first. I'm thinking of the first library
> as a sort of mask layed over the second, hiding some symbols and having
> its own versions of them instead.
I just had the occaision to do this today. My goal was to override a libc
function with my own version.
Just write your replacement function (namespace, returns and arg casting the
same!). Link it into your own shared
library. Set the LD_PRELOAD variable at run time; export
LD_PRELOAD=/usr/local/lib/libspecial.so. Then
start your app. Its just that easy. You can confirm that your dynamic
library is getting used by doing a "ldd" on your
binary.
This is a great way to instrument precompiled binarys!
Although its true that you can "just rebuild glibc", it takes _hours_ on
anything but fast SMP machines.
Adio,
Jay
>
> The above I think is easy. Here's where it get's tricky.
>
> The first library needs to be able to call the second library, even with
> symbols the first library is exporting to the programs being linked to it.
>
> And this needs to be done with no recompiling or relinking of either the
> second library or the program being run to use them. I will be root if
> I am going to specify anything on LD_LIBRARY_PATH, and usually will be
> configuring all this via ld.so.conf, so security for suid programs is not
> an issue. I will have full liberty in coding, compiling, and linking the
> front end (first) library. And I can modify ld.so if that is needed.
>
> Has anyone already done anything like this, or have in suggestions on how
> I should pursue it (other that giving up)?
>
> What is this for?
>
> Just promise that you won't suggest alternatives. I hate when people do
> that. I'm specifically asking in this post how to do library front ending
> and not the broader question of how to do the following. And I do not
> want to patch existing libraries. I know I can, but I have reasons for
> not wanting to do it that way, and the reason for not saying what that is,
> is because to do so will result in a long and pointless thread that will
> do nothing but waste time and bandwidth.
>
> 1. Change the behaviour of readdir() to return filenames in sorted order.
>
> 2. Change lots of file I/O functions to perform pathname remapping.
>
> 3. Change defaults on how certain system functions are called for some
> programs.
>
> --
> -----------------------------------------------------------------
> | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
> | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
> -----------------------------------------------------------------
------------------------------
From: Joe Bob <[EMAIL PROTECTED]>
Subject: Re: front ending libraries (even libc)
Date: Fri, 22 Dec 2000 05:35:11 GMT
[EMAIL PROTECTED] wrote:
> I'm starting to take a look at what might be needed to do library front
> ending. What I mean by that term is this. An existing library, such as
> libc, will have a complete set of its own functions. The front ending
> library will have a subset of the functions (possibly just a few, maybe
> even just one). I want to have, AT RUN TIME, for the front end library
> to be preferred over the back end library for dynamic linkage. If the
> symbol is defined in the first library found, use that. But if it is
> found not in the first, but in the second, use that. There needs to be
> not conflict with respect to the fact that the second library also has
> the same symbols found in the first. I'm thinking of the first library
> as a sort of mask layed over the second, hiding some symbols and having
> its own versions of them instead.
I just had the occaision to do this today. My goal was to override a libc
function with my own version.
Just write your replacement function (namespace, returns and arg casting the
same!). Link it into your own shared
library. Set the LD_PRELOAD variable at run time; export
LD_PRELOAD=/usr/local/lib/libspecial.so. Then
start your app. Its just that easy. You can confirm that your dynamic
library is getting used by doing a "ldd" on your
binary.
This is a great way to instrument precompiled binarys!
Although its true that you can "just rebuild glibc", it takes _hours_ on
anything but fast SMP machines.
Adio,
Jay
>
> The above I think is easy. Here's where it get's tricky.
>
> The first library needs to be able to call the second library, even with
> symbols the first library is exporting to the programs being linked to it.
>
> And this needs to be done with no recompiling or relinking of either the
> second library or the program being run to use them. I will be root if
> I am going to specify anything on LD_LIBRARY_PATH, and usually will be
> configuring all this via ld.so.conf, so security for suid programs is not
> an issue. I will have full liberty in coding, compiling, and linking the
> front end (first) library. And I can modify ld.so if that is needed.
>
> Has anyone already done anything like this, or have in suggestions on how
> I should pursue it (other that giving up)?
>
> What is this for?
>
> Just promise that you won't suggest alternatives. I hate when people do
> that. I'm specifically asking in this post how to do library front ending
> and not the broader question of how to do the following. And I do not
> want to patch existing libraries. I know I can, but I have reasons for
> not wanting to do it that way, and the reason for not saying what that is,
> is because to do so will result in a long and pointless thread that will
> do nothing but waste time and bandwidth.
>
> 1. Change the behaviour of readdir() to return filenames in sorted order.
>
> 2. Change lots of file I/O functions to perform pathname remapping.
>
> 3. Change defaults on how certain system functions are called for some
> programs.
>
> --
> -----------------------------------------------------------------
> | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
> | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
