jim@cssinc.UUCP (Jim McCorison) (03/30/91)
Being relatively new to the net I may have missed some historical aspect of this group, but isn't it supposed to be for Bnews discussion? It currently seems to be dominated by Cnews. It would sure make life easier on those of us still struggling with Bnews if there was a news.software.c group thereby making it easier to find the few, but valuable, Bnews postings. Please no flames if this happens to trigger an ancient sore spot :-) (as I said above I may have missed prior history). Sign me, Lost in a C of postings -- Jim McCorison Phone: 206-455-3507 jim@cssinc Fax : 206-646-9582 "Reality... What a concept!" UUCP : ... uunet!cssinc!jim **** Even if CSS knew my opinions, I doubt they'd consider them theirs as well.
henry@zoo.toronto.edu (Henry Spencer) (03/31/91)
In article <2202@cssinc.UUCP> jim@cssinc.UUCP (Jim McCorison) writes: >Being relatively new to the net I may have missed some historical aspect of >this group, but isn't it supposed to be for Bnews discussion? It currently seems >to be dominated by Cnews. The current interpretation is that it's for B-compatible news discussion. A couple of attempts to create a news.software.c have failed, mostly because it is, frankly, a dumb idea. The issues are very often common to both, and there isn't enough B-specific traffic to justify a separate B News group. What would be more sensible would be to rename it to news.software.transport, which would make its broader meaning more explicit. -- "The stories one hears about putting up | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 are all true." -D. Harrison| henry@zoo.toronto.edu utzoo!henry
kyle@uunet.UU.NET (Kyle Jones) (04/02/91)
jim@cssinc.UUCP (Jim McCorison) writes: > Being relatively new to the net I may have missed some historical aspect of > this group, but isn't it supposed to be for Bnews discussion? It currently seems > to be dominated by Cnews. henry@zoo.toronto.edu (Henry Spencer) writes: > The current interpretation is that it's for B-compatible news discussion. > A couple of attempts to create a news.software.c have failed, mostly because > it is, frankly, a dumb idea. The issues are very often common to both, and > there isn't enough B-specific traffic to justify a separate B News group. > What would be more sensible would be to rename it to news.software.transport, > which would make its broader meaning more explicit. Often the issues discussed are _not_ common to both news systems, which is what McCorison implied in his article. Witness the recent problems with relaynews (or some hacked version thereof), and the C news specific error messages about history and explist being corrupted. B news and C news are not compatible at the administrative level. A lot of B news and C news specific administrative questions are asked in this newsgroup. Separating the traffic doesn't mean the end of common discussions, it just means such discussion need to be cross-posted. Cross-posting is something that I hope to God news administrators, at least, can do intelligently. Renaming the group to news.software.transport legitimizes the potluck variety of traffic, but it doesn't adress thr problem that McCorison pointed out in his article.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (04/02/91)
In article <127221@uunet.UU.NET> kyle@uunet.UU.NET (Kyle Jones) writes: | henry@zoo.toronto.edu (Henry Spencer) writes: | > The current interpretation is that it's for B-compatible news discussion. | > A couple of attempts to create a news.software.c have failed, mostly because | > it is, frankly, a dumb idea. It has died because the authors of Cnews have fought against the division, and flooded this groups with C_news patch reports, administrative details, and other stuff which is of no interest to B news users. Purely politics, any claim of technical merit is not supported by analysis of the postings. By my count about 62% are purely dedicated to one system or the other. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Most of the VAX instructions are in microcode, but halt and no-op are in hardware for efficiency"