Linux-Development-Sys Digest #831, Volume #6 Tue, 15 Jun 99 03:14:36 EDT
Contents:
Help with 2.2.\* compile ([EMAIL PROTECTED])
smp latentcy - measure and post please. (Gianni Mariani)
Re: Problem with vremap function ([EMAIL PROTECTED])
Re: Have you used QNX ? (Bryan Hackney)
Re: Have you used QNX ? (Harald Arnesen)
I need clarification about malloc and brk (Martin Kahlert)
Re: glibc2: undefined references (Andreas Jaeger)
SIGALRM and serial i/o
Re: What are the differences between mySQL and mSQL? (Don Baccus)
Re: smp latentcy - measure and post please. (Martin Kahlert)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Help with 2.2.\* compile
Date: 14 Jun 1999 23:59:58 -0400
Hi all,
We have run into a problem while trying to compile new kernels from
the 2.2.* series (we have tried 2.2.9 and 2.2.10). Briefly, we create
a bzImage type binary, update lilo, and reboot. The kernel seems to be
booting with the new kernel for a while but then comes to a stop with
the following message:
VFS: Cannot open root device 08:01
Kernel Panic: VFS :Unable to mount root fs on 08:01
We read the kernel recompile README and the kernel HOWTO but could not
find any useful info. We seem to be doing the right thing but, well...
BTW, the RedHat distribution kernel has an initrd file as well (used
with the initrd option in lilo.conf). There is no mention of this in
the kernel build README. After recompiling the kernel, we did not find
any initrd*.img file anywhere under /usr/src/linux. What is the
purpose of this file and how do we create it?
We are also including our exact steps to provide further details. Any
help would be greatly appreciated.
Muammer
[EMAIL PROTECTED]
==============================================================================
Sys Description
Pentium II 266MHz
64MB
RedHat 6.0 (Kernel 2.2.5)
Adaptec AIC-7895 SCSI adaptor
4.1GB SCSI hard drive
Recompile steps:
cd /usr/src/
rmdir linux
tar zxpvf linux-2.2.10.tar.gz
ln -s /usr/src/linux-2.2.10 /usr/src/linux
cd linux
make mrproper
make menuconfig
make dep
make bzImage
make modules
make modules_install
cp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage-2.2.10
LILO update:
edit /etc/lilo.conf
image=/boot/bzImage-2.2.10
label=2.2.10
root=/dev/sda1
read-only
/sbin/lilo
------------------------------
From: Gianni Mariani <[EMAIL PROTECTED]>
Subject: smp latentcy - measure and post please.
Date: Mon, 14 Jun 1999 16:52:19 GMT
This is a multi-part message in MIME format.
==============F482C816446858E1CE6D8854
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Linux SMP users, please take the time to run this code and post the
results.
I'm especially interested in seeing if a XEON system makes any
substantial difference.
Note that this code will hog both CPU's for ~11 seconds on a 450Mhz
cpu, longer
on lower frequency CPU's and less on higher frequency CPU's. You should
only
run this on machines that are basically idle as otherwise 1. the results
you get will
be bad and 2. you'll disrupt others using the system when you hog two
CPU's.
STANDARD DISCLAIMER: I'm not responsible if your linux box goes up in
smoke or
anything else bad happens. I have run this code on my configuration and
I know it behaves
OK. I don't know if you will have any issues with you system. Make
sure you understand
what you are doing and if it will break your system.
Having said that, please run and post these results:
motherboard:
CPU:
CPU clock:
OS vers:
cpulat-output:
============ like this ....
MY mobo results:
motherboard: Tyan S1837 GX chipset
CPU: PIII
CPU clock : 450MHz
OS vers: Linux 2.2.5-15smp
cpulat-output:
diff = 161
odiff = 180
diff = 164
odiff = 165
diff = 182
odiff = 165
diff = 176
odiff = 163
diff = 191
odiff = 174
diff = 164
odiff = 184
diff = 161
odiff = 163
diff = 166
odiff = 180
diff = 164
odiff = 170
================
Why you might ask am I doing this ? Curiosity mainly. I'm interested
in finding
out what things affect this measurement. This number determines just
how
much cross-cpu communication you can afford and I'd like to measure just
how the different systems behave. I think others might be just as
curious as I.
==============F482C816446858E1CE6D8854
Content-Type: text/plain; charset=us-ascii; name="cpulat.cpp"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="cpulat.cpp"
//
// cpulat.cpp
// Authored by Gianni Mariani 13-Jun-1999
//
// This is intended to run on a dual CPU PII or better system.
// This measures the latentcy in CPU clock cycles from one
// CPU making a change to memory to the other CPU being able to
// react. This latentcy is a critical factor in shared memory
// parallel communications.
//
//
// LICENSE - GPL - GNU Public Licencse
//
// Description
// This program sets up a page of shared memory and then forks.
// Each process will share the page of memory and will use it
// to do raw shared memory spin locks using a simple while()
// loop.
//
// The child process goes into a spin and the parent process
// wakes breaks it's spin. Both processes read their respective
// time stamps just after these events. The parent process waits
// for the child to place the counter value in the shared memory
// and then measures the difference. The roles are then reversed
// and this interaction is measured 10 times.
//
// If the time stamp counters are not set up correctly by the OS
// you will get weird behaviour.
//
// This is the output of a run on a Tyan S1837 with PIII 450's using
// a stock RH 6.0 (2.2.5-15smp) Linux kernel.
//
// diff = 165
// odiff = 187
// diff = 201
// odiff = 175
// diff = 194
// odiff = 166
// diff = 192
// odiff = 182
// diff = 186
// odiff = 169
// diff = 181
// odiff = 177
// diff = 193
// odiff = 170
// diff = 162
// odiff = 219
// diff = 193
// odiff = 168
//
// compile line : g++ -O2 -o cpulat cpulat.cpp
//
#include <stdio.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/mman.h>
//
// This snippet of __asm__ magic was taken from
// a news posting. I don't know who the original
// author is. I did do a regular net search.
typedef unsigned long long u64;
inline u64 rdtsc(void) {
u64 clock;
__asm__ __volatile__("rdtsc" : "=A" (clock));
return clock;
}
#define LOOPS 10
main()
{
volatile char * adr;
int len;
volatile u64 * data;
int pgsz = getpagesize();
int fd;
char * file = tmpnam( ( char * ) 0 );
// create a temporary file
if ( ( fd = open( file, O_RDWR | O_CREAT, 0666 ) ) == -1 ) {
bombed:
perror( file );
return 1;
}
// Delete the file now, no need to have it hang around in
// the directory.
unlink( file );
// write a page to the file
if ( lseek( fd, pgsz-1, SEEK_SET ) == (off_t)-1 ) goto bombed;
if ( write( fd, "", 1 ) != 1 ) goto bombed;
// Map the page to memory
adr = ( char * ) mmap(
( char * ) 0, // Address to map to
pgsz, // Length of the mapping
PROT_WRITE, // Map for read
MAP_SHARED, // Map a shared copy
fd,
0
);
// Check to see if the mmap went OK
if ( -1l == ( ptrdiff_t ) adr ) goto bombed;
// No need for the file handle any more
close( fd );
* adr = 0;
adr[ 1 ] = 0;
data = 1 + ( u64 * ) adr;
int procid = fork();
if ( procid == -1 ) {
perror( "fork()" );
return 1;
}
if ( ! procid ) {
int n = 0;
int n2 = 1;
while ( 1 ) {
// spin and wait for the other process
// to modify memory.
while ( ( * adr ) == n ) ;
// First thing - get the cpu clock time
u64 val = rdtsc();
// Write the time to the shared memory
* data = val;
n = * adr;
// Wait a tad
while ( rdtsc() < ( val + 450000000LL/2 ) );
// Break the other CPU out of the spin
adr[ 1 ] = n2;
// Immediatly get the time
u64 val1 = rdtsc();
// Write it to shared memory
data[ 1 ] = val1;
// increment the count
n2 ++;
// If we've been around a few times
// bail
if ( n == LOOPS ) {
exit( 0 );
}
}
} else {
int n = 1;
int n2 = 0;
// Wait for the other process to get created and spun up.
u64 val = rdtsc();
while ( rdtsc() < ( val + 450000000LL/4 ) );
// Go around a bit
for ( int i = 1; i < (LOOPS+1); i ++ ) {
// break the other process.
* adr = n;
// Immediatly get the time
u64 val = rdtsc();
n ++;
if ( n == (LOOPS+1) ) {
exit( 0 );
}
// Wait about 1/4 second
while ( rdtsc() < ( val + 450000000LL/4 ) );
// Print out latentcy to other CPU from this CPU
printf( "diff = %lld\n", * data - val );
// spin and wait for the other process
while ( ( adr[ 1 ] ) == n2 ) ;
// Immediatly get the time
u64 val2 = rdtsc();
// set the new value
n2 = adr[ 1 ];
// Wait for a tad.
while ( rdtsc() < ( val + (450000000LL*3)/4 ) );
// Print out latentcy from this CPU from other CPU
printf( "odiff = %lld\n", val2 - data[ 1 ] );
while ( rdtsc() < ( val + 450000000LL ) );
}
}
return 0;
}
==============F482C816446858E1CE6D8854==
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development,comp.os.linux.hardware
Subject: Re: Problem with vremap function
Date: Mon, 14 Jun 1999 13:56:41 GMT
In article <[EMAIL PROTECTED]>,
Vincent <[EMAIL PROTECTED]> wrote:
> Hi. (I'm under Linux SuSE 6.0 (kernel 2.0.36))
>
> I'm developping a driver for industrial PCI card. Each card have 2Ko
of
> memory.
>
> The first card has an adress: 0xFF000000
> The second has an adress: 0xFF000800
>
> My problem is that vremap can't maps the second memory.
>
> vremap use this define:
> PAGE_SHIFT = 12
> PAGE_SIZE = 1 << PAGE_SHIFT #0x00001000
> PAGE_MASK = ~(PAGE_SIZE-1) #0xFFFFF000
> ~PAGE_MASK= #0x00000FFF
>
> This is the minimum of page size
>
> Error provide in the second card with the test: if (adress &
> ~(PAGE_MASK)) return NULL
> with adress is the physical adress.
>
> For the first card: 0xFF000000 & 0x00000FFF => return virtual
> adress
> For the sedond card: 0xFF000800 & 0x00000FFF => return NULL
>
> How can I resolve this error ?
> Can I reduce the page size ?
> Or, must I use other function than vremap ???
>
> Thanks for your help.
Hi!
AFAIK vremap only maps whole pages. on x86 based Systems the Pagesize is
4K (0x1000).
(i�m writing on a pci-device driver too and had the same problem until
someone told me)
regards
Martin Schreiber
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: Have you used QNX ?
Date: Tue, 15 Jun 1999 04:36:47 +0000
Reply-To: [EMAIL PROTECTED]
D Allinson wrote:
>
> Has anyone switched OS from QNX to Linux ? I'd be interested to hear of
> why / how easy.
I did that a couple of years ago and never looked back. The app was a large
machine with custom hardware ( serial controllers, motion control, etc. ).
Fortunately, I did not use any QNX specfic interfaces, only "POSIX". The
original port took two hours for 10000 lines of C++ code.
If I had been sucked into the QNX interfaces, the port would have been a
bit more effort.
--
Bryan Hackney / BHC / bhackneyatexpress-news.net
*
------------------------------
From: Harald Arnesen <[EMAIL PROTECTED]>
Subject: Re: Have you used QNX ?
Date: 14 Jun 1999 17:18:03 +0200
D Allinson <[EMAIL PROTECTED]> writes:
> Has anyone switched OS from QNX to Linux ? I'd be interested to hear of
> why / how easy.
In a recent issue of Linux Journal, there was an article about an
Australian betting firm which had done just that. Perhaps you'll find
the article at <http://www.ssc.com/>
--
Harald Arnesen, Apall�kkveien 23 A, N-0956 Oslo, Norway
------------------------------
From: [EMAIL PROTECTED] (Martin Kahlert)
Crossposted-To: comp.unix.programmer
Subject: I need clarification about malloc and brk
Date: 15 Jun 1999 06:07:45 GMT
Reply-To: [EMAIL PROTECTED]
Hi!
I have to port a large Fortran prog, which up to now runs under
HPPA, IRIX, SUN4, SOLARIS, Linux x86 and WinNT to Linux Alpha.
The Problem is the memory management and the age of the prog:
We use C malloc and do Fortran 77 dynamic memory allocation with
this (via offsets from a common block array).
Unfortunately, the offsets are 32 Bit integers
(changing that would be a major rewrite!).
But up to now on Irix (64 Bit) this works fine whithout changes,
since all pointers from malloc are 'near enough' to the common block
array. This is not the case in Linux Alpha.
I thought, malloc provides memory by using the brk(2) system call,
which enlarges the data area of the executable. Thus i thought
all pointers from malloc should be in the range from 0(or a bit more)
to the result of brk(0).
What i see on Linux Alpha, is that for the first allocated 8 MB block
(smaller ones are just fine) i am more than 4 GB away
from the common block's data area.
If i run this prog through strace (Linux's equivalent to progs like
truss, trace...) i only see brk results, which are very low
(within the first 4GB).
How can that be?
Where the heck does malloc get its memory from, then?
If anybody please could explain this to me, i would be very glad.
If possible, please add a reply via mail to your post, too,
since i don't want to miss any of them.
Thanks in advance,
Martin.
--
esa$ gcc -Wall -o ariane5 ariane5.c
ariane5.c: 666: warning: long float implicitly truncated to unsigned type
esa$ ariane5
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: glibc2: undefined references
Date: 14 Jun 1999 19:57:49 +0200
>>>>> Tobias Deiminger writes:
Tobias> Andreas Jaeger wrote:
>> >>>>> Tobias Deiminger writes:
>>
Tobias> After installing glibc2.1.1pre3 on my suse5.3 (libc; egcs1.1) to
Tobias> /usr/local I sometimes get errors during linking:
Tobias> /usr/local/lib/libc.so.6: undefined reference to
Tobias> `_dl_unload_cache@@GLIBC_2.1'
Tobias> /usr/local/lib/libc.so.6: undefined reference to
Tobias> `_dl_initial_searchlist@@GLIBC_2.1'
Tobias> ...
Tobias> What's wrong?
>>
>> Read the glibc FAQ first that comes with glibc 2.1.1.
Tobias> The only thing I found in the FAQ was that symbols starting with "_dl_" come
Tobias> from the dynamic linker.
Tobias> So I still have no idea how to my problem .
You should have searched for _dl_initial_searchlist;-)
Andreas
3.18. After upgrading to glibc 2.1, I receive errors about
unresolved symbols, like `_dl_initial_searchlist' and can not
execute any binaries. What went wrong?
{AJ} This normally happens if your libc and ld (dynamic linker) are from
different releases of glibc. For example, the dynamic linker
/lib/ld-linux.so.2 comes from glibc 2.0.x, but the version of libc.so.6 is
from glibc 2.1.
The path /lib/ld-linux.so.2 is hardcoded in every glibc2 binary but
libc.so.6 is searched via /etc/ld.so.cache and in some special directories
like /lib and /usr/lib. If you run configure with another prefix than /usr
and put this prefix before /lib in /etc/ld.so.conf, your system will break.
So what can you do? Either of the following should work:
* Run `configure' with the same prefix argument you've used for glibc 2.0.x
so that the same paths are used.
* Replace /lib/ld-linux.so.2 with a link to the dynamic linker from glibc
2.1.
You can even call the dynamic linker by hand if everything fails. You've
got to set LD_LIBRARY_PATH so that the corresponding libc is found and also
need to provide an absolute path to your binary:
LD_LIBRARY_PATH=<path-where-libc.so.6-lives> \
<path-where-corresponding-dynamic-linker-lives>/ld-linux.so.2 \
<path-to-binary>/binary
For example `LD_LIBRARY_PATH=/libold /libold/ld-linux.so.2 /bin/mv ...'
might be useful in fixing a broken system (if /libold contains dynamic
linker and corresponding libc).
With that command line no path is used. To further debug problems with the
dynamic linker, use the LD_DEBUG environment variable, e.g.
`LD_DEBUG=help echo' for the help text.
If you just want to test this release, don't put the lib directory in
/etc/ld.so.conf. You can call programs directly with full paths (as above).
When compiling new programs against glibc 2.1, you've got to specify the
correct paths to the compiler (option -I with gcc) and linker (options
--dynamic-linker, -L and --rpath).
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: <[EMAIL PROTECTED]>
Subject: SIGALRM and serial i/o
Date: 15 Jun 1999 05:21:04 GMT
Hi,
I'm posting the minimal source code for my serial port reading program.
The problem didn't seem to be the SIGALRM code in itself. It seems that
the serial port settings get reset or overwritten if I don't keep the
termios structure in memory. (i.e. if I use a function and a local variable to
initialize the port, the variable is freed after return and the state of
the port is undefined (?) )
Can someone confirm this, or is there another reason ?
Anyhow, the code seems to work now that I malloc a termios structure in main().
I'm reading in canonical mode i.e. the read() returns after a newline or
after 32 (buflen) chars have been read. The message length from the device
is always 16 characters+cr+nl .
Alas, the sleep() doesn't do what I thought it would. The serial data gets
buffered and when awaken, I get a lot of old data as well...
#define _POSIX_SOURCE 1
#include <stdio.h>
#include <stdlib.h>
#include <termios.h>
#include <unistd.h>
#include <fcntl.h>
#include <signal.h>
#include <time.h>
int stop;
void sigquit_handler(int status){
fprintf(stderr,"Ooops..SIGQUIT, cleaning up...\n");
stop = 1;
}
int main(int argc, char *argv[]){
struct termios oldtio, *newtio;
struct sigaction sigq;
int fd, ret;
char buf[32];
time_t now, unixaika;
struct tm *obstime;
/* sigquit handler */
sigq.sa_handler = sigquit_handler;
sigemptyset(&sigq.sa_mask);
sigq.sa_flags = 0;
sigq.sa_restorer = NULL;
if ( sigaction(SIGINT,&sigq,NULL)!= 0){
perror("sigaction(SIGIO)"); exit (-1);
}
newtio=malloc(sizeof(struct termios));
if( newtio==NULL ){ perror("Malloc"); exit (-1);}
fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY );
if( fd < 0 ){ perror("open"); return -1;}
ret= (tcgetattr(fd, &oldtio));
if(ret < 0){ perror("tcgetattr"); exit(-1);}
newtio->c_cflag |= CLOCAL | CREAD;
newtio->c_cflag |= CS8;
newtio->c_iflag |= INPCK | ISTRIP;
newtio->c_iflag &= ~IUCLC;
newtio->c_lflag |= ICANON;
ret=cfsetispeed( newtio, B2400);
if(ret < 0){ perror("cfsetispeed"); exit(-1);}
ret= tcflush(fd, TCIFLUSH);
if(ret < 0){ perror("tcflush"); exit(-1);}
ret=tcsetattr(fd, TCSANOW, newtio);
if(ret < 0){ perror("tcsetattr"); exit(-1);}
/* start recording at xx min 50 sec */
unixaika=time(&now);
obstime=localtime(&unixaika);
fprintf(stdout,"It is now %.2d:%.2d:%.2d , sleeping %d seconds\n ",
obstime->tm_hour, obstime->tm_min, obstime->tm_sec,
obstime->tm_sec < 50 ? 50-obstime->tm_sec : 60-obstime->tm_sec+50 );
sleep(obstime->tm_sec < 50 ? 50-obstime->tm_sec : 60-obstime->tm_sec+50);
while( 1 ){
ret = read(fd, buf, 32);
if ( ret == -1 ){ perror(">>Read failure"); } /* should this be fatal ? */
if ( ret > 0 ){
buf[ret]='\0';
unixaika=time(&now);
obstime=localtime(&unixaika);
fprintf(stdout,">>%.2d:%.2d:%.2d>>",
obstime->tm_hour, obstime->tm_min, obstime->tm_sec);
fprintf(stdout,"%d>>%s",ret, buf);
fflush(stdout);
}
}
if ( (tcsetattr(fd,TCSANOW, &oldtio)) != 0 )
perror("Restore_serial failed:");
close(fd);
fflush(stdout);
fprintf(stderr,">>Program terminated\n");
return 0;
}
------------------------------
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.lang.java.databases
Subject: Re: What are the differences between mySQL and mSQL?
From: [EMAIL PROTECTED] (Don Baccus)
Date: 14 Jun 1999 11:13:00 PST
In article <7k1vru$[EMAIL PROTECTED]>,
david parsons <o r c @ p e l l . p o r t l a n d . o r . u s> wrote:
>In article <[EMAIL PROTECTED]>,
>Don Baccus <[EMAIL PROTECTED]> wrote:
>>Not necessarily true. If you have several related tables
>>that need to be logically updated at once, the atomicity of
>>the transactional model is, well, useful if there's a crash
>>while records are being inserted or updated.
> Denormalize, denormalize, denormalize.
> Yeah, you might bloat your rdb by a factor of 10 to do this,
> but disk and core is getting cheap these days.
Denormalization is something sane folks do to increase performance,
not to avoid the need for a real database engine.
If you've denormalized checking balances into thirty tables,
don't have atomicity, and an update dies half-way through
updating these tables, which balance do you trust?
Or if another process reads these tables when processing
an order, which balance should it use if they don't all
agree?
I suppose you can start implementing all sorts of cross-checks
to help you unwind afterwards but...
Why bother? Why not use a transaction-based db in the first
place?
--
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, at http://donb.photo.net
------------------------------
From: [EMAIL PROTECTED] (Martin Kahlert)
Subject: Re: smp latentcy - measure and post please.
Date: 15 Jun 1999 06:28:46 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
Gianni Mariani <[EMAIL PROTECTED]> writes:
> This is a multi-part message in MIME format.
> --------------F482C816446858E1CE6D8854
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
>
> Linux SMP users, please take the time to run this code and post the
> results.
PPro 200 MHz, 128MB RAM egcs-1.1.2
g++ -O3 -o cpulat cpulat.cc
4 runs:
diff = 148
odiff = 115
diff = 149
odiff = 117
diff = 109
odiff = 101
diff = 102
odiff = 160
diff = 110
odiff = 169
diff = 108
odiff = 115
diff = 109
odiff = 116
diff = 98
odiff = 117
diff = 108
odiff = 116
diff = 20231908
odiff = 187
diff = 108
odiff = 244
diff = 110
odiff = 214
diff = 158
odiff = 121
diff = 117
odiff = 183
diff = 98
odiff = 178
diff = 108
odiff = 181
diff = 112
odiff = 244
diff = 113
odiff = 139
diff = 41792262
odiff = 187
diff = 98
odiff = 189
diff = 29536
odiff = 121
diff = 165
odiff = 109
diff = 240
odiff = 271
diff = 140
odiff = 123
diff = 106
odiff = 53916
diff = 117
odiff = 253
diff = 168
odiff = 156
diff = 12538502
odiff = 172
diff = 108
odiff = 115
diff = 98
odiff = 115
diff = 110
odiff = 117
diff = 113
odiff = 121
diff = 110
odiff = 116
diff = 106
odiff = 98
diff = 117
odiff = 115
diff = 111
odiff = 175
Bye,
Martin.
--
esa$ gcc -Wall -o ariane5 ariane5.c
ariane5.c: 666: warning: long float implicitly truncated to unsigned type
esa$ ariane5
------------------------------
** 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
******************************
