Linux-Development-Sys Digest #848, Volume #7     Fri, 12 May 00 11:13:13 EDT

Contents:
  Re: DNS problem (Mark(un-MASKForsyth))
  Re: pid vs. thread question (Stefaan A Eeckels)
  Re: libpath to shared objectws (Anand Krishnamoorthy)
  Re: ANSI C & void main() ("Mark Graybill")
  Re: ANSI C & void main() (Johan Kullstam)
  How much disk space ? ("Rini van Zetten")
  Re: ANSI C & void main() (Paul Kimoto)
  URGENT - HELP Forming ICMP Header ([EMAIL PROTECTED])
  URGENT - HELP Forming ICMP Header ([EMAIL PROTECTED])
  Re: ANSI C & void main() (Alexander Viro)
  [Help] is there any useful s/w for serial communication?? ("Kim, Jeong-Hwan")
  Re: LILO Win+Linux on an old system (Paul D. Smith)
  Interrupt handler problem (Arnaud Westenberg)

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

From: [EMAIL PROTECTED] (Mark(un-MASK)Forsyth)
Crossposted-To: comp.os.linux.networking,comp.os.linux.misc
Subject: Re: DNS problem
Date: Fri, 12 May 2000 09:30:29 +1000
Reply-To: [EMAIL PROTECTED]

On 9 May 2000 18:45:02 GMT, Steve <[EMAIL PROTECTED]> wrote:
>

[deletia]

>-- 
>Cheers
>Steve              email mailto:[EMAIL PROTECTED]
>
>%HAV-A-NICEDAY Error not enough coffee  0 pps. 

Oh man...AT least get the error message correct. It really should read :-

%HAV-E-NICEDAY Error not enough coffee !AS pps.

or the original error :-

%EYE-I-CLOSED No cafeine eyes closed.

This is the root cause of the problem. The second error is a consequence.

[1]

>
>web http://www.ndirect.co.uk/~sjlen/
>
>or  http://start.at/zero-pps
>
>  9:40am  up 12 days, 11:41,  2 users,  load average: 1.08, 1.02, 1.00



[1] Non OpenVMS-heads can safely ignore this.

-- 
Mark F...
unMASK for e-mail

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

From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: pid vs. thread question
Date: Fri, 12 May 2000 14:01:16 +0200

In article <[EMAIL PROTECTED]>,
        Eric Taylor <[EMAIL PROTECTED]> writes:
> I've read that 2 or more processes can have the
> same pid. If this is true, then does this mean
> that everything I might try to do that is pid
> based, like signals, affect all processes with
> the same pid? 
PIDs are a unique representation of a collection
of resources (memory map, open files, etc).
Two kernel schedulable entities can refer to the
same resources, and hence will show up in 'ps'
and friends as "processes with the same ID".
In fact, they are two schedulable entities using
the same resources. Hence they can be running
on different processors (if you have them).

> Is the reason for the same pid feature to support
> threads?
Well, the reason you see two entries in the process
table with the same PID is that the kernel supports
threads.

> If threads are implemented as a group of processes
> that share resources, I wonder how it handles 
> opening files, or mallocs (if it needs to extend
> memory) getting propogated to all the other 
> processes (threads?).
They are "propagated" by virtue of being there. Things 
don't need to be propagated, as all resources
are shared.

> When sending a signal from one proc to another on
> a "kernel supported thread" model, does the signal go to all
> threads or just one thread (if so which one)? How would
> that map into the linux implementation?
Signals are sent to PIDs. When you send a signal to a
multithreaded process, the currently active threads 
will be suspended, and the signal handlers will execute.

> Is there any other kernel support for threads, 
> is pthreads really just a posix library magic trick that
> makes it look like linux has a kernel supported thread
> model?
Magic and computers don't jive. Libraries can be used to
map one API onto another, but if the kernel doesn't support
threads a library can not "magically" fix that.

