Subject: Linux-Development Digest #156
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 11 Sep 94 13:13:05 EDT

Linux-Development Digest #156, Volume #2         Sun, 11 Sep 94 13:13:05 EDT

Contents:
  Re: 3c509 Problems (Danek Duvall)
  Re: Alpha Linux (Lloyd Miller)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Dan Pop)
  Re: RARP problem in 1.1.50 build (Thomas E Zerucha)
  Re: Alpha Linux (Albert D. Cahalan)
  Re: 1.2.0 - 1.3.0 questions -- Has anyone heard? (Bernd U Meyer)
  Re: Developing Distributed Filesystems for Linux? ("Derrick J. Brashear")
  Re: 320x200 X resolution? (Joe Thomas)
  Re: Anyone working on ISDN card drivers ?? (Patrick Schaaf)
  Re: Don't use Linux?! (Robert Moser)
  Re: Future of linux -- t (Keith Smith)
  Re: Linux console to SCO comp. prob (Keith Smith)
  Re: Multiprocessing Pentium Systems (Keith Smith)
  Re: Don't use Linux?! (Mark A. Horton KA4YBR)
  Help!--Compiling 1.1.50 (WARNES GREGORY)

----------------------------------------------------------------------------

Crossposted-To: comp.os.linux.help
From: [email-masked] (Danek Duvall)
Subject: Re: 3c509 Problems
Date: Sun, 11 Sep 1994 13:38:22 GMT

Just though I'd like to add, that, after leaving my computer alone for
a few hours, the network was up and running, with no help from me.
Weird.  

Now, however, I'm having problems with my monitor...  :)

Thanks,
Danek

------------------------------

From: [email-masked] (Lloyd Miller)
Subject: Re: Alpha Linux
Date: Sat, 10 Sep 1994 09:16:33 GMT

David Holland ([email-masked]) wrote:
> [email-masked]'s message of 06 Sep 1994 16:38:15 GMT said:

>  > Why drop one? 
>  > 16 bits = short int
>  > 32 bits = int
>  > 64 bits = long

> Over in the next thread people were talking about Unicode; why not

> 16 bits = char
> 32 bits = short
> 64 bits = int, long

> Of course that would break a lot of things, but such is the price of
> progress :-)

So you would agree with perhaps:

8 bits = short char
16 bits = long char
32 bits = short int
64 bits = long int

the default char and int sizes could be comile time / command line
options. The short and long qualifiers are already part of the language
anyway.

I agree with those who dislike the current GNU C "long long int" for 64
bits.

-- 
 Lloyd Miller, Calgary          Disclaimer:
 [email-masked]         I never wrote any of this.
 Terminal Insomniac             And besides, I got it all wrong.

------------------------------

Crossposted-To: comp.lang.fortran
From: [email-masked] (Dan Pop)
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: Sun, 11 Sep 1994 14:23:38 GMT

In <[email-masked]> [email-masked] (David Holland) writes:

>There's definitely room for a Fortran compiler, especially a good one.
>f2c just doesn't cut it for a lot of things. As far as C goes,
>remember you have to beat gcc and g++; but that shouldn't be terribly
>difficult. A native 80x86 compiler generates much better code than
>gcc, because the 80x86 architecture is so weird.
>
> > 2. How much would people pay for such a product [ loaded question ]?
>
>Depends on how good it is. If it doesn't offer any noticeable
>improvement over gcc, almost nobody's going to bother.
>
>One area where gcc falls seriously short, IMO, is performance...

Could you post some examples where a commercial native compiler for x86
produces _significantly_ faster codes than the free gcc?

Dan
--
Dan Pop 
CERN, CN Division
Email: [email-masked]
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

------------------------------

From: [email-masked] (Thomas E Zerucha)
Subject: Re: RARP problem in 1.1.50 build
Date: 11 Sep 1994 14:32:09 GMT

If you don't want to wait for another patch, you can edit rarp.c (in net/inet)
and put a #if 0 just before the "struct arphdr" line, and the #endif after the
closing brace.  There will be a nested #if 0/#endif which is within the
structure declaration.
---
[email-masked] - main email address

------------------------------

