eric@snark.UUCP (Eric S. Raymond) (03/09/88)
I received the following by email today. Since it reflects what may be a widespread confusion, I am posting it along with my reply. > I am starting to get a little confused. How is your news 3.0 related >to new C netnews from the University of Toronto? Are we heading toward >two different versions of netnews? I'm not sure I like the sound of that. >Its hard enough when not everyone is at the latest patch level. If you >could shed some light on this subject I would greatly appreciate it. No, 3.0 news is not C news. It is an entirely independent rewrite that evolved by mutation (and eventual 100% replacement) of the code in the 4.3BSD beta release of 2.10.3. It does incorporate a number of C news ideas, however, and the Toronto people are listed as contributors to the design. But I am the person responsible for the code that's in there now. Henry Spencer and Geoff Collyer have stated that they are not interested in maintaining a main-line news release. Therefore, my understanding is that 3.0 will be the official continuation of the B news line. I will maintain and extend it. I have plans to extend netnews to support full hypertext functionality, if I can scrape together the money to work on it full-time. Also note that C news only redoes the "transport" layer -- rnews, expire, inews. The only reader they supply is a hacked-over Australian version of readnews. 3.0, on the other hand, supplies rewritten and extended readers, including a couple of new ones and a back end plus control code for GNUMACS. I'm going to post this to try and forestall a flood of similar queries. ..!{ihnp4,seismo,rutgers}!cbmvax!snark!eric --> Eric S. Raymond -- Eric S. Raymond (the mad mastermind of TMN-Netnews) UUCP: {{seismo,ihnp4,rutgers}!cbmvax,sdcrdcf!burdvax,vu-vlsi}!snark!eric Post: 22 South Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
jeff@polyslo.UUCP (Jeff Weinstein) (03/09/88)
In article <223494f9:190e@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: >Henry Spencer and Geoff Collyer have stated that they are not interested >in maintaining a main-line news release. Therefore, my understanding is >that 3.0 will be the official continuation of the B news line. I will maintain >and extend it. I have plans to extend netnews to support full hypertext >functionality, if I can scrape together the money to work on it full-time. > Can either Henry or Geoff comment on this? What is the point of their work if it is not going to be part of the official news software? Will the 3.0 news have the similar performance improvements to those claimed by the C news implementors? Thanks for helping to clear up the confusion. Jeff Weinstein Computer Systems Lab Cal Poly State Univ. jeff@polyslo.uucp ucbvax!voder!polyslo!jeff
zeeff@b-tech.UUCP (Jon Zeeff) (03/10/88)
Are there any benchmarks comparing the speed of News 3.0 to C News? How about 3.0 News to the existing 2.11.14? Any other comparisons or lists of features would be helpful for people trying to decide the direction to go in. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
rsalz@bbn.com (Rich Salz) (03/11/88)
>Any other comparisons or lists >of features would be helpful RN won't work. No matter how good the 3.0 newsreader is, and no matter how close it comes to providing the features, it won't be RN. For many people, myself included, this will be a killing blow. I hope this gets fixed before this news system gets released. (I shudder to think how much this will slow down RN5.0 :-) /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
jbuck@epimass.EPI.COM (Joe Buck) (03/17/88)
In article <507@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes: >RN won't work. No matter how good the 3.0 newsreader is, and no matter >how close it comes to providing the features, it won't be RN. For many >people, myself included, this will be a killing blow. I hope this gets >fixed before this news system gets released. The answer, of course, is to put back in the DOXREFS patch as a configurable option. The authors of 3.0 news basically have three choices -- a) support the Xref: header, even though it's "wrong", or b) not complain too much when official patch #1 puts it in, or c) watch while twenty different buggy versions appear on the net, everyone does their own patch, and the software can no longer be centrally administered because everybody has slightly different code. I'm sure Eric will produce a marvelous newsreader. But tens of thousands of us know and love rn. Don't break it. -- - Joe Buck {uunet,ucbvax,sun,<smart-site>}!epimass.epi.com!jbuck Old Internet mailers: jbuck%epimass.epi.com@uunet.uu.net
mac@student.UUCP (Mary Ann Ciuffini) (03/18/88)
In article <507@fig.bbn.com>, rsalz@bbn.com (Rich Salz) writes: > >Any other comparisons or lists > >of features would be helpful > > RN won't work. No matter how good the 3.0 newsreader is, and no matter > how close it comes to providing the features, it won't be RN. For many > -- > Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. This is a test of a follow up to a message from my host
rad@tektronix.tek.com (03/18/88)
In article <2004@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >a) support the Xref: header, even though it's "wrong", or Doing it "right" (i.e. getting Xref info out of the history file) has been on my list of g-jobs to do for rn since I heard about 3.0 not including Xref: lines. People have been bitching about this for so long (in fact, since the Xref: line first appeared), I don't understand why noone has worked out the fix. Richard Doty.
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (03/21/88)
In article <2570@tekgen.TEK.COM> rad@tektronix.tek.com (Richard Doty) writes: >In article <2004@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >>a) support the Xref: header, even though it's "wrong", or >Doing it "right" (i.e. getting Xref info out of the history file) has er.. what's *wrong* with Xref: headers anyway? With Xref: headers we can do away with the need for a dbm based history file in preference to keeping the same information directly in the file system. This was discussed one month about a year ago and everybody agreed that it was do-able but nobody did it. The idea is to have a seperate directory structure which encodes the article-id into a path name, and at the leaves of the path is YetAnotherLink to the article. (something like "edu/uky/ms/g/3256" as the path name in this seperate directory structure, that particular article-id -> path mapping won't work very well, but some other mapping WILL work). In the header of the article would be the Xref: header so that you can track down the places where the article lives easily (otherwise you'd have to make a recursive traversal of the directory tree). The only extra cost is inodes for the second directory structure. For articles which have expired or been canceled, we'd have to keep the entry in the article-id directory structure, but no entries in the article structure. To save space we could truncate the file to 0 characters. Unfortunately this'll cost quite a few inodes. Then of course this idea can be extended to have extra directory hierarchies on any of the header lines. Yeah, hypertext anyone? :-) For each additional directory hierarchy we gain a new way of finding articles, but it also costs more inodes to build the directories. (REMINDER TO NON-WIZARDS: It won't cost more inodes to store extra links to the file -- that is unless you're not on Unix). -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- "Oh, I dunno -- I think Sean would be rather tasty!" -- Becky
brad@looking.UUCP (Brad Templeton) (03/22/88)
In article <8631@g.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: >The idea is to have a seperate directory structure which encodes the >article-id into a path name, and at the leaves of the path is >YetAnotherLink to the article. >... >The only extra cost is inodes for the second directory structure. Yikes!!!! What a cost. There are something like 8000 sites on this network, or so Brian Reid's surveys claim, so you're talking about at least 8000 directories (more for the hierarchy needed to avoid a directory with 8000 entries), and that means over 8000 inodes. And at least 8000 blocks of filespace for the directories, which is 8 megs on many machines. I only allocate 5 megs for all of the news spools. >For articles which have expired or been canceled, we'd have to >keep the entry in the article-id directory structure, but no >entries in the article structure. To save space we could truncate >the file to 0 characters. Unfortunately this'll cost quite >a few inodes. And if expired articles are kept for an extra 2 weeks, that's probably another several thousand inodes. Who knows, with luck, we'll get some K news volunteers, and all of these questions will become silly. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
rbp@investor.UUCP (Bob Peirce) (03/22/88)
> RN won't work. No matter how good the 3.0 newsreader is, and no matter > how close it comes to providing the features, it won't be RN. For many > -- > Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Why won't rn work? -- Bob Peirce, Pittsburgh, PA 412-471-5320 uucp: ...!{allegra, bellcore, cadre, idis, psuvax1}!pitt!investor!rbp NOTE: Mail must be < 30K bytes/message
michael@stb.UUCP (Michael) (03/27/88)
One problem with Xref: is that if news is comming in while you are reading, you may see an article in one group with an xref to a "non-existent" article (it does exist, but rn's got an out of date active file copy to work with). -- : Michael Gersten uunet.uu.net!ucla-an.ANES\ : ihnp4!hermix!ucla-an!denwa!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : "A hacker lives forever, but not so his free time"