What you need to realize is that Linux switches processes
faster than NT switches threads, and that in the UNIX model
there aren't many advantages to threads. Or put differently,
on NT (and its daddy, VMS), you *need* threads to write 
even a moderatly performing server, and hence you accept the
hassles of using threads as compared to forking a process 
per connection.
Threads are *not* a panacea, and *do* put a lot of responsibility
on the programmer (if you have two strands of execution 
accessing the same memory, you have to be damn careful!).

Whereas on UNIX one can write a more than decent server by
forking a process per connection, NT cannot even use a thread
per connection, and one has to use a hybrid model (event-driven
handling of multiple connections in a small number of threads).
The fact that in multi-threaded NT programs most of the variables
tend to be "thread-local" indicates that NT threads are a (poor)
substitution for UNIX's light-weight processes and fork()
system call.

Just IMHO, obviously.

-- 
Stefaan
-- 
--PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)--
Ninety-Ninety Rule of Project Schedules:
        The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.

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

From: Anand Krishnamoorthy <[EMAIL PROTECTED]>
Subject: Re: libpath to shared objectws
Date: Fri, 12 May 2000 18:04:10 -0400


==============14C94D00E6AA11F53C442B69
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit




> 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.
>

Go to your home directory (/home/your_login_name) and edit the
".bash_profile" file to add the LIBPATH setting to it.This will set the
LIBPATH everytime bash is started (through the TTYs when you login or when
a terminal is opened through X)

I am not pretty sure how to do it in for X as a whole. I am investigating
that.. Shall get back to you once I find that out.

Anand .K

[EMAIL PROTECTED]


==============14C94D00E6AA11F53C442B69
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
<I></I>&nbsp;
<BR><I></I>&nbsp;
<BLOCKQUOTE TYPE=CITE><I>I need to know how to set a libpath to a bunch
of shared objects so I can run</I>
<BR><I>my program that links to them.&nbsp; I cannot get at the etc/ld_so.conf
file</I>
<BR><I>since I don't have permissions.&nbsp; Is there another way.</I>
<BR><I></I>&nbsp;</BLOCKQUOTE>
Go to your home directory (/home/your_login_name) and edit the&nbsp; ".bash_profile"
file to add the LIBPATH setting to it.This will set the LIBPATH everytime
bash is started (through the TTYs when you login or when a terminal is
opened through X)

<P>I am not pretty sure how to do it in for X as a whole. I am investigating
that.. Shall get back to you once I find that out.

<P>Anand .K

<P>[EMAIL PROTECTED]
<BR>&nbsp;</HTML>

==============14C94D00E6AA11F53C442B69==


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

Reply-To: "Mark Graybill" <[EMAIL PROTECTED]>
From: "Mark Graybill" <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: Fri, 12 May 2000 12:55:12 GMT


Erik Max Francis wrote in message <[EMAIL PROTECTED]>...
>Mark Graybill wrote:
>
>> Since my C days during my undergraduate studies were pre-ANSI
>> standard, and
>> figuring my memory was failing, I checked with the Computer Science
>> and
>> Engineering department at the University of Minnesota, and found that
>> the
>> original standard did allow void main().
>
>What in the world are you talking about?  What "original standard"?
>ANSI C has always required that main return int.


Tell me when the original standard was published. (Hint: 16 >> 4; 144 >> 4;
128 >> 4; 144 >> 4;)

Where you programming in C then?

>> I doubt the new C standard includes it, ...
>
>What in the world makes you say that?


Because I had a hunch void main() was removed from the standard and all of
you people argued the same point.

>> ... which is one reason why I didn't pay
>> the large fee for obtaining a copy (the other is I don't program in C
>> anymore.)
>
>What is that?  "I suppose I'm right, so I won't bother verifying it"?


You misread.  I said I doubt the current standard includes void main() as
legal, so why pay $135 to get it.  Would you purchase it just for a debate
on a newsgroup after you've been convinced the current standard (the only
one that counts) would verify the oposing argument - especially if you
wouldn't use it in your practice?  If so, you should take a course in money
management. :)