From: [email-masked] (Albert D. Cahalan)
Subject: Re: Alpha Linux
Date: 11 Sep 1994 03:07:05 GMT

   [email-masked]'s message of 06 Sep 1994 16:38:15 GMT said:

    > Why drop one? 
    > 16 bits = short int
    > 32 bits = int
    > 64 bits = long

   Over in the next thread people were talking about Unicode; why not

   16 bits = char
   32 bits = short
   64 bits = int, long

   Of course that would break a lot of things, but such is the price of
   progress :-)

That would actually make sense, except there isn't a data type 'byte'.
Perhaps this would work:

  8 bits = byte
 16 bits = char
 32 bits = short
 64 bits = int
128 bits = long (done by the compiler with 64 bit instructions)
--

Albert Cahalan
[email-masked]

------------------------------

From: [email-masked] (Bernd U Meyer)
Subject: Re: 1.2.0 - 1.3.0 questions -- Has anyone heard?
Date: Sun, 11 Sep 1994 02:49:47 GMT

[email-masked] () writes:

>Does anyone know if built-in-quota and accounting support is planned for 
>the new release?

From the mouth of the man himself (aka: "Linus in Melbourne"):

Not in 1.2, but soon in 1.3.

Bernie

--
"And the band played 'Waltzing Mathilda' /  as we stopped to bury our slain;
And we buried ours / and the Turks buried theirs  | ..... living in Oz ....
And it started all over again"                    | 
(The Pogues, "Waltzing Mathilda", orig by Eric Bogle, "And the band played WM")

------------------------------

From: "Derrick J. Brashear" <[email-masked]>
Crossposted-To: alt.filesystems.afs
Subject: Re: Developing Distributed Filesystems for Linux?
Date: Sun, 11 Sep 1994 10:59:47 -0400

Excerpts from netnews.alt.filesystems.afs: 10-Sep-94 Re: Developing
Distributed .. by John F [email-masked] 
> I spent some time a while back reverse engineering the AFS and RX
> protocols based on publicly available documentation and a network
> monitor (because even if you make the mostly valid assumption that
> C data structures map directly to network data structures, the
> documentation about the meaning of the fields is incomplete and
> at times incorrect).
>  
> I ended up with a proof of concept: it is possible to write a program
> independent of Transarc copyrighted source which will read or write an
> AFS file most of the time.  I don't have anything I would call an AFS
> implementation, though I may turn it into one eventually.  I don't have
> any code I'm willing to release.  Since this is crossposted to a Linux
> group I should also point out that I no longer use Linux (I saw the
> article in an AFS group) and I do not use the GPL for my software.
What I'm wondering is:
a) how long something like this would take
b) how reliable it would be

I too would be willing to work on a project like this, but as to whether
the answer is to write "free" AFS client software, or to write a totally
new system, I'm not sure. Kerberos 4 is out there, and is robust, and
may be a good starting point security-wise. Kerberos 5 is also out
there, but unless you invest time getting real kadmin servers and
such.... 

Anyhow, perhaps everyone interested in something like this should form a
mailing list?

-D

------------------------------

From: [email-masked] (Joe Thomas)
Crossposted-To: comp.os.linux.misc,comp.windows.x.i386unix
Subject: Re: 320x200 X resolution?
Date: 11 Sep 1994 11:25:37 -0400

In article <[email-masked]>,
Olli Vinberg <[email-masked]> wrote:
>In article <[email-masked]>,
>Andreas Matthias <[email-masked]> wrote:
>>
>>I have one that's working here (ET4000 with 17'' AOC monitor), but it
>>occupies only about half of the screen in vertical direction. I did
>>not find out how to make it bigger vertically. Perhaps someone else
>>can continue with this:
>>
>># name        clock   horizontal timing     vertical timing      flags
>>
>> "320x200"     25      320  360  424   440    200  200  240  250

>I seriously doupt that your monitor can handle that kind of
>refresh-rates.. Te above modedb-entry would mean a refresh-rate of
>250Hz!!! I tried to make a 320x200 too, and the closest I got was

Yeah, I've seen a few people post Xconfig entries for 320x200 that would 
have yielded refresh-rates of >250 Hz.  I hope people aren't blowing up 
their monitors out there.  I managed to come up with a 504x378 mode that 
works fine, and is about the best I can do while keeping my monitor under 
90 Hz, which is all it's spec'ed up to.

