[news.admin] More groups or fewer?

mcb@lll-tis.arpa (Michael C. Berch) (09/10/87)

In article <886@hao.UCAR.EDU> woods@hao.UUCP (Greg Woods) writes:
> [...] My personal
> opinion, based on my 6 years of experience on this net, is that we have
> to limit the number of newsgroups in order to keep the system manageable.
> The more groups we have, the harder it is for a user (particularly new
> users) to find the appropriate group to post an article in. There is also
> a load associated with each newsgroup (size of the active file, amount of
> CPU time and memory consumed by the posting/reading software, number of inodes
> and disk space used for directories for each group, etc.). 

Since we do not have a true keyword-based system, newsgroup names are
pressed into service as keywords. I don't think that having more groups
causes confusion for new users; precisely the opposite. New users will
see group names like rec.music.beatles or (hypothetically) comp.unix.bsd
and realize that Usenet is structured with a reasonable fine granularity.
A newsreading-interface command that works like apropos(1) on the
newsgroups file might be helpful, e.g.,

End of article 123 (of 999) -- what next [ynq]  apropos mac

comp.binaries.mac	Encoded Macintosh programs in binary. (Moderated)
comp.emacs		EMACS editors of different flavors.
comp.sources.mac	Software for the Apple Macintosh. (Moderated)
comp.sys.mac		Discussions about the Apple Macintosh & Lisa.
comp.sys.mac.digest	Apple Macintosh: info&uses, but no programs. (Moderated)

This can easily be done from the shell, of course.

I think having a large number of newsgroups helps readers and admins
fine-tune their use and maintentance of Usenet, and can't really
believe that the load that Greg mentions (length of the active file,
additional inodes and blocks  for newsgroup directories, etc.) are
really more than trivialities at the present order of magnitude of 
number of newsgroups (100-1000). Perhaps a newsgroup count exceeding 
2000 or 5000 might have unfixable ramifications, but I do not know the
vagaries of the code well enough to come to a conclusion about this.

Michael C. Berch 
News/mail admin - lll-tis
ARPA: mcb@lll-tis.arpa
UUCP: {ames,ihnp4,lll-crg,lll-lcc,mordor}!lll-tis!mcb