>> As far as undefined behavior, which is not defined as behavior not
>> advocated
>> by ANSI standards but rather behavior not yet observed, the behavior
>> of
>> using void main() is defined if it is consistently observed in a large
>> sample of popular compilers and platforms.
>
>Get a copy of the ANSI C standard, or read the comp.lang.c FAQ.
>"Undefined behavior" has a very specific meaning, as defined in such
>standards; it means "the compiler may produce code which does anything
>it pleases."  You can argue that is not the case, and that undefined
>behavior is okay if you mean well and know that a few compilers accept
>it, but that does not make it any more true.


Why would I read comp.lang.c.FAQ?  Unless it's run by ANSI committe members,
it's contents are not the standard anymore than my book written by the
creators of C themselves, is the standard.  Besides, for one, I don't
program in C anymore; for two, if I did, I wouldn't be doing very well to
need to read answers to FAQ to C programming after more than a decade of C
programming.  :)

My original reply was relying on memory of old-world programming, which was
my mistake. Perhaps I was just bored. Or maybe I was just wanting to be
antagonistic.  Either way it brought to light some interesting interaction.

We are always at the mercy of the code the compiler produces.

When C first came out, it allowed for void main().  I'm sure Dennis Ritchie
has an original copy in his archives.  I will see if he will consult it.

>Did you even read the original thread?


All the compilers I've used allows for its use, and they don't produce
erratic behavior, or undefined behavior as you call it.  This is probably
due to legacy compatibility (a good attention to detail to have.)

You obviously don't understand what reality (what we call reality), really
is.

-Mark

/*
 * It is unfortunate that human kind has the natural propensity to make
opinion fact.
 * - Anonymous
 */



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

From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: 12 May 2000 09:35:16 -0400

"Mark Graybill" <[EMAIL PROTECTED]> writes:

> Kaz Kylheku wrote in message ...
> >Undefined behavior is quite simply behavior that is not defined.  The
> standard
> >is a merely a requirement specification which describes features that the
> >conforming language implementation must provide, and rules that programs
> must
> >obey in order to be acceptable to implementations.  Undefined behavior is
> >simply the absence of requirements. If you invoke it, you are in the hands
> of
> >the implementor. The role of standards is not to advocate or observe, but
> >simply to specify---or not, as the case may be.
> 
> Agreed - we are at the mercy of the tools ghouls.  Nothing is more annoying
> than misbehaving tools.

we are *not* at the mercy of the tools ghouls.  just use "int main"
and you have the C standard to smack them upside the head.  using the
tool in an improper way and getting hurt isn't the fault of the tool
or its implementors.  by flagrantly violating the C standard using
"void main" you *deserve* to lose.

-- 
johan kullstam l72t00052

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

From: "Rini van Zetten" <[EMAIL PROTECTED]>
Subject: How much disk space ?
Date: Fri, 12 May 2000 15:57:17 +0200

Hi all,

Does anybody know how much disk space a Linux based system minimal requires.
It should have a X-windows system.
(I would like to have it on a flash disk)

Rini

[EMAIL PROTECTED]



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

From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: ANSI C & void main()
Date: 12 May 2000 10:10:53 -0500
Reply-To: [EMAIL PROTECTED]

In article <QaTS4.59706$[EMAIL PROTECTED]>, Mark Graybill
wrote:
> When C first came out, it allowed for void main().  I'm sure Dennis Ritchie
> has an original copy in his archives.  I will see if he will consult it.

K&R2, in the summary of changes between K&R (first edition) and the ANSI
standard, says (p. 259):

: New keywords (void, const, volatile, signed, enum) are introduced.

-- 
Paul Kimoto             <[EMAIL PROTECTED]>

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

From: [EMAIL PROTECTED]
Subject: URGENT - HELP Forming ICMP Header
Date: Fri, 12 May 2000 14:08:46 GMT

Hello,

Can anyone help me in forming ICMP header. What I am doing is

#define SKB_SIZE        sizeof(struct iphdr)+sizeof(struct icmphdr)

