Linux-Development-Sys Digest #709, Volume #7     Mon, 27 Mar 00 15:13:17 EST

Contents:
  Q: time measurement kernel module (Moertl Gernot)
  Re: finding out track numbers (Josef Moellers)
  Re: libpthread causes segfault (Michael Dipperstein)
  Re: libpthread causes segfault (Michael Dipperstein)
  date ("Jean-Baptiste Bavoux")
  linux hang ! (valery brasseur)
  Re: date ("Lothar Dickhoff")
  Re: Embedded Systems Development ("Lothar Dickhoff")
  Re: Windows CE target for GCC? (Kaz Kylheku)
  Re: libpthread causes segfault (Kaz Kylheku)
  Re: [Q] How to change the max. amount of open files (Mark Astley)
  Re: linux hang ! (nightstalker)
  Re: system hung when compiling kernel (Filip M. Gieszczykiewicz)
  FDCC sets... (Andre Charbonneau)
  Re: linux hang ! (Filip M. Gieszczykiewicz)
  Re: need the source code of fsck (Paul Kimoto)
  Re: Windows CE target for GCC? (Mumit Khan)
  Serial Port -> No Interrupts !? (Daniel Dorau)
  Re: POSIX timer implementation available. ("Robert H. de Vries")
  Re: POSIX timer implementation available. (Kaz Kylheku)

----------------------------------------------------------------------------

Date: Mon, 27 Mar 2000 12:21:01 +0200
From: Moertl Gernot <[EMAIL PROTECTED]>
Subject: Q: time measurement kernel module

Hi people !

I'm writing a kernel module to measure time via the Pentium Time Stamp 
Counter,..., now I have a problem to get the CPU Speed in Mhz. 
I tried to check up how this is done if you make a "cat /proc/cpuinfo"
but without success so far...

Does anyone know how to get the CPU-MHz's inside a kernel module ?

====================================================================
Gernot Moertl                                 
[EMAIL PROTECTED]

------------------------------

From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: finding out track numbers
Date: Mon, 27 Mar 2000 14:53:44 +0200

Badrinath Venkatachari wrote:
> =

> Hi,
>  Is there (a function or computation) that would permit finding out the=

> track number and head number on the disk for a given position in a file=

> ? I want to be able to estimate the time to service a given file reques=
t
> given the present head position. Any ideas on how I can do that ?

This cannot be done in general.
Most modern disks have no fixed number of sectors/track. Rather they
store more sectors on the outer tracks than on the inner tracks.

For SCSI devices you might try to use a READ CAPACITY command with the
PMI bit set. It will give you the "logical block address after wich a
substantial delay in data transfer will be encountered", whatever that
means. Add to that the information returned by a MODE SENSE command with
Page Code 04H (this page contains number of heads and number of
cylinders) and you can get a pretty good description of the disk layout.

-- =

Josef M=F6llers
Fujitsu Siemens Computers
SHV Server DS 1

------------------------------

From: Michael Dipperstein <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: libpthread causes segfault
Date: Mon, 27 Mar 2000 05:54:00 -0800



Rob Eisink wrote:
> 
>     Are you sure you've compiled with _THREAD_SAFE? I had the same problem.
> Note that STL is _not_ threadsafe.
> 
>     Rob

I didn't even know that there was a _THREAD_SAFE definition.  Per the
howtos and FAQs, I am compiling with -D_REENTRANT.  I'll see if that
fixes anything.

-Mike

------------------------------

From: Michael Dipperstein <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: libpthread causes segfault
Date: Mon, 27 Mar 2000 06:04:48 -0800

Kaz Kylheku wrote:
> 
> On Sun, 26 Mar 2000 17:59:13 -0800, Michael Dipperstein <[EMAIL PROTECTED]>
> wrote:
> >If I take my user level test code and the '-lpthread' directive to the
> >gcc
> >command line, the code fails with a segment fault that results happened
> >in
> >function errno while trying to handle a printf.
> 
> It could be that you forgot -D_REENTRANT. In multithreaded programs, errno is a
> thread-specific value.
>
> To compile multithreaded programs, specify the -pthread option. This adds
> -D_REENTRANT and -lpthread to the compiler command line.