I also have a 360x270 mode that should work, but it needs a 12 or 12.5 
MHz dot clock.  My video card's manual says that it has 12.5 MHz dot 
clock that it uses for VGA 320x200 mode, but XFree86 2.1 doesn't find 
that clock when it does the probe.  The lowest one it finds is 25 MHz.  
Does anyone know a way to convince the X server to use a dot clock other 
than one it finds in the probe it does at startup?

(I added c.w.x.i386unix to the newsgroup line, and set followups back 
to c.o.l.misc.  For those just joining this thread, lots of people are 
looking for very low res X setups in order to run the recently released 
DOOM port for Linux.  I'm running XFree86 2.1 on Linux 1.0, with a Cirrus 
Logic CLGD 5426-based adapter (the MVGA-AVGA3VL) driving a CTX CMS-1561 
multiscan monitor.)

Joe
-- 
Joe Thomas <[email-masked]>           Say no to the Wiretap Chip!
PGP Public Key available by request, finger, or from [email-masked]
Key 01C3AADB fingerprint:  1E E1 B8 6E 49 67 C4 19  8B F1 E4 9D F0 6D 68 4B

------------------------------

From: [email-masked] (Patrick Schaaf)
Subject: Re: Anyone working on ISDN card drivers ??
Date: Sun, 11 Sep 1994 16:05:41 GMT

[email-masked] () writes:
>In article [email-masked], [email-masked] (Olaf Titz) writes:
>>
>> ftp://ftp.uni-stuttgart.de/pub/unix/linux/isdn
>>

>Thanks - I'll follow this up ... using a cheap card doesn't sound like too
>much of a problem to me :-)

>This has been the only answer so far. I can't really believe that all you
>IP service providers out there aren't using Linux machines !!!!

Well, that's how it is. As an example, while our server is running Linux,
we use a DOS box running KA9Q and ISDN packet drivers (PAPI, ISPA) as
our Internet router.

The kernel mentioned above seems to work for some people. I'd expect it
to become stable within the next months. It is the most complete free
ISDN implementation I know of, and I would advice anybody interested
in programming ISDN things under Linux to check it out.

Patrick

------------------------------

From: [email-masked] (Robert Moser)
Subject: Re: Don't use Linux?!
Date: 11 Sep 1994 04:27:41 GMT

Can't resist this one.  I'm half of a new startup company.  We're pushing the
envelope of PC hardware with a high resolution image display/processing
system.  We chose linux as our primary PC OS because it makes our 
(comparitively cheap) PC's perform like sparcstations for about 1/4 the
cost.  The only reason we don't use linux across the board is because there
isn't a sparc port (yet).  I expect our product will stress test linux in
new ways.  Further, I anticipate some OS development that will ultimately
benefit everyone which we will do on behalf of our product.

Linux was our only REAL alternative.

araw

------------------------------

From: [email-masked] (Keith Smith)
Subject: Re: Future of linux -- t
Date: Sun, 11 Sep 94 04:30:41 GMT

In article <[email-masked]>, Lau <[email-masked]> wrote:
>[email-masked]
>On 09/05/94, Joachim wrote:                   
>
>>As an example, I'm currently thinking about upgrading my 16MB to 32MB
>>since it's not enough for serious work. The AIX system at work is
>>already short at memory with 32MB, 64 or 128 MB would be fine. How
>>can I put 128 MB in my VLB PC? That's the reality I'm living in, and

My PC motherboard will hold something like 512MB, not that I could ever
afford anything close.  Compile "Hello World" under Linux, and on your
AIX box.  Compare the size of the stripped binaries.

>>I suppose Larry has a similar environment. I was even astonished that
>>he listed only a 400 MB disk, I wouldn't buy anything below 1 GB.

Also compare the size of the AIX OS (tit for tat) with Linux.  It is a
"no contest" if IBM is remotely true to form in code bloat. 

>    Reality is you'll likely never NEED 128 MB in your VLB PC.  Again, 
>pound for pound, RISC code is going to be about 30% larger than CISC code. 
> If you NEED 128 MB, get a newer motherboard w/ 72pin simms...4 32MB simms 
>= 128 MB.  I've seen quite a few MB's w/ 6 72pin simm slots, max 196 MB!!!

