home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / alt / irc / 2554 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  4.4 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!jvnc.net!yale.edu!yale!gumby!destroyer!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!csus.edu!csusac!cindy!rat!polyslo.csc.calpoly.edu!asamonte
  2. From: asamonte@polyslo.csc.calpoly.edu (Just some loser...)
  3. Newsgroups: alt.irc
  4. Subject: Re: Useless Bots
  5. Keywords: significant words from a document used as an index to content
  6. Message-ID: <1992Jul28.010325.20634@rat.csc.calpoly.edu>
  7. Date: 28 Jul 92 01:03:25 GMT
  8. References: <1992Jul27.100632.2332@rat.csc.calpoly.edu> <Bs23Gt.FMo@news.cso.uiuc.edu>
  9. Organization: Nothing worth mentioning...
  10. Lines: 97
  11. Nntp-Posting-Host: polyslo.csc.calpoly.edu
  12.  
  13. StarWatcher@uiuc.edu was telling me...
  14. >asamonte@polyslo.csc.calpoly.edu (Just some loser...) writes:
  15. >: StarWatcher@uiuc.edu was telling me...
  16. >: >asamonte@polyslo.csc.calpoly.edu (Just some loser...) writes:
  17. >
  18.  
  19. It starts to look kinda pretty after a while...
  20.  
  21.  
  22. >[re op-bots:]
  23. >:I figure most of
  24. >:the people who are on #bondage like the security of the channel.  Other places
  25. >:I think not.  Still #bondage can be managed just fine w/o Monitor.
  26. >
  27. >Mebbie, but it wouldn't be the same channel if there wasn't some sort
  28. >of channel-keeper.  If invite/op bots were outlawed, there would probably
  29.  
  30. Hah...what a defense.
  31.  
  32. >be a few #bondage regulars who would incorporate monitor's features into
  33. >their own .ircrc's, and just stay logged in to irc all the time.  Then
  34. >what?  Would you start wanting them to be banned?  If that happens, we
  35. >ought to start banning all of the ops who stay logged in for 16-20 hours
  36. >a day, but are more often away than there.
  37.  
  38. Could be.  I never said that I was out to get them banned (the 'solution'
  39. I presented in the post you replied to was just  a counter to the other 
  40. argument...it wasn't indended to express my personal views)
  41.  
  42. >:>Is the idea of only opping certain people elitist?  Perhaps, depending
  43. >:>on who the bot recognizes.  I would have objections to a bot whose sole
  44. >:
  45. >:Haha, I love this.  Depending on who$the bot ops varys it's elitist state?
  46. >:Sounds like  'If It doesn't op me, it's elitist.'
  47. >
  48. >Isn't this just the perfect example of taking someone's comments out of
  49. >context?  :-)  Read on Fred....
  50. >
  51. >:>purpose in life is to /invite and op one particular person to a (or
  52. >:>a few) channel(s).  I don't see any problems with bots with invite/op
  53. >:>lists of 50-60 people for one "regular" channel, especially if the bot
  54. >:>is being updated fairly frequently, and if the human channel ops are
  55. >:>willing to let new people on channel fairly regularly.   The bots in between
  56. >:>*shrug* I haven't had to deal with them.
  57. >: 
  58. >:Your main argument for the robot is for invite purposes?  Then why doesn't
  59. >:it jsut do that instead of oping people?  What's the point there?
  60. >
  61. >Then the channel would not be a reasonably "open" one.  Is there a way
  62. >to code a bot to "invite all people except those who have been jerks
  63. >on this channel before, or who have harassed regular channel users
  64. >in /msg's under various nicks"?  That$kind of bot would< IMhO, be too
  65.  
  66. Yes, this is so easy, it's the same code that does the invite and op
  67. 'special people'  
  68.  
  69. Brief summary.  
  70. /msg bot invite 
  71. <bot checks user@host of msger>
  72. if msger !mean_nasty_person user@host then invite.
  73.  
  74.  
  75. I have such code in my C robot, it likes some people, is indifferent to
  76. others, and dislikes others...
  77.  
  78.  
  79. >cumbersome to write and maintain to be practical.  And what happens
  80.  
  81. Just as cumbersome to maintain a list of 'trusted' people.
  82.  
  83. >when the bot's home mainframe dies unexpectedly?  You are left with
  84. >a channel with no ops, necessitating the channel-hopping two-step to
  85. >get an op, or an inability for the bot to get back on channel when its
  86. >home machine comes back up.
  87.  
  88. Oh my! work for users?  change channels for a second?  What torture!
  89. <insert extreme sarcasm here>
  90.  
  91. >
  92. >:>Of course, there is the obvious solution for people who have problems
  93. >:>with the attitudes of the op-bot or of the towers-that-be for a given
  94. >:>channel:  Tough!  If you don't like it, go form your own channel.
  95. >:>Yes, it sounds like a harsh answer, but it should be an obvious one.
  96. >: 
  97. >: There is also another obvious solution who have problems with
  98. >: op bots (just a valid as yours) get rid of them all.
  99. >
  100. >But which suggestion can be implemented easier and more practicly?  :-)
  101.  
  102. Too true...my personal view isn't to kill them all...too much effort.
  103. I just would rather discourage people from making them.
  104.  
  105.  
  106. -Alex
  107.  
  108. -- 
  109. ---King Claudius---                                   claudius@zeus.calpoly.edu
  110.