Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!mit-eddie!media-lab!media-lab.media.mit.edu!dnb
From: dnb@meshugge.media.mit.edu (David N. Blank)
Newsgroups: comp.sources.d
Subject: Re: Rich $alz is still alive ??!!!??!!
Message-ID: <DNB.90Nov30120626@meshugge.media.mit.edu>
Date: 30 Nov 90 17:06:26 GMT
References: <15169@cs.utexas.edu> <21867@well.sf.ca.us>
	<DNB.90Nov29153511@meshugge.media.mit.edu> <16084@bfmny0.BFM.COM>
Sender: news@media-lab.MEDIA.MIT.EDU
Followup-To: comp.sources.d
Organization: M.I.T. Media Laboratory
Lines: 25
In-reply-to: tneff@bfmny0.BFM.COM's message of 30 Nov 90 05:47:16 GMT

> True, that's a risk; but one that a motivated user can tackle himself by
> editing, compiling, and testing.  

I may be a motivated user, but I'm also a busy one. A good moderator
can save me and all of the other users supplied by that group lots of
cumulative time.

> YOU may be scared when a new editor or game comes down the unmoderated
> pipe, but I'M not.

Not scared, just busy.  See above.  I noted the following non-security
related services a good moderator provides in my original response:
Checks for: 
> ... code that doesn't compile, non-standard idioms (makefiles &
> etc), missing files, non-standard shar formats, portability, & etc.

> An approved, 'safe,' 'debugged' moderated channel is a wonderful idea,
> but when throughput dries up without adequate explanation or response
> from the moderator, it's little wonder confidence erodes and people
> start gravitating to less 'secure' but more available channels.

I'll agree with that.  Of course, for an accurate representation of
throughput, you have to know what the input rate is. 
       Peace,
          dNb