Actually the 72pin SIMM spec allows for up to 64MBytes of RAM on a
single simm (maybe more, but I KNOW it goes to 16Mx36bits)  That will
get you something like 384MB :).  Gosh, thats a lot of RAM.  Dunno what
a SINGLE user is gonna need that much ram for.  I'd say 32MB should be
more than adequate for anything you might be able to do on a PC/x86 type
box.  If your application calls for more than that, then you need
something a little more esoteric anyway.
-- 
Keith Smith        Digital Designs               [email-masked]
5719 Archer Rd.    PO Box 85       Free Usenet News and Internet Mail Services
Hope Mills, NC 28348-0085         All 28K/14K Modems  (910) 423-4216/7389/7391
Somewhere in the Styx of North Carolina ...         14K-V.32/28K-V.34/28K-V.34

------------------------------

From: [email-masked] (Keith Smith)
Subject: Re: Linux console to SCO comp. prob
Date: Sun, 11 Sep 94 04:58:27 GMT

In article <[email-masked]>,
Stephen Harris <[email-masked]> wrote:
>Keith Smith ([email-masked]) wrote:
>: Oh vomit.  The Fkey sequences under linux really suck.  They would be
>: GREAT if they followed a contiguous pattern, but they don't do that.  I
>: don't care what DEC did.  A suggestion would be something like:
>
>If you don't like them, then build your own keymap file and termcap entry.

Bad idea in most cases.  Ususally breaks bunches of stuff.  Of course
that is _exactly_ what I did anyway.  Oh, It _did_ break bunches of
stuff too. :()

>The point is that programs can't make assumptions about keyboard maps.
>That was the reason for termcap and terminfo in the first place!

Ahh, but they do, they do.

>: 'Splain where F22 is on a VT100 will ya?
>
>And explain where it is on a PC keyboard?  I'm damn sure there isn't any
>key above F12 on my keyboard.

Hmmm,  you need a 122 key IBM keyboard with an extra row of function keys
(f13...f24) above f1...f12.  "common" (hahahahahaha) practice uses
shift-f1 thru shift-f12 for f13 to f24 respective.

>: The WY-50 uses a CTRL-A leadin with characters from the ASCII chart
>: starting with '@' == 1 and work their way up the ASCII chart IN ORDER,
>: following the character with a CR.
>
>Isn't this the same keyboard where LEFT-ARROW produces the same code as
>BACKSPACE?  And where DOWN-ARROW produces a ^M

I did not mean to imply that the wyse keyboard layout was the be-all and
end-all of keyboard layouts.  Just that the Fkeys sent SANE logical
sequences of keys.

Down-Arrow produces a LINE-FEED (CTRL-J) actually.  The _left arrow_ is
generally the problem child.  These keyboards are also reprogrammable
on the newer models (to use your argument) and I generally map all my
wyse-150's to the SCO console layout, or use SCANCODE MODE, and the SCO
keymaps.  Simplifies things quite a bit with SCO's scancode mode.

>*Not* my favourite keyboard!  IMPOSSIBLE to tell whether the backspace or
>left arrow was pressed.  And they sure are used for different purposes!
>(stty erase '^H' anyone?)

Ahh, well, that is another bone of contention with me and the default
tty settings on login, using DEL for destructive backspace I find
annoying, but that tends to be what most mainframe and academia users
are used to.  In the DOS world they use backspace, SCO and Coherent also
use backspace for erase.

>: I have _NEVER_ seen a consistant DEC VT Function key keymap, but you can
>
>Strange.  VT220, VT320, VT420, Wyse85, Wyse99GT, MS-Kermit all produce the
>same keycodes for F5->F20  (using Shift on MS-Kermit to get F11-F20).
>Err, also Liberty and Altos5.

Err, okay, here's the deal sparky.  Wyse has sold a WHOLE SHITLOAD of
terminals.  The VT market is large, but nothing beside the wy50
compatable market.  Man those ADM-3's, wy-50/60/120/150/350/325/etc
televideo 9xx, altos, link, etc are EVERYWHERE.

