Linux-Development-Sys Digest #743, Volume #7 Wed, 5 Apr 00 12:13:24 EDT
Contents:
Re: To core or not to core - You tell me (Bertie Dastard)
Re: How compatible is Linux with .. Linux ("Peter T. Breuer")
Re: How compatible is Linux with .. Linux ("Peter T. Breuer")
Re: Rubini's device driver example (Martin Gruber)
block device development (Master of the system)
Re: block device development ("Peter T. Breuer")
Re: SMP Hang, please help (Bryan)
Re: To core or not to core - You tell me (Phil Edwards)
Re: To core or not to core - You tell me (Phil Edwards)
Kernel module autoloading problem (Thomas Huber)
Re: To core or not to core - You tell me (Dan Mercer)
To core or not to core - You tell me (Harish K Chandraia)
Re: porting WIN32 to UNIX (Linux) (Kaz Kylheku)
To core or not to core - Part 2 (Harish K Chandraia)
Re: How compatible is Linux with .. Linux (Moritz Franosch)
Resetting system I/O buffers? (Robert Cox)
PCI configuration space fun. ("Daniel J. Feren")
Re: To core or not to core - Part 2 (Kaz Kylheku)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bertie Dastard)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 05 Apr 2000 10:15:11 GMT
On 4 Apr 2000 15:23:19 GMT, [EMAIL PROTECTED] (Harish K Chandraia)
wrote:
>Hi All,
>
> I hope that somebody can tell me what is going on here. I
>have the following C program
>
>#include <stdio.h>
>
>int main()
>{
> struct def
> {
> int a;
> };
>
> struct def *ptr;
>
> ptr = NULL;
>
> printf("%d\n", ptr->a);
>}
>
>
> From all that you know about programming what do you think should
>happen when I try to compile and execute the above program. I have executed
>this piece of code on the following four machines(posting about my
>results will follow). I am not trying to be a smart ass here but I am
>only interested in knowing what you people think would happen because
>what I thought would happen didn't happen on two of the four machines.
>
>1. (samwise)# uname -a
>unix samwise 5.3 1.0 mc68060
>
>2. # uname -a
>NonStop-UX leonard 4.2MP C51IPM74.puma.0414.01:12 S5000 mips
>
>3. hercules23> uname -a
>SunOS hercules23 5.5.1 Generic_103640-24 sun4u sparc SUNW,Ultra-60
>
>4. icarus# uname -a
>SunOS icarus.cc.uic.edu 5.7 Generic_106541-10 sun4u sparc SUNW,
> Ultra-Enterprise
>
>
>Thank you
>Harish
You dereference a NULL pointer. Therefore anything could happen.
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 5 Apr 2000 10:46:38 GMT
In comp.os.linux.development.system Diego Berge <[EMAIL PROTECTED]> wrote:
: On 2 Apr 2000 17:39:42 GMT, "Peter T. Breuer" <[EMAIL PROTECTED]>
: wrote:
:>In comp.os.linux.development.apps q_49@hot###mail.com wrote:
:[ptb]
:>What world do you live in? Producing software is a technically
:>difficult task. It requires technical expertise, not politeness and
:>good manners!
: You're not 'producing software' here. You're participating in a
: public discussion forum.
Errr ... you are in the wrong cubicle. I am producing software, and
responding to a question about deploying some unknown software on
the discussion group for development of that system. You are
participating in a random public forum!
Time for coffee.
Peter
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 5 Apr 2000 10:54:35 GMT
In comp.os.linux.development.system Diego Berge <[EMAIL PROTECTED]> wrote:
: On 03 Apr 2000 14:08:12 +0200, Moritz Franosch
: <[EMAIL PROTECTED]> wrote:
[oops, probably author lost]
:>You should perhaps first try to link your program dynamically against
:>the customer's libraries. If that fails (check the output of 'ldd -r',
:>this prevents issues 1. and 2.), your installation routine should
:>install your versions of the dynamic libraries.
:>Because of 3., advanced customers should also have the choice between
:>your and their own versions of dynamic libraries. E.g. an update of
:>glibc may be necessary because of a change in the kernel while it's
:>necessary for all other libraries to link against the original ones
:>because of 1. or 2.
: ok, but then doesn't it end up being like w/ windows DLL's, where
: new apps upgrade old DLL's and along the way break those old apps
Minor version upgrades cannot break old apps (by definition, and in
theory). Your apps link according to the major version number for good
reason! If an app breaks becuase of a minor level minor increment, then
it is the apps bug, not the libraries. Unless it is the libraries, of
course, which will cause another minor library revision :-).
: using the old DLL's? Another not-so-good solution could be being able
: to access more than one version of the same library, no?
If the library is compatible, it will have a compatible minor
increment, else it will have an incompatible base version name
(unless you are redhat, or a c++ compiler).
Yes, they can distribute their own libraries for private use by means
of LD_LIBRARY_PATH. This is not a good idea. It would be best for them
to use the package formats to define the minimum revision levels they
require.
In any case, the major problem is not binaries. It is configuration
files, placement policies, and security and resource management
policies (permissions, groups, ..). Is this package going in /opt
or /usr/local? Is its configuration file going in /etc, /opt/etc
or /usr/local/etc? Is it going to use /var/lock, or /usr/spool/uucp?
Peter
------------------------------
From: [EMAIL PROTECTED] (Martin Gruber)
Subject: Re: Rubini's device driver example
Date: Wed, 5 Apr 2000 12:41:54 +0200
[Posted and mailed]
In article <[EMAIL PROTECTED]>,
Girish Chandraiah <[EMAIL PROTECTED]> writes:
> I thought this might help some newbie's like myself. As suggested by one of the
>replies
> to the original posting, printk outputs did apprear in the /var/log/messages
> xterm -C didn't seem to help. Thanks to those who responded.
Maybe a hint: In SuSE the klogd is started by default with -c 1 which
means just to print error messages (check out "ps axu"). You can change
the default value in SuSE by changeing KERNEL_LOGLEVEL in the rc.config
file to 7 (Debug Level).
You should then use printk(KERN_DEBUG"Hello World!\n"); and check the
/var/log/messages file for the entry.
bye
Martin
------------------------------
Date: Wed, 05 Apr 2000 15:26:05 +0200
From: Master of the system <[EMAIL PROTECTED]>
Subject: block device development
Hi everybody,
I'm looking for manuals, books, links, tutorials about how to write a
block device.
"Linux Device Drivers" from O'Reilly seems not to be very up to date
(The book is centered on version 2.0, but also covers 1.2.13 and
experimental versions up to 2.1.43.)
I wanna program for the next kernel 2.4 so work with 2.39.
Can anybody help?
Thanks in advance
Andreas Fleuti
e_mail: afleutiATiiic.ethz.ch (simply replace AT by @ [to prevent spam])
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: block device development
Date: 5 Apr 2000 13:30:50 GMT
Master of the system <[EMAIL PROTECTED]> wrote:
: Hi everybody,
: I'm looking for manuals, books, links, tutorials about how to write a
: block device.
: "Linux Device Drivers" from O'Reilly seems not to be very up to date
: (The book is centered on version 2.0, but also covers 1.2.13 and
: experimental versions up to 2.1.43.)
: I wanna program for the next kernel 2.4 so work with 2.39.
: Can anybody help?
Use the book and make mods as necessary. Or wait for the next edition!
There are porting docs on the web. I'd search for linux+drivers+porting.
Peter
------------------------------
From: Bryan <[EMAIL PROTECTED]>
Subject: Re: SMP Hang, please help
Crossposted-To: alt.os.linux
Date: Wed, 05 Apr 2000 14:27:50 GMT
In comp.os.linux.development.system ravi Venkat <[EMAIL PROTECTED]> wrote:
: Bryan wrote:
: > is your motherboard chip (bx, I'm assuming) very hot? I'd look to that first.
: >
: > In comp.os.linux.development.system ravi Venkat <[EMAIL PROTECTED]> wrote:
: > : Hello all,
: >
: > : We are facing a hard hang on 2.2.14 SMP kernel (red hat) while doing
: > : heavy
: > : multi-threaded i/o using a software raid driver.
: I can't possibly tell, I am not supposed to open the machine... Lab dudes will
: kick me (or
: worst case will kill me for that...) But if we are spinning on the cpu, my guess
: would be
: Yes, the chip would be hot as a frying pan
if you need SERIOUS and reliable SMP, my advice is to dump the
consumer crap (BX) and go GX or some other alternative. all wisdom
that I've encountered shows that the BX was never meant to be run at
extremes. or it was meant to be, but just can't hack it. its 'only
intel hardware' afterall - what do you expect; SGI or SUN hardware
quality? sheesh! ;-)
--
Bryan, http://Grateful.Net (ANTISPAM: email is my name at my web's domain)
(c) 2000. Publishing and/or relaying of this material on all forums other than
USENET implies agreeing to a consultancy fee of US$150 per posting. You must
obtain a written permit before you publish. Violators are subject to civil
prosecution for Copyright Infringement as applicable. Publication by C|NET
and Microsoft Networks expressly prohibited.
------------------------------
From: [EMAIL PROTECTED] (Phil Edwards)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: 5 Apr 2000 10:29:17 -0400
Alan Coopersmith <[EMAIL PROTECTED]> wrote:
+ Warren Young <[EMAIL PROTECTED]> wrote:
+ >Phil Edwards wrote:
+ >>
+ >> (all schools are always strapped for diskspace :-). They figure, if you
+ >> need a core file, you can re-enable it yourself.
+ >
+ >Not on any system I've ever used. ulimit, at least, cannot _raise_
+ >limits, it can only lower them. (For regular users only, of course.
+
+ Really? On every system I've used, regular users can raise their soft
+ limits up to the hard limit, which is why we usually set the softlimit
+ to 0 for cores, but leave the hardlimit unlimited so the users can turn
+ them back on when they want to debug.
Yep, exactly what I meant by "re-enable it yourself". The skeleton
login files distributed with a new account set the softlimit to zero; the
debugging student can either comment it out or just raise it one time on
the command line.
The only hardlimit I recall from my student days was on the CPU time, for
the generic university-wide "you only need to have a detectable pulse to
get an account" systems. There were a lot of students (and faculty, and
staff) that didn't have much more than a detectable pulse when it came to
using a computer, so the limit was needed to prevent thousands of copies
of Netscrape running by the same user for hours on end, etc, etc.
Phil
--
philip.edwards@{,sn.}wpafb.af.mil
Targeting & Attack Radar PGP ID UFOs are real.
U.S. Air Force Research Labs 0xDBABC04F The Air Force
Senior Unix Systems Administrator doesn't exist.
------------------------------
From: [EMAIL PROTECTED] (Phil Edwards)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: 5 Apr 2000 10:34:46 -0400
Richard L. Hamilton <[EMAIL PROTECTED]> wrote:
+ On Suns, dereferencing a NULL pointer is normally illegal, and will segv
+ you.
+
+ A trick I saw somewhere is to use an available but apparently undocumented
+ workaround (and of course fix your code ASAP): set LD_PRELOAD to
+ [EMAIL PROTECTED], which will provide a zero at address zero to make
+ clueless programs happy.
For the record: this is documented in ld.so.1(1)...
# NOTES
# The user compatibility library [EMAIL PROTECTED] provides a
# mechanism that establishes a value of 0 at location 0. Some
# applications exist that erroneously assume a null character
# pointer should be treated the same as a pointer to a null
# string. A segmentation violation will occur in these appli-
# cations when a null character pointer is accessed. If this
# library is added to such an application at runtime using
# LD_PRELOAD, it provides an environment that is sympathetic
# to this errant behavior. However, the user compatibility
# library is intended neither to enable the generation of
# such applications, nor to endorse this particular program-
# ming practice.
...but nowhere else that I've ever seen. Maybe the AnswerBook2 stuff?
Phil
--
philip.edwards@{,sn.}wpafb.af.mil
Targeting & Attack Radar PGP ID UFOs are real.
U.S. Air Force Research Labs 0xDBABC04F The Air Force
Senior Unix Systems Administrator doesn't exist.
------------------------------
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Thomas Huber)
Subject: Kernel module autoloading problem
Date: 5 Apr 2000 16:40:55 +0100
I ran into the following catch-22: I have compiled
ppp as modules in kernel-2.3.99-pre3 (ppp_async). In
modules.conf I added an entry 'alias ppp ppp_async'.
When I now start pppd (2.3.11) for the first time, it
complains that there's no ppp support in the kernel and
exits immediately.
However, the modules (ppp_async, ppp_generic) are
loaded in this first starting attempt. I then have to
start pppd a second time (modules already loaded), and
it works.
But of course that's not what I want. Pppd should not fail
before the kernel tried to load the module.
Any tips ? Is the bug in pppd or in the kernel ?
Thomas
------------------------------
From: [EMAIL PROTECTED] (Dan Mercer)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: 5 Apr 2000 14:33:17 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Richard Bos) writes:
> [EMAIL PROTECTED] (Harish K Chandraia) wrote:
>
>> #include <stdio.h>
>>
>> int main()
>> {
>> struct def
>> {
>> int a;
>> };
>>
>> struct def *ptr;
>>
>> ptr = NULL;
>>
>> printf("%d\n", ptr->a);
>> }
>>
>>
>> From all that you know about programming what do you think should
>> happen when I try to compile and execute the above program.
>
> Nobody knows. You're dereferencing a NULL pointer; that means undefined
> behaviour, and that means anything can happen. If your compiler thinks
> it should print something, that's OK. If he thinks it should segfault,
> that's OK. If it thinks it should email your boss with a request for
> wild sex in the cloak room at eleven, that's... maybe not OK, but
> certainly allowable as far as the ISO C standard is concerned. In short,
> nobody can tell unless they know something about your compiler they
> shouldn't need to know.
>
> Richard
I wrote a curses like terminal program on NCR SVR1. I thought printf
was cool cause if I passed a null pointer to it, it didn't print
anything, which was real convenient. Of course, the program space
merely had a null byte at location 0. When we upgrade to SVR2, all
hell broke loose. The program space now had an escape at location 0
and random chars thereafter, so every place I printed a null pointer
we got a random escape sequence sent to the terminal, with predictably
unpredictable results. Oops!
--
Dan Mercer
[EMAIL PROTECTED]
Opinions expressed herein are my own and may not represent those of my employer.
------------------------------
From: [EMAIL PROTECTED] (Harish K Chandraia)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.unix.programmer
Subject: To core or not to core - You tell me
Date: 5 Apr 2000 15:01:20 GMT
Hi All,
Thank you for all replies. I expected a segmentation fault and
thanks for pointing out that segmentation fault need not mean
that I will end up with a core image.
On the Sun OS, it always had segmentation fault and there was no core
file. On a tandem machine running
NonStop-UX leonard 4.2MP C51IPM74.puma.0414.01:12 S5000 mips, I ended
up with 0 being printed out always and on the first machine, I always
ended with a large number.......599785536. Somebody mentioned that I
might not get the same results on the same machine when I run the
program but the behaviour of the machines have been consistent.
It's also true as someone mentioned that things were fine as long as
I was just accessing ptr->a but as soon as I try to write something
into ptr->a, then all the platforms behaved in the same manner.....
segv occured.
Isn't there any standard which says how such situations should be
handled?. Does ANSI address things like this? Thank you all once
again for u'r responses and time.
Harish
In article <8cd1d7$vkl$[EMAIL PROTECTED]> you wrote:
: Hi All,
:
: I hope that somebody can tell me what is going on here. I
: have the following C program
:
: #include <stdio.h>
:
: int main()
: {
: struct def
: {
: int a;
: };
:
: struct def *ptr;
:
: ptr = NULL;
:
: printf("%d\n", ptr->a);
: }
:
:
: From all that you know about programming what do you think should
: happen when I try to compile and execute the above program. I have executed
: this piece of code on the following four machines(posting about my
: results will follow). I am not trying to be a smart ass here but I am
: only interested in knowing what you people think would happen because
: what I thought would happen didn't happen on two of the four machines.
:
: 1. (samwise)# uname -a
: unix samwise 5.3 1.0 mc68060
:
: 2. # uname -a
: NonStop-UX leonard 4.2MP C51IPM74.puma.0414.01:12 S5000 mips
:
: 3. hercules23> uname -a
: SunOS hercules23 5.5.1 Generic_103640-24 sun4u sparc SUNW,Ultra-60
:
: 4. icarus# uname -a
: SunOS icarus.cc.uic.edu 5.7 Generic_106541-10 sun4u sparc SUNW,
: Ultra-Enterprise
: Thank you
: Harish
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.development,comp.os.ms-windows.programmer.win32,comp.os.ms-windows.programmer.misc,comp.unix.programmer,comp.programming
Subject: Re: porting WIN32 to UNIX (Linux)
Reply-To: [EMAIL PROTECTED]
Date: Wed, 05 Apr 2000 15:20:44 GMT
On Wed, 05 Apr 2000 19:27:47 +1000, Jussi Jumppanen <[EMAIL PROTECTED]> wrote:
>Johannes Hacker wrote:
>
>> I am currently working on a project where I have to port a WinNT
>> Application to Linux. I am mainly focused on threads, processes,
>> synchronization and messaging between processes.
>
>I would suggest taking a look at Wine web page:
>
> www.winehq.com
>
>This is an Open Source project that is attempting to have windows
>programs (and the Win32 API) running on linux and so far they have
>done a wonderful job.
Forget it; if you are going to develop for Linux, do a real port. Wine is for
running binary windows EXE's. It's undesirable compared to having a ``native''
Linux app.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Harish K Chandraia)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.unix.questions,comp.unix.programmer
Subject: To core or not to core - Part 2
Date: 5 Apr 2000 15:31:20 GMT
Hi All,
While we are at it.....I wanted to mention another thing which
is beyond me....hope somebody can shed some light on it.
Have any of you experienced this.....you have a program which
core dumps....and you put in additional printf's and compile with
DEBUG defined in your Makefile and all of a sudden it stops core
dumping on you. What could be the reason for something like this to
happen.
A little background on what is happening in the program that
I am working on....an attempt is made to dereference a -ve number in
a function which is currently not checking to see if a NULL is being
passed to it and always assumes that a +ve value is being passed in as
the argument and it substracts some number from the argument and since
NULL is being passed, the computation ends up being a -ve number and
understandoubly core dumps but with DEBUG defined, it just stops doing
that for the same conditions.
Using adb, I know the exact point of failure and I even know that
a NULL is being passed in as an argument to the function but with a printf
/sprintf just before the function call(to which NULL is being passed) it
just doesn't happen anymore. Any thoughts.....
Thank you all for your time and thoughts.
Regards,
Harish
------------------------------
From: Moritz Franosch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 05 Apr 2000 17:47:10 +0200
[EMAIL PROTECTED] (Diego Berge) writes:
> ok, but then doesn't it end up being like w/ windows DLL's, where
> new apps upgrade old DLL's and along the way break those old apps
> using the old DLL's?
Oh no, an installation program should install only in its own
directory (/usr/local/something) and never touch any other files
without asking the user.
> Another not-so-good solution could be being able
> to access more than one version of the same library, no?
That's exactly what I meant. The installation program could install
his own versions of the libraries in /usr/local/something/lib. The
program itself then sets LD_LIBRARY_PATH (man ld.so) accordingly in
its startup script.
Moritz
------------------------------
From: [EMAIL PROTECTED] (Robert Cox)
Subject: Resetting system I/O buffers?
Date: 5 Apr 2000 15:44:56 GMT
Is there a (hopefully easy) way to flush the system I/O buffers
(as shown in "free") so that they are empty? I'd like to time
the input of a large file when I run some program. The first
time I run it, I get a good idea of how long it takes to actually
read the file into memory. After that, the time is bogus.
thanks - bob cox
------------------------------
From: "Daniel J. Feren" <[EMAIL PROTECTED]>
Subject: PCI configuration space fun.
Date: Wed, 05 Apr 2000 11:50:38 -0400
Has anyone written a user-level (not kernel-level)
device driver that can write to a PCI bus card's
configuration space? I'm refering to the unused
configuration space above 64 bytes.
I've tried to use some functions similar to those
in usr/include/linux/pci. Specifically, I've tried
using pci_write_block, but I when I check the
pci bus with another application that dumps
all the configuration space of all devices the
changes aren't there. Its seems pci_write_block
only writes to the structure and not to the actual
pci device's configuration space. Rigtht?
Is there a way to lock the contents of
the structure pci_device to the device?
If anyone has done something like above,
how, with what function, and are there any links
to source code that you know of?
This is for research and not for a school assignment.
Any ideas or suggestions would be appreciated.
--
Daniel James Feren
[EMAIL PROTECTED]
Georgia Institute of Technology, Computer Engineering
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.unix.questions,comp.unix.programmer
Subject: Re: To core or not to core - Part 2
Reply-To: [EMAIL PROTECTED]
Date: Wed, 05 Apr 2000 15:58:11 GMT
On 5 Apr 2000 15:31:20 GMT, Harish K Chandraia <[EMAIL PROTECTED]> wrote:
>Hi All,
>
> While we are at it.....I wanted to mention another thing which
>is beyond me....hope somebody can shed some light on it.
>
> Have any of you experienced this.....you have a program which
>core dumps....and you put in additional printf's and compile with
>DEBUG defined in your Makefile and all of a sudden it stops core
>dumping on you. What could be the reason for something like this to
>happen.
The causes could be:
---race conditions in the program which are perturbed by the extra I/O
introduced by the debug expressions; (obviously, single threaded programs
will rarely exhibit this kind of thing, unless it's a race against some
external event.)
---various types of undefined behavior such as the use of uninitialized
automatic data. On many compilers, local variables are mapped to stack
storage, or registers. The extra calls perturb the stack storage or
the contents of registers, so the undefined behavior of the use of
uninitialized objects can be perturbed.
---a compiler bug.
I just fixed a bug which would only appear in an optimized build of some
software without any trace diagnostics. What's worse, it only happened on a
Windows CE MIPS platform, on which multi-threaded programs just disappear when
they crash. So I cobbed together a crash dump tool that would intercept the
exception and dump the registers, stack backtrace, instruction bytes, etc. It
turned out to be due to some perverse bug in Microsoft's MIPS compiler. I
rephrased one correct expression in a trivial way and the crash disappeared.
> Using adb, I know the exact point of failure and I even know that
>a NULL is being passed in as an argument to the function but with a printf
>/sprintf just before the function call(to which NULL is being passed) it
>just doesn't happen anymore. Any thoughts.....
It really looks like some other bug. Given that it was written by someone who
thinks that pointers are just numbers, I'd keep looking for more bugs. :)
If calling sprintf before calling that function changes its behavior, it
looks like it may be depending on uninitialized automatic storage.
--
#exclude <windows.h>
------------------------------
** 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
******************************
