[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]>