My Makefile specifically uses -D_REENTRANT and -lpthread.  Does -pthread
produce the same results?
 
> >My user level thread code swaps stacks when threads are switched out.
> >Are
> >then any restrictions on stack manipulation when the thread library is
> >linked in, but none of its functions are called?
> 
> Note that the threading library's functions may be called indirectly.  For
> example, something as innocuous as putchar() uses pthread_mutex_t locks.
> 
> The LinuxThreads library identifies the calling thread by its stack pointer.

At the point of the failure there are no threads running.  In fact I can
get the failure in code that doesn't call any pthread_* functions.  The
segfault always happens during a printf, once I've started my user level
threads.  Does printf use putchar, and does putchar expect the process
to
have a stack at a fixed location?

-Mike

------------------------------

From: "Jean-Baptiste Bavoux" <[EMAIL PROTECTED]>
Subject: date
Date: Mon, 27 Mar 2000 17:29:36 +0200

when I set the time and date whoth the 'date' command
and then I reboot  , the time I've set is lost.
(I am oblige to change the date in the bios ).

Why?
What can I do?





------------------------------

Date: Mon, 27 Mar 2000 18:24:18 +0200
From: valery brasseur <[EMAIL PROTECTED]>
Subject: linux hang !

from time to time my PC hang.
when in this state I couldn't do anything : no keyboard, no network,
nothing seems to respond and I see no trace in the system logs !!!
did some body have any idea ? how can I debug that ?

note : my kernel is a 2.2.14 with a RH6.0 install.

thanks in advance.
-- 
Valery BRASSEUR                | Phone # +33 320 60 7982 
Atos Branche Multimedia        | Fax   # +33 320 60 7649
    bash: the power to toast your registry in style...


------------------------------

From: "Lothar Dickhoff" <[EMAIL PROTECTED]>
Subject: Re: date
Date: Mon, 27 Mar 2000 17:58:47 +0200

Hello Jean-Baptiste,
you have to change also the time in the hardware clock.
as root: hwclock --systohc

Try "man hwclock" to see the options.

Regs. Lothar

Jean-Baptiste Bavoux schrieb in Nachricht <8bnuqv$eih$[EMAIL PROTECTED]>...
>when I set the time and date whoth the 'date' command
>and then I reboot  , the time I've set is lost.
>(I am oblige to change the date in the bios ).
>
>Why?
>What can I do?
>
>
>
>



------------------------------

From: "Lothar Dickhoff" <[EMAIL PROTECTED]>
Subject: Re: Embedded Systems Development
Date: Mon, 27 Mar 2000 18:10:52 +0200

