NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/3b1/4364

Text File | 1993-01-23 | 9.2 KB | 185 lines

Newsgroups: comp.sys.3b1
Path: sparky!uunet!ceilidh!dnichols
From: [e-mail] (DoN. Nichols)
Subject: Re: Taylor uucp 1.4 gamma on 3B1 with TCP (long)
Message-ID: <[e-mail]>
Sender: [e-mail] (Usenet)
Nntp-Posting-Host: shindig
Organization: D and D Data, Vienna VA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 23 Jan 1993 05:05:09 GMT
Lines: 172

In article <[e-mail]> [e-mail] (Karl Swartz) writes:
>In article <[e-mail]> [e-mail] (DoN. Nichols) writes:
>
>>What do you have against nntp?
>
>I never said I have anything against it, and I thought I was fairly
>unambiguous about why I chose the path I did -- getting NNTP going
>would seem to be a lot more work than getting Taylor uucp up, and
>still doesn't even address the issue of mail.  Consider that with
>uucp I simply replace one package -- in fact, since I'm only using
>Taylor's uucico at present (with the HDB utilities) it's not even
>the whole shebang.
>
>By going to NNTP, I have to build NNTP (client and server), then
>rebuild C news with it, then rebuild trn with it, and worry about
>breaking my newsfeed.  Then I have to knock together the scripts to
>deal with batching NNTP stuff, which I could steal from work but don't
>otherwise need here since I've got a bunch of uucp feeds.  Quite a bit
>of effort for one special case.

    O.K.  I'm just using nntp so multiple machines here in the house can
read news from a single machine (which doesn't get loaded with running
X11R5, and which has the big disks.)  I don't use it as a news transport
mechanism, just a reader extension, because my feeds are all uucp.  Since I
can't NFS mount the news spool directory on the 3B1s, and didn't want to
duplicate the disk space utilization, I considered the nntp to be the best
for *my* use.  (I acutally brought it up and tested it on the Suns, while
the 3B1 was my prime netnews machine, with the 3B1 doing a feed via rsh to
the Sun (no need for nntp or uucp there, there is the viarsh option in the
transport mechanisms avaailble to C-news.))  Once everything was working
smoothly, I did a name transplant between the two machines, and so ceilidh
became a Sun 3/140 instead of a 7300, and my feeds didn't see the difference
(unless they were looking at transfer speed of the uucp.)  Perhaps you can
use something like viarsh (which worked well between the 7300 and the Sun-3
for me.)

>And then there's still Smail and SMTP to deal with when I'm done with
>news.

    Though there is a workable sendmail with the WIN/TCP software
