Subject: Linux-Misc Digest #590
From: Digestifier <Linux-Misc-Request@senator-bedfellow.MIT.EDU>
To: Linux-Misc@senator-bedfellow.MIT.EDU
Reply-To: Linux-Misc@senator-bedfellow.MIT.EDU
Date:     Thu, 11 Aug 94 11:13:14 EDT

Linux-Misc Digest #590, Volume #2                Thu, 11 Aug 94 11:13:14 EDT

Contents:
  Re: Possible bug in rpc.nfsd (Michael Faurot)
  URGENT: Sources need for comp.sources.reviewed (David Boyd)
  Re: starting X automatically on installing linux distribution (Byron A Jeff)
  Newbie to Linux has a few of questions (Vidiot)

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

From: mfaurot@phzzzt.atww.org (Michael Faurot)
Subject: Re: Possible bug in rpc.nfsd
Date: Wed, 10 Aug 1994 23:37:15 GMT

In article <37800003@glas> you wrote:
: After some time, rpc.nfsd process becomes accessible by any user in the
: system. Hes/she can kill it. What is it? This feature is very annoing.
: I use Linux 1.1.38 now, but this feature started in 1.1.37.
: Is it a bug in 1.1.37 or in rpc.nfsd, or my setup is wrong? (Hmm, last
: seems to be the answer).

I'm seeing the same thing with a 1.0.8 kernel.  Initially it's owned
by root.  Do a mount from another machine running a DOS NFS client,
and then the thing is owned by that user.

I've also had problems too when the DOS client dies/locks-up without
having first unmounted the filesystem, it causes the rpc.nfsd daemon
to cause the Linux filesystem to busy.  For example if I mounted up a
cdrom, exported that, and then had the dos machine mount it.  The dos
machine crashes without properly unmounting first.  If I go to unmount
the cdrom from the Linux host, I get error that the filesystem is
busy.  After I kill off rpc.nfsd and restart all is fine and I can
then unmount.

--
+--------------------+----------------------------+--------------------------+
|   Michael Faurot   | mfaurot@phzzzt.atww.org    |      I don't like        |
|   ------- ------   | ...!netcomsv!phzzzt!mfaurot|      lima beans!!        |
+--------------------+--------------------+-------+--------------------------+
| Fleischman:  Ed, are you hallucinating? |    I wanna go home with the      |
|         Ed:  Oh yeah, but not right now.|  Armadillo . . . --Gary P Nunn   |
+-----------------------------------------+----------------------------------+

-- 
+--------------------+----------------------------+--------------------------+
|   Michael Faurot   | mfaurot@phzzzt.atww.org    |      I don't like        |
|   ------- ------   | ...!netcomsv!phzzzt!mfaurot|      lima beans!!        |
+--------------------+--------------------+-------+--------------------------+

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

From: dwb@ITD.Sterling.COM (David Boyd)
Crossposted-To: comp.sources.testers,comp.sources.wanted,comp.sources.d,alt.sources.d,alt.sources.wanted
Subject: URGENT: Sources need for comp.sources.reviewed
Date: 10 Aug 1994 22:33:00 GMT

We need sources !!!!!!!!

Comp.Sources.Reviewed is in need of submissions.  The first package submitted
after the restart has over a dozen reviewers.  We need new packages submitted
for review. If you submitted your package to CSR before and now have a
new version re-submit it.  Dust off the code you have been planning on
cleaning up and post it to comp.sources.reviewed.  All you Linux and
386bsd users out there, submit your latest greatest Linux source programs 
to CSR.  CSR needs your submissions to work.



What is Comp.Sources.Reviewed?
==============================

"Comp.sources.reviewed" is a moderated newsgroup (moderator: David
Boyd [comp-sources-reviewed@sterling.com]) with the following guidelines:

    Comp.sources.reviewed is a moderated newsgroup for the distribution of
    program sources that have been subjected to a Peer Review process.
    Similar to the process used for academic journals, submissions are sent
    to a moderator who then sends the sources to Peer Review volunteers for
    evaluation.  The Reviewers are asked to provided a timely evaluation of
    the software by compiling and running it on their machine.  If time does
    not permit them to complete a review, they are responsible for asking
    the moderator to select another reviewer.  The completed reviews will
    be collected by the moderator and provided to the author of the software
    along with a recommendation as to whether the software should be posted
    in its current form.  The author can then decide whether to post the
    software, make the recommended corrections and re-submit the software
    for another round of reviews, or withdraw the software from the review
    process.  In cases of dysfunctional software the moderator reserves
    the right to override the Author's decision and reject the package for 
    posting.  Upon agreement between the Author and moderator to post 
    the software, the sources will be posted along with the written comments 
    provided by the Reviewers.  In all cases the Reviewers' comments will
    be posted as well.