Hi,
have a look on eLinux, a Kernel 2.033 based Linux for embedded Systems.
Also the QNX System, a Unix like OS for embedded Systems might be a good
choice (http://www.qnx.com)

Regs. Lothar





------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Windows CE target for GCC?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 27 Mar 2000 16:51:01 GMT

On Mon, 27 Mar 2000 07:45:51 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Tuomas Airaksinen <[EMAIL PROTECTED]> wrote:
>> Thu, 16 Mar 2000 08:08:25 GMT, Tom & Ada Campbell kirjoitti:
>>>Is there version of GCC that can output Windows CE executables?
>> Can you put Linux on Windows CE-machine???
>> I suppose you can't...
>
>Actually you can (http://www.linuxce.org/) but that's not an issue here. Gcc
>can produce win32 binaries, so why not CE. It might be possible to do such a
>cross compiler out of gcc but you still need CE SDK for headers and
>libraries... There even might be a solution available. Cygnuses GNUPro ETS

I'd rather see independently developed headers. The CE SDK headers suck
donkeys. These idiots don't know how to conform to any standard. They pollute
with with macros that don't belong to any documented or reserved namespace, and
are unable to take the five minutes of labor to produce a <stddef.h> .

-- 
#exclude <windows.h>

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: libpthread causes segfault
Reply-To: [EMAIL PROTECTED]
Date: Mon, 27 Mar 2000 17:03:59 GMT

On Mon, 27 Mar 2000 06:04:48 -0800, Michael Dipperstein <[EMAIL PROTECTED]>
wrote:
>At the point of the failure there are no threads running.  In fact I can
>get the failure in code that doesn't call any pthread_* functions.  The
>segfault always happens during a printf, once I've started my user level
>threads.  Does printf use putchar, and does putchar expect the process
>to
>have a stack at a fixed location?

The glibc stdio functions, and other functions in glibc, are aware of
libpthread.  When you don't link in libpthread, they end up calling pthread
stubs that do nothing. When you link in libpthread, the real functionality sets
in, as the stubs are overriden.

You cannot use the library with some user level threading model that it is not
aware of; it is not designed to be entered by two or more level threads that
are running in the context of but one system thread.  Doing so will likely
create a crash. You must ensure that only one of your user level threads enters
the library at any one time, and that before the call, its stack pointer has
been restored to the sane state which was assigned to the underlying POSIX
thread at pthread_create time. The library can't use an arbitrary stack because
it will confuse the underlying thread hooks.

Using arbitrary stacks with the libraries of some other operating systems works
fine. It should also work fine for single threaded programs in Linux. But it is
not portable to threaded Linux.

I'm guessing, but one thing that you can do is to bind your user threads to a
particular system thread. Then ensure that the stack of each user thread is
allocated within the memory region of the overall stack of the system thread.
This way, the stack pointer of the user thread will always fall into the right
range so that the caller will be correctly identified. The reentrancy caveats
still apply.

>-Mike

-- 
#exclude <windows.h>

------------------------------

From: Mark Astley <[EMAIL PROTECTED]>
Subject: Re: [Q] How to change the max. amount of open files
Date: 27 Mar 2000 12:43:41 -0500


If you're using PAM (password authentications modules IIRC, which
happens to be used in later Redhat distros), then you may need to do a
bit more work.  If you're using PAM you probably have an /etc/pam.d
directory.  If not, or if you aren't using PAM then disregard...

If you ARE using PAM (this is on Redhat now, your paths may vary):
Check for /etc/pam.d/login, and look for the line:

session    required     /lib/security/pam_limits.so

If it's not there, go ahead and add it.  Now look for
/etc/security/limits.conf.  Add some lines like:

*       soft    nofile  8192
*       hard    nofile  8192

which sets the default hard and soft fd limits for all users (except
root) to 8192.  You still have to echo to /proc/sys/file-max and
/proc/sys/inode-max.

cheers,

mark

"Lawrence K. Chen, P.Eng." <[EMAIL PROTECTED]> writes:

> That didn't work for me.
> 
> I tried it with $NEW_VALUE == 2048 and 10240, but the maximum that I can get
> is still 1024.
> 
> And my application can use up to 2048 (which it automatically tries to get
> when it starts up by using getrlimit/setrlimit).
> 
> [EMAIL PROTECTED] wrote:
> > 
> > In article <89ilcc$8jt$[EMAIL PROTECTED]>,
> >   [EMAIL PROTECTED] wrote:
> > > Hi..
> > >
> > > can anyone point me to the source file, which i would need to change
> > in a
> > > SuSE Linux Distribution, in order to increase the maximum open files
> > allowed
> > > ? I need to increase this value, since some applications (like SQUID)
> > handle
> > > too much open files for the system right now, which causes SQUID
> > (e.g.) to
> > > stop working. You would do me a favor, if you could not only respond
> > to the
> > > forum, but also to my email address, since i only can check the forum
> > via
> > > DejaNews.
> > >
> > >
> > 
> > To extent those values is much easier, just:
> > 
> > echo $NEW_VALUE > /proc/sys/file-max
> > echo $NEW_VALUE > /proc/sys/inode-max
> > 
> > You will find lots of other interesting info in /proc, like:
> > /proc/interrupts
> > /proc/ioports
> > /proc/dma
> > /proc/<processID>/...
> > 
> > Hope it helps
> > 
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> 
> -- 
>     Who: Lawrence Chen, P.Eng.          Email: [EMAIL PROTECTED]
>    What: Software Developer               URL: http://www.opentext.com/basis
>   Where: Open Text, BASIS Division      Phone: 614-761-7449
>          5080 Tuttle Crossing Blvd.       Fax: 614-761-7269
>          Dublin, OH  43016                ICQ: 12129673
>   DISCLAIMER: All opinions expressed are mine and *NOT* my employers

------------------------------

From: nightstalker <[EMAIL PROTECTED]>
Subject: Re: linux hang !
Date: Mon, 27 Mar 2000 18:03:35 GMT

valery brasseur wrote:

> from time to time my PC hang.
> when in this state I couldn't do anything : no keyboard, no network,
> nothing seems to respond and I see no trace in the system logs !!!
> did some body have any idea ? how can I debug that ?
>
> note : my kernel is a 2.2.14 with a RH6.0 install.
>
> thanks in advance.
> --
> Valery BRASSEUR                | Phone # +33 320 60 7982
> Atos Branche Multimedia        | Fax   # +33 320 60 7649
>     bash: the power to toast your registry in style...

here's how to debug this :
    check out if all your hardware is functioning correctly.

last time i had a crash my video card was broken .. ps:
this was the first crash in 2 or 3 years :)



