Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!samsung!cg-atla!raybed2!mwm
From: m...@raybed2.msd.ray.com (mwm)
Newsgroups: news.sysadmin
Subject: Cnews vs. Bnews
Message-ID: <1750@raybed2.msd.ray.com>
Date: 29 Aug 90 18:24:32 GMT
Distribution: news
Organization: Raytheon Co., Tewksbury, Mass.
Lines: 20
Posted: Wed Aug 29 19:24:32 1990
Sorry if this is a frequently asked question, but I'm taking over the
news admin at my site and I want to know if I should convert to Cnews.
I know Cnews is supposed to be faster and supposedly less arcane. Is
this true?
Being that I don't know squat about Cnews and know only diddly about Bnews
my question is should I devote the time to learn Bnews or should I just
try to get Cnews running? This isn't a very high priority task at my
site so I don't want to spend tons of time acclimating.
Thanks in advance for your advice (no flames please).
Mark
--
*Mark Marino * He's got a watch with a minute hand, an eon hand and
*...@raybed6.msd.ray.com * millenium hand, and when they meet, its a happy land
*Raytheon Co. * Powerful man, Universe man. - tmbg
*Tewksbury, MA *
Path: gmdzi!unido!mcsun!uunet!wuarchive!rex!samsung!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry
From: he...@zoo.toronto.edu (Henry Spencer)
Newsgroups: news.sysadmin
Subject: Re: Cnews vs. Bnews
Message-ID: <1990Aug30.162431.2236@zoo.toronto.edu>
Date: 30 Aug 90 16:24:31 GMT
References: <1750@raybed2.msd.ray.com>
Organization: U of Toronto Zoology
Lines: 77
Posted: Thu Aug 30 17:24:31 1990
In article <1...@raybed2.msd.ray.com> m...@raybed2.msd.ray.com (mwm) writes:
> ... I want to know if I should convert to Cnews.
> I know Cnews is supposed to be faster and supposedly less arcane. Is
> this true?
Our standard blurb on the subject is the following:
Pros and Cons of C News, as against B News 5 July 1990
Pro - C News is generally much faster; in particular, processing of
incoming news is 10-30 times the speed of B News and expire is faster
by a similar factor. The speed of the "main path" approaches the
theoretical ultimate, since it is almost completely system-call-bound
and it does no unnecessary system calls.
- C News gives the news administrator more control in certain ways,
notably per-group selection of expiry time.
- C News uses shell files wherever possible, making it much easier
to change to suit local policies.
- C News is much more robust against strange inputs; in particular,
it avoids fixed-length buffers and so the code does not misbehave
when buffers overflow.
- C News includes full support for use in an NFS-based cluster
of systems, with updates done centrally to avoid the problems of
synchronization and locking over NFS.
- C News is very careful not to overflow disks.
- Although this was a slight surprise to us, we are told (by several
sources) that C News does not provoke the old System V inode bug
(filesystems falsely claiming to have run out of inodes). B News
definitely does.
- C News is fully B-News compatible at the news-reader level, so
existing news-reader programs work just fine with it. (In fact,
the C News distribution does not include a sophisticated reader
at all; we're quite happy with existing ones and have no desire
to reinvent this particular wheel.)
- C News code is generally simple and clean, and there have been
very few bugs reported. (Most of the patch activity has been
improvements rather than bug fixes.)
- For the dedicated code-basher, there is substantial documentation
of C News's innards.
- Apart from the requirement that credit be given, there are no
restrictions on commercial use and redistribution.
Con - C News is relatively new and is still evolving in small ways, so
patches are more frequent than for B News.
- The inews program (used for local postings but not for relaying
news from elsewhere) is rather slow, which is occasionally a nuisance
to posters and trips up over-simplistic attempts to gateway mailing
lists into newsgroups.
- C News documentation needs work and is on the sparse side for
novice news administrators. (Although the latest edition of the
UUCP/Usenet Nutshell Handbook covers C News, which helps.)
- C News is *not* system-administration-compatible with B News,
so news administrators have some relearning to do, and help and
advice may be harder to find.
- Occasional rarely-used features of B News are not supported or
are done differently, so conversion takes some care.
- The extensive use of shell files makes it difficult to port C
News to non-Unix systems.
--
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday| he...@zoo.toronto.edu utzoo!henry
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!vixie
From: vi...@wrl.dec.com (Paul Vixie)
Newsgroups: news.sysadmin
Subject: Re: Cnews vs. Bnews
Message-ID: <1990Aug31.184323.6254@wrl.dec.com>
Date: 31 Aug 90 18:43:23 GMT
References: <1750@raybed2.msd.ray.com> <1990Aug30.162431.2236@zoo.toronto.edu>
Sender: n...@wrl.dec.com (News)
Organization: DEC Western Research Lab
Lines: 34
Posted: Fri Aug 31 19:43:23 1990
In article <1990Aug30.162431.2...@zoo.toronto.edu> he...@zoo.toronto.edu (Henry Spencer) writes:
# Pro [...]
# - C News uses shell files wherever possible, making it much easier
# to change to suit local policies.
I'm sorry, Henry, but I don't agree. If I make a change to one of these
shell files, the next time you send out a patch or a new version, I am
screwed. Local policy needs to be implemented in terms of hooks, not as
hacks on software that the world tries to keep syncronized to what you
guys ship out. Granted, shell files are still a good idea because they
make it easier to figure out what's going on -- but this is the wrong way
to provide for customizations.
# - C News includes full support for use in an NFS-based cluster
# of systems, with updates done centrally to avoid the problems of
# synchronization and locking over NFS.
Once we get the HIDDENNET and LOCALDISTRIB functionality in here, this
will be true. As it is I have to run all my "addgroup"'s on all of my
distributed servers, which makes C News less functional than B News as
regards cluster management.
# - C News is fully B-News compatible at the news-reader level, so
# existing news-reader programs work just fine with it.
With the exception of the non-updated "minimum article" field, this is
true. XRN uses it, as did VMS VNEWS until I upgraded to C News :-).
Now, don't get me wrong -- I love C News and I would never go back.
I just think your pro/con document needs some additions :-) :-)...
--
Paul Vixie
DEC Western Research Lab <vi...@wrl.dec.com>
Palo Alto, California ...!decwrl!vixie
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!news
From: f...@dictionopolis.cs.psu.edu (Felix Lee)
Newsgroups: news.sysadmin
Subject: Re: Cnews vs. Bnews
Message-ID: <F*#pde?1@cs.psu.edu>
Date: 1 Sep 90 02:09:58 GMT
References: <1750@raybed2.msd.ray.com> <1990Aug30.162431.2236@zoo.toronto.edu>
<1990Aug31.184323.6254@wrl.dec.com>
Sender: n...@cs.psu.edu (Usenet)
Organization: Penn State Computer Science
Lines: 12
Posted: Sat Sep 1 03:09:58 1990
Nntp-Posting-Host: dictionopolis.cs.psu.edu
> If I make a change to one of these shell files, the next time you
> send out a patch or a new version, I am screwed.
If you leave all the scripts in $NEWSBIN alone and put localized
versions in $NEWSCTL/bin, then updates are very painless. Everything
in C News puts $NEWSCTL/bin in front of the program search path. This
could be better documented.
There's only a few scripts with "well-known" pathnames that you can't
treat this way, like inews and rnews.
--
Felix Lee f...@cs.psu.edu
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!vixie
From: vi...@wrl.dec.com (Paul Vixie)
Newsgroups: news.sysadmin
Subject: Re: Cnews vs. Bnews
Message-ID: <1990Sep1.190103.1176@wrl.dec.com>
Date: 1 Sep 90 19:01:03 GMT
References: <1990Aug30.162431.2236@zoo.toronto.edu> <1990Aug31.184323.6254@wrl.dec.com> <F*#pde?1@cs.psu.edu>
Sender: n...@wrl.dec.com (News)
Organization: DEC Western Research Lab
Lines: 25
Posted: Sat Sep 1 20:01:03 1990
In article <F*#pd...@cs.psu.edu> f...@dictionopolis.cs.psu.edu (Felix Lee) writes:
# [vixie]
# > If I make a change to one of these shell files, the next time you
# > send out a patch or a new version, I am screwed.
#
# If you leave all the scripts in $NEWSBIN alone and put localized
# versions in $NEWSCTL/bin, then updates are very painless. Everything
# in C News puts $NEWSCTL/bin in front of the program search path. This
# could be better documented.
Felix, you avoided my point. If I put a localized version in $NEWSCTL/bin
and Henry fixes a bug in the "real" version in $NEWSBIN/*, then my news
system will run without Henry's latest bug fix. If he fixes a bug someplace
else at the same time which REQUIRES the file I'm hiding to be fixed, then
my news system probably will not work.
The right solution is not to hide Henry's versions of things, but for Henry's
software to call various "local hooks" at various times to resolve local
policy issues (like: should this newgroup/rmgroup/whatever be honored?).
All Henry and Geoff would have to do is make sure that the local-hook
interface didn't change, and then they could patch to their heart's content.
--
Paul Vixie
DEC Western Research Lab <vi...@wrl.dec.com>
Palo Alto, California ...!decwrl!vixie
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!news-server.csri.toronto.edu!utgpu!utzoo!henry
From: he...@zoo.toronto.edu (Henry Spencer)
Newsgroups: news.sysadmin
Subject: Re: Cnews vs. Bnews
Message-ID: <1990Sep1.232617.23727@zoo.toronto.edu>
Date: 1 Sep 90 23:26:17 GMT
References: <1750@raybed2.msd.ray.com> <1990Aug30.162431.2236@zoo.toronto.edu> <1990Aug31.184323.6254@wrl.dec.com>
Organization: U of Toronto Zoology
Lines: 50
Posted: Sun Sep 2 00:26:17 1990
In article <1990Aug31.184323.6...@wrl.dec.com> vi...@wrl.dec.com (Paul Vixie) writes:
>...Local policy needs to be implemented in terms of hooks, not as
>hacks on software that the world tries to keep syncronized to what you
>guys ship out. Granted, shell files are still a good idea because they
>make it easier to figure out what's going on -- but this is the wrong way
>to provide for customizations.
Unfortunately, there is no limit to the bizarre customization requirements
people can think up, so it is inherently impossible to provide hooks for
them all. Agreed that hooks are better than editing shell files, but the
latter remains important to provide for customization that the authors
did not anticipate, or considered so specialized that they did not feel
it was worth its keep in general-distribution software.
># - C News includes full support for use in an NFS-based cluster
># of systems, with updates done centrally to avoid the problems of
># synchronization and locking over NFS.
>
>Once we get the HIDDENNET and LOCALDISTRIB functionality in here, this
>will be true. As it is I have to run all my "addgroup"'s on all of my
>distributed servers, which makes C News less functional than B News as
>regards cluster management.
What we may have here is a conflict of terminology. When we said "NFS-based
cluster", we meant "news stored on one machine and accessed via NFS on
others". We get the functionality of HIDDENNET -- as we understand it --
by simply punting all postings to the server. I fear I'm not sure what
LOCALDISTRIB is, and a quick grep through the 2.11 sources Geoff keeps
online didn't find it. We are always open to suggestions on possible
improvements, but we want them specified precisely, not by mysterious
all-caps buzzwords. :-)
Is there a problem with doing local-but-more-than-one-system additions
of groups, etc., by sending out a control message with a restricted
distribution? That's the obvious thing to do.
># - C News is fully B-News compatible at the news-reader level, so
># existing news-reader programs work just fine with it.
>
>With the exception of the non-updated "minimum article" field, this is
>true. XRN uses it, as did VMS VNEWS until I upgraded to C News :-).
Smart news readers don't use it, or don't depend on it for anything
important. And we do provide tools for updating it, although it's true
that our default setup currently doesn't run them. (This will probably
change, sigh.) We never modified, or even recompiled, any of our news
readers.
--
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday| he...@zoo.toronto.edu utzoo!henry
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!rutgers!news-server.csri.toronto.edu!utgpu!utzoo!henry
From: he...@zoo.toronto.edu (Henry Spencer)
Newsgroups: news.sysadmin
Subject: Re: Cnews vs. Bnews
Message-ID: <1990Sep1.233050.23815@zoo.toronto.edu>
Date: 1 Sep 90 23:30:50 GMT
References: <1990Aug30.162431.2236@zoo.toronto.edu> <1990Aug31.184323.6254@wrl.dec.com> <F*#pde?1@cs.psu.edu> <1990Sep1.190103.1176@wrl.dec.com>
Organization: U of Toronto Zoology
Lines: 17
Posted: Sun Sep 2 00:30:50 1990
In article <1990Sep1.190103.1...@wrl.dec.com> vi...@wrl.dec.com (Paul Vixie) writes:
>The right solution is not to hide Henry's versions of things, but for Henry's
>software to call various "local hooks" at various times to resolve local
>policy issues (like: should this newgroup/rmgroup/whatever be honored?).
We do this already on a small scale, and plan to do it more; for example,
it is the obvious way to deal with newgroup policy. However, it does not
do anything for customization in ways that we don't anticipate... and
there is a lot of really weird customization out there. People who do
such things inherently have work to do when the stuff they've customized
gets revised, but even this is easier with shell files than C code.
Incidentally, although I'm the more vocal of the two of us, a great deal
of the software in question is Geoff's, not mine.
--
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday| he...@zoo.toronto.edu utzoo!henry
Path: gmdzi!unido!mcsun!uunet!bu.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!csus.edu!ucdavis!uop!uop.edu
From: nsa...@uop.edu (Nick Sayer)
Newsgroups: news.sysadmin
Subject: Re: Cnews vs. Bnews
Message-ID: <26e07655.7e1@uop.uop.edu>
Date: 2 Sep 90 03:02:45 GMT
References: <1750@raybed2.msd.ray.com> <1990Aug30.162431.2236@zoo.toronto.edu> <1990Aug31.184323.6254@wrl.dec.com> <1990Sep1.232617.23727@zoo.toronto.edu>
Sender: nsa...@uop.edu
Organization: University of the Pacific, Stockton, CA [138.9.200.1]
Lines: 69
Posted: Sun Sep 2 04:02:45 1990
he...@zoo.toronto.edu (Henry Spencer) writes:
>># - C News is fully B-News compatible at the news-reader level, so
>># existing news-reader programs work just fine with it.
>>With the exception of the non-updated "minimum article" field, this is
>>true. XRN uses it, as did VMS VNEWS until I upgraded to C News :-).
>Smart news readers don't use it, or don't depend on it for anything
>important.
Au contraire, mon fraire :-)
If you wanted to see whether an expire had been run recently, is it
easier to look through an entire directory for missing articles,
just check the min field? Granted, this doesn't ALWAYS work, but
perhaps 95% of the time it does, and for news readers that work
with a database and management daemon (nn is an excelent example),
having the min field taken care of greatly simplifies and improves
the database management.
Another example:
Say you had a reader that allowed (for some unexplained
reason, bear with me) you to enter the number of an article to read
(or perhaps some other scheme where retrieval by number is desirable.
nntp comes immediately to mind). Wouldn't it be a reasonably good idea
to check the bounds of the input number against minimum and maximum
first before trying an fopen() on the file name? If you have more than
a week or two of news on-line, that fopen() may take a non-trivial amount
of time. And how about supplying the article range limits in the prompt?
(postnews does this if you want to followup, but postnews isn't
particularly smart)
Yet another example:
Suppose your unix doesn't allow you to read a directory? Don't laugh. I
had one. It was an old piece of junk, and the having of it prompted
me to go out and buy a Sun, but it's brain damaged kernal only allowed
root to read a directory (that's right, ls was suid). Having newsreaders
suid to root is ludicrous. You'd have to make sure they don't give you
a shell, make sure they don't mysteriously chown things, make sure you
can't write files to mysterious places (e.g. saving an article to
/etc/passwd)... So what do you do if you want to find all unread
articles? for(i=0;i<max;i++) fopen(sprintf("%d",i),"r"); ? What if max
is 6 digits long? It sure does help to know that you only have to open
numbers 999000-999999 instead of 0-999999.
Yet another example: Say you're reading news for the first time,
and the article numbers are 6 digits long. Again, do you start reading
at #1 and take a coffee break while the counter climbs to 900000?
There. I've written down 4 places where knowing the min can be
useful in as many minutes.
Smart readers may not RELY on it, but smart readers can make use of
it to make reading news a little quicker, and less error prone.
--
Nick Sayer | Disclaimer:
N6QQQ | "Just because you're reading my post doesn't
mrap...@quack.sac.ca.us | mean we're gonna take long showers together."
209-952-5347 (Telebit) | -- Gunnery Sgt. Thomas Highway
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry
From: he...@zoo.toronto.edu (Henry Spencer)
Newsgroups: news.sysadmin
Subject: Re: Cnews vs. Bnews (minimum-article field)
Message-ID: <1990Sep4.002250.4821@zoo.toronto.edu>
Date: 4 Sep 90 00:22:50 GMT
References: <1750@raybed2.msd.ray.com> <1990Aug30.162431.2236@zoo.toronto.edu> <1990Aug31.184323.6254@wrl.dec.com> <1990Sep1.232617.23727@zoo.toronto.edu> <26e07655.7e1@uop.uop.edu>
Organization: U of Toronto Zoology
Lines: 54
Posted: Tue Sep 4 01:22:50 1990
In article <26e07655....@uop.uop.edu> nsa...@uop.edu (Nick Sayer) writes:
>>Smart news readers don't use it, or don't depend on it for anything
>>important.
>
>If you wanted to see whether an expire had been run recently, is it
>easier to look through an entire directory for missing articles,
>just check the min field? ...
The right way to solve this one is to have expire, or the shell file
wrapped around it (doexpire in C News) tell you. Just after expiry is,
in any case, a dandy time to update news-reader databases.
Note also that if you want to know any time an article vanishes, you're
up the creek, because none of the news versions will notify you when a
cancellation is done.
>Say you had a reader that allowed (for some unexplained
>reason, bear with me) you to enter the number of an article to read
>(or perhaps some other scheme where retrieval by number is desirable.
>nntp comes immediately to mind). Wouldn't it be a reasonably good idea
>to check the bounds of the input number against minimum and maximum
>first before trying an fopen() on the file name? ...
Why? You have to do the fopen() in any case to find out whether the
article exists, because of cancellations and explicit expiry dates.
It is important to realize that even if the min number is kept completely
up to date, there is no guarantee that there are not huge gaps in the
article sequence between min and max. A news reader that can cope
intelligently with such gaps -- and all news readers should, because
they do occur! -- is, at most, slightly helped by the min field.
>Suppose your unix doesn't allow you to read a directory? ...
We're not, particularly, interested in non-Unix systems, even if some
idiot of a supplier chooses to call them "unix". Circumventing the
problems of a broken system can be arbitrarily difficult.
>Yet another example: Say you're reading news for the first time,
>and the article numbers are 6 digits long. Again, do you start reading
>at #1 and take a coffee break while the counter climbs to 900000?
No, instead of taking a coffee break, you fix your news reader to read
the directory after it misses a few times in a sequential-numbers scan.
Most news readers do this already, because of the gap problem.
Dumb software, or software that has to use dumb protocols (including,
I'm afraid, NNTP), sometimes places unwise dependency on the min number
being right and the min..max sequence being densely populated. No matter
how hard you work at making the first of these assumptions correct, the
second will remain false.
--
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday| he...@zoo.toronto.edu utzoo!henry
|