How to submit software
======================

- Software is mailed to the csr submission address 
  (comp-sources-reviewed@sterling.com)
  in small (< 80K) shar files.

  All software packages must include:

        a. An introduction to the package for the moderator containing:
        
           1. Information on any hardware or software dependencies.

           2. Any suggestions for or limitations on the review period.

           3. A brief description of the package suitable for inclusion in 
              the CFR.

        b. A makefile, or makefile equivalent.

        c. Directions for building and installing the software

        d. Manual Page(s) or other documentation detailing how to use
           the software.

- Upon acceptance of the package for review, your name will be added to
  a restricted mailing list for the author and reviewers (the moderator 
  will also monitor the list).  Respond as necessary to any questions or
  comments from the reviewer.  Providing patches during the review cycle
  is discouraged but allowed to fix specific problems encountered by
  reviewers. (NOTE - The moderator will not be tracking patches provided via
  this mailing list.  The Author will be required to provide a complete set
  of patch updates to the moderator following the review period and the 
  package will require a regression review prior to being posted).  

- Any author who becomes abusive or derogatory towards the reviewers, or
  the moderator will have their review terminated.  Future reviews of
  software by that author will be at the discretion of the moderator.

- At the completion of the review period the moderator will provide the
  author with a summary of the review comments and will conduct a vote 
  among the reviewers, the author and himself as to the suitability of
  the package for posting. The vote will be anonymous (only the moderator
  will know who voted what way) and the final tally of the votes will
  serve as a reccomendation to the author on the suitability of the
  package for posting.

- The author will review the comments and with the help of the moderator,
  make a decision on how to proceed along one of the following paths:

        a. Withdraw the package from the review process.

        b. Request that the package be posted as-is (the moderator
           reserves final approval on this option). 

        c. Provide the moderator with a set of patches to the original
           baseline and request an abbreviated regression review by the
           current set of reviewers (No CFR will be issued). (Note -
           The moderator reserves the right to determine if the patches 
           are too extensive and the package requires a complete review
           cycle).

        d. Opt not to post the package at this time and to resubmit for
           a complete review at a later date.

What the moderator will do
==========================

- On receipt of the package the moderator will check the package to 
  determine if it meets the submission criteria above, unpacks cleanly, and
  if feasible at least builds on the moderator's work machine.  If the package
  does not meet the submission criteria the author will be notified and asked
  to re-submit the package.

- The moderator will generate a CFR which includes the following:

      a. A brief description of the package.

      b. A list of known limitations and hardware/software requirements
         for the package.

      c. The dates for the review period.

      d. Directions on how to obtain the package for review (Currently
         only mail-server support for retrievals is planned. Anonymous FTP
         support can be added in the future if folks want it).

      e. The address of the mailing list for discussions during the review
         period.

- The moderator will mail the CFR to the standing reviewers list (see 
  below for how to be added to that list) and will post the CFR to 
  comp.sources.testers along with any other appropriate groups (e.g.
  comp.windows.x for X based packages, comp.os.linux.announce for linux 
  packages, etc).

- The moderator will monitor who retrieved the package for review and the
  discussion list during the review period.  If during the initial part 
  review period the package appears to be dysfunctional the moderator (after
  consultation with reviewers) may terminate the review cycle and provide 
  the author with a description of the problems encountered by the reviewers.

- If no one volunteers to review the package within a reasonable time
  following the CFR the moderator will either:

        a. Reissue the CFR with new review dates.

        b. Suggest to the author that the package be posted to another
           appropriate source group.

- Prior to the expiration of the review period the moderator will remind
  any reviewers who have not submitted reviews that they are due.  This will
  be done via either private mail or the package discussion list.