------------------------------

From: [EMAIL PROTECTED] (Filip M. Gieszczykiewicz)
Subject: Re: system hung when compiling kernel
Date: 27 Mar 2000 13:29:52 -0500

In Article <[EMAIL PROTECTED]>, through puissant locution, Karsten 
Bickel <[EMAIL PROTECTED]> soliloquized:
>Hallo Anders Larsen,
>> > Now I tried to build my first own kernel based on the kernel-sources
>> > 2.0.36.
>> > All works fine till the point gcc tries to compile 'ide.c'. It starts
>> > compiling and then the system(!) hung. Nothings works (e.g. switch to
>> > another virtual console, numlock key, ...) - the only exit is a hard 
>> > reset
>> > or power off/on.
>> > I tried it several times - exactly the same.
>> > I reinstalled the sources, compiler, libraries - exactly the same.
>> 
>> That's common behaviour when the system runs out of memory.
>> If you can't add RAM, you must increase the available swap space.
>
>I set up an 32 MB swap partition. At one of my tries I switched to another 
>virtual console and startet 'top'. At the moment the system hung up I had 
><300kb free memory and the swap was used with <3 MB -> 29 MB free(!).

486DX2/80 is plenty to compile kernel. What type of fs are you using?
ext2? I would boot from a rescue floppy and fsck it. Remake the swap
by first checking for badblocks (-c or best run badblocks with -w
flag to do a pattern-write test). If that still fails, ensure that
your BIOS is setup properly. I'd [uh oh] disable secondary cache or
add wait-states to the write/read for the RAM.

I take it you're _running_ 2.0.36  and want to rebuild?

Also, what base distrib are you running? Slackware? RH?

At this point, I'd suspect something hardware: bad CPU (do you have
a fan on that DX2/80 - needs it!), is the HD/io-subsystem able to
handle the load, RAM timing issues.

Linux rebuild is an *excellent* way to test physical hardware. It
stresses the components like nothing else :-)

PS. Ever get any signal 11's from gcc? Glaring sign your hardware
ain't up to par.

Cheers,
Filip G.

------------------------------

Date: Mon, 27 Mar 2000 13:23:13 -0800
From: Andre Charbonneau <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel
Subject: FDCC sets...

Hi,
Does anyone here has information about FDCC sets and if they are
currently supported in Linux?

Thanks,
-- 
Andre Charbonneau
Software Engineer
Corel Corporation
728-0826 x5612

------------------------------

From: [EMAIL PROTECTED] (Filip M. Gieszczykiewicz)
Subject: Re: linux hang !
Date: 27 Mar 2000 13:41:15 -0500

