Linux-Development-Sys Digest #573, Volume #6 Sat, 3 Apr 99 02:14:17 EST
Contents:
Re: Proposal: "Linux 2000 Platform" (Alexander Viro)
Proposal: "Linux 2000 Platform" (Kendall Bennett)
Re: "playing MPEGs" or "problems with SMP kernel" (Andrew D Lenharth)
can we do float point calculation in kernel module? ([EMAIL PROTECTED])
Re: Seeking on large block devices (Taketoshi Sano)
Re: Proposal: "Linux 2000 Platform" ([EMAIL PROTECTED])
Re: Proposal: "Linux 2000 Platform" (Jeremy Crabtree)
Re: IDE Chipsets (Chris Leahy)
Re: meminfo and ps (Michael Hirsch)
Re: Proposal: "Linux 2000 Platform" (Christopher B. Browne)
Re: cc compiler (Harald Arnesen)
Re: polling an interface at 12 KHz (Peter Teuben)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Date: 2 Apr 1999 11:36:22 -0500
In article <[EMAIL PROTECTED]>,
Christopher B. Browne <[EMAIL PROTECTED]> wrote:
>On 1 Apr 1999 21:34:22 -0500, Alexander Viro <[EMAIL PROTECTED]>
>posted:
>>In article <[EMAIL PROTECTED]>,
>>>I suggest dpkg instead, it's a bit more, shall we say, 'advanced'.
>>
>>Seconded, with possible ports integration.
>
>Unfortunately, the flaming of Red Hat by those of the Slackware
>Religion acts as an anodyne, distracting people from the possibility
>that there might be ideas out there that are better than either
>system's approach.
>
>The fixation on RPM, with occasional vague mention of dpkg, betrays a
>generally vast ignorance of the various packaging methods that in use.
>Almost certainly Ports and the Debian tools represent something closer
>to the "state of the art" than does RPM.
>
>Anyone for stow? Depot? NSBD?
>
>Note that RPM would be a whole lot more usable if there was something
>functionally equivalent to Debian's APT and dselect tools...
You know, it looks like a case of common UTD (UI Transmitted Disease) -
functionality gets ignored, UI becomes the only thing that is considered.
Instead of looking at the existing tasks and properties that can be provided
by such tools it becomes a matter of "foo has a pretty button in the top
left corner of the window!" - "So?" - "It's cool!" - "<shudder>".
Slackware folks have a point, BTW - there are situations when no tool
is more reliable than tool which may leave the system in hard-to-recover state.
Example: databases are generally faster than long sectioned text files. So
keeping mailboxes in a database may be nice. Except that M Sexchange is prone
to breakage and recovering the database in question is *not* a nice exercise.
From the tools I've seen dpkg and friends are the best system
for dealing with binary packages. Ports lose here, but win for source
packages. Probably the best combination would be something a-la ports
able to generate .deb or equivalent. Notice that it's *not* only matter
of clever packaging scheme. You need (at least): (a) source
dependencies for each source package; (b) binary dependencies for each
binary package (one source package may generate several binary ones);
(c) well-defined set of virtual packages (e.g. ability to say that
package foo depends on web-browser) + common methods to interact with
packages providing given virtual package (e.g. register a new MIME
type) + alternatives mechanism; (d) well-defined core sets (for binary
and for source work), so that all packages can assume that binary core
is present and for source builds - that packages from source core are
present. All that stuff is the work for distribution-maker (and accurate
dependency calculation - for maintainer of each package). Clever tools
may work if that information is present. They can't *replace* it.
How it was? "Do it right, *then* make it pretty"... Not the other
way round.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Kendall Bennett)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Proposal: "Linux 2000 Platform"
Date: Thu, 1 Apr 1999 11:31:43 -0800
Hi All,
Since the announcement of MetroWerks CodeWarrior for the "Red Hat Linux"
platform, a couple of threads have brought up the subject of difference
between Linux distributions. As a developer of commercial products for
the Linux platform, we are all too familiar with the subtle differences
between Linux distributions that cause headaches for vendors wishing to
develop and *support* products for the Linux platform. Hence
software vendors end up developing for and supporting their products on
the most popular Linux distribution, which is currently Red Hat.
I know there is already the Linux LSB project underway to hopefully solve
some of these problems. However I think we need something more
definitative than this. What we need to do is put together something
similar to the the Microsoft PC '99 guidelines, but for Linux
distributions. I am proposing that we start a new project to define the
'Linux 2000 Platform'.
Since there will be differences between the different uses for Linux, we
should define multiple variations of the Linux 2000 platform. The
contents of what make up the variations Linux 2000 platform should be
debated and eventually voted on to come up with the final guidelines.
Some people may not agree with the final vote, but the important thing is
that compromises need to be made for this to be successful. We may also
want to define what are 'base components' that must be installed on every
system, and components that are optional and may or may not be installed
by the user.
The important thing here is that then software vendors can say that they
support the 'Linux 2000 Platform' as opposed to a particular Linux
distribution. People writing books about Linux can target the 'Linux 2000
Platform' as well, so people wanting to learn about Linux can simply get
any distribution that is Linux 2000 compliant. As long as the
distribution guidelines are set in and the distribution vendors correctly
follow the guidelines, the Linux world will be a better place.
Perhaps we need a new mailing list dedicated to defining and regulating
these issues?
The following are my first two (very bare) suggestions to begin with:
Linux 2000 Workstation
======================
Base components:
. Standard locations for all configuration files!
. Glibc based
. RPM for package manager
. GNU make, C/C++ compiler and development libraries
. XFree86 installed to /usr/X11R6/lib (or /usr/X11)
Optional components:
. Web browser (Netscape or Mozilla variation?)
. Need more suggestions here!
Linux 2000 Server
=================
Base components:
. Standard locations for all configuration files!
. Glibc based
. RPM for package manager
. GNU make, C/C++ compiler and development libraries
. XFree86 installed to /usr/X11R6/lib (or /usr/X11)
. Ftp, telnet servers
. Apache web server
. Web browser (Netscape or Mozilla variation?)
Optional components:
. Need more suggestions here!
--
+----------------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+----------------------------------------------------------------------+
| Kendall Bennett | To reply via email, remove nospam from |
| Director of Engineering | the reply to email address. Do NOT send |
| SciTech Software, Inc. | unsolicited commercial email! |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+----------------------------------------------------------------------+
------------------------------
Crossposted-To: comp.os.linux.x,comp.os.linux.setup,comp.os.linux.misc
From: Andrew D Lenharth <[EMAIL PROTECTED]>
Subject: Re: "playing MPEGs" or "problems with SMP kernel"
Date: Fri, 2 Apr 1999 00:10:34 GMT
I have a dual PII-350, And video is smooth as can be. This using a #9
rev3D and a Matrox G200. Maybe you're out of ram and things are getting
paged (like the video player)?
Andrew LEnharth
On Thu, 1 Apr 1999, Peter Kharchenko wrote:
> Hi,
> I've ran into a weird problem when I put a second processor into my
> system: When the kernel is running in SMP mode with two processors,
> video players don't seem to work. All of them (mpeg_play, MpegTV, xanim)
> are showing the same exact problem: they spit out a bunch of frames,
> then freeze, then spit out some more and so on.
> If I turn off the SMP option and recompile that same kernel, all works
> fine. If I run an SMP kernel having just one processor in the system, it
> all runs fine too. I have not noticed any other problems running the
> system in SMP mode with two processors. I imagine this has something to
> do with timings (and yes, I've tried to turn Enhanced Real Time Clock
> option, it doesn't help).
>
> I was wondering if anyone else was having a similar problem or has any
> suggestions on how to fix this.
>
> (my system is a dual PII-450, and I tried the following kernels: 2.2.5,
> 2.2.4 and 2.1.132 ... all giving the same results :( )
>
>
> Thanks in advance for any suggestions,
>
> -peter.
>
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: can we do float point calculation in kernel module?
Date: Sat, 03 Apr 1999 03:10:56 GMT
Dear all:
I'm now writing some kernel modules and want to do some float point computing
there. I tried a little bit and it seems work. But I'm not sure if there are
any potential risks to do so.
Any suggestions will be greatly appreciated.
Daniel
------------------------------
From: Taketoshi Sano <[EMAIL PROTECTED]>
Subject: Re: Seeking on large block devices
Date: 02 Apr 1999 17:31:21 +0900
Hi. Have you read the source code of sfdisk ?
It uses _llseek (2) in sseek().
That code will b fairly good example for your code, I think.
Me, for myself, Have not use llseek on 34GB disk, but
I assure it can go over 2GB limit on my 4GB IDE disk :)
In article <[EMAIL PROTECTED]>
Brad Dietrich <[EMAIL PROTECTED]> writes:
> have a large block device (SCSI hard drive ~ 34 GB) that I need to read
> data from and can't mount. (It is a Macintosh HFS Plus Filesystem, and I
...
> but I am running into seeking problems on the block device. I had
> started by using fseek after fopening the block device file, but
m> realized that I am going to run into the 2 GB offset limit on the signed
> offset parameter to fseek. Can someone offer another alternative to
> seeking to points on the block device? I will always want to be reading
> multiples of SCSI 512kb blocks, so I just need to seek to a SCSI block
> number really.
--
t.sano <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Date: 2 Apr 1999 23:57:46 GMT
In comp.os.linux.development.system Christopher B. Browne <[EMAIL PROTECTED]>
wrote:
: Unfortunately, the flaming of Red Hat by those of the Slackware
: Religion acts as an anodyne, distracting people from the possibility
: that there might be ideas out there that are better than either
: system's approach.
: The fixation on RPM, with occasional vague mention of dpkg, betrays a
: generally vast ignorance of the various packaging methods that in use.
: Almost certainly Ports and the Debian tools represent something closer
: to the "state of the art" than does RPM.
I think that whatever package manager you are using should be smart
enough to figure out what distro you are using. This is a major
project...but it would be a great benefit to all concerned. Create a
specification for the software creators to follow in specifying where they
want it installed. The package will have a database of distros that will say
where they will allow things to be installed, and if there is a conflict, it
will then create symlinks in the place the package wants pointing at the
place where the distro wants the package installed. If the software creators
want to do some extra work, they might be a option for different sets of
configuration files for each distro. Another option will be to check for
dependancies...some programs have none, others a great number of them.
Now, I am not totally familar with Ports, or the Debian package
managemetn system, since, alas, I used to run SLS, and now Slackware, with a
year long flirtation with Red Hat.
I've been using Linux since kernel v0.12, and have see all sorts of
package systems, they are great for many people...but there will always be
us who like to compile things and install them ourselves. Yes, we may be
twisted...<grin>...but the heart of Linux has always been flexablity. And I
think it would be a shame to loose that flexablity.
ttyl
Farrell
---
Farrell J. McGovern Sysadmin/Security for Unix Systems
Using Linux since kernel ver. 0.12 Specialist in Linux Systems
------------------------------
From: [EMAIL PROTECTED] (Jeremy Crabtree)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Date: 3 Apr 1999 00:35:24 GMT
Reply-To: [EMAIL PROTECTED]
Christopher B. Browne allegedly wrote:
>On 1 Apr 1999 21:34:22 -0500, Alexander Viro <[EMAIL PROTECTED]>
>posted:
>>In article <[EMAIL PROTECTED]>,
>>>I suggest dpkg instead, it's a bit more, shall we say, 'advanced'.
>>
>>Seconded, with possible ports integration.
>
>Unfortunately, the flaming of Red Hat by those of the Slackware
>Religion acts as an anodyne, distracting people from the possibility
>that there might be ideas out there that are better than either
>system's approach.
When did I flame anyone?
>The fixation on RPM, with occasional vague mention of dpkg, betrays a
>generally vast ignorance of the various packaging methods that in use.
>Almost certainly Ports and the Debian tools represent something closer
>to the "state of the art" than does RPM.
>
>Anyone for stow? Depot? NSBD?
I dunno...the whole lot of package tools would have to be evaluated
before any one could be selected.
(Which is why the summary selection of RPM without ANY consultation
bugs me a bit.)
>Note that RPM would be a whole lot more usable if there was something
>functionally equivalent to Debian's APT and dselect tools...
Or even pkgtool's character-mode interface.
(Glint is okay, but the CLI RPM stinks)
(WHOA!...pkgtool is a...sh SCRIPT!?...cool...)
>>>(I use Slackware, and I don't use ANY package managers ;)
>>
>>>> . GNU make, C/C++ compiler and development libraries
>>
>>>Well, DUH! ;)
>
>I disagree, slightly. POSIX make is a more unambiguously requirable
>option.
HERETIC!...okay, point taken, but gmake, gcc (egcs) and the like
would be the most likely ones to use.
>>>> . XFree86 installed to /usr/X11R6/lib (or /usr/X11)
>>
>>Optional. Install libs if you are so inclined, but server and
>>applications do not belong to required part.
>>
>>>Or both, thanks to the wonders of sym-links.
>>
>> Exactly.
>
>Absolutely.
So, we're all in agreement here? <G>
(FWIW, I did exactly this when installing XF86 3.3.3.1 on my
system...symlinks are wonderful things)
>>>>Optional components:
>>>> . Web browser (Netscape or Mozilla variation?)
>>
>>Or lynx, or any other browser. What's the difference for 3-rd party
>>applications?
>
>If trying to establish a standard, shouldn't the product picked be
>require to conform to some standards? :-).
So...Arena is the one, then? ;)
Or, am I confused?
--
"Being myself a remarkably stupid fellow, I have had to unteach myself
the difficulties, and now beg to present to my fellow fools the parts
that are not hard" --Silvanus P. Thompson, from "Calculus Made Easy."
------------------------------
From: Chris Leahy <[EMAIL PROTECTED]>
Subject: Re: IDE Chipsets
Date: Fri, 02 Apr 1999 16:55:25 -0800
Chris Leahy wrote:
> Hello all,
>
> I'm a RedHat user but this question can be put to users of any linux
> distribution.
> I'm running RedHat 5.2 with an AMD K6-2 400 MHz on an ASUS P5A
> Motherboard
> The problem is this, (though its not an emergency)
> Even the latest kernel (2.2.5 I believe) does not recognize the ALi 154x
> chipset on the motherboard
> The result is that it runs ok, but DMA is disabled at boot and can not
> be enabled.
> Earlier on I found a 3rd party patch for the 2.2.0 kernel that added
> support for the ALi chipset
> and this runs ok but I would like to be using the latest kernel and the
> patch would only go on the 2.2.0 source
> I'm wondering when support for this popular (and common) super 7 chipset
> will appear in the
> official release.
>
> If the answer is unknown to any of you maybe someone could direct me to
> a place where I might find the answer to this question.
>
> Please CC replies to [EMAIL PROTECTED]
>
> Thanks for your help
>
> Chris
I'm answering my own post here for the benefit of anyone who is looking for
the same
answer as I was.
I found a patch for the 2.2.5 kernel that includes support for the Ali
15xx (Aladdin V ) chipset.
The patch can be found at
http://www.dyer.vanderbilt.edu/server/udma/
Chris
------------------------------
From: Michael Hirsch <[EMAIL PROTECTED]>
Subject: Re: meminfo and ps
Date: 02 Apr 1999 22:08:20 -0500
[EMAIL PROTECTED] (David T. Blake) writes:
> Anyway, he brought an interesting problem to my attention.
> cat /proc/meminfo shows 90+% of the RAM being used.
>
> If you sum the RAM stamps of the output of ps aux, it
> accounts for less than a fifth of the result seen in
> /proc/meminfo.
>
> What could account for this discrepancy ? It has been
> seen in 2.0.25 and 2.2.5 now.
Intelligent and aggressive disk caching.
Compare the numbers you get from /proc/meminfo and the free command.
You will notice that the buffers + cache + free of meminfo adds up to
about the free listed by free.
Every time linux reads from the disk, it keeps what it read in
memory. It doesn't wipe it out until that memory is needed, but then
it is just a question of overwriting it--no caching to disk needed.
The has the effect that memory gets filled up, but mostly with
disposable stuff.
I remember never using swap when I have 32 meg, but noticing that
memory was tight. So I added another 64 meg, and filled it all up!
Of course, I later realized it was almost all cached.
--
Michael D. Hirsch Work: (404) 727-7940
Emory University, Atlanta, GA 30322 FAX: (404) 727-5611
email: [EMAIL PROTECTED] http://www.mathcs.emory.edu/~hirsch/
Public key for encrypted mail available upon request (or finger
[EMAIL PROTECTED]).
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Reply-To: [EMAIL PROTECTED]
Date: Sat, 03 Apr 1999 02:07:11 GMT
On 3 Apr 1999 00:35:24 GMT, Jeremy Crabtree <[EMAIL PROTECTED]> posted:
>Christopher B. Browne allegedly wrote:
>>On 1 Apr 1999 21:34:22 -0500, Alexander Viro <[EMAIL PROTECTED]>
>>posted:
>>>In article <[EMAIL PROTECTED]>,
>>>>I suggest dpkg instead, it's a bit more, shall we say, 'advanced'.
>>>
>>>Seconded, with possible ports integration.
>>
>>Unfortunately, the flaming of Red Hat by those of the Slackware
>>Religion acts as an anodyne, distracting people from the possibility
>>that there might be ideas out there that are better than either
>>system's approach.
>
>When did I flame anyone?
I'm not pointing you out; I'm pointing out the all-too-typical flaming
that takes place.
>>The fixation on RPM, with occasional vague mention of dpkg, betrays a
>>generally vast ignorance of the various packaging methods that in use.
>>Almost certainly Ports and the Debian tools represent something closer
>>to the "state of the art" than does RPM.
>>
>>Anyone for stow? Depot? NSBD?
>
>I dunno...the whole lot of package tools would have to be evaluated
>before any one could be selected.
>
>(Which is why the summary selection of RPM without ANY consultation
> bugs me a bit.)
The people that created Red Hat's distribution made their "summary
selection;" those that created Debian made another; those that created
SuSE made another.
I would see the issue of non-consultation as an issue with respect to
a plan to establish (let's say) RPM as the "favored package manager"
for LSB, which is intended to be a public standard.
In contrast, it is entirely reasonable for people who are building
their own systems to make their own decisions.
>>Note that RPM would be a whole lot more usable if there was something
>>functionally equivalent to Debian's APT and dselect tools...
>
>Or even pkgtool's character-mode interface.
- Does it multiplex data sources together?
- Does it monitor package dependancies and codependancies?
>(Glint is okay, but the CLI RPM stinks)
Glint is almost functionality-free, and hasn't been *significantly*
improved since its introduction. No multiplexing, no significant
dependancy checking... Basically just a "dumb" menu atop a
filesystem.
>(WHOA!...pkgtool is a...sh SCRIPT!?...cool...)
>
>>>>(I use Slackware, and I don't use ANY package managers ;)
>>>
>>>>> . GNU make, C/C++ compiler and development libraries
>>>
>>>>Well, DUH! ;)
>>
>>I disagree, slightly. POSIX make is a more unambiguously requirable
>>option.
>
>HERETIC!...okay, point taken, but gmake, gcc (egcs) and the like
>would be the most likely ones to use.
Normative standards are always worth *considering.* In the end, I'd
probably prefer to use GNU make, but I don't think it particularly
wise to head down the "using GNU-Make-isms" path...
>>>>> . XFree86 installed to /usr/X11R6/lib (or /usr/X11)
>>>
>>>Optional. Install libs if you are so inclined, but server and
>>>applications do not belong to required part.
>>>
>>>>Or both, thanks to the wonders of sym-links.
>>>
>>> Exactly.
>>
>>Absolutely.
>
>So, we're all in agreement here? <G>
>
>(FWIW, I did exactly this when installing XF86 3.3.3.1 on my
> system...symlinks are wonderful things)
No, the point is that while it may be a nice thing to be aware of
where X goes, *IF INSTALLED,* that is not a mandatory component. I've
got headless boxes where running an X server would be just plain
stupid.
>>>>>Optional components:
>>>>> . Web browser (Netscape or Mozilla variation?)
>>>
>>>Or lynx, or any other browser. What's the difference for 3-rd party
>>>applications?
>>
>>If trying to establish a standard, shouldn't the product picked be
>>require to conform to some standards? :-).
>
>So...Arena is the one, then? ;)
>Or, am I confused?
Mandating a particular browser is *dumb.*
-> There are a whole bunch of offshoots of Netscape's browser that
would be worth considering:
{Navigator|Communicator} in assortedly {Motif|GTk|Qt} variations,
with major version "numbers" 3.x, 4.0x, 4.5x, and hopefully 5.x
Real Soon Now.
Heaven only knows how many combinations that adds up to...
-> Arena's probably not a real good choice, considering that the last
new release was in March 1998...
-> Doubtless there are some Grail partisans...
-> Chimera has two "streams," and is pretty nicely suited to "popping
up documentation."
-> KDE and GNOME both have "browser widgets" for their help systems
that are fairly small, and reasonable choices for some purposes...
-> Who knows? The Mnemonic guys might get theirs "productionized,"
and it might well be preferable to Netscape.
Based on the varying sets of needs and constraints that people have,
virtually all of these are decent choices under the right
circumstances.
Given that none are terribly "standards-conformant," choices will be
arbitrary.
Frankly, I think that the "best" standardization would be done much as
with EDITOR/VISUAL; one would set the environment variables
HELP_BROWSER, SSL_BROWSER, BROWSER, and the system pick one on
demand...
Further multiplexing would be doable by setting those variables to run
shell scripts that check on system configuration and dynamically
figure out what to do.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: Harald Arnesen <[EMAIL PROTECTED]>
Subject: Re: cc compiler
Date: 02 Apr 1999 11:59:05 +0200
Dominic Leelodharry <[EMAIL PROTECTED]> writes:
> I have Redhat Linux
> And I can not seem to get the cc compiler to work.
> I think I am missing the header files such as <stdio.h> etc, does any
> one know where I can
> down load them from, If they are included as a RPM could you tell what
> that is called
They are in 'glibc-devel-2.0.n-nn.rpm' ('libc-devel', if you use Redhat
4.2 or older).
Btw. this question really belongs in comp.os.linux.setup. Followup set
there.
--
Harald Arnesen, Apall�kkveien 23 A, N-0956 Oslo, Norway
------------------------------
From: Peter Teuben <[EMAIL PROTECTED]>
Subject: Re: polling an interface at 12 KHz
Date: Sat, 03 Apr 1999 02:01:07 -0500
I had a similar problem at 5 KHz, but I had to poll faster, since
you can miss a beat. It tried a few things, but it became pretty
clear to me the only way to *reliably* get the data from that line
was to use Real-Time Linux (http://www.rtl.org). Works like a charm
for me. I've got some background on personal experiences in my
web tree
- peter;
--
Peter Teuben http://www.astro.umd.edu/~teuben
Astronomy Department mailto:[EMAIL PROTECTED] (no SPAM !!)
University of Maryland ftp://ftp.astro.umd.edu/pub/teuben
College Park, MD 20742 audio:301-405-1540
------------------------------
** 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
******************************
