geoff@utstat.uucp (Geoff Collyer) (01/06/88)
> 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
clewis@spectrix.UUCP (Chris R. Lewis) (01/07/88)
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
geoff@utstat.uucp (Geoff Collyer) (01/08/88)
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
dave@lsuc.uucp (David Sherman) (01/08/88)
In article <1988Jan7.191212.9827@utstat.uucp> geoff@utstat.uucp writes: > 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. B news has its problems, but this isn't one of them. The whole point of patch(1) is that you do NOT need to go back to virgin source. I've made a number of minor changes in B news for lsuc, and whenever I've run patch it's done a good job of finding the right place to patch (offset N lines). Occasionally it's trying to change a line very close to where I've made changes, and fails; so I get a .rej file and fix it by hand. Very simple. If B news patches were posted by reposting the corrected source instead (all the patches put together are now approximately the same size as the original distribution), I'd have to keep track of local patches I'd made. This way I don't. I realize you guys don't want to get into a lot of support, but where changes are appropriate, patch files are a Good Way to do it. David Sherman -- { uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!dave