Xref: utzoo ont.uucp:348 tor.news:111
Newsgroups: ont.uucp,tor.news
Path: utzoo!utstat!geoff
From: geoff@utstat.uucp (Geoff Collyer)
Subject: Re: putting up C alpha news
Message-ID: <1988Jan7.191212.9827@utstat.uucp>
Summary: C news is an *alternative* to B news; some sites won't be able to run
	B news soon, even if C news *is* hard to install.
Organization: Statistics, U. of Toronto
References: <1988Jan5.011219.2676@utstat.uucp> <1988Jan6.000342.19591@lsuc.uucp> <1988Jan6.142625.5695@utstat.uucp> <381@spectrix.UUCP>
Distribution: ont
Date: Thu, 7 Jan 88 19:12:12 EST

I do hope people aren't getting bored with this back-and-forth
discussion.  Let us know if you are and we'll go back to private mail.
Sorry about the length of this article: I've tried to keep the quoting
down yet give some context, and there is new information here (I
believe).

In article <381@spectrix.UUCP> clewis@spectrix.UUCP (Chris R. Lewis) writes:
>The bulletins didn't help much before, during or after.  Official "patches"
>would have helped more.

Henry and I don't have the manpower to provide support of C news,
and I at least am not terribly fond of several aspects of B news and
related politics, one of which is the frequent mandatory patches,
requiring that you go back to virgin source, apply patches and reapply
local fixes or policy.  One of the reasons we wrote C news was to free
ourselves from the tyranny of B news software maintenance; I am
reluctant to inflict a similar discipline on others.  I don't want to
get into the business of maintaining C news nor of releasing new
versions regularly.

>Many of the READMES were almost totally useless or out and out wrong - 
>eg: lib.proto's and newsbin.proto's - locations for some of the files 
>required some inspired guessing, and many README's were hard to find 
>anything useful in, being buried under advertisements.  Most of them 
>were somewhat lacking in hard useful information.  I know that this 
>stuff is obvious to you guys, but it ain't obvious to people who've 
>never seen it before.

Alas, the README files were also alpha versions; they had become out of
date, but I wouldn't say they were totally useless nor content-free.
On re-reading them just now, I see that they do not lead one by the hand
through installation as the B news installation paperback does, but they
do describe in general terms the work to be done, with the rude comments
largely confined to rnews/README.  Would you really have preferred no
README files at all?  The ads and snarky remarks are the product of
residual bitterness at B news, after tolerating B news for years; they
are gradually being removed as the wounds heal (you should have seen the
vicious abuse in the pre-alpha versions!).  I wouldn't say that the
setup of C news is obvious to us; I'm still getting used to the
/usr/lib/news vs /usr/lib/newsbin split.

>I don't think I would have been successful if I hadn't had 4 or 5 years
>of experience with B news on a multitude of machine types.

As the READMEs say, we expect C news installers to have experience with
B news; we haven't yet produced comprehensive documentation, and the B
news documentation gives a good overview.  Someone with no previous
exposure to news will probably need quite a while to install C Alpha
news.  However, Chris is the only person we heard from who had
significant trouble putting up C Alpha news (everybody had a little
trouble).

>The software itself is remarkably bug-free for an initial alpha release.

Thanks, we try to keep the bugs out.  I believe the nasty one was the
putenv bug, which was published.

>I find it interesting to note that not only wasn't Henry running *all*
>of C-news [...] let alone Alpha, but neither is Geoff - you did say that you
>weren't running the input spooling software didn't you?

C Alpha is actually more stable than the later version we installed on
utzoo.  utzoo is now running all of C news and utstat is running all but
the input subsystem.  I don't see much need for the input subsystem
because utstat gets relatively little news and runs much faster than
utzoo (utstat is a Sun 3, not a PDP-11).  On utzoo we shook out a lot of
the Alpha release problems of integrating the input subsystem with the
rest of relaynews and friends, but there is still work to be done.

