Linux-Development-Sys Digest #928, Volume #6 Sat, 3 Jul 99 04:13:50 EDT
Contents:
Re: Why we are still holding on to X Windows (Christopher Browne)
Re: C++ templates: More than Turing Complete? (Davin McCall)
Re: Why not C++ (Christopher Browne)
Re: Why we are still holding on to X Windows (Kaz Kylheku)
Re: usleep() (Peter Samuelson)
Re: help:why program can be run inside gdb but can not in command line (Peter
Samuelson)
Re: /dev/par* (Peter Samuelson)
Re: creating a universal loadable kernel module (Peter Samuelson)
Re: /dev/par* (Alexander Viro)
Re: Illegal Instruction in glibc 2.1 (Andreas Jaeger)
Max threads, processes, file descriptors, etc ... (Gerald Gutierrez)
Re: Why not C++ (Timo Tossavainen)
Re: Why not C++ (Nathan Myers)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Reply-To: [EMAIL PROTECTED]
Date: Sat, 03 Jul 1999 04:29:32 GMT
On 1 Jul 1999 21:19:21 -0700, david parsons <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Michael Gu <[EMAIL PROTECTED]> wrote:
>
>>From: Junyang Gu <[EMAIL PROTECTED]>
>>
>>Let's face it. X Windows is a really premitive base for modern GUI,
>>terrible font support breaks GUI all the time, no sound capability, ....
>>If Linux is going to desktops to compete with Microsoft, it got to come
>>up with something much better then X.
>>
>>So, why don't we drop the X and innovate?
>
> "Write it and let us know when it's ready for testing"
Provide a coherent and reasonably-complete design specification, and
that would be enough to establish, at least in general terms, whether
the would-be replacement actually "innovates" over what X offers.
Produce something good enough that it starts pushing X off of peoples'
computers and you'll be taken even more seriously.
Emit aphorisms like "Why don't we drop the X and innovate" that lack
information about what it is that is supposed to supplant X and feel
ignored...
--
The shortest distance between two puns is a straight line.
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/xbloat.html>
------------------------------
From: [EMAIL PROTECTED] (Davin McCall)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: Sat, 03 Jul 1999 04:33:25 GMT
On 2 Jul 1999 13:49:34 -0700, [EMAIL PROTECTED] (Nathan Myers)
wrote:
>"Indefinite time and coding effort", then, if you like.
>But by quibbling you have missed the point.
I was just repressing what seemed to me to be an exaggeration.
As for the point, I worry that I'm still missing it.
>>I would say "approaching sensible" and almost completely disagree with
>>the performance statement. In most cases a compiled program written in
>>a high level language performs very acceptably, but not nearly as well
>>as an equivalent program hand coded in assembly language (or machine
>>code).
>
>This may have been true at one time. Modern CPUs are so complex
>that hand-coding is unlikely to do better than a good compiler
>on a significant program.
Yet this I still disagree with. My line would be something like:
"Modern CPUs are so complex that compilers hardly have a chance of
achieving the efficiency of good hand-coded assembly (or machine
code)."
Why? Because current compilers just don't take all the necessary
things into account.
This has been argued about before. Take a good read of
http://www.geocities.com/SiliconValley/9498/optimize.html
Even two different compilers can give dramatic differences in
efficiency of the code they produce. I have lost the URL but recently
was reading a web site comparing the performance of code generated by
different compilers, which included a dumping of the machine code and
clear analysis of why particular code was faster.
>The point you missed by quibbling is that once you cleave the solution
>space along a library boundary, you have left the domain of "computer
>science" and are firmly in the domain of "engineering" where your
>precious axioms are just obvious facts, and the hard problems
>involve tradeoffs and organizational choices.
I'm really not sure what you mean. "Cleave the solution space along a
library boundary"??
>>I take it that you mean they must understand the principles, although
>>not necessarily how they are applied in C++.
>
>No, absolutely the opposite! Real, useful programs are written
>using real language features. To understand principles you must
>first understand the specific application. All valid principles
>are derived from experience, however they may be dressed up after
>the fact.
Perhaps I was taking you too literally again. If not: Maybe principles
are derived from experience (that is probably arguable in itself), but
not necessarily from experience with C++. Even the principles of the
C++ language can be seen in use in other languages. I can envisage the
indirect studying of the C++ principles, whether knowingly or
unknowingly, by studying various other languages (including those
which C++ has borrowed its principles from).
Davin.
__________________________________________________________
*** davmac - sharkin'!! [EMAIL PROTECTED] ***
my programming page: http://yoyo.cc.monash.edu.au/~davmac/
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Reply-To: [EMAIL PROTECTED]
Date: Sat, 03 Jul 1999 04:28:07 GMT
On 02 Jul 1999 14:37:55 -0400, Johan Kullstam
<[EMAIL PROTECTED]> wrote:
>o r c @ p e l l . p o r t l a n d . o r . u s (david parsons) writes:
>
>> In article <[EMAIL PROTECTED]>,
>> Bruce Hoult <[EMAIL PROTECTED]> wrote:
>>
>> >Dylan is not several hundred percent slower than C as Java is.
>>
>> Have you benchmarked Java vs C on the same machine? (No, I don't
>> mean benchmarking C on a machine vs Java running on a p-machine
>> on that machine); there's certainly nothing in the design of
>> Java that would make it much slower than C on the same machine.
>>
>> Dylan is Yet Another Pascal, isn't it? It looks like the bastard
>> child of a shotgun marriage between Ada and Pascal.
>
>afaict dylan is the bastard child of lisp and the algol family (which
>includes pascal, ada and sort of includes C and C++). this isn't to
>say that dylan is all bad. it is taking some good ideas of both.
Paul Graham, author of "Common Lisp" and "On Lisp" characterizes Dylan
thus:
"Dylan is a hybrid of Scheme and Common Lisp, with a syntax like
Pascal."
--
"Let me get this straight:
A company that dominates the desktop, and can afford to hire an army of
the world's best programmers, markets what is arguably the world's LEAST
reliable operating system?
What's wrong with this picture?" -- <[EMAIL PROTECTED]>
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/langlisp.html>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Sat, 03 Jul 1999 04:56:22 GMT
On Wed, 23 Jun 1999 20:28:08 -0700, Michael Gu <[EMAIL PROTECTED]> wrote:
>This is a multi-part message in MIME format.
>--------------A5822B086F0CBFD5938D644C
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>
>
>--------------A5822B086F0CBFD5938D644C
>Content-Type: message/rfc822
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>Path:
>wnb1!wnmaster1!wn3feed!worldnet.att.net!208.134.241.18!newsfeed.cwix.com!209.208.190.2!news.globix.net!uunet!nyc.uu.net!ffx.uu.net!news.ssi1.com!news
>From: Junyang Gu <[EMAIL PROTECTED]>
>Newsgroups: comp.os.linux.advocacy
>Subject: Why we are still holding on to X Windows
>Date: Wed, 23 Jun 1999 13:29:17 -0700
>Organization: Silicon Systems, Inc.
>Message-ID: <[EMAIL PROTECTED]>
>NNTP-Posting-Host: pc721t.tus.ssi1.com
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>X-Mailer: Mozilla 4.5 [en] (WinNT; U)
>X-Accept-Language: en
>Xref: wnb1 comp.os.linux.advocacy:263983
>
>If Microsoft is a monopoly, X Windows acts more like a monopoly in the
>Unix world.
X Window dammit. No s.
>Let's face it. X Windows is a really premitive base for modern GUI,
>terrible font support breaks GUI all the time, no sound capability, ....
What do you call XBeep()? It's sound.
An interface other than X can be used for advanced sound on a local machine.
At least XBeep() remotes!
>If Linux is going to desktops to compete with Microsoft, it got to come
>up with something much better then X.
>
>So, why don't we drop the X and innovate?
Why don't we try a simpler warm-up exercise first? Your new
computing task is to figure out how to turn off the MIME-encoding
of your Usenet postings. It looks especially ridiculous
when your content type is 7 bit USASCII.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: usleep()
Date: 2 Jul 1999 23:58:49 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Daniel R. Grayson <[EMAIL PROTECTED]>]
> Have you ever wished usleep() were accurate? It's possible, because
> select() with timeout is accurate.
So use select() with timeout (and no fd's).
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: help:why program can be run inside gdb but can not in command line
Date: 3 Jul 1999 00:08:27 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[y chen <[EMAIL PROTECTED]>]
> > I had a program and i can run it inside gdb without any problem.
> > However, When i run it in command line, it seg fault.
> > Does anyone have same experience and tell me how to fix it?
[Daniel R. Grayson <[EMAIL PROTECTED]>]
> This can happen if gdb doesn't present exactly the same environment
> to the program.
Actually I suspect (s)he's using an uninitialized variable, which gdb
happens to initialize to (say) 0 but the Real World [tm] doesn't.
Lots of things are different inside and outside debugging environments.
Perhaps the only ways to avoid/minimize this are (a) to use some sort
of ICE, or (b) to attach (read-only) to a regular-running process � la
the kernel gdb stubs out there, which after all is not too different
from an ICE, at least conceptually.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: /dev/par*
Date: 3 Jul 1999 00:40:31 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Alexander Kuznetsov <[EMAIL PROTECTED]>]
> 1. Can any body tell what is the device /dev/par* ?
parport. The abstraction needed by the fact that not all parallel
ports are used for printers these days, and furthermore can often be
shared between devices.
> 2. Can it be used to communicate with other linux PC throu parallel port
> and how?
Yes. I don't know how, but you probably want to use PLIP, which shoves
IP packets through the parallel port.
> If (2. == yes) {
> 3. How cable should be wired?
> }
Quoting from the kernel source file linux/drivers/net/plip.c:
The cable used is a de facto standard parallel null cable -- sold as
a "LapLink" cable by various places. You'll need a 12-conductor cable to
make one yourself. The wiring is:
SLCTIN 17 - 17
GROUND 25 - 25
D0->ERROR 2 - 15 15 - 2
D1->SLCT 3 - 13 13 - 3
D2->PAPOUT 4 - 12 12 - 4
D3->ACK 5 - 10 10 - 5
D4->BUSY 6 - 11 11 - 6
Do not connect the other pins. They are
D5,D6,D7 are 7,8,9
STROBE is 1, FEED is 14, INIT is 16
extra grounds are 18,19,20,21,22,23,24
I was under the impression you could do better with modern (i.e.
bidirectional) parallel ports, but I don't see any docs for this.
> else {
> 4. What how to fast communicate to other Linux without
> networking (because of
> security) ?
> }
If you just want to hang a getty on a parallel port, I don't know how.
If you want anything more, it will be just as insecure as a pair of
Ethernet cards and a hub.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: creating a universal loadable kernel module
Date: 3 Jul 1999 00:44:04 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[<[EMAIL PROTECTED]>]
> Does anybody know if there is a possibility to compile a kernel
> module in a way so that I can load it under a non-smp / smp machine
> with kernel symbol versioning on /off ?
Yeah. Compile it four times.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: /dev/par*
Date: 3 Jul 1999 02:35:54 -0400
In article <7lk7of$6id$[EMAIL PROTECTED]>,
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>[Alexander Kuznetsov <[EMAIL PROTECTED]>]
>> 2. Can it be used to communicate with other linux PC throu parallel port
>> and how?
>
>Yes. I don't know how, but you probably want to use PLIP, which shoves
>IP packets through the parallel port.
Set it up as if you had an ethernet segment with 2 boxen and use plip0
as interface name.
>> If (2. == yes) {
>> 3. How cable should be wired?
LapLink will work fine. Anything with right sockets has very good chances
to be what you need. IOW, if you see a cable that fits - try it.
>> 4. What how to fast communicate to other Linux without
>> networking (because of
>> security) ?
>> }
>
>If you just want to hang a getty on a parallel port, I don't know how.
>If you want anything more, it will be just as insecure as a pair of
>Ethernet cards and a hub.
IOW, reasonably secure, assuming that you drop packets from external
links that would be routed to another box. BTW, using hub for a
point-to-point ethernet link is an odd idea - use the right cable and
there you go.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: Illegal Instruction in glibc 2.1
Date: 03 Jul 1999 08:36:57 +0200
>>>>> Hans-Joachim Baader writes:
> Hi,
> since I installed glibc 2.1 (and later 2.1.1) one of my machines has
> problems. Several programs crash with SIGILL. Here's a sample from
> the gdb disas command:
> The illegal instruction happened at 0x4011d9f8:
> 0x4011d9f8 <__tzfile_read+500>: bswap %eax
> Call stack:
> #0 0x4011d9f8 in __tzfile_read () from /lib/libc.so.6
> #1 0x4011c80f in tzset_internal () from /lib/libc.so.6
> #2 0x4011d6f7 in __tz_convert () from /lib/libc.so.6
> #3 0x40119a72 in localtime () from /lib/libc.so.6
> #4 0x80a88ea in Perl_pp_gmtime ()
> #5 0x80a8888 in Perl_pp_localtime ()
> #6 0x80b1402 in Perl_runops_standard ()
> #7 0x805929d in perl_run ()
> #8 0x8057839 in main ()
> #9 0x400adfff in __libc_start_main () from /lib/libc.so.6
> This machine runs exactly the same software as some of my other
> machines. The only difference I see is that this machine has a
> 386 CPU while the others have 486, Pentiums, K6 and Celeron.
> I compiled glibc myself with egcs 1.1.2 and i586-pc-linux-gnu as
> target. i386-pc-linux-gnu didn't make a difference.
> Obviously, the bswap instruction is not a 386 instruction. But
> why the heck does the compiler create non-386 instructions?
> I didn't tell it to...
configure for i386-pc-linux-gnu and compile with
`-march=i386 -mcpu=i386' (just -m386 doesn't work!) - and tell me
per email whether it worked or not.
Cheers,
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
Subject: Max threads, processes, file descriptors, etc ...
From: Gerald Gutierrez <[EMAIL PROTECTED]>
Date: 03 Jul 1999 00:06:51 -0700
Hi all.
I remember some time back there was a discussion regarding how to
change the maximum user & system wide number of threads, processes and
file descriptors, amongst other things.
Does anyone know where I might be able to find such information?
Thanks.
Please forward replies to [EMAIL PROTECTED]
------------------------------
From: Timo Tossavainen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: Sat, 03 Jul 1999 13:00:18 +0300
Kaz Kylheku wrote:
>
> On Fri, 02 Jul 1999 20:27:45 +0300, Timo Tossavainen <[EMAIL PROTECTED]> wrote:
> >Nathan Myers wrote:
> >>
> >> Only people who take the trouble to understand why C++ solves real
> >> problems better than the alternatives have any hope of designing a
> >> language that can supplant it.
> >
> >There you go again. I don't understand why C++ solves real
> >problems better than the alternatives, even though I've
> >been programming C++ for several years.
>
> Because a lot of real world problems have performance requirements,
> as well as the ability to interface tightly to machine-level
> constructs, in addition to requiring object oriented techniques.
That much I will give to C/C++, it's easy to do machine-level stuff
but it's also easy to interface from other languages to C when they
need this capability.
>
> You should probably forget it even in C++.
>
Why is that ? I think most of them are proven solutions to real
world problems in the context of C++.
> >There are numerous successful projects written in Lisp. Lisp
>
> How many of these have anything to do with high performance
> computing? Name three real-time kernels written in Lisp.
Many actually. RT Kernels I don't know about but I think
it would be possible theoretically if the Lisp environment
was equipped with extensions to handle the low level machine-
dependent issues.
The Mars Pathfinder project used lisp at least in some places.
I take it that high performance means both speed and extreme
reliability.
> Does anyone write device drivers in Lisp? Has anyone written
> the software for a high-performance internet router in Lisp? How about
> simulations? Who does number-crunching in Lisp, whether scientific,
> engineering, or financial? What about computer graphics? Compilers?
Number crunching in CMUCL is as fast as C (faster in some cases,
slower in some). I wouldn't say that Common Lisp Music, a software
synthesis package, isn't number crunching. For computer graphics
there are OpenGL bindings to Common Lisp, as for Compilers
CMUCL is mostly written in Common Lisp. For web stuff there's
the CL-HTTP server.
The code produced by a decent Common Lisp compiler is no worse
than that produced by a C compiler. In most cases you have to
expicitly state the types of the variables, which is what
you always have to do in C. Not stating the types of variables
is an option that C/C++ doesn't have. Lisp still manages to catch
_all_ variable typing errors, unless you tell it otherwise. C/C++
doesn't. The CMUCL compiler is extremely helpful when optimizing;
when using the maximum speed setting it informs when it cannot
optimize and why, so you can iterate until you've got the whole
code optimized.
for more information on Lisp applications you could visit:
http://www.elwoodcorp.com/alu
How many buggy programs with memory leaks and typing errors
written in C/C++ are out there ? How about symbolic algebra,
logical inference, expert systems, AI etc. ? Maybe these aren't
as hot now, but they will be in the future. I would say
that these are real world problems that Lisp handles better
than C++. Each language has areas where it is powerful, I'm
only pointing out that C++ isn't the silver bullet, it isn't
the best choice for all problems like some people like to
claim.
> >is one of the oldest programming languages and it's still
> >among the best. What does that tell you about dynamic
> >languages ? They evolve to fullfill the changing needs of the
> >users; static languages eventually fade away and die.
>
> Fortran is older and is still in use.
True. It has a reputation for good performance in number cruncing.
> In reality a balance is needed. The software must be developed on time, perform
> well, be stable and survive changing requirements. Of these, all but one
> can be overcome with sheer discipline and ingenuity even in the face of
> primitive programming tools. The one that cannot is performance. You cannot
> will your program into running any faster, and restructuring a program into
> running faster will only go so far---and perhaps at the sacrifice of clarity
> and structure.
Actually implementing speedups algorithmically using adaptive data
structures and other algorithmic techniques will speed the program up
a lot more than fiddling with assembly. While it is true that some
parts of programs need to run fast, most parts do not. Not optimizing
the parts that do not will not be noticeable to the user, optimization
should be focused to where it is needed. Servers are another story...
especially if they need to survive unrealistic benchmarks arranged by
a competing evil empire =)
> >> (Hint 1: copying the syntax might be a mistake.)
> >
> >Yes, the prefix-notation of Lisp is a lot more powerful than
> >the infix-notation of C++.
>
> That may be true, but the infix notation is what most humans learn from first
> grade, and hence find easier to understand. When computers were first taught to
> parse and evaluate algebraic expressions, it was a big step forward. Prefix
> notations are nothing but laziness on the part of the language designer, who
> forstalls his or her fears of implementing the expression parser by making
> concessions in the syntax.
It's good for automated and run time code generation. The notation
is more concise and less ambiguous than the infix notation.
There are many solid alternatives to C++ out there, the question
you have ask yourselves is that have really tried to keep an
open mind and seriously considered them. Learning Lisp has improved
my C++ programming style a lot, knowing many different approaches
will not hurt, but knowing only one approach will.
Timo
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: 3 Jul 1999 00:31:03 -0700
Timo Tossavainen <[EMAIL PROTECTED]> wrote:
>Nathan Myers wrote:
>> Timo Tossavainen <[EMAIL PROTECTED]> wrote:
>> >Nathan Myers wrote:
>> >>
>> >> Only people who take the trouble to understand why C++ solves real
>> >> problems better than the alternatives have any hope of designing a
>> >> language that can supplant it.
>> >
>... I don't believe it does solve problems
>better than the alternatives. Could you elaborate a bit on
>why you think that C++ is better than everything else
>available for any problem (at least any _real_ problem) ?
No sane person would maintain that *any* particular language is best
for "any real problem".
C++ is currently best for a number of economically important classes
of problems, and the language that supplants it will be better for
those problems. C is ripe for supplanting for that reason: for any
problem C can address, someone skilled in C++ can do substantially
better.
This is not to say that everywhere C is used, C++ would be the
best alternative; often C was used just because it was there, and
some third language might be a better choice than C++. Nonetheless,
many programs done in languages other than C (e.g., lately, Fortran)
would better have been done in C++.
>> >If your definition of better is faster and smaller, without
>> >regard for development speed, extensibility, maintainability
>> >and robustness, then I understand your point.
>>
>> No. You have entirely missed the point, in fact.
>
>Ok. Compared to C, C++ is better in all these respects (except
>maybe size and equal at speed), but it seems that for most
>people nothing else than optimized C/C++ will do even if it means
>sacrificing some of the other goals that I see at least as important.
>The point I missed being ?
The point you missed is that the most important aspects of C++ are
its expressive powers, and specifically those designed to help
decompose problems into libraries. Maintainability and robustness
depend on effective decomposition. But it isn't enough to be able
to code something, you must be able to *afford* to code it.
The machine-code-speed requirement is what keeps the design honest.
There are too many low-level details to allow you to decide in each
case if your language primitives are fast enough. You have to be able
to trust that they always are as efficient as can be, because low-level
inefficiencies multiply. High-level efficiency leaves no room for
low-level design mistakes.
The combination of expressiveness in the construction of libraries,
and scrupulous fidelity to the real machine model, is what gives C++
its strength. That strength has been enough to overcome its most
unfortunate inheritances from C: bad declaration syntax and
promiscuous numeric conversions.
Still, those problems that C and C++ fail to address well (even
through libraries) should certainly be approached using other
languages. Very large systems are almost always constructed using
a mix of languages with differing characteristics. GNU/Linux itself
is a good example: kernel in heavily customized C, utilities in
portable C and C++, configuration in various scripting languages.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
** 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
******************************