In Article <[EMAIL PROTECTED]>, through puissant locution, valery 
brasseur <[EMAIL PROTECTED]> soliloquized:
>from time to time my PC hang.
>when in this state I couldn't do anything : no keyboard, no network,
>nothing seems to respond and I see no trace in the system logs !!!
>did some body have any idea ? how can I debug that ?
>note : my kernel is a 2.2.14 with a RH6.0 install.

Suspect hardware. Are you overclocking? Is the fan on the CPU dying?
When you created your filesystems, did you do 'badblocks -w' on them
first? How old is your hardware? etc. etc etc.

here's a tip: Fire up X, fire up a few copies of netscrape, go into
the 2.2.14 kernel directory, [check you have ~64MB swap :-], and
do a "make clean; make dep; make bzImage".

Did it lock up solid? ;-)

Recompile with the SysRq key enabled - read the docs how to do that.

Cheers,
Filip G

------------------------------

From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: need the source code of fsck
Date: 27 Mar 2000 13:42:10 -0500
Reply-To: [EMAIL PROTECTED]

In article <[EMAIL PROTECTED]>, Hasan Jamal wrote:
> I need the source code of "fsck", the file system checker under the
> /sbin
> directory. 
> I have searched most of the ftp archives related to linux and did not
> find anywhere. 

I believe that it is part of the e2fsprogs:
http://web.mit.edu/tytso/www/linux/ext2.html

-- 
Paul Kimoto             <[EMAIL PROTECTED]>

------------------------------

From: [EMAIL PROTECTED] (Mumit Khan)
Subject: Re: Windows CE target for GCC?
Date: 27 Mar 2000 19:14:32 GMT