void pkt_send(char *dest,char *src)
{
        struct icmphdr *icmph;
        struct iphdr *iph;
        struct rtable *rt;
        static int icmp_seq = 0;
        int i,errno;
        struct sk_buff *skb;
        struct device *dev = dev_get("eth1");

        skb = alloc_skb(SKB_SIZE+dev->hard_header_len+15,GFP_ATOMIC);
        skb->dev = dev;
        skb_reserve(skb,(dev->hard_header_len+15)&~15);

        /* form ip hdr */
        skb->nh.iph = iph = (struct iphdr *)skb_put(skb,sizeof(struct
iphdr));

        /* fill ip header */
        iph->daddr = in_aton(dest);
        iph->saddr = in_aton(src);
        iph->version = 4;
        iph->ihl = 5;
        iph->tos = 0;
        iph->tot_len = htons(skb->len);
        iph->id = 10;
        iph->frag_off = 0;
        iph->ttl = 64; /* default ip ttl */
        iph->protocol = IPPROTO_ICMP; /* icmp */
        iph->check = 0;
        iph->check = ip_fast_csum((unsigned char *)iph,iph->ihl);
        printk("\n ip formed %s",dest);

        /* fill icmp hdr */
        skb->h.icmph = icmph = (struct icmphdr *)skb_put(skb,sizeof
(struct icmphdr));
        icmph->type = ICMP_ECHO;
        icmph->code = 0;
        icmph->checksum = 0;
        icmph->un.echo.id = 0;
        icmph->un.echo.sequence = icmp_seq;
        icmph->checksum = cksum((u_short *)icmph,sizeof(icmph),0);
        icmp_seq++;

        skb->protocol = __constant_htons (ETH_P_IP);

        /* now to get the routing info*/
        rt = NULL;
        ip_route_output(&rt,iph->daddr,iph->saddr,0,0);
        if(&rt->u.dst == NULL)
                printk("\n error");
        skb->dst = &rt->u.dst;
        skb->dst->output(skb);
        printk("\n pkt send to %s",dest);
}

u_short cksum(const u_short *buf, int length, u_short csum)
{
        int nleft = length;
        const u_short *buffer = buf;
        int sum = csum;
        u_short ret_val = 0;

        while(nleft > 1)
        {
                sum += *buffer++;
                nleft -= 2;
        }
        if(nleft == 1)
        {
                sum += htons(*(u_char *)buffer << 8);
        }
        sum = (sum >> 16) + (sum & 0xffff);  /* add top 16 to low 16 */
        sum += (sum >> 16);             /* add carry */

        ret_val = ~sum;                 /* truncate to 16 bit */
        return(ret_val);
}

At the destination through tcpdump I can c the packet coming but giving
wrong icmp csum error and because of which not getting the reply for
the same.
 Can any one guide me in this regards.

Thanks in advance
Bhagyashree


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED]
Subject: URGENT - HELP Forming ICMP Header
Date: Fri, 12 May 2000 14:08:26 GMT

Hello,

Can anyone help me in forming ICMP header. What I am doing is

#define SKB_SIZE        sizeof(struct iphdr)+sizeof(struct icmphdr)

