Linux-Development-Sys Digest #942, Volume #6 Thu, 8 Jul 99 22:14:06 EDT
Contents:
kernel programming (dave frost)
EQL enslave binary won't run under rh 6.0! (brian)
Re: Writing sound driver for Linux (Herve Lefebvre)
egcs weaknesses (was idiocy but let's be civil) (Ian Hutchinson)
System Developer(s) Wanted ("JP S-C")
PCI Hot Plug (Jim Puthukattukaran)
Patch for glibc-linuxthreads-2.1.1 (Kaz Kylheku)
Re: egcs weaknesses (was idiocy but let's be civil) (Daniel Robert Franklin)
Re: kernel programming ("Daniel Pietsch")
Re: Why not C++ (toto)
Re: egcs weaknesses (was idiocy but let's be civil) (Don Waugaman)
interrupt handler in C ("klauspg")
Re: linx vs hurd (Christopher Browne)
Re: Why not C++ (Nathan Myers)
Re: CD-ROM File Time Bug (Terry Boldt)
Re: System Developer(s) Wanted (Christopher Browne)
----------------------------------------------------------------------------
From: dave frost <[EMAIL PROTECTED]>
Subject: kernel programming
Date: Thu, 08 Jul 1999 22:15:48 +0100
Hi all,
I am just about getting into compilers and os programming. I would
realy like to have a very small version of linux. Posiibly a very old
version so that i can install bug fixes etc to help learning.
Where can i get the oldest version of linux for this kind of thing ?
I realy want it as small as possible, just a kernel and a c compiler
realy, obviously drivers of hard disks and monitor( command line mode )
but that is about it.
Any help realy appreciated.
Thanks
Dave
------------------------------
From: brian <[EMAIL PROTECTED]>
Subject: EQL enslave binary won't run under rh 6.0!
Date: Thu, 08 Jul 1999 17:14:50 -0400
Reply-To: [EMAIL PROTECTED]
Hello again.
I have just upgraded my system to rh 6.0 and am now experiencing
problems running the eql_enslave binary.....I believe rh 6.0 upgrades
glibc to V2.0? could this be the problem? I have not been able to
recompile the binary sucessfully nor can I find another binary with a
version number higher than 1.2......Can someone help me? The only error
I get is: Can't execute binary file......
Is there a way to get more verbose output to see what the actual
problem is? Thanks in advance!
Brian Gilman
------------------------------
From: Herve Lefebvre <[EMAIL PROTECTED]>
Subject: Re: Writing sound driver for Linux
Date: Fri, 9 Jul 1999 01:06:07 +0200
Le jeu, 08 jui 1999, ellis a �crit :
>In article <[EMAIL PROTECTED]>,
>lefebvre herve <[EMAIL PROTECTED]> wrote:
>
>>Where can I find some docs/samples about writing linux drivers for sound
>>cards ?
>
>Are there plenty of samples in the kernel source tree?
Well, "samples" yes but... I do not know where I must start to look at ... :)
Any doc or spec about drivers coding somewhere ???
--
H.L.
------------------------------
From: Ian Hutchinson <[EMAIL PROTECTED]>
Subject: egcs weaknesses (was idiocy but let's be civil)
Date: Thu, 08 Jul 1999 18:54:32 -0400
I was depressed by this thread because people seem to be admitting out
of the box that egcs produces bigger and slower code than gcc.
When I upgraded to RH6.0 and found that I only had egcs, I naturally
decided to switch. The penalty was enormous. I found that to compile -O
a big program (which you can see for yourself at
http://hutchinson.belmont.ma.us/tth )
took egcs 10 (yes ten) times longer than unoptimized and five times
longer than it took gcc to compile it optimized.
So unfortunately here is another strike against ecgs from the viewpoint
of compiling speed.
I am left with only one possible advantage of egcs versus gcc and that
is the integration of g77. All of the other areas sound like losses.
Can someone point out some of the benefits I should be getting?
Ian Hutchinson.
------------------------------
From: "JP S-C" <[EMAIL PROTECTED]>
Subject: System Developer(s) Wanted
Date: Thu, 8 Jul 1999 12:04:52 -0700
Dear Readers of comp.os.linux.development.system,
I am looking for Linux System Developer(s) who will possibly do some
programming or consulting for me. There may be payment for their services
(not necessarily huge amount of money) depending on their qualifications.
If you are an experienced Linux System Developer please mail me or post a
message in this newsgroup with a subject of something like "System
Developer(s) Wanted, REPLY" Thank you for your time.
Sincerely JP S-C
CodeArchive Book Reviewer, ITA
Web Developer, Linux and Graphics
Newbie, Entrepreneur
------------------------------
From: [EMAIL PROTECTED] (Jim Puthukattukaran)
Subject: PCI Hot Plug
Date: 8 Jul 1999 21:51:07 GMT
Hello all,
Alan Cox has started a mailing list for PCI Hot Plug support in Linux. Interested
parties can subscribe to the list and please send me some email. I can update you
as to what is being planned in this effort.
The mailing list is : [EMAIL PROTECTED]
thanks,
Jim Puthukattukaran
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: linux.dev.kernel,gnu.bug.glibc,comp.os.linux.development.apps
Subject: Patch for glibc-linuxthreads-2.1.1
Date: Tue, 06 Jul 1999 21:27:12 GMT
If the thread manager is unable to clone() a process, it must undo some
resource allocations that it performed in preparation of the new thread:
namely, it must unmap the initial stack (if one was created) and stack guard
page. HOwever, this is messed up! The guard page must be unmapped first, then
the stack. Because the top of the stack holds the thread structure which is
needed to retrieve the pointer to the guard page. Here is the patch.
This bug will cause the thread manager to segfault and turn into a zombie,
which results in massive deadlock in a threaded application. Such
a failure scenario was detected by Igor Khasilev, who posted his
observations in to comp.programming.threads.
--- manager.c.orig Tue Jul 6 14:09:24 1999
+++ manager.c Tue Jul 6 14:11:13 1999
@@ -379,10 +379,10 @@ static int pthread_handle_create(pthread
/* Free the stack if we allocated it */
if (attr == NULL || !attr->__stackaddr_set)
{
- munmap((caddr_t)((char *)(new_thread+1) - INITIAL_STACK_SIZE),
- INITIAL_STACK_SIZE);
if (new_thread->p_guardsize != 0)
munmap(new_thread->p_guardaddr, new_thread->p_guardsize);
+ munmap((caddr_t)((char *)(new_thread+1) - INITIAL_STACK_SIZE),
+ INITIAL_STACK_SIZE);
}
__pthread_handles[sseg].h_descr = NULL;
__pthread_handles[sseg].h_bottom = NULL;
------------------------------
From: [EMAIL PROTECTED] (Daniel Robert Franklin)
Subject: Re: egcs weaknesses (was idiocy but let's be civil)
Date: 8 Jul 99 23:10:14 GMT
Ian Hutchinson <[EMAIL PROTECTED]> writes:
>I am left with only one possible advantage of egcs versus gcc and that
>is the integration of g77. All of the other areas sound like losses.
>Can someone point out some of the benefits I should be getting?
C++ that works?
- Daniel
--
******************************************************************************
* Daniel Franklin - Postgraduate student in Electrical Engineering
* [EMAIL PROTECTED]
******************************************************************************
------------------------------
From: "Daniel Pietsch" <[EMAIL PROTECTED]>
Subject: Re: kernel programming
Date: Thu, 8 Jul 1999 19:18:50 -0400
Sounds like you'd be more interested in Minix or ELKS (Embeddable Linux
Kernel Subset).
Minix is similar to Linux in that it's a Unix clone that runs on x86 PCs.
Minix was designed and written as a learning tool. It has a modular kernel
that is small enough that one person can understand it. You'd also really
like the book: "Operating Systems: Design and Implementation" by Andrew S.
Tannenbaum (and some other guys). Get this book and it comes with a free
Minix CD (i.e. the OS plus the source code). Minix will even compile for
8086 CPUs if you don't want the virtual memory.
In fact, I believe that Minix inspired the creation of Linux when Tannenbaum
and Torvalds disagreed over Minix's future: Tannenbaum wanted it to remain a
small learning tool for his students, and Torvalds and his followers wanted
something that was ... well ... like Linux. You can actually see a copy of
Torvalds' original announcement of his new operating system (Linux) in the
first few pages of the RedHat 5.2 manual: it was posted to COMP.OS.MINIX.
As for ELKS, it's similar to Minix in that it has a small kernel that one
person can understand, it doesn't need an MMU and can run on older
processors or systems with scarce resources. It is, however, still in the
early stages of development (of course, you might like that if you wish to
contribute). Right now they have it running on 8086 or better CPUS, and
eventually envision it running on a lot of older CPUs -- even the 6502
(which I'll believe when I see it).
I recommend Minix for your adventure since it goes hand-in-hand with
Tannenbaum's book (Tannenbaum's also written some excellent books on
computer networking, operating system theory, and distributed operating
systems). You can find his stuff at Amazon.
The following should be of interest:
Minix:
http://minix1.hampshire.edu/
http://www.amazon.com
news://comp.os.minix
ELKS:
http://www.elks.ecs.soton.ac.uk/cgi-bin/ELKS
--
---
Daniel Pietsch
SST (a division of Woodhead Canada Limited)
Windows 95/NT/CE Developer (Applications and Device Drivers)
Remove NOSPAM and its mirror from my email address to reply,
------------------------------
From: toto <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Thu, 08 Jul 1999 20:15:37 -0700
Mike McDonald wrote:
> You think delete() is quick?
Compared to using a garbage collector--yes, very much so. Plus, keep in
mind, garbage collector doesn't eliminate the need to release memory,
all it does is do it automatically. It may be using the same delete or a
similar mechanism.
--
len
if you must email, reply to:
len bel at world net dot att dot net (no spaces, ats2@, dots2.)
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Subject: Re: egcs weaknesses (was idiocy but let's be civil)
Date: 8 Jul 1999 17:31:42 -0700
In article <[EMAIL PROTECTED]>,
Ian Hutchinson <[EMAIL PROTECTED]> wrote:
>I was depressed by this thread because people seem to be admitting out
>of the box that egcs produces bigger and slower code than gcc.
I don't think that there were any such admissions. I think it is safe
to say that egcs is much more aggressive in its optimization than gcc
was, and this may in many circumstances produce larger code - but the
code will be faster. Code size does not truly correlate with speed.
The troll^H^H^H^H^Hposter in question claimed that egcs created bloated
executables in comparison with gcc 2.7. The cited evidence was a 14K
difference in the compressed size of two kernels - which is a lousy
benchmark, given egcs' more aggressive time optimizations as well as
the fact that the "compressibility" of the code produced has a larger
influence on the final kernel size than the size of the object code.
Given the rather lame benchmark, I see little to convince anyone that
egcs produces worse code. If he were to post the vmlinux (uncompressed)
sizes, as well as a compilation with the -Os flag and an analysis of the
actual runtime kernel sizes (after initialization code has been thrown
away) then I might look at the original poster as something more than
a mythological monster hiding under a bridge pestering goats.
The other items cited were equally laughable. Comparing the size of
two different software packages to claim that egcs is less efficient
than gcc? Citing a "10-20%" speed loss on an unspecified benchmark
run under unspecified conditions? There's not enough there to pay
attention to, frankly, and I suspect that a lot of participants
ignored the post on that basis.
>When I upgraded to RH6.0 and found that I only had egcs, I naturally
>decided to switch. The penalty was enormous. I found that to compile -O
>a big program (which you can see for yourself at
>http://hutchinson.belmont.ma.us/tth )
>took egcs 10 (yes ten) times longer than unoptimized and five times
>longer than it took gcc to compile it optimized.
When you optimize more aggressively, you will take longer to produce
optimized code, Q.E.D. That's why you have different optimization levels.
Feel free to chose whichever level of optimization is best for your task
at hand.
>So unfortunately here is another strike against ecgs from the viewpoint
>of compiling speed.
>
>I am left with only one possible advantage of egcs versus gcc and that
>is the integration of g77. All of the other areas sound like losses.
>
>Can someone point out some of the benefits I should be getting?
Try writing any C++ template code with g++ 2.7 or before, and then try
the same tasks with egcs. You'll find the latter to be a heck of a lot
better.
Better yet, compile the programs you use everyday under each compiler
and benchmark them. If egcs is worse than gcc, it should show up
plainly. I'm sure that the egcs project would welcome hearing about
your analysis, for better or worse - this is, after all, how programs
get better.
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
We need to be happy in this wonderland without once being merely comfortable.
- G. K. Chesterton
------------------------------
From: "klauspg" <[EMAIL PROTECTED]>
Subject: interrupt handler in C
Date: Fri, 9 Jul 1999 02:20:11 -0000
Hi,
does anybody know if GCC (i386) can emit a function that is actually naked
(no stack frame, no return).
Regard,
Klaus P. Gerlicher
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: gnu.misc.discuss
Subject: Re: linx vs hurd
Reply-To: [EMAIL PROTECTED]
Date: Fri, 09 Jul 1999 01:00:00 GMT
On 08 Jul 1999 18:16:39 -0400, Adam Di Carlo <[EMAIL PROTECTED]> wrote:
>Following up on the database vs filesystem question, I have a friend
>who hates the utter redundancy between applications (even unix
>applications). His notion was to build a file system could be
>trivially used as a database as well (without requiring the
>specialized access that databases require, i.e., SQL, although you
>could layer that on I suppose).
>
>His notion was that such a file system would consist of only
>directories, no files, that is, a directed graph where any leaf node
>can become a branch node. Moreover, allow nodes to cross-link, rather
>like a directory hard-linking to another directory, so it's more of a
>cyclic directed graph than an acyclic one.
*No files?* That's a bit more original than the ideas I've seen so
far.
Although I guess that arguably allows one to correspond this to a DBMS
that doesn't allow BLOBs.
>If such low level information storage systems were actually worked
>out, I think theoretically we could generalize databases, file
>systems, web servers, etc. (One possible basis for this abstraction,
>as it occurs to me now, is a grove in the HyTime sense).
On a web server, you'd probably want to have the leaves be files.
The problem that comes in, and which is probably worth thinking
through, is that in such a system, the set of metadata that is
desirable to maintain will be somewhat different than you'd have with
a traditional filesystem.
Issue #1: There is a need to have two presentations for filenames:
- One that permits *anything* to be put into a filename, and
- One that permits filenames to be processed under the assumption
that they *don't* contain special characters such as spaces,
slashes (/ or \), quotes (", ', `)
Issue #2: The filesystem probably needs to support having a different
set of metadata.
- Some of the dates normally attached to a UNIX-like FS may be
utterly irrelevant.
- One might want to have a "user defined secondary index," with an
algorithmicly efficent access means (whether hashed, for efficient
access to specific keys, sorted, for efficient access to ranges,
or linear search when the assumption that "if you use this key
you'll be scanning the whole table" holds).
In effect, this amounts to having a *highly* parametrized filesystem
where you get to define a new FS "on demand."
Bounce this over to the Reiserfs mailing list; they've held
discussions involving this sort of thing, generally under the moniker
of "namespaces."
--
"I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb. Thank you."
-- Vance Petree, Virginia Power
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/linuxkernel.html>
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 8 Jul 1999 17:38:40 -0700
david parsons <o r c @ p e l l . p o r t l a n d . o r . u s> wrote:
>Nathan Myers <[EMAIL PROTECTED]> wrote:
>>NF Stevens <[EMAIL PROTECTED]> wrote:
>>>[EMAIL PROTECTED] (Nathan Myers) wrote:
>>>>
>>>>... the C++ compiler can optimize [template] code better than you
>>>>can [code] by hand in C, because it knows more about expressions
>>>>than you can tell the C compiler.
>>>
>>>The fact that templates expand to C++ code means that
>>>_templates_ cannot improve the efficiency of code.
>>
>>But C++ templates _don't_ expand (macro-like) to C++ non-template code.
>
> That is, I hope, a feature of an implementation, not the language;...
Optimization is a feature of implementations. We are discussing
optimization. David, please post where you have something meaningful
to contribute. Random noise helps nobody.
> ... Templates are very very sophisticated #defines
I can spot a troll when I see one. You only expose your own ignorance
with glib zingers like this.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
Date: Thu, 08 Jul 1999 20:55:06 -0400
From: Terry Boldt <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: CD-ROM File Time Bug
Peter Samuelson wrote:
>
> [Terry Boldt <[EMAIL PROTECTED]>]
> > How does the 'system' know that the time stored on the CD-ROM is UTC?
>
> Because you used a Unix variant to record it. (Actually a CD-burning
> program wouldn't *have* to use UTC but I think mkisofs is sensible
> enough to do so.)
Hmm - so I have to rely on the world using one system - Unix - This
sounds too much like MS to me.
>
> If you didn't burn the CD in Unix, then Heisenberg's Uncertainty
> Principle gives you a 12-hour window each way for when the CD was
> actually burnt. Note that this has nothing to do with the Unix client;
> you have that *same* 12-hour window if you read the CD in DOS, OS/2,
> Winblows, whatever.
>
> In other words, the Unix scheme is *predictable*. Other schemes rely
> on knowing where the CD came from.
Not at all - I only rely on what the person recording the CD says,
either personally or by comparing with the file giving the directory
listing incldued on the CD. I received a CD-ROM from TurboLinux today.
In comparing the file times in the directory listing file on the CD-ROM
with KDE - I get a different time for all files from what TurboLinux
says they should be. Without detailed knowledge of Linux/Unix I would
naturally reject the CD as unreliable.
>
> > Does the standard for writing CD-ROM state that the stored time is
> > UTC time? And this is universally recognized by all?
>
> 1) Dunno, I've never read ISO-9660. 2) I think so, in the Unix world.
> Outside Unix, YMMV. But why would you want to go outside Unix? (:
World domination by any factor is unpalatable.
>
> Think about this: do you care *exactly* when a CD file was created? If
> you *don't* really care, there is no issue here. If you *do* care, why
> are you willing to be off by as much as 23 hours because you don't know
> the original time zone?
If I *didn't* care I would not have posted to begin with.
My application MUST HAVE IDENTICAL REPORTING on all systems. By
reporting the time recorded on the media for removable media, there is
no problem - no correction. I now know that for Unix variants the
application must 'uncorrect' the displayed times/dates to get back to
the times recorded by the originator as other systems expect.
>
> > And if the CD-ROM was recorded in Paris, both differ from the time
> > the person in Paris thinks it was recorded.
>
> Not if the person in Paris used a Unix variant.
Yes even if the person in Paris used a Unix variant. Refer to my example
from TurboLinux above.
>
> > For a hard disk, this 'correction' probably makes sense
>
> It *does* make sense. And implementing arbitrary special cases is
> definitely not the Unix way, even if it were a good idea here, which I
> contend that it isn't.
If Unix doesn't have 'special cases' then why are there at least three
version of the grep utility. I am sure that anybody that has used any
flavor of Unix for very long can name many more 'special' cases.
>
> > If I backup a file to a floppy at Home on the east coast and then fly
> > (with my laptop and floppy) to the west coast. Correct the TZ setting
> > when I arrive so that the time displayed makes sense locally. I then
> > display the contents of the floppy directory to verify the time on
> > the file to ascertain that I have the correct floppy and backup, the
> > file time reported is going to appear completely wrong since it has
> > now been 'corrected' to west coast time with a 3 hour difference.
>
> No. You're looking at the problem wrong. Try this perspective:
>
> TZ=EST5EDT for the East Coast, we're in DST so time is -0400.
>
> - Back up file at 3:00 PM which is 19:00 UTC.
> - Fly to the West Coast. Six hours later you are settled in your
> hotel room, set your watch back three hours and have dug out your
> laptop.
>
> TZ=PST8PDT now, so time is now -0700.
>
> - This means it is 6:00 PM now, local time.
> - Look at file. `ls' notes your time zone and says you created the
> file at 12:00 noon.
> - Hmmm, `date' tells you it's 6:00 PM now, so that was six hours ago.
> - Sure enough, you created the file about six hours ago.
> - Yup, it's the same file.
>
> It's entirely consistent. What is the problem?
You have the wrong end of the stick. I noted the time the backup was
recorded, not the elapsed time till I expect to use it. If I attempt to
use the backup floppy three days later, I sure as heck am not going to
rely on a calculation of the elapsed time. In checking the file time
displayed against the time recorded, the two do not match because of the
TZ 'correction'. Again refer to the TurboLinux example above.
>
> Now the problems with what you are wanting:
>
> (a) You are assuming that a computer will only have *one* time zone
> active at any given time. What if five users are logged in from five
> different time zones? Which time zone should the system report
> removable media files in? The present system works fine, because the
> kernel does *everything* in UTC and the conversion happens in userspace
> with the help of your custom TZ variable.
No - I am relying on the fact that for removable media, the time
reported could/should be that recorded on the media where ever it was
recorded and not 'corrected' to the time to where I am attempting to
read it. That 'correction' leads to errors - see the TurboLinux example
above.
>
> (b) What's "removable" and what isn't? You can't always tell. Thanks
> to loopback mounting, you can mount a floppy disk image almost the same
> as a floppy ... so do you treat the disk image as "removable" or not?
> (If not, that's an ugly special case.) How about SCSI ZIP drives?
> They look (to the computer) a lot like other SCSI drives -- are you
> going to insert a kludge into the kernel to detect the difference?
The 'system' may not not be able to reliably tell, but the appropriate
device driver sure a heck should be able to tell. The device driver for
the CD-ROM should have some way of signalling the system that the media
is removable and not to apply erroneous 'corrections'. The user could
possibly over-ride where desired.
>
> (c) Why stop with removable media? Why not correct for network
> filesystems, by where they're being mounted from? (Not necessary,
> actually, since NFS servers usually use UTC and the SMB protocol is
> explicitly TZ-aware, but one can imagine a network filesystem you
> couldn't make assumptions about.)
But you ARE making assumptions by blindly applying the TZ 'correction'
to ALL file systems - irregardless of their type. Again the device
driver or file system s/w written for the device or file system could be
written to signal such information to the OS as appropriate.
Being blindingly 'consistent' may be good for machines, but I have never
met a 'consistent' human - remember who is master and what is slave
here.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: System Developer(s) Wanted
Reply-To: [EMAIL PROTECTED]
Date: Fri, 09 Jul 1999 01:00:10 GMT
On Thu, 8 Jul 1999 12:04:52 -0700, JP S-C <[EMAIL PROTECTED]> wrote:
>Dear Readers of comp.os.linux.development.system,
> I am looking for Linux System Developer(s) who will possibly do some
>programming or consulting for me. There may be payment for their services
>(not necessarily huge amount of money) depending on their qualifications.
>If you are an experienced Linux System Developer please mail me or post a
>message in this newsgroup with a subject of something like "System
>Developer(s) Wanted, REPLY" Thank you for your time.
On the other hand, considerable numbers of experienced kernel
developers have been hired up by Red Hat Software and
(whatever-they-call-the-company-formerly-known-as) VA Research,
reportedly at inflated Silicon Valley rates...
--
"The only ``intuitive'' interface is the nipple. After that, it's all
learned."
-- Bruce Ediger, [EMAIL PROTECTED] on X interfaces.
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
** 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
******************************
