Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!vsi1!lmb
From: l...@vicom.COM (Larry Blair)
Newsgroups: news.software.b
Subject: Comments on C news
Message-ID: <2228@vicom.COM>
Date: 17 Jun 89 23:52:48 GMT
Organization: VICOM Systems Inc., San Jose, CA
Lines: 46
Now that I've had a chance to play with C news, I have a few comments and one
major gripe.
Good things:
The flexible expire. The easy aliasing and nonjunking of undesired groups
The passing on of junk. I particularly like the way sendbatches works,
since it lets me set up a multifeed batch with "uux -l" very easily.
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 fact that
by default news is always spooled with deferred execution [maybe there's a
good reason for this]. Some of the questions in the config are unanswerable
by even an experienced admin [is your rindex fast?].
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). 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? There's no groups listed. The duplicates
lines don't save the path, making it impossible to tune your feeds. The
control messages aren't differentiated from regular news postings. The
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,
since Geoff and Henry have said that they may never release a new version.
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).
Overall, I'd like to use C news. I had hoped the Eric would get his
stuff together, but the latest round has convinced me that TMN will always
be risky. Henry and Geoff have taken great pains to try to get it right
the first time. If they had been a little less closed with their beta
tests, they might have gotten it perfect.
Btw, is my rindex fast? I've running SunOS 3.5 and will go to 4.0 sometime.
What about the ANSI-compatible questions?
--
Larry Blair ames!vsi1!lmb l...@vicom.com
Newsgroups: news.software.b
Path: utzoo!henry
From: he...@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 <2...@vicom.COM> l...@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 he...@zoo.toronto.edu
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!vsi1!lmb
From: l...@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: l...@vicom.COM (Larry Blair)
Organization: VICOM Systems Inc., San Jose, CA
Lines: 63
= he...@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 l...@vicom.com
Newsgroups: news.software.b
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: Comments on C news
Message-ID: <1989Jun22.174603.10483@utzoo.uucp>
Organization: U of Toronto Zoology
References: <2228@vicom.COM> <1989Jun20.211939.7835@utzoo.uucp> <2277@vicom.COM>
Date: Thu, 22 Jun 89 17:46:03 GMT
In article <2...@vicom.COM> l...@vicom.COM (Larry Blair) writes:
>=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?
Uh, why? Either you run newsrun periodically, or you ask newsspool to run
it every time a batch comes in. Or both. I don't see the utility of the
"&", which will foul up trouble reporting. And I don't see any point to
checking every minute, which can in any case be achieved by running newsrun
frequently.
>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.
Do remember that duplicate articles are normal in some situations; for
example, Toronto deliberately has redundant feeds, which means duplicates,
in quantity, are to be expected. The log does report which neighbor they
came from; our experience is that information back beyond that is seldom
useful (and it's very bulky).
>... 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...
I don't understand -- if there is adequate free space in spool/news,
incoming articles will not get rejected anyway. If there isn't, then
there is nothing that can be done about it. The borderline cases,
where spool/uucp and spool/news are on the *same* filesystem and the
space freed up by the uucp files is just enough for the articles to be
filed (unlikely, they are usually bulkier once unbatched), frankly seem
to me to come under the heading of brinkmanship. I repeat, the space
checks are meant as disaster mitigation, not to routinely let you run
safely with disks on the brink of overflow.
--
NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology
US government is to freedom. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Newsgroups: news.software.b
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: Comments on C news
Message-ID: <1989Jun22.174603.10483@utzoo.uucp>
Organization: U of Toronto Zoology
References: <2228@vicom.COM> <1989Jun20.211939.7835@utzoo.uucp> <2277@vicom.COM>
Date: Thu, 22 Jun 89 17:46:03 GMT
In article <2...@vicom.COM> l...@vicom.COM (Larry Blair) writes:
>=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?
Uh, why? Either you run newsrun periodically, or you ask newsspool to run
it every time a batch comes in. Or both. I don't see the utility of the
"&", which will foul up trouble reporting. And I don't see any point to
checking every minute, which can in any case be achieved by running newsrun
frequently.
>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.
Do remember that duplicate articles are normal in some situations; for
example, Toronto deliberately has redundant feeds, which means duplicates,
in quantity, are to be expected. The log does report which neighbor they
came from; our experience is that information back beyond that is seldom
useful (and it's very bulky).
>... 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...
I don't understand -- if there is adequate free space in spool/news,
incoming articles will not get rejected anyway. If there isn't, then
there is nothing that can be done about it. The borderline cases,
where spool/uucp and spool/news are on the *same* filesystem and the
space freed up by the uucp files is just enough for the articles to be
filed (unlikely, they are usually bulkier once unbatched), frankly seem
to me to come under the heading of brinkmanship. I repeat, the space
checks are meant as disaster mitigation, not to routinely let you run
safely with disks on the brink of overflow.
--
NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology
US government is to freedom. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!vsi1!lmb
From: l...@vicom.COM (Larry Blair)
Newsgroups: news.software.b
Subject: Re: Comments on C news
Message-ID: <2293@vicom.COM>
Date: 23 Jun 89 00:11:01 GMT
References: <2228@vicom.COM> <1989Jun20.211939.7835@utzoo.uucp> <2277@vicom.COM> <1989Jun22.174603.10483@utzoo.uucp>
Reply-To: l...@vicom.COM (Larry Blair)
Organization: VICOM Systems Inc., San Jose, CA
Lines: 34
In article <1989Jun22.174603.10...@utzoo.uucp> he...@utzoo.uucp (Henry Spencer) writes:
=In article <2...@vicom.COM> l...@vicom.COM (Larry Blair) writes:
=>
=>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?
=
=Uh, why? Either you run newsrun periodically, or you ask newsspool to run
=it every time a batch comes in. Or both. I don't see the utility of the
="&", which will foul up trouble reporting. And I don't see any point to
=checking every minute, which can in any case be achieved by running newsrun
=frequently.
The reason I'd like to background the newsspool (actually, the newsrun) is
so that my UUXQT will be able to go on to the next X. file without waiting
for the whole batch to be unbatched. I'm worried about what happens if I
background it, though; it is reading the parent's stdin.
As far a as running newsrun every minute, that would use several orders of
magnitude more cpu than just stat'ing the directory. I intend to implement
this sort of daemon.
=Do remember that duplicate articles are normal in some situations; for
=example, Toronto deliberately has redundant feeds, which means duplicates,
=in quantity, are to be expected. The log does report which neighbor they
=came from; our experience is that information back beyond that is seldom
=useful (and it's very bulky).
We have 4 full feeds. Every one of those feeds has an exclusion on what
they feed to us for some of the sites upstream from them. The South Bay
is a veritable rat's nest of crossfeeds. The way that we are all able to
determine what to exclude is from the log.
--
Larry Blair ames!vsi1!lmb l...@vicom.com
|