- At the expiration of the review period the moderator will summarize the
  reviews and provide the summary, and complete reviews to the author.
  The moderator will also conduct an anonymous poll among the reviewers,
  moderator, and author as to the reccomended disposition of the package.
  The final tally of this vote will be provided to the author and reviewers.

- If the author opts to provide a set patches to correct identified 
  problems the moderator will:

     a. First verify that the patches apply to the baseline source cleanly. 

     b.  The patch set will then be provided to the existing reviewers via 
         the package discussion list along with the expiration date of the 
         regression review period.  Only one set of patches will be accepted 
         for a package during the review cycle.  If the patches render the 
         software dysfunctional the review will be terminated and the author
         author asked to select another option from above.

     c.  The moderator will collect the regression review comments and provide
         them to the author who will select one of the other options for
         the package.

- If the author opts to post the package, the moderator will post the
  baseline software along with the reviews to the c.s.r group and will 
  update the archives at ftp.uu.net and ftp.sterling.com.

- The moderator will post the review summary to all groups to which the
  CFR was posted along with a "thank you" to the reviewers, and the location
  of the software in the archives.

How to become a CSR reviewer
============================

- In order to become a CSR reviewer all you need to do is retrieve the
  package for review by subscribing to the package mailing list, and mail
  your review to the moderator at comp-sources-reviewed@sterling.com.  
  (See below for instructions on how to use the mail server).

- To be notified of packages available for review via E-mail subscribe to
  csr-reviewers@ftp.sterling.com mailing list (See below for how to
  subscribe).



What do the reviewers do
========================

- Reviewers receive a copy of the CFR either via their favorite new group
  or via the standing reviewers mailing list (which all reviewers will be
  given opportunity to join.  No one will be automatically placed on the
  list).

- Reviewers request the package from the mail-server announced in the
  CFR by subscribing to the mailing-list for package reviewers. 

- Reviewers should also retrieve a copy of the Guide for Reviewers either
  from the mail server.

- Reviewers should unpack the distribution, and build the software on
  their platform(s).  Any problems with the build should be coordinated
  with Author of the package via the discussion mailing list.  This is
  expected to be the most step where the reviewer and author will agree
  to patch the software in order for it to build on a new platform.

- The reviewer should note ALL problems either building or executing the
  software during the review period.

