Linux-Development-Sys Digest #901, Volume #7 Wed, 24 May 00 14:13:17 EDT
Contents:
Re: Need ideas for university funded project for linux (Praedor Tempus)
Re: Need ideas for university funded project for linux (Leslie Mikesell)
Writing driver for AMCC 5933 based PCI card (Julian Back)
Re: Linux Bootable CD (bill davidsen)
Re: Need ideas for university funded project for linux (Alexander Viro)
Re: Need ideas for university funded project for linux (JEDIDIAH)
Re: Need ideas for university funded project for linux (Praedor Tempus)
Re: What !@#$ moron colorised g++? (Michal Jaegermann)
Re: Need ideas for university funded project for linux (Praedor Tempus)
Re: Need ideas for university funded project for linux (Praedor Tempus)
Re: Need ideas for university funded project for linux (JEDIDIAH)
Unexpected hang in write() call (Mark Adams)
----------------------------------------------------------------------------
From: Praedor Tempus <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Wed, 24 May 2000 11:14:50 -0600
Dowe Keller wrote:
>
> On 23 May 2000 13:07:01 GMT, David T. Blake <[EMAIL PROTECTED]> wrote:
> >David Steuber <[EMAIL PROTECTED]> wrote:
> >> [EMAIL PROTECTED] (David T. Blake) writes:
> >
> >> ' Section 3b) (on modifications to QT)
> >> ' When modifications to the Software are released under this
> >> ' license, a non-exclusive royalty-free right is granted to the
> >> ' initial developer of the Software to distribute your modification.
> >>
> >> The right is non-exlusive. That means everyone can get that right. I
> >> think TrollTech is just trying to prevent forking of the Qt library
> >> here.
> >
> >No, they are ensuring they can continue a revenue stream based
> >on contributions from outside the company. They will take your
> >modification and include it in QT Pro.
> >
> >> As I said previously, if you don't like the Qt license, you can
> >> create your own library. There is no one to stop you. You can
> >> also use one of the other available libraries.
> >
> >I was not arguing I should create a library. I was not arguing
> >against QTs right to use whatever license they like. I was
> >arguing that people should think twice before referring to QT
> >licensing as substantially free or "open source". The right to
> >fork is absent, the right not to have your contributions included
> >in proprietary works (such as QT Pro) is gone, and QT gets a copy
> >of EVERYTHING that even links to their code, even if it is not
> >publicly available.
>
> I agree about the right to fork, but several free software licenses
> (the X-Windows, and BSD licenses come to mind) allow people to make
And the right to fork is good because...? Because it is GOOD to
fragment
software and libraries so that apps fail to work nicely? So that if you
want app A to work, built on a forked library, you have to install yet
another version in addition to the original - or worse, replace the old
with the new, probably/possibly breaking all your software based on
the pre-forked libs?
I can't see the "right to fork" as a good thing. Forking is what killed
the unix baby early on. It is brought up as a fear of something that
could possibly kill linux (for general use...but then, there are
fascist,
elitist linux-users who would welcome this just so they can remain part
a silly "exclusive" club - barring anyone but themselves from using
their pet operating system).
I would like a nice, clear explanation of why forking should be
considered
good. Why is there a rampant, unreasoned hatred of standards?
Standards
make coder's lives easier, make user's lives easier. SOME things should
be standardized (the kernel is standardized and controlled thru one
point:
Linus...so is this evil and bad? Should the kernel not be allowed to
fork
to extremis?). Standardizing does NOT automatically mean stagnation or
crap. It simply means concerted, generally accepted measured changes at
intervals so that you KNOW that this or that API wont be broken on you
with each iteration/upgrade (M$ does this). MesaGL/OpenGL is also
standardized and doesn't go off on forking jaunts...so they are evil?
praedor
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: 24 May 2000 12:19:37 -0500
In article <[EMAIL PROTECTED]>,
David Steuber <[EMAIL PROTECTED]> wrote:
>' Just putting the code on the same machine is not a problem.
>' You must create a 'derived work', which has been commonly
>' described as code linked in a single process. Linking
>' GNU readline (GPL, not LGPL) into a database control
>' program that used a commercial client library would be
>' an example. While you can probably get away with building
>' such a program yourself, distributing it would be at
>' least questionable, especially if you redistributed a copy
>' of the GPL'd readline with it. Now for something even
>' more confusing, consider what happens if you have a
>' perl script that dynamically loads readline and also
>' uses DBI which can pull in an assortment of database
>' client libraries at runtime, including commercial versions.
>' If this ends up linking to (say) Oracle libs, does it
>' become illegal to distribute the script?
>
>I would think not. The dynamicly loaded modules are not part of the
>script, they are just used by the script.
But Richard Stallman has made threats against people shipping
anything that linked against GPL'd code that was not GPL'd
itself. However any claim of control over the run-time
derived work goes away if an alternative non-GPL'd library
could be used instead. In a generic perl/DBI case, this
would seem to apply, since DBI can invoke a number of
different database libraries. But, what if the specific
distribution contained oracle-specific routines in the
perl script and would not work with anything else? Perl
isn't a problem here because it has the artistic license
as well as the GPL - I was using a case of also linking
readline as the potential problem).
>' The GPL instead shackles any other code linked into a derived
>' work with its own restrictions, or in the cases where
>' other code already has different restrictions it makes the
>' combination impossible.
>
>I think the only code shackled by GPL is the code that is derived from
>GPL. In the case of linkage above, the top level code must be
>compatible with GPL, but the libs it uses does not have to be.
No, readline is specifically GPL instead of LGPL to encumber
as much additional code as possible. Or from the other point
of view to prevent actually using it as many places as possible.
>If I have GPL lib A and proprietary lib B and my code C uses A and B,
>then my code C is GPL. I can distribute my code without distributing
>A or B. My code may even be able to work without A or B with reduced
>or different functionality.
According to Stallman, you are forced to GPL your code if you
distribute it and it won't work without A. But you can't
GPL it if it won't work without B (motif being a borderline
exception over the years).
>OK, you say reusable components like libs are better off with a less
>restrictive license. That is fair. But if the lib is under a BSD
>style license, Microsquish can take that library, change it, and not
>release any of the changes back to the public.
Yes, which does nothing to damage the code that continues to
be available.
>Once you use an
>'enhanced' feature, you are tied to a non-free Microsquish library.
>You are at the mercy of Microsquish. If the code is at least LGPL,
>then the library code is still going to be free. Microsquish must
>make its changes available as source.
Unlikely. In the former case you will at least have working,
well tested code as the base and we won't have to deal with
a worse alternative. If the base code is not usable in a
proprietary product, the alternative is to re-invent it, usually
badly. Imagine where we would be if every vendor including
tcp/ip had re-written it from scratch because the bsd version
could not have been used. Microsoft and Linux both went this
route even though it wasn't required, and the world has gone
through several years of pain as a result shaking out bugs
that we really didn't need in the first place.
>Now if the library is GPL, then anything linking too it must also be
>GPL or GPL compatible. What about software that makes system calls in
>Linux? Must that also be GPL?
No, using the interface to the kernel has been specifically defined
as not constituting a derived work in the kernel COPYING file.
>Should I demand that Netscape ( now
>AOL ) release _all_ the code for Navigator? Surly all programs must
>make system calls at some level. Does the Linux kernel make
>commercial software for Linux impossible? Make that closed source,
>proprietary software. No Oracle or Sybase for Linux?
Without the exception that would be a possible interpretation
of the GPL.
>I guess that must mean running such software on *BSD instead. But
>what if the application uses networking protocols to link to other
>software? Is that linkage that GPL affects? How far does it go?
The usual interpretation is where the components are linked
into a single executable, but the line is pretty fuzzy in
these days of dynamic runtime linking, loadable modules, etc.
>Although I would prefere
>all software to be GPL, I do see the need to accommodate people who do
>not like the GPL.
There is also the issue of existing software components that are
not GPL'd and are under someone else's control. The GPL prohibits
anything that could be considered a derived work as a combination
with these.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Julian Back)
Subject: Writing driver for AMCC 5933 based PCI card
Date: Wed, 24 May 2000 17:24:26 GMT
Reply-To: [EMAIL PROTECTED]
I have written a driver for a PCI card based on the AMCC 5933 chip.
This chip supports DMA to read and write data to memory on the card.
My driver seems to work fine if I don't use the DMA (just read and
write to the FIFO on the chip directly). DMA to the card also seems
to work OK. But when I use DMA to read from the card the Linux system
completely locks up (you have to use the reset button). This happens
after several thousand successful transfers.
I suspected a problem with interrupt handling but I have now modified
the driver not to use interrupts but the crash still occurs if I enable
DMA from the card into the PCs memory.
A possibly related problem is that on some PCs (especiall PIIs) data DMAed
to and from the card occasionally gets corrupted. I got round this by
only DMAing 32 bytes or less at a time.
I would suspect a hardware problem with the card but there are Solaris x86
and Windows NT drivers for this card that use DMA and work OK (and I have
used the Solaris driver on a PC on which my Linux driver crashes). I also
program the chip's DMA registers in the same way as the Solaris driver does.
I am hoping to look at this with a PCI analyser but I can't understand why the
card should be behaving so differently on Linux.
Julian Back
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Linux Bootable CD
Date: 24 May 2000 17:23:14 GMT
In article <[EMAIL PROTECTED]>,
Jean-Claude MEILLAND <[EMAIL PROTECTED]> wrote:
| Does anybody know how to make a linux bootable CD with an entire linux
| system installed and a ram disk for the system to be usable. Just like
| Suse CD Live.
You need to understand initrd and the eltorito bootable CD stuff.
First, eltorito allows you to have a floppy image to boot, of 720, 1440,
or 2880k size. That gets copied to a ramdisk, and the ramdisk kernel
gets booted. I didn't say that well, but those are the things you need
to know.
After boot a single rc file gets executed, look it up but it might be
/linuxrc from memory. It can be a script or executable program like
bash.
This should get you started, I make bootable CDs, but I have a few
eltorito images I created a year ago and I don't start from scratch
anymore. This should be enough to look up the rest.
If you build a kernel you need RAMdisk and initial RAMdisk support in
the kernel. You can then mount a new root filesystem and the initrd will
be mounted on /initrd (again, from memory) if the mount point exists.
Check the LILO docs as well.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"Doing interesting things with little computers since 1979"(tm)
The hardest test of maturity is knowing the difference between
resisting temptation and missing a once-in-a-lifetime opportunity.
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: 24 May 2000 13:24:07 -0400
In article <[EMAIL PROTECTED]>,
Praedor Tempus <[EMAIL PROTECTED]> wrote:
[snip'a'lot]
>make coder's lives easier, make user's lives easier. SOME things should
>be standardized (the kernel is standardized and controlled thru one
>point:
>Linus...so is this evil and bad? Should the kernel not be allowed to
>fork
>to extremis?). Standardizing does NOT automatically mean stagnation or
Kernel _is_ allowed to fork. RTFGPL and for $DEITY sake, get the fuck out
of c.o.l.d.system with that off-topic drivel, will you?
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (JEDIDIAH)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Wed, 24 May 2000 17:31:11 GMT
On Wed, 24 May 2000 11:14:50 -0600, Praedor Tempus <[EMAIL PROTECTED]> wrote:
>Dowe Keller wrote:
>>
>> On 23 May 2000 13:07:01 GMT, David T. Blake <[EMAIL PROTECTED]> wrote:
>> >David Steuber <[EMAIL PROTECTED]> wrote:
>> >> [EMAIL PROTECTED] (David T. Blake) writes:
>> >
>> >> ' Section 3b) (on modifications to QT)
>> >> ' When modifications to the Software are released under this
>> >> ' license, a non-exclusive royalty-free right is granted to the
>> >> ' initial developer of the Software to distribute your modification.
>> >>
>> >> The right is non-exlusive. That means everyone can get that right. I
>> >> think TrollTech is just trying to prevent forking of the Qt library
>> >> here.
>> >
>> >No, they are ensuring they can continue a revenue stream based
>> >on contributions from outside the company. They will take your
>> >modification and include it in QT Pro.
>> >
>> >> As I said previously, if you don't like the Qt license, you can
>> >> create your own library. There is no one to stop you. You can
>> >> also use one of the other available libraries.
>> >
>> >I was not arguing I should create a library. I was not arguing
>> >against QTs right to use whatever license they like. I was
>> >arguing that people should think twice before referring to QT
>> >licensing as substantially free or "open source". The right to
>> >fork is absent, the right not to have your contributions included
>> >in proprietary works (such as QT Pro) is gone, and QT gets a copy
>> >of EVERYTHING that even links to their code, even if it is not
>> >publicly available.
>>
>> I agree about the right to fork, but several free software licenses
>> (the X-Windows, and BSD licenses come to mind) allow people to make
>
>And the right to fork is good because...? Because it is GOOD to
So a standard can be free to propagate into the hands of
anyone that needs it.
>fragment
>software and libraries so that apps fail to work nicely? So that if you
There's no good reason that multiple implementations of the
same standard should fail to work nicely with each other.
This is only an outcome if you believe in the M$ view of how
software works.
[deletia]
As far as 'Unix fragmentation' goes, I've been building
source tarballs on various Unixen since before a viable
version of Windows ever came into existence. So, I'm not
sure what this boogeyman was supposed to have been doing
to me.
--
In what language does 'open' mean 'execute the evil contents of' |||
a document? --Les Mikesell / | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
From: Praedor Tempus <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Wed, 24 May 2000 11:35:34 -0600
Leslie Mikesell wrote:
>
> In article <[EMAIL PROTECTED]>,
> David Steuber <[EMAIL PROTECTED]> wrote:
>
[...]
>
> >OK, you say reusable components like libs are better off with a less
> >restrictive license. That is fair. But if the lib is under a BSD
> >style license, Microsquish can take that library, change it, and not
> >release any of the changes back to the public.
>
> Yes, which does nothing to damage the code that continues to
> be available.
[...]
But it leads to PRECISELY the problem that exists on the Windoze side of
the PC that is generally agreed to be bad. M$ produces extensions to
some standard. Because they are big, powerful and influential AND
provide tools that MANY use that then utilize these
alterations/extensions,
creating software/web pages, etc that incorporate these extensions,
they lock out alternatives.
There is no reason to assume, magically, that M$ could not and would not
succeed in doing so (if they wished) with BSD-based/non-GPL software.
They have the right to extend it and break it and not release the
alteration. Many people would use it (a RELATIVELY small core of
hardcore linux/bsd users are not significant in the big scheme so
THEIR refusal to go along is irrelevant in the larger market) and
break intercompatibility...hmmm...just like in the windoze world.
BSD licenses vs GPL or LGPL, would foster this sort of thing. There
just isn't (yet) a big boy on the block like M$ taking advantage of
his weakness in the licensing scheme.g
I ask for someone to defend this ability when it comes to BSD-style
licenses while at the same time railing AGAINST the practices of
M$ in a similar manner. They are doing what a BSD license permits.
They make a practice of code forking to force users to use THEIR
solutions rather than a competitors...but in the BSD license world
this would be a good thing, fully supported by "the community"?
I honestly ask why this is not hypocrisy because I really don't see
why it isn't?
praedor
------------------------------
From: [EMAIL PROTECTED] (Michal Jaegermann)
Subject: Re: What !@#$ moron colorised g++?
Date: 24 May 2000 17:37:07 GMT
Reply-To: [EMAIL PROTECTED]
Chetan Ahuja ([EMAIL PROTECTED]) wrote:
: Alexander Viro <[EMAIL PROTECTED]> spoke thusly:
: > <gaaaaack...>
: > Who is responsible for that piece of idiocy? I mean, could the author of
: > that bright idea please stand up, name himself and receive his, erm, due?
: More quotes from the gcc script on my system
:
: # Author: Jamie Moyers <[EMAIL PROTECTED]>
: # Started: April 20, 1999
: # Licence: GNU Public License
If Jamie Moyers wants to waste his time on this crap that it his private
business and one can only shrug. One may hope that he will see light
some day. But whomever decided to foist that as a __default__ on a
distribution is a truly certified idiot.
Linking this bright idea to 'cat' should render it harmless, I would
think.
Michal
------------------------------
From: Praedor Tempus <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Wed, 24 May 2000 11:47:46 -0600
JEDIDIAH wrote:
>
> On Wed, 24 May 2000 11:14:50 -0600, Praedor Tempus <[EMAIL PROTECTED]> wrote:
> >Dowe Keller wrote:
[...]
> >>
> >> I agree about the right to fork, but several free software licenses
> >> (the X-Windows, and BSD licenses come to mind) allow people to make
> >
> >And the right to fork is good because...? Because it is GOOD to
>
> So a standard can be free to propagate into the hands of
> anyone that needs it.
[...]
Then perhaps I am misunderstanding what is meant by "forking".
As for the unix bogeyman...sure it is an easy thing to write code that
would work on any unix. It is also possible to make largely portable
code if you write for windoze...but you lose enhancements and
optimizations
in doing so.
Would not your code have worked better/faster/more efficiently on unix
version X if you had written for unix version X rather than defaulting
to the generic? Is it not this type of fragmentation (I use that word
instead of forking until I properly understand the term) that relegated
unix to a niche market rather than taking over? The commericial
unix makers kept going with propriatory versions rather than versions
that would play well together. After a, perhaps, convoluted path we
end up with Windoze as the predominant PC os. I doubt it would ever
have been more than a stillbirth if unix hadn't fragmented and
collapsed on itself the way it did (perhaps there would be an M$-like
AT&T unix that everyone would be fighting against).
------------------------------
From: Praedor Tempus <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Wed, 24 May 2000 11:55:19 -0600
Alexander Viro wrote:
>
> In article <[EMAIL PROTECTED]>,
> Praedor Tempus <[EMAIL PROTECTED]> wrote:
> [snip'a'lot]
> >make coder's lives easier, make user's lives easier. SOME things should
> >be standardized (the kernel is standardized and controlled thru one
> >point:
> >Linus...so is this evil and bad? Should the kernel not be allowed to
> >fork
> >to extremis?). Standardizing does NOT automatically mean stagnation or
>
> Kernel _is_ allowed to fork. RTFGPL and for $DEITY sake, get the fuck out
> of c.o.l.d.system with that off-topic drivel, will you?
No. I am part of this thread to learn and will continue to put forth my
thoughts, expecting errors to be corrected or encounter mere opinions of
no more worth than my own, thank you.
As for kernel forking...is not linus torvald the ultimate point of
control
for what a linux kernel is? A linux kernel is what he ultimately says
is
a linux kernel. Others are not linux, by definition. They may be
compatible
but they would not be linux.
------------------------------
From: [EMAIL PROTECTED] (JEDIDIAH)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Wed, 24 May 2000 18:01:09 GMT
On Wed, 24 May 2000 11:47:46 -0600, Praedor Tempus <[EMAIL PROTECTED]> wrote:
>JEDIDIAH wrote:
>>
>> On Wed, 24 May 2000 11:14:50 -0600, Praedor Tempus <[EMAIL PROTECTED]> wrote:
>> >Dowe Keller wrote:
>[...]
>> >>
>> >> I agree about the right to fork, but several free software licenses
>> >> (the X-Windows, and BSD licenses come to mind) allow people to make
>> >
>> >And the right to fork is good because...? Because it is GOOD to
>>
>> So a standard can be free to propagate into the hands of
>> anyone that needs it.
>[...]
>
>Then perhaps I am misunderstanding what is meant by "forking".
Forking can imply many different things depending on who
is making the implications and what their agenda might be.
>
>As for the unix bogeyman...sure it is an easy thing to write code that
>would work on any unix. It is also possible to make largely portable
>code if you write for windoze...but you lose enhancements and
>optimizations
>in doing so.
Very little code really needs that much 'tweaking'. Even the
code that does get tweaked the most can still manage to be
successfully represented with interfaces optimized for widest
compatibility rather than the highest framerate.
>
>Would not your code have worked better/faster/more efficiently on unix
>version X if you had written for unix version X rather than defaulting
>to the generic? Is it not this type of fragmentation (I use that word
It would likely work even faster if designed with clear functional
goals in mind rather than being driven from the marketing department
and subject to creeping featurism.
>instead of forking until I properly understand the term) that relegated
>unix to a niche market rather than taking over? The commericial
>unix makers kept going with propriatory versions rather than versions
>that would play well together. After a, perhaps, convoluted path we
>end up with Windoze as the predominant PC os. I doubt it would ever
>have been more than a stillbirth if unix hadn't fragmented and
>collapsed on itself the way it did (perhaps there would be an M$-like
>AT&T unix that everyone would be fighting against).
--
In what language does 'open' mean 'execute the evil contents of' |||
a document? --Les Mikesell / | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
Subject: Unexpected hang in write() call
From: Mark Adams <[EMAIL PROTECTED]>
Date: Wed, 24 May 2000 11:06:01 -0700
I have a multithreaded application using 'real time' scheduling
(SCHED_FIFO) which is multiplexing data and sending it to a
hardware device.
After a period of between half an hour and several hours, the
thread that is sending data to the output device hangs inside
write(). Normally, the rate of output is governed by the output
device and so a 'ps' listing normally shows the output thread
blocked with WCHAN shown as a location within the device driver
where it waits for buffer space to become available.
However, when the problem occurs and the output thread hangs,
WCHAN is a location in the kernel, c0109195. Excerpt from
System.map:
c0109158 t ret_from_exception
c0109168 T ret_from_intr
c0109188 t handle_bottom_half
c0109190 t reschedule
c010919c T divide_error
c01091a4 t error_code
When this hang occurs, if the thread is sent a signal (e.g.
SIGALRM or SIGCONT following a SIGSTOP), it springs into life
once again -- subsequent write() calls do not block.
Can anyone suggest what could be causing this? My feeling is
that it must be some combination of threads, real-time scheduling
and I/O.
The problem occurs on two different machines:
Linux 2.2.13, libc-2.1.2, libpthread-0.8
Linux 2.2.5, libc-2.1.1, libpthread-0.8
Cheers,
Mark
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
** 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
******************************
