home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / alt / irc / 4593 < prev    next >
Encoding:
Text File  |  1992-12-11  |  3.1 KB  |  58 lines

  1. Newsgroups: alt.irc
  2. Path: sparky!uunet!digex.com!mattm
  3. From: mattm@digex.com (Matt Mosley)
  4. Subject: Re: Waxing nostalgic without much of a point.  Was: Re: Why people care so strongly about IRC (sorry, a bit long)
  5. Message-ID: <Bz42rt.7px@access.digex.com>
  6. Sender: usenet@access.digex.com
  7. Nntp-Posting-Host: power.digex.com
  8. Organization: Express Access Online Communications, Greenbelt, MD USA
  9. References: <9212100353.AA25829@hrt213.brooks.af.mil> <1g5r5aINN1hk@usenet.INS.CWRU.Edu> <1g842vINNjnm@usenet.INS.CWRU.Edu>
  10. Date: Fri, 11 Dec 1992 20:11:51 GMT
  11. Lines: 45
  12.  
  13. In article <1g842vINNjnm@usenet.INS.CWRU.Edu> gjm5@po.CWRU.Edu (Gregory J. Meyers) writes:
  14. >     I like NickServ.  It does fulfill a needed service, and it does it     
  15. >elegantly.  Perhaps bots like NickServ could be used to economize the IRC,
  16. >by watching the load on the system and suggesting improvements to the IRCops.
  17. >It could help to cut down on the number of netsplits.  With time it might
  18. >even be allowed to make those changes itself.
  19.  
  20. Oh, wonderful - now you're suggesting that an automated client handle
  21. things that require human intervention.  This sound really great for the
  22. IRC network.
  23.  
  24. >     I wouldn't call kicking bots a service; more of a challenge.  Those of
  25. >us who partake in warbot battles from time to time are striving to write the
  26. >best program to beat out all the others.  Code must be at a premium, for the
  27. >bot that is quickest on the draw is sure to win the battle.  And the program
  28. >has to be hardy, too, to cope with any situation rapidly.  It's all too easy
  29. >to trick most bots.  But writing a bot that can't be fooled takes hours and
  30. >hours of work, and then we get on a channel and try to see whose program is
  31. >the best.
  32.  
  33. I'm really disgusted with this kind of logic.  Can't you realize that some
  34. of us are _paying_ for network links, and you're sending hundreds of useless
  35. mode/kick commands over the net?  Don't you know that they are propogated
  36. _everywhere_?  Obviously you've never been a system administrator, and
  37. don't understand the damage this can really do.
  38.  
  39. >     I'm thinking of a sort of loose democracy.  The details are nowhere
  40. >clear in my mind yet, but definitely anyone should be allowed to vote.  Maybe
  41. >IRCops should be given more than one vote; maybe users who demonstrate their
  42. >competency on the subject should be given more votes.  Since we have to start
  43. >somewhere, I'd probably suggest that the admins decide how many votes people
  44. >get.  (Each user would have to apply individually to his admin; I'm sure a
  45. >lot of people just wouldn't bother so there shouldn't be an excessive number
  46. >for any admin to handle.)  And to provide yet another way for bots to be
  47. >useful, a VoteServ could be set up to do the tally.  In the end, the panel
  48. >of bot judges could be assembled, and they would then be given complete power
  49. >concerning whether bots live or die, and which ones.
  50.  
  51. You're forgetting one very important point.  IRC always has been and always
  52. will be an __Anarchy__.  You figure out the rest...
  53.  
  54. -- 
  55. Matt Mosley            <>    "Think for yourself, and feel the
  56. Digital Express Group        <>     walls..  become sand beneath your
  57. mattm@digex.com            <>     feet."   -  Queensryche
  58.