Linux-Development-Sys Digest #799, Volume #6 Wed, 9 Jun 99 00:14:29 EDT
Contents:
Re: LinuxThread and GLIBC2.1 bug (David Wragg)
Casio QV-11 on Lava DSerial PCI Port (Marco Fonseca)
Re: Linux development tools - new : download freeware compiler with IDE and
GuiDesigner for Linux & Windows (Christopher B. Browne)
Re: TAO: the ultimate OS (Crispin Cowan)
HELP: kernel errors! (Remco van den Berg)
Re: the ultimate OS ("Hayden Walles")
Re: gcc: Internal compiler error: program cc1 got fatal signal 11 (root)
Re: EGCS problem - RH6.0 (LEBLANC ERIC)
IDE problem (UDMA) ("H barre (6.62e-34 J.s)")
Re: EGCS problem - RH6.0 (Eric Christopher)
Re: Linux development tools - new : download freeware compiler with IDE and
GuiDesigner for Linux & Windows ("Max Reason")
Images ("Lenny grosso")
Question about "ld86" that makes /usr/src/linux/arch/i386/boot/bootsect ("Cha, Hyun
Jin")
----------------------------------------------------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: LinuxThread and GLIBC2.1 bug
Date: 08 Jun 1999 20:34:56 +0000
XuYifeng <[EMAIL PROTECTED]> writes:
> I am using Redhat Linux 6.0. it seems glibc 2.1 and LinuxThread 0.8
> have a bug, I recently encountered it: after called function daemon()
> to turn program to background service, and then use pthread_create()
> to create a thread, the pthread_create() is always blocked and never
> return, normally daemon() will let descriptor 0, 1, 2 point to
> /dev/null, I changed these three descriptors to point to a real disk
> file, the problem disappeared! the scenario does not exist under
> glibc2.0 and LinuxThread 0.7.
Well spotted. The problem is in glibc-2.1 that daemon() calls
__fork(), whereas in glibc-2.0 it calls fork(). The result is that
LinuxThreads gets confused (specifically, it has the wrong pid for the
main thread).
The definition of daemon() isn't very long, so you can just copy the
file misc/daemon.c from the glibc-2.1 source (that file is BSD
licensed). Change the call to __fork() to a call to fork(), compile it
and link it into your program and all should be well.
David Wragg
------------------------------
From: Marco Fonseca <[EMAIL PROTECTED]>
Subject: Casio QV-11 on Lava DSerial PCI Port
Date: Tue, 08 Jun 1999 20:56:41 -0400
Does anyone out there know how I can go about getting Linux to recognize
the Lava card (which in Win98 device manager appears in two separate
entries: as a parent card and as COM ports 5 and 6) and then Casio
digital camera attached to it?
Thanks,
Marco Fonseca
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Subject: Re: Linux development tools - new : download freeware compiler with IDE and
GuiDesigner for Linux & Windows
Reply-To: [EMAIL PROTECTED]
Date: Wed, 09 Jun 1999 01:18:34 GMT
On Tue, 8 Jun 1999 06:52:16 -0000, Max Reason <[EMAIL PROTECTED]>
posted:
>[EMAIL PROTECTED] wrote in message ...
>> On Mon, 7 Jun 1999 22:13:55 -0000, Max Reason <[EMAIL PROTECTED]>
wrote:
>>
>>> Like I say below, I'm willing to make the XBasic source code
>>> available, but I'm ignorant of the mechanisms that work best.
>>> I mean look, I created the XBasic information and download
>>> pages and got jumped on for not "doing it right". When it comes
>>> to releasing the source code I'd like to "do it right" - but I don't
>>> know what that means. I hope to get opinions from a few more
>>> active Linux fans to guide me.
>>
>> [prev discussion snipped]
>>
>> this is a decision that only you can make (i assume you wrote
>> XBasic, or own the source)...
>
> Hey, there's a great idea - I could admit I own the source but
> not admit I wrote it. Then maybe I can escape criticism for
> the older and less-well-written sections! Great idea - thanks!
>
>> for many open source projects, the program, in source form,
>> along with pertinent license documents, helpful documentation,
>> and contributions in a contrib directory, are included in a
>> gzipped tarball...
>
> Do you think there should be two versions available, one for
> the majority who don't need source and prefer not to waste
> several megabytes of disk space - and another for the few
> who would "support" XBasic in the sense people are saying.
All you need worry about, forcibly, is the source code. With the
*widespread* use of binary packaging tools like RPM and dpkg, it is not
at all unreasonable to expect someone to build a binary package that
will be conveniently installable. And someone on the BSD side might
build a "Ports" version. All of these will be dependent on the
source code, so what's important is always the source...
The bonus is that by letting someone else be responsible for that,
this gets an extra person or two involved, which can't but be a good
thing...
>> for licensing, may i suggest a trip to www.fsf.org?
>
> I'll check that link out later tonight.
The suggestion that you look to <http://www.perl.org> for info
on the "Artistic License" was another good suggestion; it is
*extremely* difficult to get unbiased evaluations of the common
"open source" licenses because almost everyone has a significant
bias of one sort or another.
>> i'd also prepare each separate document of the client's
>> source code to include the copyleft statements, along with
>> contact information in the document's header space...
>>
>> however, after reading about 400K of assembler code
>> in the source...
>
> Don't be too scared! That is 400K of assembly language
> source text. Most of that is comments - it's very heavily
> commented. I just looked at the xlib.o file made from it,
> and it's 74KB, which means the actual executable binary
> is probably only - what? 32KB to 64KB maybe. If people
> dislike assembly in an open source project on principal,
> all of it could be converted to XBasic - about 1/3 - 1/2
> of the assembly are core routines where speed matters
> (like super-fast malloc(), calloc(), free() routines) and the
> rest for historical reasons [translation: stupid decision].
Do you have an assembler integrated in? If it takes a proprietary
assembler to get it assembled, that will be something of a barrier...
Note that the downside to assembler is that there are increasing
numbers of people not using IA-32-based architectures, and the "general
availability" of 64-bit systems is fairly rapidly approaching.
The *big* problem with assembler is that it ain't portable. I
suspect that if the system becomes popular, an item on the "task list"
will be to make it portable...
--
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: [EMAIL PROTECTED] (Crispin Cowan)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 9 Jun 1999 01:35:04 GMT
In article <[EMAIL PROTECTED]>,
Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>: Vladimir, are you really *that* clueless? Do you seriously imply
>: that work here is done without design? Sigh... Look, there are several
>: criterions that should be met to get, erm, a positive attention:
>
>give me a design document that outlines the areas I have covered
>in mind, for Linux. I will look at it. I have not found such a document.
"The UNIX Time-sharing System", by D.M. Ritchie and K. Thompson,
Communications of the ACM, Vol. 17, # 7 (July 1974), pages 365-375.
UNIX had a vision. Linux is an re-implementation of UNIX.
You present something that perports to be a vision, but you don't
substantiate any of the motivation for the decisions the vision makes.
Since there is not motivation and no implementation, we have no way of
evaluating whether your vision is a good idea or not. We have to, in
effect, take your word for it.
You then go on in discussion with various parties to demonstrate that
you have no idea what you are talking about, making your "expert
opinion" on such design issues seriously suspect. MANY people have
wish lists, and most of those people know far more about what they're
talking about than you do. So we cannot just take your word for it.
You must either substantiate your design with scholarly justifications
or with an implementation and experiments before anyone can take you
seriously.
Crispin
=====
Crispin Cowan, Research Assistant Professor of Computer Science, OGI
NEW: Protect Your Linux Host with StackGuard'd Programs :FREE
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
Microsoft: Putting the "lame" in "layman"
------------------------------
From: [EMAIL PROTECTED] (Remco van den Berg)
Subject: HELP: kernel errors!
Date: Tue, 08 Jun 1999 20:56:54 GMT
Just got this on my screen:
Jun 8 21:49:56 jupiter kernel: Unable to handle kernel paging request at
virtual address 14408b70
Jun 8 21:49:56 jupiter kernel: current->tss.cr3 = 0284e000, %cr3 = 0284e000
Jun 8 21:49:56 jupiter kernel: *pde = 00000000
Can somebody tell me what caused this message?
some system info:
Linux jupiter 2.2.5 #7 Wed Apr 7 23:20:00 CEST 1999 i586 unknown
total used free shared buffers cached
Mem: 95956 92872 3084 64932 8692 41180
-/+ buffers/cache: 43000 52956
Swap: 69516 116 69400
-Remco
--
============================================================================
Remco van den Berg Admin DSE http://www.dse.nl/
[EMAIL PROTECTED] Linux Certified Systems Engineer :-)
============================================================================
------------------------------
From: "Hayden Walles" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: the ultimate OS
Date: Wed, 9 Jun 1999 13:37:57 +1200
This is more of a comment on the discussion thread, rather than any
particular messages within it (except the original document of course)
The Tao document has created rather a clutter of replies and
counter-replies. Many of these criticize the author for posting such a
document for a variety of reasons. A popular one is that this "design
document" is too vague to be of any use.
Since the post, this thread has been largely devoted to saying "Where is
your code?", "You don't know what an object is", "You don't define your
terms" and similar criticisms aimed at eroding the credibility of the
author. Some of the criticism is valid, much of it is hypocritical
(especially quasi-peer-review that uses no better critical method than the
author), and almost all ignores the crucial fact that Tao is a DESIGN
document.
Alright, perhaps it is too long. Perhaps the author repeats himself,
and perhaps the author has a limited knowledge of the features he is
discussing. Fairly obviously he went too far with the choice of newsgroups
to post to. But one thing he cannot, IMHO, be accused of is bad design.
Most critics of the Tao document are content to quibble with exact
wording of the technical details, and use this to generally bash the ideas
presented. But these critics do not recognise properly - indeed some appear
to have no comprehension of it - the formal design process. The Tao
document is just a beginning. It specifies two things: the Tao brief, and
a single Tao concept. Admittedly these are presented b the author in a
confusing and muddled way, but they are there.
The Tao brief calls for an operating system that cannot contract a
virus, is easiest to use for the end-user, is easy to configure, maintain
and repair, etc. The author of the Tao document has used these brief
parameters as his paragraph topics generally. I'll allow that some of these
parameters are too vague, and that they should either be subdivided or
rewritten.
After introducing each parameter, the author introduces the aspect of
his design concept that will fulfill it. Here we find the author proposing
the object-oriented ideas, and various filesystem, compilation options
associated with them. This is no crime. Nor is it a crime that the he does
not explain the technically exact meaning of object - this is a concept, not
a final specification, and exact description is not necessary. The ensuing
design stages, where development occurs, will gradually add to and filter
the concept. A chair in concept may develop into a sofa, or a kitchen
stool.
It would of course be better of there were more than one concept arrayed
for comparison with the author's one. This is also a part of design. No
doubt there are people out there who have alternative solutions to the brief
set out for Tao. Submit them, and allow us to compare the concepts. The
author of the Tao document did not publish in such a wide forum merely to
aggravate us. If Tao is an open-design operating system, his intention was
no doubt to get constructive feedback.
So if you are wont to flame the thread with arguments similar to "You
don't tell me exactly what this is so I won't talk t you!" instead send
queries. Suggest alternatives to the concepts used to solve the brief.
Develop the brief to define the terms. Many posters have show that they
have the expertise to do this, but they only demand answers of the author,
who presumably wants _us_ to define these terms.
To the Tao document author, I suggest that you rewrite the essay, divide
it into a brief, your concept, and any other concepts you may receive, and
repost it (to fewer,more suitable groups) for comment and development.
To everyone: Read the Tao brief. Read the Tao concepts. Let Tao develop
further before you shower it with scorn.
=========
Hayden Walles
[EMAIL PROTECTED]
http://thor.prohosting.com/~walles
------------------------------
From: root <[EMAIL PROTECTED]>
Subject: Re: gcc: Internal compiler error: program cc1 got fatal signal 11
Date: Wed, 09 Jun 1999 15:32:04 -0500
Reply-To: [EMAIL PROTECTED]
I used to get the same errors on a Cyrix chip. Changing it to an AMD fixed the
problem
Daniel Robert Franklin wrote:
> Nigel Tamplin <[EMAIL PROTECTED]> writes:
>
> >Hi,
>
> >I keep getting the following error when compiling large programs on my
> >Red hat 6 intel box.
>
> >gcc: Internal compiler error: program cc1 got fatal signal 11
>
> >I have had the error when compiling postgres-6.4.2 and also
> >openssl-0.9.3a, the source code compiles cleanly on my Red Hat 5.2
> >machine but not on my Red hat 6.0 machine.
>
> >Any ideas?
>
> Yes. This is a FAQ - in short, your hardware is probably defective. Do
> a search for the Sig11 FAQ, that should give you all the information
> you need.
>
> - Daniel
> --
> ******************************************************************************
> * Daniel Franklin - Postgraduate student in Electrical Engineering
> * [EMAIL PROTECTED]
> ******************************************************************************
------------------------------
From: [EMAIL PROTECTED] (LEBLANC ERIC)
Subject: Re: EGCS problem - RH6.0
Date: Wed, 09 Jun 1999 02:16:45 GMT
root ([EMAIL PROTECTED]) wrote:
:
: I am trying to compile the following code -
jughead:~$ g++ -Wall test.c
jughead:~$ ./a.out
The pay is: 480
jughead:~$ g++ --version
egcs-2.91.63
I use Debian 2.1 with some newer packages. (glibc 2.1, egcs, etc)
[snip code]
: I manually typed the above code and error messages in so take that into
: account. I am not receiving any errors about 'iostream.h' missing.
: Why is this happening?
A missing library? I think libstdc++ maybe...
Regards,
E.
------------------------------
From: "H barre (6.62e-34 J.s)" <[EMAIL PROTECTED]>
Subject: IDE problem (UDMA)
Date: Tue, 8 Jun 1999 22:20:35 +0200
I just compiled in the kernel 2.2.4 and I was happy that
it offer a specific driver for the Ali 1543 chipset (UDMA on Asus
motherboard).
But I still obtain a stange message :
[J'obtiens un bug IDE � chaque d�marrage de l'ordinateur,
apr�s un certain laps de temps d'inactivit�.
ex: j'allume mon PC, je vais faire autre chose, le message
de login est affich� et en dessous ce message :]
hdc: timeout waiting for DMA
hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: DMA disabled
ide1: reset: success
[C'est syst�matique depuis que j'ai la carte m�re ALi et le nouveau
driver 'drivers/block/alim15x3.c' qui va avec le kernel 2.3.3 !
D'ailleurs meme en forcant le DMA avec le BIOS et/ou avec 'hdparm'
j'obtiens les meme symptomes !
Un peu d'aide me serait n�cessaire et j'en serais tr�s reconnaissant.]
I hope that somebody encounter this same problem
Thanks
Michel B.
------------------------------
From: Eric Christopher <[EMAIL PROTECTED]>
Subject: Re: EGCS problem - RH6.0
Date: 08 Jun 1999 18:42:56 -0700
This should go to the egcs list, however, you need to use:
#include <iostream>
instead of:
#include <iostream.h>
-eric
root <[EMAIL PROTECTED]> writes:
> I am trying to compile the following code -
>
> --------
> #include <iostream.h>
>
> float ComputePay(float hours, float rate)
> {
> return hours * rate;
> }
>
> main()
> {
> double hours;
> double payrate;
>
> hours = 40;
> payrate = 12.5;
>
> cout << "The pay is: " << ComputePay(hours, payrate) << "\n";
>
> return 0;
> }
> ------------
>
> Compiling this code results in the following errors.
>
> In function 'main':
> undefined reference to 'cout'
> undefined reference to 'ostream::operator<<(char const *)'
> undefined reference to 'ostream::operator<<(float)'
> undefined reference to 'ostream::operator<<(char const *)'
>
> -------------
>
> I manually typed the above code and error messages in so take that into
> account. I am not receiving any errors about 'iostream.h' missing.
> Why is this happening?
>
>
> Thanks,
> tom
------------------------------
From: "Max Reason" <[EMAIL PROTECTED]>
Subject: Re: Linux development tools - new : download freeware compiler with IDE and
GuiDesigner for Linux & Windows
Date: Tue, 8 Jun 1999 16:58:35 -0000
Christopher B. Browne wrote in message ...
>On Tue, 8 Jun 1999 06:52:16 -0000, Max Reason <[EMAIL PROTECTED]>
>posted:
>>[EMAIL PROTECTED] wrote in message ...
>>> On Mon, 7 Jun 1999 22:13:55 -0000, Max Reason <[EMAIL PROTECTED]>
>wrote:
>>>
>>>> Like I say below, I'm willing to make the XBasic source code
>>>> available, but I'm ignorant of the mechanisms that work best.
>>>> I mean look, I created the XBasic information and download
>>>> pages and got jumped on for not "doing it right". When it comes
>>>> to releasing the source code I'd like to "do it right" - but I don't
>>>> know what that means. I hope to get opinions from a few more
>>>> active Linux fans to guide me.
>>>
>>> [prev discussion snipped]
>>>
>>> this is a decision that only you can make (i assume you wrote
>>> XBasic, or own the source)...
>>
>> Hey, there's a great idea - I could admit I own the source but
>> not admit I wrote it. Then maybe I can escape criticism for
>> the older and less-well-written sections! Great idea - thanks!
>>
>>> for many open source projects, the program, in source form,
>>> along with pertinent license documents, helpful documentation,
>>> and contributions in a contrib directory, are included in a
>>> gzipped tarball...
>>
>> Do you think there should be two versions available, one for
>> the majority who don't need source and prefer not to waste
>> several megabytes of disk space - and another for the few
>> who would "support" XBasic in the sense people are saying.
>
> All you need worry about, forcibly, is the source code. With the
> *widespread* use of binary packaging tools like RPM and dpkg,
> it is not at all unreasonable to expect someone to build a binary
> package that will be conveniently installable. And someone on
> the BSD side might build a "Ports" version. All of these will be
> dependent on the source code, so what's important is always
> the source...
>
> The bonus is that by letting someone else be responsible for
> that, this gets an extra person or two involved, which can't but
> be a good thing...
I agree with that, but I missed something. Who would these
extra person or two you mention be?
>>> for licensing, may i suggest a trip to www.fsf.org?
>>
>> I'll check that link out later tonight.
>
> The suggestion that you look to <http://www.perl.org> for info
> on the "Artistic License" was another good suggestion; it is
> *extremely* difficult to get unbiased evaluations of the common
> "open source" licenses because almost everyone has a
> significant bias of one sort or another.
One thing that would help me would be a list of what are the
natures of the significant biases, and the overall feelings
people have about one vs another.
>>> I'd also prepare each separate document of the client's
>>> source code to include the copyleft statements, along with
>>> contact information in the document's header space...
>>>
>>> however, after reading about 400K of assembler code
>>> in the source...
>>
>> Don't be too scared! That is 400K of assembly language
>> source text. Most of that is comments - it's very heavily
>> commented. I just looked at the xlib.o file made from it,
>> and it's 74KB, which means the actual executable binary
>> is probably only - what? 32KB to 64KB maybe. If people
>> dislike assembly in an open source project on principal,
>> all of it could be converted to XBasic - about 1/3 - 1/2
>> of the assembly are core routines where speed matters
>> (like super-fast malloc(), calloc(), free() routines) and the
>> rest for historical reasons [translation: stupid decision].
>
> Do you have an assembler integrated in? If it takes a
> proprietary assembler to get it assembled, that will be
> something of a barrier...
This takes a little explaining. When you develop programs
in the development environment, XBasic emits executable
binary directly into memory, then executes it - translation is
directly from XBasic source-code to executable binary
machine instructions. To make standalone executables
XBasic generates an assembly language file and makefile.
The assembly language generated by Linux XBasic
assembles on whatever assembler was bundled with
Caldera Linux 4+ years ago when I make Linux XBasic.
This is probably the GNU assembler, but recently I got
a new computer and don't have Linux on it to check.
Anyway, I assume the assembler must be one of the
standard freely available Linux assemblers. Right?
The assembler for the Windows implementation IS
non-standard, but an old friend of mine wrote it and
it's based on something called yacc as I recall.
Anyway, I have all the files required to build it, so it too
can become part of the XBasic source code package.
> Note that the downside to assembler is that there are
> increasing numbers of people not using IA-32-based
> architectures, and the "general availability" of 64-bit
> systems is fairly rapidly approaching. The *big* problem
> with assembler is that it ain't portable. I suspect that if
> the system becomes popular, an item on the "task list"
> will be to make it portable...
XBasic does NOT have an inline assembler. I've been
roundly criticized for that many times. Your comments,
however, seem to lean in my favor. Finally! :-)
Like I said, the assembly language can be recoded in
XBasic and made totally "portable", since the rest of
XBasic is written in XBasic already - without C library
support but yes, of course direct Linux system calls.
Nonetheless, your comments strike me as somewhat
strange. Maybe I designed XBasic in a stupid way,
but to port XBasic to an Alpha or Sparc or Merced
requires making it emit code for the target CPU
everywhere it emits code. That seems like lots more
work than converting a small assembly language file.
Originally I developed XBasic for a Motorola 88000
workstation (running UNIX of course). That's a very
nice 32-bit RISC CPU. When I made the Windows
and Linux and UNIX implementations of XBasic for
the 80486+ CPU, I had to live with only 8 registers,
compared to the 32 I had in the 88000. Now maybe
I am a stupid compiler designer, but for me it was
more work to change XBasic to emit code for the
80486 from the 88000 than to rewrite that assembly
language file. I was not aware that compilers could
be effectively written so you simply plug in a new
CPU architecture template (or something) and say
presto-chango, emit efficient optimized code for
this new CPU architecture. Of course I CAN see
that going from one 32 register RISC CPU to another
32 register RISC CPU would not be as much work.
And XBasic was very much designed to scale to
64-bit architectures without difficulty or problems
with 32-bit vs 64-bit program compatibility. Anyway,
that is the situation with XBasic - for better or worse.
By the way, what is "IA-32-based architecture" mean?
Does that mean Intel 80486/Pentium I, II, III - or what?
Max
------------------------------
From: "Lenny grosso" <[EMAIL PROTECTED]>
Subject: Images
Date: Tue, 8 Jun 1999 11:45:22 -0500
Does anybody know of good resources and information for creating images for
floppys. This would let me make and install for my new linux dist.
Thanks
Lenny grosso
------------------------------
From: "Cha, Hyun Jin" <[EMAIL PROTECTED]>
Subject: Question about "ld86" that makes /usr/src/linux/arch/i386/boot/bootsect
Date: Wed, 09 Jun 1999 12:35:02 +0900
I have a question about ld86.
when I finished "make zImage", here is the result.
.
.
-rwxr-xr-x 1 root root 544 Jun 9 09:50 bootsect*
-rw-r--r-- 1 1046 1046 9540 Jun 9 09:50 bootsect.S
-rw-r--r-- 1 root root 1241 Jun 9 09:50 bootsect.o
-rw-r--r-- 1 root root 8149 Jun 9 09:50 bootsect.s
.
.
I have changed the "booting message" in bootsect.S from "Loading"
to "Fucking M$"(^^;).
Now, I have bootsect.o(size 1241) different from original
bootsect.o(size 1238).
But, bootsect* size 544(512 + MINIX_HEADER_LEN(32)) never changed.
And, there is another strange thing.
Original "booting message" is "\nLoading"(9byte).
message size 9byte to 16byte make same result above.
but message size 17byte, 18byte.... make ld86 error.
ld86: cannot write output file bootsect
and bootsect size is big as much as disk full.
It's so strange to me.
How can ld86 make different size bootsect.o same size bootsect?
Why message size(maybe bootsect.o size??) important to ld86?
BUT!!! ld86 make different size setup.o different size setup!!
Is it originally designed that?
That's it.
Sorry about my poor english ^^;
Thanks in advance....
------------------------------
** 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
******************************