In article <PkED4.3982$[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
>Actually you can (http://www.linuxce.org/) but that's not an issue here. Gcc
>can produce win32 binaries, so why not CE. 

GCC and binutils development sources have Win-CE support. Please browse
through the respective mailing lists for more info. I don't know how
complete or robust the support is however.

I understand there were quite a few "interesting" challenges to support 
CE targets, so it's not as simple `... win32 binaries, so why not CE'.
Also, note that the win32 support in GCC/Binutils typically implies Intel 
architecture, and CE needs a lot more than that.

Cygnus Solutions/Red Hat did the work.

Regards,
Mumit


------------------------------

From: Daniel Dorau <[EMAIL PROTECTED]>
Subject: Serial Port -> No Interrupts !?
Date: 27 Mar 2000 19:21:52 GMT

Hello there,
I have a problem with my serial port (Intel BX chipset, Linux 2.2.12,
Debian 2.1). The serial port seems to send no interrupts.
The serial module does not register the interrupts correctly, I guess.

Loading the module shows:

Mar 27 21:09:11 wds kernel: Serial driver version 4.27 with SHARE_IRQ
DETECT_IRQ enabled 
Mar 27 21:09:11 wds kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A 
Mar 27 21:09:11 wds kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A 

It seems to be all ok, but /proc/interrupts does not list those
interrupts and adding a lot of debugging messages into serial.c
shows that its interrupt handler is called only by a timer
function but not due to actual interrupts. This causes a delay
of 5-10 seconds until a change of a modem status line is detected
by a TIOCMIWAIT ioctl.

Calling setserial /dev/ttyS0 irq 4 does not help either.

How can I get that serial.c to register the interrupts properly?

-- 
Daniel Dorau                            [EMAIL PROTECTED] 
<< Linux is like living in a tipi: No windows, no gates, Apache inside >>
       PGP key available, send mail with 'Subject: send pgp key' 
            fingerprint: 8D7E0B2F9E2E5338  DB7B24742E8B2EAE 

------------------------------

From: "Robert H. de Vries" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: POSIX timer implementation available.
Date: Mon, 27 Mar 2000 21:24:41 +0200

Kaz Kylheku wrote:

> An implementation of the posix clock_* and timer_* functions is available
> at http://users.footprints.net/~kaz/posixtimer.html.
>
> Everything seems to work, except areas where there isn't enough support (no
> sigqueue(), no support for new style signal handlers. timer_getoverrun()
> always returns zero).
>
> The clock_* functions basically augment gettimeofday() and friends,
> and work with struct timespec instead of struct timeval.
>
> The POSIX timer interface is a way to have signals delivered after a time
> delay, with the option for retriggering. More importantly, the timer expiry
> notifiation can be done in a separate thread rather than by delivery of a
> signal. The interface allows the user to specify what attributes the timer
> thread should have (e.g. priority).
>
> I don't have this neatly packaged, and you may find that some of the
> definitions in public.h conflict with <signal.h>. The idea behind this
> release is to get some feedback.

At  http://www.rhdv.cistron.nl/posix.html you can find a complete kernel based
implementation of the complete set of POSIX timer functions. This
implementation is 100% compliant.

    Robert


--
Robert de Vries
[EMAIL PROTECTED]




------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: POSIX timer implementation available.
Reply-To: [EMAIL PROTECTED]
Date: Mon, 27 Mar 2000 19:55:19 GMT

On Mon, 27 Mar 2000 21:24:41 +0200, Robert H. de Vries <[EMAIL PROTECTED]> wrote:
>At  http://www.rhdv.cistron.nl/posix.html you can find a complete kernel based
>implementation of the complete set of POSIX timer functions. This
>implementation is 100% compliant.

This implementation is far from complete. Completely absent is the support
for SIGEV_THREAD, which I view as a notification mechanism which eclipses
SIGEV_SIGNAL in usefulness and importance.

My user-space implementation provides the SIGEV_THREAD support described in the
Single UNIX Specification. This support allows the user to specify that
a timer notifiation be executed in the context of a thread which calls a
specified function. What is more, the user can choose the attributes of
the thread (other than making the thread joinable, which is explicitly
forbidden.)

Having a notification function invoked in a thread is far more useful than the
delivery of a signal, because you can do more in the context of a thread than
in the context of a signal: you have full use of the library functions, 
including the POSIX threading functions themselves. Such a notification
call can acquire and release mutex locks, perform I/O, allocate memory, etc.

Signal notification makes the most sense in single threaded applications.
Signals and multi-threaded programming usually make a poor mixture. 

I'm not saying any of this to criticize your work; but I think that as long as
the threading implementation (LinuxThreads) is based heavily in user space,
than at least the SIGEV_THREAD feature of the POSIX timers also must be in user
space, because it requires the services of the LinuxThreads library in order to
create a proper LinuxThreads thread.

What we do need from the kernel to make the timers more fully compliant is
support for the new style signals.  User space can use a dedicated thread to
deliver the signals, but without the advanced support, I can only use
pthread_kill() to give an ``old-fashioned'' signal to a particular thread. The
timer spec allows the user to use new features of sigaction to register a new
kind of signal function which receives all kinds of new context info (which,
among other things, can distinguish whether the signal was caused by an
old-style kill or the new function sigqueue.). An of course, the shared signal
queue is needed so that the kill goes to any thread within the ``process''
which has the signal unblocked, rather than to a particular thread.
If all this was in place, then the dedicated ``signal thread'' I hacked
up would simply call sigqueue() instead of pthread_kill() and the kernel
would take care of the rest.

I don't see a big need for the kernel to actually manage these timer objects
and handle the expiry. Though a mixed approach could work; the kernel could
perform the SIGEV_SIGNAL events itself, and handle the timing of SIGEV_THREAD
ones but defer their processing to user space: this is analogous to using
a kernel web server to handle static page requests, and passing the clumsy
dynamic stuff to a user space server.  It would avoid having to context
switch a a user space thread to deliver a signal, which is a big win.

Another issue is that struct sigevent is used in interfaces other than the
timer. What about providing the notice of asynchronous I/O completion as
a SIGEV_THREAD? It might be useful for the library to have a common module
for managing and dispatching these threads. (I haven't addresses this in 
my timer module, which maintains a internal threads that are dedicated for
waiting on their timer queues and doing the callouts.)

-- 
#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
******************************

Reply via email to