void pkt_send(char *dest,char *src)
{
        struct icmphdr *icmph;
        struct iphdr *iph;
        struct rtable *rt;
        static int icmp_seq = 0;
        int i,errno;
        struct sk_buff *skb;
        struct device *dev = dev_get("eth1");

        skb = alloc_skb(SKB_SIZE+dev->hard_header_len+15,GFP_ATOMIC);
        skb->dev = dev;
        skb_reserve(skb,(dev->hard_header_len+15)&~15);

        /* form ip hdr */
        skb->nh.iph = iph = (struct iphdr *)skb_put(skb,sizeof(struct
iphdr));

        /* fill ip header */
        iph->daddr = in_aton(dest);
        iph->saddr = in_aton(src);
        iph->version = 4;
        iph->ihl = 5;
        iph->tos = 0;
        iph->tot_len = htons(skb->len);
        iph->id = 10;
        iph->frag_off = 0;
        iph->ttl = 64; /* default ip ttl */
        iph->protocol = IPPROTO_ICMP; /* icmp */
        iph->check = 0;
        iph->check = ip_fast_csum((unsigned char *)iph,iph->ihl);
        printk("\n ip formed %s",dest);

        /* fill icmp hdr */
        skb->h.icmph = icmph = (struct icmphdr *)skb_put(skb,sizeof
(struct icmphdr));
        icmph->type = ICMP_ECHO;
        icmph->code = 0;
        icmph->checksum = 0;
        icmph->un.echo.id = 0;
        icmph->un.echo.sequence = icmp_seq;
        icmph->checksum = cksum((u_short *)icmph,sizeof(icmph),0);
        icmp_seq++;

        skb->protocol = __constant_htons (ETH_P_IP);

        /* now to get the routing info*/
        rt = NULL;
        ip_route_output(&rt,iph->daddr,iph->saddr,0,0);
        if(&rt->u.dst == NULL)
                printk("\n error");
        skb->dst = &rt->u.dst;
        skb->dst->output(skb);
        printk("\n pkt send to %s",dest);
}

u_short cksum(const u_short *buf, int length, u_short csum)
{
        int nleft = length;
        const u_short *buffer = buf;
        int sum = csum;
        u_short ret_val = 0;

        while(nleft > 1)
        {
                sum += *buffer++;
                nleft -= 2;
        }
        if(nleft == 1)
        {
                sum += htons(*(u_char *)buffer << 8);
        }
        sum = (sum >> 16) + (sum & 0xffff);  /* add top 16 to low 16 */
        sum += (sum >> 16);             /* add carry */

        ret_val = ~sum;                 /* truncate to 16 bit */
        return(ret_val);
}

At the destination through tcpdump I can c the packet coming but giving
wrong icmp csum error and because of which not getting the reply for
the same.
 Can any one guide me in this regards.

Thanks in advance
Bhagyashree


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: ANSI C & void main()
Date: 12 May 2000 10:29:44 -0400

In article <[EMAIL PROTECTED]>,
Johan Kullstam  <[EMAIL PROTECTED]> wrote:

>we are *not* at the mercy of the tools ghouls.  just use "int main"
>and you have the C standard to smack them upside the head.  using the
>tool in an improper way and getting hurt isn't the fault of the tool
>or its implementors.  by flagrantly violating the C standard using
>"void main" you *deserve* to lose.

Just to add some irony: while the guy in question acts like a luser,
there is one environment where void main is _mandated_. And before you
start mentioning $LUSERISH_COMPANY_OF_CHOICE - nope. It isn't. Yes, it's
not UNIX. Nope, they don't pretend that it's ANSI C. However, you gotta
give them their due - after all, one of them invented the language...

(The thing being: Plan 9 doesn't have exit(2), it has exits(2), with
corresponding change in wait(2); they pass strings instead of the exit
codes and char *main() would be even more against the spirit of language.
Since in UNIX we only have exit codes...)

-- 
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

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

From: "Kim, Jeong-Hwan" <[EMAIL PROTECTED]>
Subject: [Help] is there any useful s/w for serial communication??
Date: Fri, 12 May 2000 14:38:27 GMT

Hi, every one
Is there any useful s/w for x-window based serial communication
which I wish to use for monitoring data from COM port.
Many people recommend minicom, but it is text based.


Thanks in advance
Kim




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

From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: LILO Win+Linux on an old system
Date: 12 May 2000 10:38:18 -0400
Reply-To: [EMAIL PROTECTED]

%% Josef Moellers <[EMAIL PROTECTED]> writes:

Josef: thanks for your time on this.

