Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!vsi1!lmb
From: lmb@vicom.COM (Larry Blair)
Newsgroups: news.software.b
Subject: Re: Comments on C news
Message-ID: <2277@vicom.COM>
Date: 21 Jun 89 17:20:46 GMT
References: <2228@vicom.COM> <1989Jun20.211939.7835@utzoo.uucp>
Reply-To: lmb@vicom.COM (Larry Blair)
Organization: VICOM Systems Inc., San Jose, CA
Lines: 63

= henry@utzoo.uucp (Henry Spencer):
> me:

>The fact that default mode is to allow newgroups to be executed.

=We think this is a sensible default.

Vehement disagreement here.  Only a masochist would allow some bozo to
change all of his moderated groups to unmoderated (or vice-versa) or
create alt.flame.weemba.nice ad infinitum.

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

I'd like a combination of both.  Would an rews.immed with "newspool -i &"
work?  Actually, how about a daemon that stats the news spool directory
every minute?

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

Not possible with the current output.

>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.
=Please don't expect the changes to get into the official release.  We
=really do feel strongly about terse logging.

I appreciate the need to avoid the humongous log that B news produces, but
you left out some very important things.  Unless you save the path some
duplicate articles, there is no way to tell where they are coming from.

I have added a few things to the log that will allow reasonable traffic
statistics to be created.  The overall increase in log size if less than
10% for accepted articles and perhaps 40%-80% on the duplicates.  I will
post the changes, along with a modified version of Erik Fair's awk script,
once I have run it all long enough to have confidence.  Btw, the changes
are only a few lines, so if Henry doesn't want to add them, it won't be
that difficult to re-add them after every release.

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

True.  But if the batch were directly to relaynews without spooling in
this case (assuming that spool/uucp and spool/news are on different
filesystems), the uucp free space would increase and the news wouldn't
be lost.  Maybe there should be a way to specify an alternate spool
area on a different filesystem in case of no space in the primary.
-- 
Larry Blair   ames!vsi1!lmb   lmb@vicom.com