package.  My major problem with it was lack of good documentation, and lack
of a good starting sendmail.cf for *my* setup, which was multiple machines
etherneted together at home, and everybody else is a uucp connection through
uunet at present (earlier thorugh a friend's system).  I could never manage
to convince it that something with an '@' in it could be reached via any
other route than the ethernet (which was, of course, no help).  With the
Suns running SunOs 4.1.1, and example starting points both for the mail hub,
and for the client machines, I was able (with some delving into the fairly
good documentation that comes in the docu-crate for 4.1.1) to get it working
correctly.  (I probably could do the same for the 3b1, now, but there is no
motivation, since it is just another client machine.)

    [ ... ]

>>One advantage of nntp over what you appear to be describing is that
>>nntp needs a news spool directory only on *one* machine.
>
>Did I say the two had identical feeds?  I don't believe I did.  One
>machine carries a full feed, distributing all or parts of it along to
>other machines (including my second machine) and then getting rid of
>it to make room for the next wave as quickly as possible.  The other
>gets a small feed of stuff I really want, and keeps it around as long
>as I need.  If I read news on the primary machine it'd miss most of
>the discussions I might be interested in, not to mention the problem
>of falling asleep because the thing is so damned slow.

    O.K.  under these circumstances, I can see why you wouldn't want to
bother with nntp.  I was assuming the condition of one machine with the
major disk farm, and smaller client machines without enough disk to really
want to do news spooling on them.  Also, I was assuming that all news would
have to be retained on the primary incoming machine, rather than offloading
carefully selected portions to another machine.

>At work I have a SPARCstation 2 with 4.5 GB of disk dedicated solely
>to news, which not only has enough space to keep articles for a decent
>period of time but also is fast enough to handle it all and also do a
>reasonable job of serving user requests for news.  It's great for all
>of the NNTP clients we have.  It's also not relavent to my 3B1 setup.

    A Sun-3 with adequate disk does a reasonable job of being a nntp
server, as long as there is adquate memory so swapping is not to likely to
occur.

>>I have not ried to do the compile of taylor uucp ...
>
>Another reason for trying Taylor is that it is supposed to be quite a
>bit more efficient in using CPU cycles than other uucps.  If this can
>eke a bit more throughput out of the Telebits before I get 386BSD up
>and running, great!

    That improved throughput is quite adequate reason to use it on the
3b1, which needs all the help that it can get at high baud rates (the serial
port drivers are a prime problem, which you will be bypassing by using the
ethernet.

>>    My experience with the WIN/TCP include files was that when one of
>>the include files which came with that package bears the same name as one in
>>the standard include directory tree, it usually will include that one by
>>explicit path, so the two are combined effectively into a single include
>>file.  There may be cases where this doesn't happen that you have
>>encountered that did not get in my way.
>
>First one in my notes is <errno.h>.  There is a Wollongong version and
>it does not include the standard version, though both do include the
>standard <sys/errno.h>.  The standard <errno.h> has
>
>    extern int errno;
>
>while the Wollongong one does not.  Ding!
>
>Same goes for <signal.h>; in this case the missing define is
>
>    extern (*signal())();

    I hadn't noticed these, but you are correct.  Perhaps the programs
which I have compiled expected the declarations above to not be present in
the header files, and so did the declarations on their own.  (That may be
the case in the stock BSD, though I haven't had access to a stock BSD to
check that out.)  In any case, the declarations *are* present in the SunOs
4.1.2 that I just checked.

>And then there's <sys/wait.h> -- the Wollongong version is essentially
>a no-op, so if you get that turkey you'll be missing all the stuff in
>the standard version.

    You're right - perhaps that should be changed to include
<sys/wait.h>.

    [ ... ]

>>Of course, this is a bit of a problem with gcc, because the
>>fixincludes script didn't know about the WIN/TCP headers, so it
>>didn't sanitize them for gcc compatability.
>
>Eh?  I didn't know about the fixincludes script either!  Was this with
>gcc 2.x or with 1.40?  I just checked and it isn't in the gcc 1.40
>package I got.

    Was that the source package, or a pre-compiled one?  The
pre-compiled version has a set of headers in /usr/local/lib/<whatever> which
were generated by the fixincludes.  Essentially, it adapts them so you don't
need to use the -traditional flag on the compiler for most things.  I
believe that it was as far back as the 1.37 or so - I never had access to
any earlier versions (or at least no reason to try for access, with the
later ones already out.)  Fixincludes takes almost longer than the one stage
of the compilation - perhaps longer - on a SPARC machine running 4.1.1.
What it does is build a tree in the appropriate location of /usr/local/lib
(where is deemed appropriate has fluctuated violently up till around 2.1.1
or so), which is a copy of everything in /usr/include/* (but it misses
things like /usr/5include on the Sun).  It then checks the contents of each
subdirectory in the copies, fixes those that it recognizes as needing
fixing, and then removes any that didn't need fixing, so the compiler falls
through to the stock /usr/include/* for everything that hasn't been
changed.  You *can* run the compiler without this stage of operations, but
you need the -traditional flag for almost everything.  Without it, the
default return types of certain functions and their arguments is wrong.
Since gcc passes other sizes than the default double, int, and pointer as
return values from functions, it needs to declare return types which would
otherwise be incorrect with gcc's assumptions when using the stock libs.

    Anyway, you had a much firmer grasp of just what you needed and why
than I was able to glean from your article, though that could have been a
factor of me being too sleepy (as I am again :-)

    Goodnight
        DoN.

--
 Email:   <[e-mail]>  |  ...!uunet!ceilidh!dnichols
         <[e-mail]>
 Donald Nichols (DoN.)  |   Voice (Days): [phone] (Eves): [phone]
    --- Black Holes are where God is dividing by zero ---