I spent a good couple of hours last night, trying all sorts of things,
but nothing worked :(.

I've installed LOADLIN and that works, so at least now I can boot faster
than from my rescue disk :-/, but this system is going to be a firewall
connected to my cable modem so I want it to auto-boot into Linux.  AFAIK
DOS's menu system doesn't have a timeout feature like LILO does.

First, I discovered that, indeed, the disk geometries are mismatched.
Linux's fdisk reports that /dev/hda (Windows) has sectors=63, heads=64,
and cylinders=525 and /dev/hdb (Linux) has sectors=63, heads=64, and
cylinders=1023.

But, the BIOS setup auto-detect for the disks reports that /dev/hda has
sectors=63, heads=16, and cylinders=2100 and /dev/hdb has sectors=63,
heads=16, and cylinders=4096 (I'm not 100% sure I remember the right
cylinder value for /dev/hdb, but it was 40xx).

Adding "linear" definitely doesn't help, and I definitely re-ran lilo
every time... I was very careful about that.

I decided to try to make a bootable floppy rather than booting off of
the rescue disk, since that's so slow.  I followed the instructions in
the mini-HOWTO and in the user's guide, but it also didn't work!  This
time it got to "LI" then froze; no infinite repeats.

I added disk= params to the lilo file; my lilo.floppy looked something
like this:

  boot=/dev/fd0
  map=/floppy/map
  delay = 10
  ramdisk = 0
  timeout = 100
  prompt
  disk=/dev/hda
      bios=0x80
      sectors=63
      heads=16
      cylinders=2100
  disk=/dev/hdb
      bios=0x81
      sectors=63
      heads=16
      cylinders=4096
  image=/vmlinuz
      root=/dev/hdb1
      label=linux
      read-only
  other=/dev/hda1
      label=msdos
      table=/dev/hda
      loader=/floppy/chain.b

I used mke2fs on a floppy disk in /dev/fd0, then mounted it on /floppy
and copied the boot.b and chain.b files to it, then ran lilo -C
lilo.floppy.  Lilo didn't complain about anything, and wrote to the
floppy.  I rebooted; it stuck at "LI".

I tried adding "linear" and re-running lilo -C lilo.floppy, and the same
thing happened.

So, then I read that LILO can actually boot off of a DOS partition!  I
have installed Windows98, but I was careful to use FAT16 not FAT32, so
it seems that should work for me.

I mount /dev/hda1 on /c as an "msdos" filesystem, and created this
lilo.dos config:

  boot=/dev/hda
  map=/c/boot/map
  delay = 10
  ramdisk = 0
  timeout = 100
  prompt
  disk=/dev/hda
      bios=0x80
      sectors=63
      heads=16
      cylinders=2100
  disk=/dev/hdb
      bios=0x81
      sectors=63
      heads=16
      cylinders=4096
  image=/c/boot/vmlinuz
      root=/dev/hdb1
      label=linux
      read-only
  other=/dev/hda1
      label=msdos
      table=/dev/hda
      loader=/c/boot/chain.b

I created a /c/boot directory, copied boot.b, chain.b, and vmlinuz to
it, then ran lilo -C lilo.dos.  It didn't complain, and installed stuff
into that directory.

I rebooted, and it hung again at "LI".  I tried adding "linear" and
re-running lilo -C lilo.dos, and the same thing happened.

Then, I went to bed :(.

You mentioned in your message that the cylinder value is useless; can
that be right, when the only difference in geometry between my 1G and 2G
HD that BIOS reports is in the cylinder value?

I'm at a loss...

-- 
===============================================================================
 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.

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

Date: Fri, 12 May 2000 15:08:55 +0200
From: Arnaud Westenberg <[EMAIL PROTECTED]>
Subject: Interrupt handler problem

Hi all,

I have the following problem:

To address my hardware I had to write low-level read and write
functions. These functions first write the desired address to the base
address of my hardware and then I can read or write the contents of the
desired address from the base address plus 1.
(could somebody tell me the name of this sort of memory addressing?)

The problem begins at interrupt time. The lowlevel hardware access is so
slow that I loose the next interrupt and message (no hardware buffer). I
have to read several successive bytes wich means several low-level
operations. Normally one would use insb.

This problem occurs on a P160, on a 486 with hardware wich is direct
addressable I have no problems.

Does someone has any suggestions?

TIA 

Greetings Arnaud

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


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