home *** CD-ROM | disk | FTP | other *** search
/ Il CD di internet / CD.iso / SOURCE / N / CNEWS / _CNEWS.TAR / usr / doc / cnews / README.old < prev    next >
Encoding:
Text File  |  1994-09-02  |  9.8 KB  |  189 lines

  1. This is C News.
  2.  
  3. C News is a reimplementation of the transport and storage subsystems of the
  4. news software -- basically, everything except news readers.  We supply a
  5. simple news reader (written by Michael Rourke, included by permission,
  6. slightly modified [so bugs are probably our fault]) as a replacement for
  7. B-News readnews suited to use by occasional users.  For regular news users,
  8. there are several more sophisticated readers widely available, and all should
  9. work with C News.  We use Larry Wall's "rn" ourselves; we have not included
  10. it because this distribution is already rather big.
  11.  
  12. C News's major advantage over B News is that it is much faster.  Timings
  13. quite a while ago gave C News a speed advantage of roughly a factor of 25
  14. in processing incoming batches.  This has probably improved a bit since.
  15. C News is now, on good machines with good C libraries, mostly system-call
  16. bound.  Use of system calls has been optimized with some care, so it's
  17. unlikely that further big speed improvements can be made at user level
  18. without sacrificing backward compatibility.  See our paper in the Winter '87
  19. Usenix proceedings for some discussion of how the speed was achieved.
  20.  
  21. C News also wins over B News on simplicity and robustness.  We provide
  22. (in our opinion) everything that's necessary, and avoid the frills that
  23. run up the complexity and decrease reliability.  We have not attempted to
  24. provide every feature anyone can think of, and have no plans to do so
  25. in future either.  (This is one reason why we've stayed out of the news-
  26. reader business, which generally has a bad case of feature-of-the-week
  27. syndrome.)
  28.  
  29. C News's files are fully compatible with those of B News for any program
  30. that does not read log files and does not inspect the middle field of the
  31. history file closely.  (The one major program that does is "nntp"; current
  32. versions (1.5.8 and later) include our C News support, including a significant
  33. speedup.)  C News complies fully with RFC 1036 (nee RFC 850), the official
  34. definition of news interchange format.
  35.  
  36. C News is, by intent and *we think* in practice, compatible with B News
  37. at the level of most interfaces to the normal user, which basically means
  38. the semantics and options of "inews".  It is *not* compatible on the
  39. system-administration level, although we think most of the changes are
  40. improvements or worthwhile simplifications.  The "postnews" that we supply
  41. is not compatible with that of B News; it is purely interactive, as news
  42. that is already formatted can simply be fed to "inews -h".
  43.  
  44. For those who now run one of our ancient pre-alpha versions, many things
  45. have changed, and in particular the four-field history file format is gone.
  46. C News has also changed quite a bit since the alpha release that went out
  47. on Usenet some time ago.
  48.  
  49. For our beta testers, build and the Makefiles have changed quite a bit but
  50. the software itself needed only fairly trivial fixes.
  51.  
  52. We know of three things that could still use work in this release:
  53.  
  54.     1. The documentation could use work, especially for naive customers.
  55.     As it stands, it pretty much assumes a general knowledge of news
  56.     software.
  57.  
  58.     2. There are a great number of small improvements that could
  59.     be made to the installation process, especially to permit still more
  60.     customization via the "build" program.
  61.  
  62.     3. The fgetmfs function (in the libc directory) assumes that fgets
  63.     does not alter the buffer beyond the end of the string.  We are not
  64.     sure how portable this is, although it works on all our beta-test
  65.     systems, and may revise fgetmfs someday.
  66.  
  67. The active file format is the 4-field one that B news introduced midway
  68. through 2.10, with minor additions: an `x' in the 4th field means
  69. ``discard articles in this newsgroup'', and `=group' in the 4th field
  70. means ``file articles for this newsgroup under `group' instead''.
  71.  
  72. The history file format is like B with one exception:  the second field,
  73. which few programs ever look at, now consists of two subfields separated
  74. by a tilde (~).  The first is the arrival date as a decimal number, the
  75. second is the expiry date (if any) as a human-readable date (as emitted by
  76. rnews) or a decimal number (after expire has gotten its hands on it once).
  77. Expire is tolerant of human-readable dates in both those places, but other
  78. things may not be.  The best way to get the history file into the new
  79. format is to rebuild it completely (this is RELATIVELY quick).
  80.  
  81. The sys file format is like a late-model B news with two extensions.
  82. First, the second field (groups and distributions) may optionally be
  83. split into two subfields (newsgroups and distributions, respectively)
  84. with a slash. This permits solutions to various tricky problems that can
  85. arise in odd situations if it is impossible to tell what's a newsgroup
  86. name and what's a distribution.  Second, there is a new flag in the
  87. third field:  f is like F except that its output has the size
  88. information that the C batcher wants for accurate limiting of batch
  89. size.
  90.  
  91. The way the news articles themselves are stored is totally unchanged; we
  92. have been unable to think of any changes that are worth the trouble.
  93.  
  94. There are some new control files in /usr/lib/news, to control the smarter
  95. expire and batcher.  (Old C News sites, note some format changes.)
  96.  
  97. File organization:  the one change is that programs are now kept mostly
  98. in /usr/lib/newsbin, with /usr/lib/news reserved for control files etc.
  99.  
  100. B News sites note:  /bin/rnews is now a front end for the input spooler.
  101. The real news-filing program is called relaynews and is not in /bin.
  102.  
  103. C News is meant to run adequately on a 16-bit machine, although this has
  104. not been tested thoroughly since utzoo became a Sun.
  105.  
  106. Most (by intent all) of the programs understand seven key environment
  107. variables: NEWSARTS specifies location of articles (default
  108. /usr/spool/news), NEWSCTL specifies location of control files (default
  109. /usr/lib/news), NEWSBIN gives location of programs (default
  110. /usr/lib/newsbin), NEWSUMASK gives the umask to be used in creating
  111. files (default 002), NEWSPATH gives the path used to find "normal" programs
  112. (default /bin:/usr/bin), NEWSMASTER is the address to which problem
  113. reports should be mailed (default usenet), and NEWSCONFIG is the full
  114. pathname of a little file that shell programs can use to pick up local
  115. default settings for all these things (the equivalent for the C programs
  116. is in the C News library) (default /usr/lib/news/bin/config).  The
  117. environment variables override the defaults for testing and for operation
  118. in funny situations.  Note that one or two things (e.g. relaynews), as
  119. distributed, will insist on renouncing setuid privileges if invoked with
  120. these overrides.
  121.  
  122. Be warned that the simple news reader in
  123. rna has not been gone over very well to make sure that it uses the
  124. standard configuration mechanisms.  Hardwired pathnames may be present there,
  125. and in general the stuff there is not well fitted into our automatic-install
  126. machinery.
  127.  
  128. See ROADMAP for a run-down on what's where in the distribution.  See
  129. doc/install for how to install it.  You may wish to read notebook/problems,
  130. which discusses common difficulties.  Conf/build is the interactive setup
  131. program that does most of the work, or rather, sets up shell files which,
  132. when run, do most of the work.  Even if your system is odd enough that
  133. you don't want to run the shell files conf/build generates -- doit.bin and
  134. friends -- as is, you are most strongly advised to run conf/build and use
  135. the resulting shell files as guides, rather than trying to "wing it"
  136. yourself.  Getting the library built correctly is *NOT* trivial, because
  137. we try to cater to all 57000 different variants of Unix and there are a lot
  138. of decisions that have to be made.  This is why we supply a 31KB shell
  139. program to generate the configure+compile+install instructions, rather than
  140. just sending a complete pre-cooked recipe embodied in a Makefile:  there are
  141. too many variables affecting how it should be done.
  142.  
  143. For general background and information on running a news system, we highly
  144. recommend the Nutshell Handbook:
  145.  
  146.     "Managing UUCP and Usenet", by Tim O'Reilly and Grace Todino,
  147.     O'Reilly & Associates, 1989, ISBN 0-937175-48-X.  This latest
  148.     edition covers C News as well as B News.  It's not perfect but
  149.     it's lots better than nothing.  Inquiries to nuts@ora.com or
  150.     uunet!ora!nuts.
  151.  
  152. C News has been tested pretty thoroughly.  We're also thoroughly sick of
  153. it and make no promises that there will ever be another release.  We may,
  154. repeat *may*, provide updates via some appropriate newsgroup (currently
  155. the best choice is "news.software.b", although there is some sentiment for
  156. folding all the subgroups there into just "news.software"; we oppose
  157. creation of "news.software.c" because we don't think there will be enough
  158. traffic to justify a whole newsgroup).
  159.  
  160. If you've found a problem, we definitely do want to hear about it.  But,
  161. we *do not* want to see 2000 lines of diff listing!  What we want to see
  162. is a concise human-readable description of what the problem is and how, 
  163. if at all, you solved it.  If we want the diff listing, we will ask.
  164. Similarly, we are interested in hearing about changes and improvements,
  165. but want to see terse descriptions first.
  166.  
  167. If you want us to consider changes/fixes/etc, send them to us, don't just
  168. post them to the net.  We don't necessarily read all possibly-relevant
  169. groups.  Only postings from us are officially part of C News.
  170.  
  171. To send comments, complaints, problem reports, etc., do *not* mail to
  172. Geoff or Henry personally, but to:
  173.  
  174.     c-news@zoo.toronto.edu
  175. aka    c-news@zoo.utoronto.ca
  176. aka    utzoo!c-news
  177.  
  178. (Note that this has changed, c-news used to be on utstat.)
  179.  
  180. The current C News distribution can currently always be retrieved by
  181. anonymous ftp from ftp.cs.toronto.edu in file pub/c-news/c-news.Z (a shell
  182. archive) or pub/c-news/c-news.tar.Z (a tar archive) and the complete set
  183. of patches can also be found on ftp.cs.toronto.edu in the directory
  184. pub/c-news/patches.  FTP during our peak hours (12h00-17h00 Eastern) is
  185. not encouraged.
  186.  
  187.                     Geoff Collyer
  188.                     Henry Spencer
  189.