>: So if you wanna emulate the "Most common" sequences you'd best pick the
>: Wyse keyboard sequences.
>
>Still disagree.  The most common terminal emulation that I have seen is that of
>a DEC VT.  But this is besides the whole point of the argument.
>
>1) Linux keyboard is reprogrammable
>2) Software with keyboard sequence limits is severly broken.

There are _ALWAYS_ limits.  Using the entire RAM resource of a machine
to map keycode sequences would seem to me to be rather wasteful yes?

Additionally long keyboard sequences are increasingly time consuming to
decode, and require longer detect timeout intervals ESPECIALLY when used
remotely over a modem with compression turned on.  I wrote an f-key
decode sequence with timeout to decode _anything_ up to the machine
resource, but to save going nuts I avoided sorting the sequences into a
tree and simply implemented a linear in-stream compare with shift
holding chars in a queue of the same size as the longest key sequence
you are decodeing.  Real pain in the ass, and it'll really beat the
machine if you define a few hundred 10 character Fkey sequences.

The main problem with longer sequences is TIME.  With the VT Fkey layout
the lead-in key is also a commonly used key used to back up one step in
most programs.  This means you _have_ to implement a timeout to detect a
naked escape.  Using a leadin like CTRL-A or maybe something odd like
CTRL-] means you can INSTANTLY detect the press of ANY single key on the
keyboard.  This makes your applications more responsive.  This makes
users happier.  Oh yea, who cares about _USERS_?  Silly me.