- Specifically the reviewer should note:

        a. Whether the documentation (both for building and using the
           software was clearly written and adequate.

        b. Whether the makefile (or makefile equivalent) was well
           structured and easily modified if necessary for the build 
           (i.e. select compiler, etc).

        c. Does the software perform as defined in the documentation.  

- The reviewer is also encouraged to comment on more subjective areas:

        a. Reviewers are encouraged to review the source code and comment
           on the structure and design. (Note: Comments on coding style 
           and indenting are discouraged. If you don't like the indenting, 
           run the code through cb). However, comments of how well the
           code is commented and the meaningfulness of variable/function
           names are appropriate.

        b. Does the package meet one or more functional requirements 
           for your organization.

        c. Are there areas in which the package could be improved (MMI,
           additional functionality, etc).

        d. Are there extraneous functions performed by the package that 
           really don't belong.

        e. If you ported the package to a new platform (i.e. One not
           originally noted by the author) how easy was it, and were there 
           areas which could be made more portable.

- Reviewers are free to run the software through any automated test
  tools they feel are appropriate (CodeCenter, ObjectCenter, Purify, 
  Insight, Sentinal, etc).

- Reviewers are to submit their reviews to the CSR moderator by the
  review deadline.  At a minimum the review must state the name of the 
  package, the platform (hardware, os) the review was run on, and whether 
  the package successfully built and executed.

- Reviewers will be reminded prior to the expiration of the review period
  that the reviews are due.  If the reviewer is not able to submit a review
  by the deadline they should notify the moderator. (Note - Work requirements
  and deaths in the family are acceptable excuses ;-).

- Any questions about the software should be routed through the discussion
  list provided.  Any reviewer who is abusive or derogatory towards either
  the author, the moderator, or other reviewers will be removed from
  the discussion list and will only be permitted future reviews at the
  discretion of the moderator.  We are all professionals and I expect
  us to behave that way.

- If the author provides a set of patches the reviewer will be asked
  to apply the patches and regression test the package

- Provide you input on the suggested status of the package to the
  moderator when polled.

- Bask in the knowledge that you helped to contribute to the quality of
  free software on the internet.

Where are the Archives?
=======================

The official archive sites for comp.sources.reviewed are ftp.uu.net
(uunet.uu.net) and ftp.sterling.com, where the sources are available 
by anonymous FTP (and other means) in /usenet/comp.sources.reviewed.  
Like most sources groups, the archives for CSR are organized in terms 
of "volumes".  In the future CSR may go to package based archives such
as are provided for comp.sources.misc and comp.sources.x in addition
to the volume/issue based archives.

An Index of sources already posted to the group is posted at the beginning
of each volume of CSR. It can be obtained via anonymous FTP from 
ftp.sterling.com:/usenet/comp.sources.reviewed/index.  If you do not have
FTP capabilities you can use the following command to have it sent to
you via email.

echo "send index from comp.sources.reviewed" | /bin/mail netlib@uunet.uu.net


How do I use that silly mail-server?
====================================

        To: csr-<package_name>-request@ftp.sterling.com
        Subject: help

        Thanks!
        <your signature here>

And it will send you a help file.  Here is a summary of the Subject lines
the mail-server might do something useful with:
Info commands:
        Subject: help

To subscribe to the package review list and have the package automatically
mailed to you:

        Subject: subscribe

To get a package for review (if you lost the first):
        Subject: archive get  part1 part2 ... partn 

To correspond with the package author and other reviewers send mail
to:  csr-<package_name>@ftp.sterling.com

What can I review right now?
============================

There is currently one (1) review in progress.  

csize - A program for counting lines of C source code 
        Reviews due by 15 Augest 94

If you submitted a package for review but it has become lost in the 
transition please notify the moderator or resbumit the package.  
Please submit your packages now.

What else should I do?
======================

Subscribe to comp.sources.testers -- we need you.
Submit you packages to comp.sources.reviewed

Thanks for you time and efforts!
--
David Boyd, comp-sources-reviewed@sterling.com
-- 

-- 
David W. Boyd                UUCP:     uunet!sparky!dwb
Sterling Software ITD        INTERNET: Dave_Boyd@Sterling.COM
1404 Ft. Crook Rd. South     Phone:    (402) 291-8300 
Bellevue, NE. 68005-2969     FAX:      (402) 291-4362
I survived - Seoul Sea of Fire Tour 94

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

From: byron@gemini.cc.gatech.edu (Byron A Jeff)
Subject: Re: starting X automatically on installing linux distribution
Date: 10 Aug 1994 22:23:54 GMT

In article <CuC1G9.C1C@news.cis.umn.edu>,
Sujat Jamil <sujat@shahada.iman.org> wrote:
-In article <CuB7y3.Inx@carmen.logica.co.uk>,
-Charle Kempson <kempsonc@carmen.logica.co.uk> wrote:
->Sujat Jamil (sujat@shasta.ee.umn.edu) wrote:
-
-[My earlier post suggesting automatic launching of X during Linux
-distribution installation deleted]
-
->
->This is a fair idea, though my instinctive feeling is that it would be
->very difficult to find the 'lowest common denominator' for X.  The X11
-
-I disagree.  Compare with Windows or OS/2.  They install straight into
-the graphical environment.  They use the baseline 640x480 VGA
-resolution.

Which suck. People end up having to install higher performance drivers to
get better resolution. And it's not necessarily easy.

-
-There's no reason that we can't do the same with a Linux distribution.
 
Yes there are.

-
->distribution in its Slackware form comes 'ready to go' but, I wonder,
->how many people have actually been able to run X out of the box, without
->some major messing about with device drivers (/dev/ps2aux etc) and 
->configuration options for the X server?  Unless some reliable way can be
->found to probe the system hardware in Linux installation and install the
->correct drivers for the hardware and write the correct Xconfig file this
->would seem not to be feasible.

True. Slackware actually asks you what you have. Also SuperProbe is pretty
good about gathering info on your video card.

-
-Most graphics cards are at the very least backward compatible to VGA.
-But, I agree that some sort of probe would be helpful.  Plus, think
-about Unixware or Solaris.  To my knowledge, they both install
-straight into X.  They are also PC *nixes which have to deal with a
-plethora of hardware variations.  

They must use a 640x480 VGA baseline. Can anyone comment on how these Unixes
gather the info necessary to run X?

-
->
->It is very easy to draw unfarourable comparisons with *nixes from the likes
->of SUN and HP, who IMHO have made a very good job of turning *nix from a 
->command line OS to a graphically orientated OS.  At work here I have an HP
->715 running HP-VUE, and it is easy enough for a complete novice to use, yet
->powerful enough to be completely customizable to my needs (in the best
->*nix tradition).  

True. But the software knows what the video hardware is going to be.

-
-Right! And I think the same can be done with Linux/X!

Not really. Not out the box.

-
-
->But I think it only fair to point out that after a bit
->of work exactly the same(well, almost!) result can be achieved using XDM
->and X on a Linux workstation.  Given the disparity in resources available
->Linux does an extremely creditable job of bringing Workstation power and 
->flexibility to the PC.  My PC boots straight into the X display manager
-
-Mine does too.  And I suspect a huge portion of Linuxers with enough
-resources to run X do the same on their PC!  So, why not automate the
-process on install?  We can always customize to our heart's contents.
-True to the *nix tradtion, as you say. :)

