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

Text File | 1993-01-21 | 5.1 KB | 116 lines

Newsgroups: comp.sys.3b1
Path: sparky!uunet!spool.mu.edu!uwm.edu!linac!unixhub!ditka!ohare!kls
From: [e-mail] (Karl Swartz)
Subject: Re: Taylor uucp 1.4 gamma on 3B1 with TCP
Message-ID: <[e-mail]>
Organization: Chicago Software Works
References: <[e-mail]> <[e-mail]>
Date: Thu, 21 Jan 1993 12:30:39 GMT
Lines: 105

In article <[e-mail]> [e-mail] (DoN. Nichols) writes:
>In article <[e-mail]> [e-mail] (Karl Swartz) writes:
>>The thought of getting Smail 3.1 to use Wollongong's Lose/TCP ...
>>... and then news and NNTP as was most unappealing.  Taylor uucp
>>running over TCP seemed a more reasonable approach.

>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.

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

Basically, I'm changing the transport so it seems to make a lot more
sense to change the transport software (one piece) than to change a
number of high-level pieces of software.  NNTP isn't the right tool
to solve the problem.

>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.

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.

>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!

>    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())();

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 just need to specify the WIN/TCP include tree first on your
>command line, before it searches the stock headers.

That was *not* a positive approach for a lot of stuff!  I ended up
using the Wollongong includes, before the standard ones, only for
networking modules, which went well enough.  For everything else I
ignored the Wollongong stuff.

>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.

>Good Luck

Thanks!  I got some pointers from several folks as well as several
patches which I'll be trying out this weekend.  Stay tuned ...

--
Karl Swartz    |INet    [e-mail]
1-415/854-3409    |UUCP    uunet!decwrl!ditka!kls
        |Snail    2144 Sand Hill Rd., Menlo Park CA 94025, USA
 Send sci.aeronautics.airliners submissions to [e-mail]