Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!hp4nl!star.cs.vu.nl!ast
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: Split this Newsgroup ... PLEASE!
Message-ID: <7572@star.cs.vu.nl>
Date: 15 Sep 90 15:15:07 GMT
References: <10717@life.ai.mit.edu>
Sender: news@cs.vu.nl
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Lines: 34

In article <10717@life.ai.mit.edu> cracraft@ai.mit.edu (Stuart Cracraft) writes:
>Therefore, why not split the newsgroup into:
>
>    comp.os.minix.ibm    ... for discussion of IBM PC Minix
>    comp.os.minix.amiga  ... for Amiga Minix devotees
>    comp.os.minix.mac    ... for Macintosh Minix users
>    comp.os.minix.utils  ... for common sharable utilities/commands
>    comp.os.minix.libs  ...  for common sharable libraries
>    comp.os.minix.announce ... for messages from AST, Evans, and others
>			     with announcements.
I'd rather wait until the Amiga and Macintosh users come online, but I am
gradually coming around to the idea of some sort of split.  The main
argument against it is that people are sloppy.  People who have an X and
make a fix to, say, grep, will invariably post it to comp.os.minix.X
because that is the only group they read.  Thus the only way to avoid
missing everything is to read them all, in which case, why split?

If and when we split, I'm inclined to have one group:

comp.os.minix.sources

for new programs, patches, diff listings, new releases, etc.  This will
make life easier for archive maintainers and users, as this group will
have a high signal-to-noise ratio.  Possibly other groups for discussions,
questions, etc. specific to one machine (ibm, amiga, atari, mac, and eventually
sparc), and maybe one general-purpose group (comp.os.minix.d) for general
discussion.  Actually, most of the current traffic falls into that category.
Maybe also a group comp.os.minix.dev.null for discussions of the PDP-11
memory management unit and the like.

Anyway, lets wait until the Amiga and Mac users show up in bulk, since the
problem doesn't really hit until then.

Andy Tanenbaum (ast@cs.vu.nl)