Sorry about the filled disks; we were (perhaps overzealously) trying to
do exactly the opposite of what B news does when there is trouble
(lose the batch and don't tell anyone).  Now that utzoo is running
all of C news, we are getting the wrinkles ironed out.

>It should be pointed out that much of the configuration changes
>are by changing or creating shell code.

We find shell code easier to adapt than C code.

>Thus, for example, if one of your outgoing feeds is not a C-news site,
>you have to create a couple of shell files and nowhere is there
>documentation on what they have to be for sites of differing types [...].

I'm not aware of any need to treat B news feeds and C news feeds
differently; could you mail me the details?  If you are thinking of
generating "#! cunbatch " for B 2.11, I believe that's optional; it's
certainly unnecessary - C news strips it immediately on contact.

>In constrast, B-news is pretty good at having ALL code that you need -
>configuration is primarily build switches and the occasional parameter.

C news is not for people who like B news, indeed it helps to have years
of bitter resentment of B news :-).  Aside from the appalling source
code and lack of performance of B news, I think the single item I detest
most about B news is the simultaneous complexity and simple-mindedness
of its configuration procedure.

Every time you touch the makefile, B news wants to rebuild everything.
You're supposed to maintain localize.sh, which makes making any changes
clumsy.  There are 65 different #defined symbols in B 2.11's src/news.h
and they virtually all have to be examined and possibly changed to
configure B news.  As a result, the code is heavily #ifdefed, which
reduces the likelihood that very many of the possible combinations of
#define options have been tested.  Yet despite this, B news believes
that there are really only three kinds of Unixes: V7, 4.2BSD and System
V, which is less true every day; the boundaries are blurring and
features are migrating, and there really are other variants.

There are few #ifdefs in C news and I am trying to weed out the
remaining few.  The slightly clumsy rnews/vers directory subtree of C
Alpha has been replaced with a series of libraries of emulations for
various major Unix variants, but it is easy to extend this structure
to any new variant that comes along: make a new directory, populate
it with appropriate emulations and type "make".  This is far superior
to code full of "#if defined(V7) || !defined(BSD4_1C)".  What's more,
the code in those libraries may even be reusable in other portable
programs (shock! horror!); see Henry's February Usenix paper for more on
this subject.

>Not helping is the fact that utzoo, utstat and lsuc
>are hardly vanilla versions of whatever version of UNIX they are.

utstat actually is pretty vanilla Sunix: our pty driver has Blit
support, but the rest of the kernel and all of our C library are
straight from Sun.

>The major difficulty is almost total lack of installation information,
>installation utilities, inconsistent makefiles, the same configuration
>changes having to be made in a multitude of places, and there's little
>or no "operational" information. [...] Not to mention the multiple
>copies of things all over the place (three copies of the rnews shell
>file, several strcpy.c's etc.)

The makefiles are improving, and we will spend some time on installation
documentation when we are done writing C news.  The duplicate copies of
files were meant to be links, because I expected to distribute a tar
archive.

>What C-news needs over the Alpha version (and of course, many of these
>are in the works or already done): [...]
>	3) Simplification of the installed system directory structure.

I'm not sure what your objection is.  We believe in using subdirectories
to group related files and search paths to find programs, and that won't
change.  We are also interested in separating the news programs from the
files corresponding to the data base of a given site's news system
(thus /usr/lib/news vs /usr/lib/newsbin) to permit convenient sharing of
programs via network file systems.

>For something that's supposed to be "small", it's distribution is 
>remarkably large.  Though, after wading thru all of the stuff, operationally
>it's quite small.  Lots of redundancy.

The redundancy was an accident (see above).  Um, yes, the distribution
is bigger than I would like.  The individual programs are relatively
small and less tangled than the B news sources, due to the use of source
subdirectories and libraries.  The overall structure does need a road
map.  The programs would be smaller but for silliness like The Great
Mod Group Renaming.  Part of the bulk of C news is error checking, which
B news often ignored.

>Some information on how to do this [build a test C news] would be
>greatly appreciated rather than individual "particles" in this and that
>makefile that don't seem to go together anyways.

There are several ways: edit libcnews/path.c, recompile everything and
comment out the definitions of NEWSARTS, NEWSCTL and NEWSBIN in
top-level (only) shell files such as inews, rnews, sendbatches, and
whatever invokes expire; just change those definitions in the shell
files; change the definitions in your environment and export them if you
just want to run a few tests.

>I do *like* C-news once you manage to get the durn thing running properly.
>But I'm gonna keep spectrix at B2.11 patch 14 until the C-news beta comes out.
>And, I'd recommend that commercial/production sites (particularly nodes) 
>do the same.

Some sites will not have that option soon, and that was the point I
originally tried to make.  Even if it is a lot of work to install C
news, B news will not be an option for some sites, soon, due to the
growth in news traffic and the slowness of B rnews.  That's all.

Enough said?
-- 
Geoff Collyer	utzoo!utstat!geoff, utstat.toronto.{edu,cdn}!geoff