🚀 go-pugleaf

We here at UUNET run both INN and C News, because I have very mixed
feelings about them in different environments.  I will openly admit
that my personal bias is toward C News, but when it comes to
just flat out recommending one or the other to people I don't do it.
It really depends on a lot of different factors for complex news
administration tasks.  People running very generic news systems are
well served by either.

So, before I go trampling on the messages singing the praise of INN
over C News, mostly because I feel that C News should be defended at
this point by someone who's been pounding on both systems, I would
like to point out that I definitely appreciate both systems.  I
wouldn't still be using them both at UUNET if I didn't feel that way.

In <1gi9joINN5qm@intercon.no> aras@intercon.no (Arne Asplem):
> I've just started to use INN (as a replacement for Cnews) myself,
> and my first impressions is that in general INN has a much cleaner
> design. Cnews is a mix of shell-script and binaries located "all over
> the file-system", where INN is a more typical client/server design,
> with a deamon process running all the time.

You seem to think that packing everything in to one place makes for a
cleaner design.  I don't fully agree with that position in the case of
network news.  While clearly it does have its wins in certain areas,
like the problem Rich originally set out trying to solve with multiple
feeds offering the same articles before the base news system could
process them, there are other ways that this can be a nuisance.
C News has a more modular design with different subsystems more easily
isolated from one another, and less cross-subsystem knowledge
necessary to accomplish some more complex tasks.

INN is also a mix of shell scripts and binaries and config files just
about as spread all over the place as C News.  The only real
difference there is that Rich didn't make his bin directory
hierarchal.  I personally prefer one config file included by all of
the programmes to subst being run on so many different scripts.

     - support for both UUCP and NNTP in one package
     - improved logging

I don't think it's that improved to be notable, except for one thing:
enabling tracking of ip addrs of hosts, rather than Path: names, in
the regular "news" log (like C News's "log" from relaynews) is a much
better audit trail for finding sources of forged articles.

     - cleaner design

Debatable.

     - easy to install (more complicated config files though !)

No real win over C News here, in my opinion.

     - more configuration options for complex installations

No real win over C News here, in my opinion.  Of course, we run
versions of both that aren't quite what the generic distributions are.

     - good (better ?) performance (haven't tested this !)

In some ways.  It depends on how you measure performance.

In <1glceaINNkik@smurf.smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs):

   In news.software.b, article <1992Dec15.175743.9862@dragon.acadiau.ca>,
     peter@dragon.acadiau.ca (Peter Steele) writes:
   > On another note, INN *must* have more going for it than just what
   > is described above. What other reasons might make it worthwhile to
   > switch to INN.

   Lots.
   - Central control.If you say "ctlinnd mode" and "running" comes back, then
     you know your News system is up and OK, no further questions necessary.

This isn't totally true, of course, depending on how you've configured
your outgoing feeds.  It just usually means that the input system is
ok, but I'm not certain that is a 100% truth either.

   - No lock files. The daemon remembers its state.

Which can be a major pain in the butt when you have other non-innd
code trying to manipulate some subsystem, like outgoing batchfiles.
While ctlinnd does provide a good interface for most people, there are
applications for which this somewhat all-or-nothing server/client
model is lacking.  Especially in the face of things like buffchan,
which doesn't provide the clean model which straight batchfile writing
by innd does, there are areas where you just can't be sure that what
you see is really what you get and that you can dicker with some
aspect of the system with relative impunity.

   - Direct posting. As soon as inews returns, you know your article entered the
     News system and was spooled to other sites.

This is generally a win for INN.  You can get it with C News, but you
can take a delayed response time hit.  C News can win a little here,
though, in not requiring that the newsrun system be active in order
for an article to be accepted and spooled at the server for processing.
(INN's inews will spool locally if it can't connect to the server, but
that means every machine which that can happen on has to run rnews ...)

   - More than one concurrent incoming feed. (Right now, I've got two rnews
     jobs, two incoming NNTP feeds, and an inews active. They don't block one
     another and all get instant and reliable feedback on the articles they
     deliver.)

INN definitely does have an advantage here as long as the feeds are
offering redundant information.  Leaf sites or sites fed largely
different traffic by their multiple feeds won't see much of a bonus
here.

   - Reworked "newsfeeds" (nee sys) file with much finer control as to what
     actually gets written to batch files.

First off, I don't think you really have that much finer control.
Secondly, I have philosophical differences here.  It is my belief that
someone who has requested "rec.bicycles" would by default like to get
whatever rec.bicycles is reorganised to.  To duplicate the hierarchal
feeding behaviour of B/C News you need to make entries something like
"rec.bicycles,rec.bicycles.*" for everything that a site is fed just
to prepare for eventual reorganisations.  (Flat out using
"group.name*" in place of  "group.name,group.name.*" is not truly the
same.)  I am definitely in favour of hierarchal feeding.

People like to claim that INN's newsfeeds file has no hidden gotchas
like B/C News.  Baloney, and even Rich will admit that.  The ME: line
default feed is extremely counter-intuitive, especially to people who
have run other systems.  The forwarding of articles based on where
they are filed locally and not on their global Newsgroups: headers can
also bite you.  There's other things to remark about here, too, but I
can't recall them right now. 

   - Directly feed the batch into a program, via pipe. People have been seeing
     article transfer times on the order of 200 msec, using this method to feed
     another system via nntplink.

This is a win if you really care.  I think it is a mistake to care
about 200msec propagation times, even having been one of the very
first people to run relaynewsd and nntplink with logfile mode.

   - Combine the previous two to do some really ugly things like statistics
     gathering or sendsys-bomb cancelling. Especially the latter isn't really
     doable, given the above subsecond transfer times, unless you can get the
     Cancel into your news server _right_now_.

There doesn't seem to really be that big a win for INN here, either,
except maybe in that cancelling area.  Then again, how much do you
really have your server really making such time critical assessments of
message validity automatically?

UUNET's stats are actually still run from a C News machine (though
they could be run on an INN machine just as well --- it is a merely a
space on the servers issue now).

   - One INN system can mirror another INN system. No more problems with
     renumbered articles -> instant switchover when the primary server fails
     and/or when it is temporarily overworked.

C News does this, too.

Incidentally, though the C News folks do not seem to make much public
mention of this, they too are working on an NNTP implementation which
should be much better suited toward interacting with a C News base
server and have all the usual hallmarks of their good code.  It sounds
to me like it won't be that much longer (though I certainly won't
provide numbers on their behalf) before it is available.  If you are a
C News site currently contemplating the INN switch on the basis of
better NNTP performance, you might consider waiting just a little
while longer and giving their NNTP a try.