stoney`
At 06:48 PM 10/23/2002 -0400, you wrote:
[user-com snipped from the cc-list--I'm only covering the coder-com side
of things here]
> Quite a few users I know see the new host hiding option as a loss of
> accountability, since no detailed information demarcating what
> [EMAIL PROTECTED] can/will and can't/won't do.
>
> In my situation, as one of the ops in #usa (which tends to have 200-350 use
> rs during any part of the day), the host-hiding option further stresses what
> I consider to be a far too small banlist size even further; just the simple a
> ddition of this 'v-host on the cheap' means more bans added to our pending li
> st of bans, and more bans set in such a channel.
FYI, we have increased the ban count to 45 in the upcoming .03 release,
and we are considering making it proportional to the count (or perhaps
recent count) of users on a given channel.
> I know I'm calling someone's baby ugly, but this feature didn't have the lo
> gistical/social side of the equation as well thought out before it was enacte
> d.
Host hiding has been in the works for a long time; the chief objection
was in fact the accountability issue. This problem was "solved" by the
addition of the ACCOUNT feature--accountability can now still be provided,
at least in terms of the network administrators. Of course it's not
perfect, but it's something we unfortunately need to provide these days.
> So, rather than being entirely negative about the feature, I will suggest a
> few things that can improve/avert rough spots:
Thank you! :)
> The Channel ban list size needs an increase, in some way -- the simple solu
> tion would be to simply increase the list size allowed up from 30 (easy for c
> oders, it's a config change, but a pain for admins - it's a server reboot).
Actually, it does not involve a reboot; addition of an F-line is sufficient.
As I stated above, we've increased the limit to 45 for now.
> I'd like to discuss a few other alternatives I have in mind becuase I
> believe strongly that a change IS needed for the better.
We'd love to hear the ideas.
> But before I do, it'd be best to get input from the coders and/or admins th
> at have profiled servers recently to see what the current situation is, and h
> ow proposed banlist changes would affect things, pro and con. There's not muc
> h sense in proposing fanciful ideas that either tax ram, and/or bandwidth, an
> d/or cpu excessively over the current state, unless there's a genuine improve
> ment.
One recent statistic I ran suggested that the average number of bans per
channel was quite low--perhaps around 8. I think I also tried to correlate
number of bans with size of channel, but I don't happen to recall those
statistics, and I probably need a more careful statistics generator...and
probably an email here :) One thing I was curious about was conclusively
answered by my statistics run--the average text length of a ban is indeed
just below 40, which is where it's set. (Bans are limited both by number
and by total length--the limit is MAXBANS * AVBANLEN.)
As I mentioned above, I have considered the idea of making the length of
the ban list proportional to the recent numerical size of the channel.
One problem is how to define "recent"--should it be the instantaneous size
of the channel? That could prevent you from adding a ban if there was a
split. How about the maximal count over time? Someone could then join a
couple hundred vhosted clones so they could add 70 bans in an attempt to
use up memory--though it's not clear to me that that's a real worry.
It'd be nice to have a brainstorming session over how to calculate the
"recent" numerical size of a channel and what the proportionality should
be--should it be linear? Quadratic? Advantages? Disadvantages?
--
Kevin L. Mitchell <[EMAIL PROTECTED]>
Py Fivestones [EMAIL PROTECTED]
