Linux-Development-Sys Digest #844, Volume #7 Thu, 11 May 00 03:13:16 EDT
Contents:
Problems with serial communication (Jens Kristian S�gaard)
Re: Problems with serial communication (Kaz Kylheku)
Re: Possible Kernel Bug? (Matthias Kleinmann)
routing cache? (Weiguang Shi)
Re: LILO Win+Linux on an old system (Paul D. Smith)
Linux response time ("Ling Su")
Re: Two really easy (I'm sure) questions (Andreas Rottmann)
Re: Two really easy (I'm sure) questions (Erik Max Francis)
Re: libpath to shared objectws (Paul Kimoto)
Re: Object oriented OS (?) ("Maxim S. Shatskih")
Re: Linux response time (Christopher Browne)
Re: Two really easy (I'm sure) questions (Kaz Kylheku)
Re: Object oriented OS (?) (Kaz Kylheku)
Re: boot messages ("duan")
Re: Linux response time (Graham Stoney)
Re: LILO Win+Linux on an old system (Josef Moellers)
Re: Need to find my IP address (Chris)
Re: Possible Kernel Bug? (Ulrich Eckhardt)
Re: binary compression -- good or bad? (Josef Moellers)
Re: Linux response time (Thomas Reinemann)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jens Kristian S�gaard)
Subject: Problems with serial communication
Date: 11 May 2000 00:28:06 +0200
Hi all,
I'm programming a system in C on the Linux platform, where I need to
keep track of the two serial (com) ports at one time. I use standard
open()/read()/write()/select() calls, but it seem to have some speed
issues.
It is as if the modem delivers the data too fast, and the first 4-8
bytes of a line completely "disappears". This doesn't happen all the
time, but only sometimes (which makes it very hard to debug).
The hardware is only a 386 40 mhz, which ofcourse means it has to be
fast.
I initialize the port like this:
struct termios tio;
int arg=1;
tio.c_cflag = SMS_BAUD | CRTSCTS | CS8 | CREAD | CLOCAL;
tio.c_iflag = IGNPAR | ICRNL | IXON | IXOFF;
tio.c_oflag = 0;
tio.c_lflag = ICANON | FLUSHO;
tio.c_cc[VMIN] = 0;
tio.c_cc[VTIME] = 1;
tcflush( fdSMS, TCIFLUSH );
tcsetattr( fdSMS, TCSANOW, &tio );
if( ioctl( fdSMS, TIOCSSOFTCAR, &arg ) )
printf( "Couldn't set software carrier!\n" );
And write a command like this:
sprintf( buf, "AT+CMGL=\"ALL\"\r" );
write( fdSMS, buf, strlen( buf ) );
And then read the output with this function.
char *inputBuffer = malloc( 1024 ), *tmp, c;
int count=0, res, retry=0;
fd_set readfs;
struct timeval Timeout;
FD_SET( fd, &readfs );
Timeout.tv_usec = 0;
Timeout.tv_sec = 2;
if( (res = select( fd+1, &readfs, NULL, NULL, &Timeout )) == 0 ) {
inputBuffer[count] = '\0';
return inputBuffer;
}
igen:
retry++;
while( ((res = read( fd, &c, 1) > 0)) && (count<1023) && (c != '\n') )
inputBuffer[count++] = c;
if( retry > 3 ) { /* was 25 */
inputBuffer[count] = '\0';
return inputBuffer;
}
if( res == 0 ) {
FD_SET( fd, &readfs );
Timeout.tv_usec = 0;
Timeout.tv_sec = 2;
if( (res = select( fd+1, &readfs, NULL, NULL, &Timeout )) != 0 )
goto igen;
}
inputBuffer[count] = '\0';
return( inputBuffer );
Anyone got suggestions?
Thanks for your answers!!!!
--
Jens Kristian S�gaard,
[EMAIL PROTECTED] -- http://www.jksoegaard.dk/
S�ger du noget? -- http://www.google.com/
echo|perl -ple'$_+=4E-6*!int rand()**2+rand()**2while$i++-1E6'
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Problems with serial communication
Reply-To: [EMAIL PROTECTED]
Date: Wed, 10 May 2000 23:25:53 GMT
On 11 May 2000 00:28:06 +0200, Jens Kristian S�gaard <[EMAIL PROTECTED]> wrote:
>The hardware is only a 386 40 mhz, which ofcourse means it has to be
>fast.
>
>I initialize the port like this:
>
> struct termios tio;
> int arg=1;
>
> tio.c_cflag = SMS_BAUD | CRTSCTS | CS8 | CREAD | CLOCAL;
> tio.c_iflag = IGNPAR | ICRNL | IXON | IXOFF;
> tio.c_oflag = 0;
> tio.c_lflag = ICANON | FLUSHO;
Hmm, the flag to set up CTS/RTS handshaking is conspicuously absent.
> while( ((res = read( fd, &c, 1) > 0)) && (count<1023) && (c != '\n') )
> inputBuffer[count++] = c;
Issuing a system call for each input character is horribly inefficient. This
approach is utterly incompatible with your requirement for high performance.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Matthias Kleinmann)
Subject: Re: Possible Kernel Bug?
Date: 10 May 2000 23:23:49 GMT
On Wed, 10 May 2000 20:53:59 GMT, Joe Ceklosky <[EMAIL PROTECTED]> wrote:
[...]
>To set up the test:
> -contiunously build the kernel over and over
> -run top with a refresh of 1
> -continuously dd if=/dev/sdaX of=/dev/null bs=1024 count=600000
>
>After this runs for a while (even quick sometimes) the machine will
>hang, but it's a funny hang, it's not locked up 100%
>
>Everything that was running continues to run, but anything
>looking for disk I/O will be stuck in a D status using ps.
>All I/O will be hung, but top continues to run fine. This
>will of course drive the load on the machine to like 50.
[...]
Did you try to
-^C or to run an cron job that kills the pids or something like that?
-use a higher nice level (this should work)
Do you have swap enabled? (disable it if you have 128MB and no real need for it)
btw: if you dont use ulimit something like
#include <unistd.h>
int main()
{while(fork())for(long i=1;i>0;i++);}
or so does the job as well.
Matthias
ps:a simular "bug" in XFree is now fixed in XFree 4.0
------------------------------
From: Weiguang Shi <[EMAIL PROTECTED]>
Subject: routing cache?
Date: Wed, 10 May 2000 17:26:39 -0600
Hi, there:
I was looking at the routing code in Kernel version 2.2.13. It seemed to
me that the routing cache is an array of pointers that could lead to a
list of arbitrarily long. In the extreme case, this will make a route
lookup time longer than retrieving it directly from the FIB.
Could you please shed some light on this?
Thanks.
Weiguang
Weiguang Shi | E-mail: [EMAIL PROTECTED]
Department of Computing Science | http://www.cs.ualberta.ca/~wgshi
University of Alberta | Office: CAB 481
Edmonton, AB, Canada, T6G 2H1 | (O) (780)492-3927
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: LILO Win+Linux on an old system
Date: 10 May 2000 19:54:04 -0400
Reply-To: [EMAIL PROTECTED]
%% "Eric Keller" <[EMAIL PROTECTED]> writes:
ek> Paul D. Smith wrote
>> I put W98SE on the 1G drive as the master on IDE1 (I need both at least
>> initially, since I need Windows so the cablemodem guys are happy).
ek> W98 wants to put a fat32 file system on anything bigger than 512 mbytes.
I used FAT16. However, that's not the problem: I don't even get to a
LILO boot prompt, so there's no way it can be interacting with the
Windows partition AFAICS.
ek> You will be so much better off if you use fat16. Then you can put
ek> lilo on the mbr. I have found win98 doesn't mess with the mbr
ek> unless you tell it, which can be a pain. My experience with
ek> redhat 6.1 on a winnt machine is that the install will insinuate
ek> that you can put lilo on any disk, but then you kill everything if
ek> it isn't the right kinda file system.
I'm not exactly sure what you're trying to say here, but as I said, it
can't be a problem with the Windows filesystem since I'm not able to get
past the "LI" in the boot sequence.
ek> Hope i'm not totally off base. Are you using a generic install,
ek> or is it possible your kernal doesn't like your computer?
Kernel works fine; as I mentioned, it boots great from floppy with
"linux root=/dev/hdb1".
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: "Ling Su" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.embedded
Subject: Linux response time
Date: Wed, 10 May 2000 17:37:02 -0700
Reply-To: "Ling Su" <[EMAIL PROTECTED]>
Hi,
I have a simple question on the system response time for general Linux with
a high preformance processor(like Pentium III 800MHz). How about the
improvement with the RT-Linux extension?
Thanks
-Ling
------------------------------
From: Andreas Rottmann <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Two really easy (I'm sure) questions
Date: 11 May 2000 02:47:48 +0200
[EMAIL PROTECTED] (Mike McDonald) writes:
> In article <[EMAIL PROTECTED]>,
> Erik Max Francis <[EMAIL PROTECTED]> writes:
> > Mario Klebsch wrote:
> >
> >> Do you say, that calling exit() will result in undefined behavior? I
> >> know, it works on the systems, I use, and I can accept, that it works
> >> only by accident, but pleaye explain, why the behavoir is undefined?
> >
> > "Undefined behavior" means ...
>
> We understand what "undefined behavior" means. We don't understand why
> "exit(0)" is undefined behavior. Is it because ANSI C doesn't defined exit()?
> That it's left to POSIX instead to define?
>
No, exit(0) is ok, but you can't be sure to return a proper exit
status. Use exit(EXIT_SUCCESS) instead.
Andy
--
Andreas Rottmann (Dru@ICQ, 54523380@ICQ)
Pfeilgasse 4-6/725, A-1080 Wien, Austria, Europe
http://www.penguinpowered.com/~andy/
mailto:[EMAIL PROTECTED]
[one of 78,35% Austrians who didn�t vote for Haider!]
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Two really easy (I'm sure) questions
Date: Wed, 10 May 2000 18:10:27 -0700
Andreas Rottmann wrote:
> No, exit(0) is ok, but you can't be sure to return a proper exit
> status. Use exit(EXIT_SUCCESS) instead.
Actually, exit(0) is perfectly good ANSI C (7.10.4.3; "If the value of
`status' is zero or EXIT_SUCCESS ...").
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Light ... more light!
\__/ (the last words of Goethe)
7 sisters productions / http://www.7sisters.com/
Web design for the future.
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: libpath to shared objectws
Date: 10 May 2000 21:22:10 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Jim Tivy wrote:
> I am a newbie to Linux. I need to know how to set a libpath to a bunch
> of shared objects so I can run
> my program that links to them. I cannot get at the etc/ld_so.conf file
> since I don't have permissions. Is there another way.
You can use the LD_LIBRARY_PATH environment variable to specify a list of
directories to search for dynamic libraries. See the ld.so(8) man page.
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: "Maxim S. Shatskih" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.development
Subject: Re: Object oriented OS (?)
Date: Thu, 11 May 2000 03:35:15 +0400
> I don't know. I sort of assumed that was the case because performance
> was so bad :-) (i.e. 55,000 cycles for a same-machine, null-RPC).
Maybe TCP/IP checksums are computed even for loopback? :-)))
> Anyone know how to get null-RPC to improve on (say) Linux?
Linux has pipes, named pipes (UNIX FIFOs, nothing to do with SMB named
pipes), UNIX domain sockets, IP stack and SysV messages. This is all.
I don't think Linux guys will invent some cardinally new IPC - they will
wait till it
will be POSIX...
Max
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.arch.embedded
Subject: Re: Linux response time
Reply-To: [EMAIL PROTECTED]
Date: Thu, 11 May 2000 02:19:01 GMT
Centuries ago, Nostradamus foresaw a time when Ling Su would say:
>I have a simple question on the system response time for general Linux with
>a high preformance processor(like Pentium III 800MHz). How about the
>improvement with the RT-Linux extension?
The RT-Linux extension isn't generally going to improve response times;
it is going to worsen them.
The point to RT is to provide _predictable_ worst-case performance for
some specific processes.
That is not, in general, going to improve performance. Rather, it will
worsen performance in general.
The way that there would be an improvement in performance is in that you
would strip out of the system any spurious processes, leaving in only
the components absolutely necessary for your embedded system.
--
Rules of the Evil Overlord #84. "I will not have captives of one sex
gnuarded by members of the opposite sex."
<http://www.eviloverlord.com/>
[EMAIL PROTECTED] - - <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Two really easy (I'm sure) questions
Reply-To: [EMAIL PROTECTED]
Date: Thu, 11 May 2000 04:40:12 GMT
On 11 May 2000 02:47:48 +0200, Andreas Rottmann <[EMAIL PROTECTED]> wrote:
>No, exit(0) is ok, but you can't be sure to return a proper exit
>status. Use exit(EXIT_SUCCESS) instead.
exit(0) and exit(EXIT_SUCCESS) are equally correct. The standard blesses the
value 0 as a successful termination indicator. It may be passed to exit,
or returned from main.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: alt.os.development
Subject: Re: Object oriented OS (?)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 11 May 2000 04:49:56 GMT
On Wed, 10 May 2000 10:32:10 +0100, Greg Law <[EMAIL PROTECTED]> wrote:
>"Maxim S. Shatskih" wrote:
>>
>> > same-machine RPC going over TCP over loopback to get to another process
>> > (which is what I believe happens if you do it naively on most UNIXes).
>>
>> Are you sure that such RPC will not use UNIX domain sockets?
>
>I don't know. I sort of assumed that was the case because performance
>was so bad :-) (i.e. 55,000 cycles for a same-machine, null-RPC).
>
>Does anyone know what happens here? i.e. On most UNIXes, when you do an
>RPC to a different process on the same machine and you don't do any
>'cleverness', do the messages just go over the loopback interface?
>Anyone know how to get null-RPC to improve on (say) Linux?
Sending TCP over loopback will not go over UNIX domain sockets or any
other short circuit. It will be handled by going all the way down to the
loopback adapter. All the TCP protocol mechanisms are still in place.
To reduce the overhead, don't use TCP.
There aren't a great many applications to which this is important. The obvious
examples may be applications which place their user interfaces from their core
logic into separate processes. X is also an example.
Within the same machine, you have alternatives: UNIX domain sockets, and shared
memory with semaphores for synchronization.
For truly bandwidth intensive communication, shared memory is probably your
best bet.
Ideally, your RPC layer should be able to go over any one of these mechanisms
easily, and transparently to the programmer.
--
#exclude <windows.h>
------------------------------
From: "duan" <[EMAIL PROTECTED]>
Subject: Re: boot messages
Date: Thu, 11 May 2000 11:26:16 +0800
It's easy to disable the kernel messages ,I have done this by changing the
kernel code,
but i'm failed to disable the message of startup daemon(which invoked by
init process).
Sake <[EMAIL PROTECTED]> wrote in message
news:8e5m5j$r2q$[EMAIL PROTECTED]...
> Hi there,
>
> I'm integrating a Linux application box. I don't want the user
> to see those kernel booting messages every time they turn on the
> machine. Is there a way to divert those messages ? Idealy, I would
> like to be able to put up a grafic logo on the screen when the machine
> is booting (I mean before the log-on screen)
>
> e-mail response is greatly appreciated.
>
> Thanks in advance.
>
> [EMAIL PROTECTED]
>
>
>
>
------------------------------
From: Graham Stoney <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.embedded
Subject: Re: Linux response time
Date: 11 May 2000 05:53:53 GMT
In article <8fcusj$bcg$[EMAIL PROTECTED]>,
Ling Su <[EMAIL PROTECTED]> wrote:
>I have a simple question on the system response time for general Linux with
>a high preformance processor(like Pentium III 800MHz).
The question is "simple" only in the sense that it doesn't contain enough
information to answer it meaningfully. Meaningful performance related
questions are complex by definition.
What exactly to you mean by "system response time"? This could mean keystroke
response time, process switch latency, interrupt latency, I/O response time,
or any of a number of other measures which could be labeled "system response
time", depending on the system in question. Once you've worked out what it is
you actually want to measure, an enormous number of variables then impact the
actual value.
You'll need to ask a more specific question to get a meaningful answer.
Regards,
Graham
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: LILO Win+Linux on an old system
Date: Thu, 11 May 2000 08:45:31 +0200
"Paul D. Smith" wrote:
> I'm not exactly sure what you're trying to say here, but as I said, it
> can't be a problem with the Windows filesystem since I'm not able to ge=
t
> past the "LI" in the boot sequence.
Technically speaking, this means that the first "half" of the LILO boot
loader was loaded successfully, but the second "half" wasn't ("half"
because they are not equal in size).
Have you tried
1. to add the keyword "linear" to your /etc/lilo.conf file?
2. to add the disk parameters (C/H/S) to the /etc/lilo.conf file?
I'd suggest you try the first first, it often fixes the problem.
-- =
Josef M=F6llers
Fujitsu Siemens Computers
SHV Server DS 1
------------------------------
From: [EMAIL PROTECTED] (Chris)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: Thu, 11 May 2000 06:50:31 GMT
On 9 May 2000 02:37:53 GMT, [EMAIL PROTECTED] (brian moore) wrote in
comp.os.linux.development.apps:
>Why would you want to specify 'eth0' instead of '10.1.2.3'?
Perhaps I want to read the binding port from a config file when the
program loads but the interface address is controlled by a DHCP client so
the numeric address can't be known in advance.
------------------------------
Date: Thu, 11 May 2000 08:56:25 +0200
From: Ulrich Eckhardt <[EMAIL PROTECTED]>
Subject: Re: Possible Kernel Bug?
Joe Ceklosky wrote:
>
> Hardware:
> MSI 6153 Socket 370 MB
> Intel Celeron 466
> 128 Meg PC 100 DIMM
> Buslogic 958W
> Quantum 9.1 and 4.5G SCSI Wide HD's
>
> Kernel:
> 2.2.14 or 2.2.15
>
> First I have verified that the memory is good in the machine.
> Under kernel compilation I have NEVER seen a SEGV.
>
> To set up the test:
> -contiunously build the kernel over and over
> -run top with a refresh of 1
> -continuously dd if=/dev/sdaX of=/dev/null bs=1024 count=600000
>
> After this runs for a while (even quick sometimes) the machine will
> hang, but it's a funny hang, it's not locked up 100%
>
> Everything that was running continues to run, but anything
> looking for disk I/O will be stuck in a D status using ps.
> All I/O will be hung, but top continues to run fine. This
> will of course drive the load on the machine to like 50.
>
> Another thing, I was once cat'ing /proc/interupts when this happened
> and everything is fine, but the IRQ count on the SCSI card was stuck.
> The light on the scsi card was on of course, but it refuses to handle
> any interrupts. I did not see any timeouts on the scsi bus
> either.
>
> I also changed the SCSI card to an Adaptec 2940UW and saw the same
> problems.
>
> Does anyone have any ideas as to what is going on?
> Is it the motherboard or is this rare kernel bug?
Hi,
i think it's a problem of the SCSI-Bus (Termination ?)
or a problem of your Harddrive.
Check with dmesg if you get SCSI-Error messages (due to
this problems syslogd may not be able to log these messages)
and probably kill syslogd and see, if you get error messages
on the console.
Uli
--
Ulrich Eckhardt Tr@nscom
http://www.uli-eckhardt.de http://www.transcom.de
Lagerstra�e 11-15 A8
64807 Dieburg Germany
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: binary compression -- good or bad?
Date: Thu, 11 May 2000 09:02:57 +0200
Yuzheng Ding wrote:
> =
> I heard the greatness of binary compressors like upx that takes away th=
e fat
> from an executable while having "no memory penalty". On the other hand =
I heard
> that at elast for Windows9x, such compression nullifies code sharing, t=
hus
> suffering heavy memory penalty if you look at the entire picture.
> =
> What's the case with Linux? Would code/data sharing be impacted in any=
ways
> of means? Do unix programs only share the code other than those in
> dynamically linked shared libraries? It seems to me that the sharing of=
> dynamically linked shared libraries should not be impacted as they are =
loaded
> after the program begins (thus after decompression). Did I miss anythin=
g?
I don't know upx, but from what you describe, it works like the kernel
decompression by putting a small decompression code followed by the
compressed binary into a single file and execute the decompression code
when starting the program which, in turn, produces the actual binary.
Linux program code is faulted in, i.e. in theory execution is started
with no code in memory at all. When the CPU tries to execute the first
instruction, the page (usually some 4K) containing the first byte of
that instruction is loaded into memory. Therefore, only those pages are
loaded into memory that are really referenced, i.e. if you only use some
5% of your code, only this 5% is actually loaded into memory.
Using a decompressor will load the entire program into memory, not
discriminating between those code parts that will be used and those code
parts that will never be used.
Also, since the code segment is read-only, it can be shared between
processes executing the same binary. The decompressed code will have to
be stored into some kind of writable code segment which then cannot be
shared. So you'll end up with several copies of identical code segments
which were loaded entirely (and had to be swapped out in case of memory
shortage) and could not be shared.
Some architectures might even prohibit executing code from a data
segment.
My guess is that the time saved by loading a compressed code is more
than eaten up by de-compressing the code (enetring the kernel again and
again to allocate additional memory) and coping with the increase in
memory utilization.
-- =
Josef M=F6llers
Fujitsu Siemens Computers
SHV Server DS 1
------------------------------
Date: Thu, 11 May 2000 09:09:02 +0200
From: Thomas Reinemann <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.embedded
Subject: Re: Linux response time
Ling Su wrote:
>
> Hi,
>
> I have a simple question on the system response time for general Linux with
> a high preformance processor(like Pentium III 800MHz). How about the
> improvement with the RT-Linux extension?
What means system response time? There are some test how long it take to
fulfil any request independent from the source of the request. On a
Linux box you can expect that your request will served latest after
50ms, in almost all cases :-). This depends on the Linux time slice of
10 ms and possible higher prior tasks.
With an RT extension of Linux you can drop this to some ten us. This
depends on your hardware. With a multi processor board you can reduce
response times very strong to some us because the more close grained
timer of this boards. Have in mind you need only these board not more
than one processor, necessarily.
You should read the home page of the RT Linux extensions, there are
showed some comparisons.
http://www.rtlinux.org/rtlinux/index.html
http://www.aero.polimi.it/projects/rtai/
http://www.thinkingnerds.com/projects/rtl-ws/rtl-ws.html
Bye Tom!
------------------------------
** 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
******************************
