Newsgroups: tor.news,ont.uucp,news.config
Path: utzoo!utstat!geoff
From: ge...@utstat.uucp (Geoff Collyer)
Subject: genat down with disk troubles
Message-ID: <1987Dec23.161042.2776@utstat.uucp>
Organization: Statistics, U. of Toronto
Distribution: ont
Date: Wed, 23 Dec 87 16:10:42 EST
I spoke with Mike Stephenson of Genamation (the local Pyramid dealers)
this afternoon, and he reports that genat has been down for the past few
days with a broken Eagle, but repairmen are working on the Eagle now,
and genat should either be up by the end of the afternoon, or will be
down for the holidays.
If genat is down for the holidays, utzoo does not have the disk space
to hold the unsent news that is queued for genat, so genat and sites
downstream from it will lose some news.
--
Geoff Collyer utzoo!utstat!geoff, utstat.toronto.{edu,cdn}!geoff
Newsgroups: ont.uucp,tor.news
Path: utzoo!utstat!geoff
From: ge...@utstat.uucp (Geoff Collyer)
Subject: Re: genat down with disk troubles (Lsuc problems too)
Message-ID: <1988Jan5.011219.2676@utstat.uucp>
Summary: the storm was real; caused by B news on utzoo & lots of traffic
Organization: Statistics, U. of Toronto
References: <1987Dec23.161042.2776@utstat.uucp> <360@spectrix.UUCP>
<1988Jan3.201804.10833@gpu.utcs.toronto.edu> <236@syntron.UUCP>
Distribution: ont
Date: Tue, 5 Jan 88 01:12:19 EST
I am the news administrator for utzoo during Henry's absence. Just to
set the record straight, there was a news storm or flood originating at
utzoo at Christmas time. It has passed except that dciem hasn't picked
it all up yet and genat has been down, or at least not ready to receive
news, and so hasn't seen it yet. (So all you sites downstream of dciem
and genat can gird your loins now: dciem is now receiving some news and
genat appears to be healing. :-) I think there is a lesson (or two) in
the story of the flood...
Until mid-December, utzoo ran B 2.10 rnews [gasp! well it is public
information; you could have discovered this by sending a version control
message], but only from 6:30 PM each week night until about 8 AM the
next morning, and around the clock on weekends, to prevent interference
with real work during the day. Around the end of November, Henry
noticed that not only was B rnews not processing all of the nightly news
flow by 8 AM, but the 24-hour processing on the weekends left some
unprocessed news on Monday morning. I did some gross measurements in
early December which suggested that the rate of accumulation of
unprocessed news was slightly over 1Mb/day. As you might expect from
that rate, within three weeks of Henry first noticing a backlog on
Monday morning, there was a backlog of about 25Mb of incoming news on
utzoo by mid-December, growing rapidly.
On December 15th, Henry installed C rnews and let it loose (subject
to the same time-of-day restrictions as above) on the backlog at 6 PM.
During the night of December 15th-16th, C rnews processed all but a few
megabytes of the incoming queue and at 10:03 PM on December 16th,
C rnews polished off the last article of the backlog.
There's a lesson here for any other VAX-750-class machines (utzoo is a
PDP-11/44 with 2 Eagles and 3Mb or 4Mb main memory) which don't process
news during the day: Switch to C news. Soon. It's no fun putting up
news software when there's a gun (consisting of a rapidly-growing
backlog) pointed at your disks (but it certainly does concentrate the
mind! :-). Thus endeth the advertisement.
Then there was the small problem of distributing all that news. Just
filing it all reduced utzoo's free space on /usr to 6Mb, at which
threshold utzoo's news batcher refused to generate batches due to the
lack of free space, and Henry left for vacation (December 21st). I
spent a couple of days removing files, forcing calls to sites with dead
autodialers, and waiting for the storm to expire. Around Christmas,
expire started producing a lot of free space, so that batching could
proceed even faster (now that the articles being batched had mostly
expired :-).
utstat gets a fairly small (and shrinking) subset of the available news,
so I don't have a good feeling for how many megabytes are in a day's
news flow, but I gather it is now about 1.5Mb-2Mb. A permanent,
standing 1200 baud UUCP baud connection can pump no more than 9.5Mb/day
(assuming 110 bytes/second, which is the empirical upper bound at
1200 baud). A surprising number of utzoo's news neighbours in Toronto
have only 1200 baud modems, so this is not entirely academic. Looking a
little into the future, keeping 9.5Mb/day for 10 days (as utzoo
currently does) will consume 95Mb under /usr/spool/news and a
site-specific volume in the outgoing UUCP queues. You will also need
about 5Mb free for the incoming, unprocessed news for a single day
(compressed).
Let's look a little further into the future. B rnews on a VAX 750 under
4.2BSD processed about 67 bytes/second. C rnews, when I last measured
it (over a year ago), was processing over 1,000 bytes/second on the same
machine, so C rnews should not present a limit to volume of news until
major news links use Telebit Trailblazers. Assuming 1,000 bytes/second
through the Trailblazers and standing connections, one can only pump
86.4Mb/day. Retaining news for 10 days will consume 908Mb (864Mb in
/usr/spool/news + 44Mb incoming), or 2.4 Sun Eagles, or about 2
Swallows.
Somewhat later, CSRI should have a good FDDI Internet connection, so we
should be able to transfer 10Mb of news per second, but C rnews will
likely be running at only several kilobytes/second, unless we use
a Cray as the main U of T news server. Unfortunately current disks
typically transfer data no faster than about 2.5Mb/second, but we shall
assume that disks will get magically faster. Assuming that the C rnews
on the Cray can keep up with FDDI transfer rates, we can transfer only
864Gb of news per day. Keeping it for 10 days will consume 9Tb in
/usr/spool/news, which will have to be on fast optical disks or in Cray
4 main memory. :-) :-)
More seriously, I am interested in the growth of Usenet traffic vs. the
increases in speed of news hardware and software, and may try to plot
the curves. I would guess that in a few years, the growth of traffic
will exceed the ability of machines smaller than Sun 4s running C news
to keep up. I suspect that eventually only relatively large machines
will be able to keep up with traffic volumes, especially if the owners
of machines carrying news want people to get work (other than news
maintenance) done on those machines.
I see some final lessons: don't volunteer to be a backbone site :-); and
only moderated groups will survive in the long-term. I wonder how long
is "long-term": three years or five? I can remember news flows of
100kb/day; it all seemed so harmless then :-).
--
Geoff Collyer utzoo!utstat!geoff, utstat.toronto.{edu,cdn}!geoff
Newsgroups: ont.uucp,tor.news
Path: utzoo!utstat!geoff
From: ge...@utstat.uucp (Geoff Collyer)
Subject: correction to my comments on news traffic
Message-ID: <1988Jan5.133442.1846@utstat.uucp>
Summary: I forgot compress, but total volume is 3Mb/day
Organization: Statistics, U. of Toronto
References: <1987Dec23.161042.2776@utstat.uucp> <360@spectrix.UUCP>
<1988Jan3.201804.10833@gpu.utcs.toronto.edu> <236@syntron.UUCP>
<1988Jan5.011219.2676@utstat.uucp>
Distribution: ont
Date: Tue, 5 Jan 88 13:34:42 EST
Rayan tells me that total news flow is 3Mb/day, about twice what I
estimated. On the other hand, I largely ignored the effect of
compression on news transfer times: compression tends to halve the
time. These two effects should cancel each other, making my previous
estimates approximately correct. :-)
Compression does slow transmission of news on machines where the
(elapsed) time to compress a batch exceeds half the time to send the
batch uncompressed (similarly, on reception, if time to uncompress
exceeds half the time to receive the batch uncompressed). This is
unlikely to hold for any modern machine (utzoo is another matter).
After thinking a little more about traffic growth, I remembered that
someone has observed that Usenet traffic doubles each year. Assuming
100kb/day in 1982, that assumption yields 3.2Mb/day in 1987, which is
pretty close to reality. If traffic continues to double yearly, in
mid-1989, 1200 baud will not supply enough bandwidth to receive a full
news feed. In 1990, 2400 baud won't be adequate. Around the end of
1992, the Trailblazers (over 9600 baud) will run out of steam, with
daily news flow of 102Mb. If the phone companies follow New Jersey
Bell's lead, we may have end-to-end-digital dial-up data communication
by then, and be able to run considerably faster, and without modems. By
1994, daily flow will reach 410Mb, requiring a VAX Eagle *per day*. By
1997, daily flow will reach 3.3Gb, approaching one byte per person on
Earth.
The answer to my own question seems to be that "long-term" is about four
years. By then, we will need modems faster than Trailblazers, digital
dialup data communication, widely-available WANs (Wide-Area Networks),
or moderation of most groups.
--
Geoff Collyer utzoo!utstat!geoff, utstat.toronto.{edu,cdn}!geoff
Path: utzoo!utcsri!jarvis.csri.toronto.edu!utgpu!ryesone!lsuc!dave
From: d...@lsuc.uucp (David Sherman)
Newsgroups: ont.uucp,tor.news
Subject: Re: genat down with disk troubles (Lsuc problems too)
Message-ID: <1988Jan6.000342.19591@lsuc.uucp>
Date: 6 Jan 88 05:03:40 GMT
Article-I.D.: lsuc.1988Jan6.000342.19591
Posted: Wed Jan 6 00:03:40 1988
References: <1988Jan5.011219.2676@utstat.uucp>
Reply-To: d...@lsuc.UUCP (David Sherman)
Distribution: ont
Organization: Law Society of Upper Canada, Toronto
Lines: 26
Summary: C news fast but hard to install
In article <1988Jan5.011219.2...@utstat.uucp> ge...@utstat.uucp writes:
>There's a lesson here for any other VAX-750-class machines (utzoo is a
>PDP-11/44 with 2 Eagles and 3Mb or 4Mb main memory) which don't process
>news during the day: Switch to C news. Soon. It's no fun putting up
^^^^^
>news software when there's a gun (consisting of a rapidly-growing
>backlog) pointed at your disks (but it certainly does concentrate the
>mind! :-). Thus endeth the advertisement.
So, despite Henry being a co-author of C news and utzoo being a
machine that really needed help, he wasn't even running it?
Maybe that explains why C news was so much "fun" to install.
The message that I have from clewis is that C news is rather
difficult to install. From my (personal) point of view, not
having had to do the installation work, I say C news is great,
since it runs so much faster. But unless/until you guys can
repackage it so it installs more easily (perhaps Chris can
give you some advice on that score), our Official Statement
to the world is: don't install C news unless you have lots
and lots of expert hacker time to spare. Thus endeth the
comment to the advertisement.
David Sherman
--
{ uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!dave
Newsgroups: ont.uucp,tor.news
Path: utzoo!utstat!geoff
From: ge...@utstat.uucp (Geoff Collyer)
Subject: putting up C alpha news
Message-ID: <1988Jan6.142625.5695@utstat.uucp>
Summary: it may not be easy, but it may be essential
Organization: Statistics, U. of Toronto
References: <1988Jan5.011219.2676@utstat.uucp> <1988Jan6.000342.19591@lsuc.uucp>
Distribution: ont
Date: Wed, 6 Jan 88 14:26:25 EST
> So, despite Henry being a co-author of C news and utzoo being a
> machine that really needed help, he wasn't even running it?
Henry is the junior author of C News (that's why his name is second on
the Usenix paper). He wrote expire, the batcher, the input subsystem
and a few library functions; I wrote the rest: inews, rnews, relaynews,
newshist, gngp, and the support libraries.
utzoo had been running all of C news but C rnews for some time. I don't
know the reasons for Henry continuing to run the B rnews, but I can
guess at them: utzoo is a backbone site and it's prudent not to disturb
the news or uucp transport software without good reason, and until the
backlog appeared, there wasn't a compelling reason to switch, given that
utzoo doesn't process news during the day.
> Maybe that explains why C news was so much "fun" to install.
Well, we did warn that it might require work. To quote the top-level
README.FIRST file of the alpha release:
This IS NOT the definitive release. As the word "alpha" implies, it
is not even beta test. This release is NOT nicely packaged, it is NOT
bug-free, it does NOT have the full desired functionality (for example,
it doesn't have moderated-group security yet), it undoubtedly has some
portability and compatibility problems, it is not properly documented,
and it WILL be superseded by a later version in a conversion that is
NOT guaranteed to be painless. In other words, use at your own risk.
It is essentially our current working version.
If you don't have time to explore its idiosyncrasies and babysit its
problems, you should not even try to put it up.
With that warning in mind, I continue to advise any VAX-750-class site
with a system programmer, getting a full news feed, and not processing
news during the day (utzoo fits that description, and I think dciem
does, for example) to switch to C news, *out of necessity*, not for my
ego gratification. If the people running such a site wait a little
longer, they won't have much choice. Consider my suggestion to be a bit
of friendly advice to those about to be overrun by news. The sooner
they switch, the more time they will have to install C news, without
a growing backlog of unprocessed news filling their disks.
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). 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.
Incidentally, we do appreciate Chris's feedback and the beta release
should be both more robust and easier to install. (No, I don't know
when that will be, but we hope to have something to announce at February
Usenix.)
--
Geoff Collyer utzoo!utstat!geoff, utstat.toronto.{edu,cdn}!geoff
Path: utzoo!utcsri!jarvis.csri.toronto.edu!utgpu!tmsoft!spectrix!clewis
From: cle...@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: cle...@spectrix.UUCP (Chris R. Lewis)
Distribution: ont
Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada
Lines: 145
In article <1988Jan6.142625.5...@utstat.uucp> ge...@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
Newsgroups: ont.uucp,tor.news
Path: utzoo!utstat!geoff
From: ge...@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 <3...@spectrix.UUCP> cle...@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
Newsgroups: ont.uucp,tor.news
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: genat down with disk troubles (Lsuc problems too)
Message-ID: <1988Jan16.192746.2003@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1988Jan5.011219.2676@utstat.uucp>, <1988Jan6.000342.19591@lsuc.uucp>
Date: Sat, 16-Jan-88 19:27:41 EST
> So, despite Henry being a co-author of C news and utzoo being a
> machine that really needed help, he wasn't even running it?
I was running a lot of parts of it, but not the whole thing. In particular,
I wasn't running C rnews. This was partly sheer inertia, partly reluctance
to mess with working software without need, and partly lack of real need --
until quite recently, the antique B rnews we ran was more or less coping
with the load. Oh yes, and partly being decidedly busy. I am relieved to
have made the switch -- it was long overdue -- but it was a significant
effort at a time when I had too many other things to do. The growing
backlog forced my hand.
Also, calling me "co-author" is perhaps a bit strong; Geoff did most of the
hard parts. I've done more of the interfacing to the outside world, but
that's for other reasons (e.g. I talk more!).
> The message that I have from clewis is that C news is rather
> difficult to install... But unless/until you guys can
> repackage it so it installs more easily... our Official Statement
> to the world is: don't install C news unless you have lots
> and lots of expert hacker time to spare.
Chris seems to have had an unusually difficult time of it, based on the
reports we hear. However, note the following in README.FIRST as sent
out with the alpha release:
If you don't have time to explore its idiosyncrasies and babysit its
problems, you should not even try to put it up.
You wuz warned.
--
Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
|