Your suspicions are unfounded. Many many many people out there lack the
RAM, disk space, video, monitor, or CPU horsepower to give X justice.
What percentage of folks have 8M, 1024x768 NI monitor, acclerated graphics
card on a 486? Probably not 50% of Linux users.

For the longest I've run a 386DX40, 4MB, 256K ET3000 card, and a 14" monitor.
X is dog slow on it due to swapping and a lack of accelerated video.

However for a non X linux box it's extremely useful.

-
->with nice customised resources, then on login goes into fvwm.  From here
->all the most commonly used tasks - setting upa slip connection, dowloading
->mail, playing Xmahjongg, performing an FTP etc may all be done from 
->intuitive menus from the background - No Xterm's required - which as you say
->gives you complete freedom from character based interaction with  the PC.

The lack of character based interaction is what I hate the most about both
the Windows and MacOS interfaces. It's fine for novices but in reality when
I need to do real work a virtual console or an rxvt is the ticket.

-
-Exactly!  That's exactly the kind of environment I would like the
-novice Linuxer to encounter on installation!  I'm sure you agree that
-for the novice, the biggest obstacle to Unix, which is clearly a far 
-superior resource manager than Windows, OS/2, MacOS and the like, is
-the admittedly non-user friendly character based shell.  Why not
-abstract it away for the beginner?  For those of us who couldn't live
-without our beloved character based shells, like myself :), we always
-have the option of launching an xterm!

Because to realize the true power of the underlaying OS one must interfact
with it. I might be agreeable to a transisitional type interface where the
user has menus that build command lines for common tasks. But to completely
isolate the user from the complexity of Unix also isolates them from much
of the power. The complexity and power go hand in hand.

-
->
->But back to the original point, making installation painless!  i would point 
->out that, like it or lump it, any *nix requires System Adminislration chores, 
->including the upload and installation of new packages.  Therefore there must be
-
-Sure!  All in good time, though.  The user first installing Solaris or
-Unixware also is going to be a system administrator, but they are
-hand-held into it, not shoved into it!  You don't have to upgrade to
-x.x.x.x+ version right in your first week of Linux use.  You don't
-have to recompile the kernel, even within the first two weeks. :)  I
-admit it:  I still haven't recompiled my kernel.  So, I am not
-adventerous! :)

True. In fact at one point I hadn't upgraded in almost 6 months. As long
as there isn't anything you need and your machine is stable, why upgrade.

-
-
->
->As for comparisonms with other GUI based OS's, I think that Linux + X + WINE (so we
->can all do some useful wordprocessing in Linux) would be a serious challenge
->to the traditional GUI based systems for serious users.  Even my girlfriend - 
->not an expert in computers of any sort, has no trouble booting, logging on, using
->and shutting down our system.  I count that as a success!

Once you get over the "But it's not DOS/Windows!" phobia it realtively painless.