[ IBM's SAA takes over in computing, Film at 11. ]
-- 
Keith Smith        Digital Designs               [email-masked]
5719 Archer Rd.    PO Box 85       Free Usenet News and Internet Mail Services
Hope Mills, NC 28348-0085         All 28K/14K Modems  (910) 423-4216/7389/7391
Somewhere in the Styx of North Carolina ...         14K-V.32/28K-V.34/28K-V.34

------------------------------

From: [email-masked] (Keith Smith)
Subject: Re: Multiprocessing Pentium Systems
Date: Sun, 11 Sep 94 05:12:03 GMT

In article <[email-masked]>,
Richard Lamont <[email-masked]> wrote:

>Apparently compilations run about five times as fast with two Pentiums
>compared to one. I have no idea why this should be the case.

Because a compile is not a single process it is like 5 or 6ish

cpp -> cc1 -> cc2 -> cc3 -> [as ->] ld -> object_file

Depends alot on your compiler and how it does stuff like pre-processing,
and symbol resolutions.  Most masssage your program for at least 4
passes.  And they all run in a kernel pipleine, so you cut context
switching to do the compile in half for starters. and of course later
stages get a processor each to themselves.
-- 
Keith Smith        Digital Designs               [email-masked]
5719 Archer Rd.    PO Box 85       Free Usenet News and Internet Mail Services
Hope Mills, NC 28348-0085         All 28K/14K Modems  (910) 423-4216/7389/7391
Somewhere in the Styx of North Carolina ...         14K-V.32/28K-V.34/28K-V.34

------------------------------

From: [email-masked] (Mark A. Horton KA4YBR)
Subject: Re: Don't use Linux?!
Date: Sun, 11 Sep 1994 09:01:18 GMT

Michael Schumacher ([email-masked]) wrote:

: Hello Linuxers!

5. On the other hand, I can tell you how to make lots of money with Linux: 
   simply download the archives of tsx-11, sunsite, nic.funet.fi,
   prep.ai.mit.edu and ftp.x.org, put them on a CDROM, call it "Dream Linux"
   or similar, and sell if for US$35 per copy. It's that easy. Let's say,
   an average user is looking for "the better OS" and wants to try out
   Linux. He buys a "Dream Linux" CD - and is lost. Nothing works "out of
   the box", no reasonable documentation is available, nor hotline support. 
   What will happen? I'm quite sure that most of these desperated people
   will close the Linux chapter - forever.

  Quo vadis, Linux? Do we continue to like Linux "as is", or should we
change something in order to encourage companies to develop commercial, but
sophisticated end-user software for this beautiful OS? Do we continue to
keep Linux a powerful tool for wizards only, or do we want to see Linux 
being used in offices and other commercial environments? If we *really*
want Linux to succeed, we *need* the companies and their commercial products!

=============================================================================
                                (.. Ahem ..)

                mount -r -t raving.human /dev/keyboard /soapbox

I would, if I may, like to address these two points that Mr. Schumacher
makes.  First, regarding "5." above, not all Linux CD distributions are mere
dumps of the archive sites nor do they sell for large amounts of money.  With
some distributions, these DO "work out of the box" (assuming the user has
fairly standard hardware), they DO contain reasonable documentation (what
about all the FAQs, HOWTOS, Installation Guide, LDP publications, etc. 
provided as ASCII text with a DOS/Windows viewer for the new user and a
shell-based viewer for existing UNIX(tm) users?), and they DO provide a
reasonable amount of hotline support for FREE, albeit not necessarily through
a toll-free number (I think that someone paying $20.00 for a complete Linux
release with documentation doesn't mind spending a bit more of their own
money on phone calls if they run into trouble and indeed, have noticed this
in actuality).  [As an aside here to avoid flames, I must say that I assist
with Technical Support for the InfoMagic CD distributions.]  In my experience,
most users who call with technical support needs have accidentally overlooked
something or need a small pointer to the appropriate documentation; i.e. they
are NOT the clueless, brainless masses who are afraid to go beyond the 
bounds of vendor handholding.  Given the extremely wide variety of peripherals
that Linux supports (particularly in the CD-ROM area) there will be some 
problems... this is unavoidable.  It is far easier to take the attitude of
a vendor such as SCO or SUN and say "We will support THESE hardware config-
urations and ONLY THESE hardware configurations."  Given this option, Linux
installations could be automated to the point of "mount the CD, boot the
diskette provided, go to lunch."  And do not forget the capital investment
necessary to bring a CD to market... collecting the files, paying royalties,
premastering, mastering, pressing, packaging, inventory, staff.... I paid
a LOT for Solaris 2.3 for one of my SPARCs (yes I do use vendor software
at times) which arrived with serious bugs and then was informed that I'd 
have to PURCHASE the new "update" CD to fix many of those bugs.  Yessir!
Vendor support, you say?

As far as commercial products for Linux, I think that if they are there,
they will be purchased.  The recently announced Flagship package (a 
Clipper and xBASE clone to compile applications written in this popular
format) is just such an example.  They have a demo version that can be
downloaded and tried out for free and a special offer to Linux users 
wherein a single-user license is $199.00 and an unlimited-user (development
AND end-user packages) is only $499.00.  I spent my own money on this package
after running the demo, works great!  I applaud this company on their
forsight and willingness to take a chance on Linux rather than sit back
like many of the "commercial" vendors, afraid to invest anything at all in
a new environment.  The smart vendors will be getting in now, while the
market is relatively young and it's easier to capture a large share of it
rather than wait until it's "safe" and they become just another one of a
few hundred betting that they can capture 10% of the market!  Somehow,
the marketeers never see this flaw in their reasoning!  ;-)  

                                umount /soapbox

Regards,
Mark

--
"Linux!     Guerrilla UNIX Development     Venimus, Vidimus, Dolavimus."
============================================================
Mark A. Horton       ka4ybr             [email-masked]
P.O. Box 747 Decatur GA US 30031-0747         [email-masked]
+1.404.371.0291                     33 45 31 N / 084 16 59 W

------------------------------

From: [email-masked] (WARNES GREGORY)
Subject: Help!--Compiling 1.1.50
Date: 11 Sep 1994 04:24:21 GMT

I am trying to compile the 1.1.50 kernel and get the following error
at the very end:
        ld: No such file or directory for crt0.o
Could someone please point me to where this is supposed to be and where
I can get it from.  (I have had some problems with a corrupted file
system and have ended up wiping a few things here and there :(. )

Details:

Details:
        downloaded and untarred the 1.1.45 kernel
        applied patch.46 to patch.50 with 'patch -p0 < patch.xx'
        ran make:
                make config
                make dep
                make clean 
                make zImage

        The above error occured while running 
                make -C zBoot 
        in direcotory '/usr/src/linux/zBoot'

Thanks,
        Greg ([email-masked])

------------------------------

** 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-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************