[IRCServices] Desperate Problems

[Andrew Church]

<rant>

     Permit me to offer _my_ years of experience and point out that network
and server maintenance is completely meaningless without users.  This is
just as true of IRC as of the Internet in general; when was the last time
you talked to someone maintaining a gopher server, for example?  This is
what we in the field technically refer to as "being too literal".
Example:

     If you read RFC 1459, scripting isn't even mentioned, whereas the
duties of an IRCop are; in such duties are network/server maintenance.
So by standard, choosing to keep a network tool like StatServ would be
more helpful to the oper than worrying about whether or not a few users
get flooded by clonebots.

     (Note that StatServ and {nick protection, scripting} are entirely
orthogonal, except to the extent that nick protection and StatServ run in
the same process; and of course, if StatServ crashes then StatServ can't
continue working as a network tool, which makes this a non-solution to
start with.)

     Of course, this is completely irrelevent to the original question,
which was not "I'm going to pick one of these two things to get rid of,
which one should I choose".  The original question was "Having StatServ
enabled causes Services to crash, how can I make it stop crashing?"
Saying "Leave StatServ enabled and let the users deal with Services
crashing" does not answer that question.

</rant>

  --Andrew Church
    achurch at dragonfire.net
    http://achurch.dragonfire.net/

>I was suggesting a lesser of two evils. Services is in no way required for 
>network maintenance, so asking me to decide which is more helpful, is 
>totally irrelevant.
>
>A good set of opers and a RFC compliant IRCd will have all the tools needed 
>for the task. Please remember that IRC was conceived without services and 
>the oldest net still runs without them.
>
>I'm not one to get into a heated debate over my opinion.
>
>If you read RFC 1459, services isn't even mentioned. Where as the duties of 
>an IRCop are, in such duties are network/server maintenance. So by 
>standard, choosing to keep a network tool like StatServ would be more 
>helpful to the oper than worrying about whether or not a few nicks get 
>changed/killed.
>
>Whatever you decide is of course your choice alone, I'm just here to help 
>by offering my years of experience.
>
>I do trust that these problems will be handled in the near future. In the 
>short time I have known Andrew, he has always been good about fixing 
>problems in a timely manner.
>
></rant>
>
>
>Scott Seufert
>aka katsklaw
>Server Admin
>Excalibre.ShadowFire.Org
>
>
><snip>
>
>> > This creates an inconvenience for the user, but keeps the network 
>> stable(The
>> > IRCop's prime duty, IAW RFC1459).
>>
>>Umm not having services and having services... u decide which is more 
>>helpful in keeping the network up and running
>>properly. Keep in mind the 22% cpu usage, having to restart services on 
>>the server, and that guesting will only cause
>>confusion, and nothing else. IMHO both should be removed on a temporary 
>>basis until the issues are resolved.
>>
>> > Scott Seufert
>> > aka katsklaw
>> > Server Admin
>> > Excalibre.ShadowFire.Org
>>
>>Imran Ali Rashid
>>Server Admin of a small tiny, two servers linked across a modem irc 
>>network. Converting the modem link to lan in about a
>>week, so splits issue should be non-existant.
>>irc.giki.edu.pk
>>
>>
>>---------------------------------------------------------------
>>To unsubscribe, send email to majordomo at ender.shadowfire.org
>>with "unsubscribe ircservices" in the body, without the quotes.
>
>
>---------------------------------------------------------------
>To unsubscribe, send email to majordomo at ender.shadowfire.org
>with "unsubscribe ircservices" in the body, without the quotes.

---------------------------------------------------------------
To unsubscribe, send email to majordomo at ender.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.