Newsgroups: news.software.b
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Comments on C news
Message-ID: <1989Jun20.211939.7835@utzoo.uucp>
Organization: U of Toronto Zoology
References: <2228@vicom.COM>
Date: Tue, 20 Jun 89 21:19:39 GMT

In article <2228@vicom.COM> lmb@vicom.COM (Larry Blair) writes:
>Not so good things:
>
>The fact that default mode is to allow newgroups to be executed.  The config
>doesn't even give you a choice and the documentation doesn't state how to
>disable it [just change "newgroups" /usr/lib/newsbin/ctl]...

The documentation is admittedly not all it could be.  "build" attempts to
hit the high spots, not to address every possible need of everyone (that's
one of the reasons why it builds shell files instead of just charging in
and doing it -- so you can overrule it).  We think this is a sensible default.

>The fact that
>by default news is always spooled with deferred execution [maybe there's a
>good reason for this]...

Efficiency is always an issue for us.  There are provisions for running it
immediately, although "build" doesn't know about them.

>Some of the questions in the config are unanswerable
>by even an experienced admin [is your rindex fast?].

Nevertheless, said questions are (a) significant, and (b) impossible to
figure out automatically.

>Major gripe:
>
>The log file.  The documentation states a goal of not modifying files that
>programs will look at.  The log file is examined to create site statistics
>that are posted (at least in the Bay Area)...

We consider the log file an aspect of the implementation rather than the
user interface, I'm afraid.  Yes, things that examine it will need fixing.

>It's not just that the format
>was changed; most of the useful information was removed.  Just how did they
>decide what to put in the log? ...

By our opinion of what was useful.  We don't appreciate multi-megabyte log
files, which are all too common nowadays if you use verbose log formats.
You should have seen what it was like before I talked Geoff into adding
some of the current information...

>log is broken to the point of worthlessness; I'll stick to 2.11.17+ until
>I get the time to rewrite the logger.  When I do, I'll post the changes...

Please don't expect the changes to get into the official release.  We
really do feel strongly about terse logging.

>Another thing I noticed is that the spooler won't spool the incoming batch
>if space is short.  On some systems [ours], /usr/spool/uucp and /usr/spool/
>news are on the same filesystem.  This means that spooling the incoming
>batch doesn't increase the space used (when the uucp D. file goes away).

But *not* spooling it *does* increase the space available.  That's the
point.  The space-checking stuff is not intended to routinely let you run
right up against the limit; the correct solution to that situation is to
buy more disks.  The software is aimed at averting disaster if a disk fills
up temporarily.

>Btw, is my rindex fast?  I've running SunOS 3.5 and will go to 4.0 sometime.
>What about the ANSI-compatible questions?

The answers I use on utzoo (SunOS 3.2) are fast rindex, ANSI-compatible
everything except ldiv and stdlib.h.
-- 
You *can* understand sendmail, |     Henry Spencer at U of Toronto Zoology
but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu