Xref: utzoo ont.uucp:347 tor.news:110
Path: utzoo!utcsri!jarvis.csri.toronto.edu!utgpu!tmsoft!spectrix!clewis
From: clewis@spectrix.UUCP (Chris R. Lewis)
Newsgroups: ont.uucp,tor.news
Subject: Re: putting up C alpha news
Message-ID: <381@spectrix.UUCP>
Date: 7 Jan 88 19:19:06 GMT
Article-I.D.: spectrix.381
Posted: Thu Jan  7 14:19:06 1988
References: <1988Jan5.011219.2676@utstat.uucp> <1988Jan6.000342.19591@lsuc.uucp> <1988Jan6.142625.5695@utstat.uucp>
Reply-To: clewis@spectrix.UUCP (Chris R. Lewis)
Distribution: ont
Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada
Lines: 145

In article <1988Jan6.142625.5695@utstat.uucp> geoff@utstat.uucp writes:
>If you pay attention to the alpha release README files and the C News
>Bulletins published in news.software.b (there have been six so far), you
>will have less trouble installing C alpha news than Chris Lewis did,
>partly because we hadn't published all the Bulletins when he installed C
>news on lsuc, and partly because Chris was rushed and didn't read all
>the READMEs first (or so he said).

That's *not* quite what I meant.  The one thing I didn't read was the 
newsbatches manual page (and paid for it by having to refeed a couple 
of sites).  What I had actually meant by my "I can't read everything" is
that I didn't read all of the shell files and sources before trying
to bring it up.  I shoulda.  I *know* it's an alpha release.  I understand
what that means.  (I had quite a few suggestions that I mailed to
Geoff and Henry - I'm not going to repeat these here).

The bulletins didn't help much before, during or after.  Official "patches"
would have helped more.

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.  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 (mnetor, stm386, VME/10's, spectrix and assistance with yetti, 
genat etc.).

The software itself is remarkably bug-free for an initial alpha release.
There were only two real bugs that affected us (one spotted elsewhere
and reported in a bulletin, the other I found.  Did you ever publish
that one ? -  I forget. (real nasty one)).

However, there are a number of places where some of the operational aspects
of it can be improved.  I find it interesting to note that not only
wasn't Henry running *all* of C-news (until considerably after the alpha
release, and much of his C-news is considerably changed beyond what was
released) let alone Alpha, but neither is Geoff - you did say that you 
weren't running the input spooling software didn't you?  That's where 
most of my problems arose out of.  C-news is intended to be, and mostly 
is, much better at making sure you don't drop anything than B-news.  
However, as distributed, the input spooling and error recovery in all 
those shell files leaves something to be desired - in its zeal to make 
sure that you don't lose anything, it makes sure you have several copies 
of a blown batch.  (Depending on the circumstances, as much as: one 
mailed to "usenet" (aliased to Dave Sherman and myself), one dropped 
in /tmp, the original left behind in /usr/lib/news/incoming/bad.)  
Something as minor as an accidental batch file (specified in sys) 
permission or ownership change can drop a whole day's worth of news 
in 3 or more places.  lsuc blew it's disks twice until I 
defeated/modified some of the error recovery code and added disk
throttles into the input spooler.

It should be pointed out that much of the configuration changes
are by changing or creating shell code.  Intentionally, if I read
the philosophy documents correctly.  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 (except for lots of interesting,
amusing, but useless comments in various places).  So, for example, 
you have to know what the batch formats are for varying versions of 
news, AND, understand the batcher well enough to know that you *do*
have to make the change and where.

In constrast, B-news is pretty good at having ALL code that you need -
configuration is primarily build switches and the occasional parameter.
(Eg: sendbatches parameters for feed sites of varying types).  The
only things you really have to add are throttles (if you need 'em, and
they're very site-specific) and the occasional minor change for a system
type not anticipated by the authors - Eg: Spectrix is a Xenix system
but not on a PC, AT or 386 (very rare nowadays) and we need only
two one-liner define changes (In spite of the fact we're Xenix, I WANT 
to use DBM and I WANT lock files, not locking or lockf subroutines).

To put it in a nutshell, with B-news, you only have to answer
a moderate number of questions about how your system differs from others.  
Half of 'em are along the lines of "Are you BSD4.3? 4.2? Xenix? SV?)
With C-news you have to figger out the questions *are* before you can
answer them.  Not helping is the fact that utzoo, utstat and lsuc
are hardly vanilla versions of whatever version of UNIX they are.
(Who ever heard of V7's with getopt, ndir, "strings" etc anyways!)

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.  Building was sort of
fun too - your libraries of adaptor routines (eg: all of SV memory, strings
etc.) are *very* nice, but hard to decide exactly what you need - all
of the makefiles need to be custom-editted and trial-run in some cases
quite a few times.  Not to mention the multiple copies of things all over 
the place (three copies of the rnews shell file, several strcpy.c's etc.)

Never did get the libc adaptor makefile to work (done manually).
(I try to do minimal changes to things, particularly build structure so
that patching from an "official source" is easy).

What might have helped is a statement "we don't intend to ship any official
patches, so you're free to hack it up anyway you like" - woulda saved lots
of time.

What C-news needs over the Alpha version (and of course, many of these
are in the works or already done):

	1) Complete overhaul of the makefiles for consistency and auto-config.
	2) Simplification and rationalization of the input spooler
	   (already done, not released yet)
	3) Simplification of the installed system directory structure.
	4) Installation mechanism
	5) Up-to-date READMEs.  Less advertising (why do you need to advertise -
	   the only guys to see it already HAVE it) and smart-alec comments 
	   PLEASE!  They're a hinderance given the design philosophy.
	   (Some of both is appreciated and gives the odd chuckle.  Definately
	   overdone though)
	6) An operational guide.

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.

>I would also remind people that
>it is easier to build a test C news system than it is a to build a test
>B news system, and I encourage people to run B news and C news in
>parallel until they feel confident of C news.

Some information on how to do this would be greatly appreciated rather
than individual "particles" in this and that makefile that don't seem
to go together anyways.

>Incidentally, we do appreciate Chris's feedback and the beta release
>should be both more robust and easier to install.

Thank you.  That's what I intended. 

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.  Unless you like spending overnighters babying it for the first
week or so.  (I must admit though, the news storm and previous "bursty"
load did exaggerate the problems)
-- 
Chris Lewis, Spectrix Microsystems Inc,
UUCP: {uunet!mnetor, utcsri!utzoo, lsuc}!spectrix!clewis
Phone: (416)-474-1955