-
-I agree.  If WINE becomes stable and powerful enough, essentially all
-the productivity software will become instantly available for Linux.
-I think this factor together with a friendlier GUI based installation
-process that I discussed, and an X-based abstraction layer, could pose
-a very significant challenge to the traditional, less powerful,
-"friendly" operating environments.

Not likely. Most novices have a SEVERE phobia to change. To them because they
don't see any difference there's no reason to change. In fact there is a 
reason not to change because then they'd have to learn something new and
different.

Example: One of admin folks was transistioning from a PS/2 to a 486. During
the transistion I set up a Linux box with X windows, DOSEMU, and all the
tools. He was quite effective with the setup. But what happened when the
486 came in? Switched right back to DOS (not Windows, DOS) Why? "Because I
don't need all that Linux stuff." Of course now we have another 486 that
only a single person can use and is blind to the network, but hey he's happy.

Linux doesn't need to become the next Windows/Mac. It serves a bunch of 
needs in terms of networking, communications, multitasking, etc. in it's
current form. To cripple it to appease novice users denies the very power
that Linux brings to the game. Compromise is fine, but to be honest if
novice users knew what they were using or knew what they needed, they
wouldn't be novices would they?

Consider a transistional interface that grows the user without diminishing
the system.

BAJ
-- 
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel - And Using Linux!
Georgia Tech, Atlanta GA 30332   Internet: byron@cc.gatech.edu

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

From: brown@wi.extrel.com (Vidiot)
Subject: Newbie to Linux has a few of questions
Date: 9 Aug 94 15:20:12 GMT
Reply-To: brown@wi.extrel.com



This past weekend I replaced my ISC 2.0.2 Unix with Linux Slackware 2.0.
The PC is a Compaq 386/20e with internal 14.4 modem.

The getty that is operating is agetty.

Now for the questions:

1) The modem isn't reset from an outside call.  It is as if the DTR isn't
   being dropped after the connection finishes, leaving the modem with S0
   set to zero.  Is something setting S0 to 0?  Did I miss something in all
   of the documentation?  The modem is already configured for correct
   operation.  All I want to happen is that when communication is finished,
   either externally or internally, DTR is dropped to cause the modem to
   reset, getting it ready for the next call to come in.

2) What happened to the polling abilities of HDB UUCP?  I used to be able to
   poll certain machines I am connected to (because they can't call me) and
   now all of that appears to be gone.

3) How is UUCP supposed to be activated in order to send the queued mail?
   Am I just supposed to crontab uucp to kick off uucico -r1 when I want?
   None of this is explained in all of the documentation that I read.
   Between the Smail and Uucp documentation, nothing indicates what to do
   to kick off the actual transport from the machine.  Because I have been
   working with UUCP for over 15 years, I have a handle on what is supposed
   to happen, but those pieces to this HDP UUCP are missing.

4) When using "cu" to connect to a remote machine, how do I turn off 8-bit
   no parity?  The remote machine is 7-bit, even.

5) When I use "cu" to remotely log in to another machine, just what exactly
   does "console" emulate, vt100, vt102, something else?  If it isn't any
   of those, what is it?

Well, those are the questions that I have for now.  Sorry if they sound a
little harsh, but it is frustrating getting some of the simple things
going.

Oh, when I was reading my old stuff from floppy, using cpio, I could easily
lock up the 1.1.18 kernel just by going into another console window and doing
very little.  The floppy would stop being read and all keyboard input will
be ignored.  It took a power switch reset to get going again.  What is cpio
doing to the system that causes it to lock?  I have 4 MB of RAM and a 16 MB
swap partition on the machine.  I haven't had to reset the machine since I
stopped using cpio.

Please resond via e-mail, in order to not bother those net readers who already
know all this stuff about Linux.

Thanks in advance.
---
e-mail: brown@wi.extrel.com  or  ftms!brown%astroatc.UUCP@cs.wisc.edu
phone: (608) 273-8262  fax: (608) 273-8719  voice-mail: (800) 426-6488 ext 8293
System Administrator - Extrel FTMS - Madison WI.   [An era has come to an end.]
    [The need for igniting the midnight petroleum has come to a close as well.]



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


** 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: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU

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

    Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU

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-Misc Digest
******************************
