karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) (07/11/89)
I almost hate to ask this question; it seems too prone to starting a flame fest, or perhaps a massive b*tch-and-moan session, neither of which interests me particularly. Nonetheless, this note prompts me to ask... [rick@pcrat.uucp:] BTW, C news wasn't any panacea here, even with DBZ... It *does* seem more manageable, though, than B news. I am curious (truly, just _curious_) as to what in B news people find "unmanageable." Define "unmanageable" in whatever terms suit you in your context. I find B news really quite manageable. What I need are tools for hacking on the configuration files more mechanically, e.g., adding a new feed requires me to edit sys, nntp_access, and nntpsend. Alternatively, sys, Systems, Permissions, and newsbatches (local script which does UUCP batching). Otherwise, it needs relatively little care in terms of daily monitoring/management. I run report.awk every night so I get activity summaries; I expire once a week on a 3-week basis; I use trimlib to keep the number of logfiles to a manageable set (just the last 2 days or so); little else. Where do others find that B news eats your time for "management"?
rick@pcrat.uucp (Rick Richardson) (07/11/89)
In article <KARL.89Jul10213445@dinosaur.cis.ohio-state.edu> karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes: > >I am curious (truly, just _curious_) as to what in B news people find >"unmanageable." Define "unmanageable" in whatever terms suit you in >your context. 2.11B news would leave zero length news articles around, not in the history files, so expire wouldn't delete them. It also left these babies around in /usr/spool/news: -rw-rw-rw- 1 news news 0 Jul 2 00:02 .ara01543 -rw-rw-rw- 1 news news 0 May 21 00:26 .ara06710 -rw-rw-rw- 1 news news 0 May 23 03:15 .ara09155 -rw-rw-rw- 1 news news 0 May 24 21:31 .ara10912 -rw-rw-rw- 1 news news 0 Jun 8 22:41 .ara11786 -rw-rw-rw- 1 news news 0 May 27 07:51 .ara13609 -rw-rw-rw- 1 news news 518 Jul 2 00:02 .ina01543 -rw-rw-rw- 1 news news 4235 May 21 00:26 .ina06710 -rw-rw-rw- 1 news news 637 May 23 03:14 .ina09155 -rw-rw-rw- 1 news news 2263 May 24 21:31 .ina10912 -rw-rw-rw- 1 news news 720 Jun 8 22:41 .ina11786 -rw-rw-rw- 1 news news 1075 May 27 07:51 .ina13609 I didn't notice those until there was a megabyte hiding in there. And then there were the L<* files left in /tmp. All of these things were fixed by running a "find", and maybe would have been fixed had I not given up patching it after patch 12 or 13. It was taking up too much time patching. And the manual edits to "newsgroups" after a checkgroups to delete the "general" group which got added every time even though it was already there. (I don't know what C news will do with this yet). I'm sure there were other irritations, but I stopped caring long ago. -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
denny@mcmi.UUCP (Denny Page) (07/19/89)
rick@pcrat.UUCP (Rick Richardson) writes: >2.11B news would leave zero length news articles around, not in the history >files, so expire wouldn't delete them. It also left these babies around >in /usr/spool/news: [...] >And then there were the L<* files left in /tmp. It's not supposed to do that :-). >had I not given up patching it after patch 12 or 13. Perhaps you should have stuck with it. Level 14 does not appear to have these problems unless you kill news processes or you have problems in your sys file. -- Someday has arrived