/srv/irclogs.ubuntu.com/2014/05/07/#ubuntu-ops.txt

ubottunedbat called the ops in #ubuntu ()00:54
rwwfalse alarm ^00:54
=== Captain_h00k is now known as h00k
rwwlol i scared off a troll with my scariness06:00
rwwrawr06:00
elkyi like how he joined a channel of fake users to educate them about their fakeuserness06:00
rwwelky: he's the Holden Caufield of IRC06:01
rwwand equally tedious06:01
elkyheh06:01
FlannelWWHCD?06:07
Flannel(He'd call everyone phony, that's what he'd do.)06:08
valorieand put on his people shooting hat06:08
valorienot unlike chanops06:08
valorie;-)06:08
DJonesIdleOne: Pici: It wasn't something I set deliberatly, I set a +q as /mode +q *!*@*38.116.192* to stop multiple web gateway users with slightly different ip's trolling, when it was set, for some reason it went as +qi rather than just +q But I thought that was just something automatic for that hostname and not channel wide07:44
bazhang<alteregoa> i am looking for a ubuntu versio without systemd08:09
bazhang<alteregoa> darmok and jalad at tanagra16:50
bazhang* [IamSoSad] #ubuntu #freenode17:12
Picimaybe he wants to crosspost to #debian or something (hes not there, but whatever)17:12
DJonesPossible troll .... sexappeal> how does one patch KDE2 under FreeBSD? (from #ubuntu)17:56
Jordan_Uunopaste repeated itself in #ubuntu, http://pastebin.ubuntu.com/7412089/ (note that the +q is not repeated, but the message and -q both are).19:14
tsimpsonit probably lagged19:53
Jordan_UStill, lag should not cause it to repeat itself like that.19:54
rwwit would if the user said enough to trigger it twice19:56
Jordan_UI'm not saying that isn't what caused it, I think it probably is. I'm saying that lag *shouldn't* cause that to happen.19:56
rwwso it issued a +q and message after one time, then did it again. you only saw one +q because the ircd silently ignores duplicate list mode changes19:56
rwwhow would you code around that?19:57
tsimpsonif it sent both +q in the same message (/mode +qq host host) the server will combine them19:57
Jordan_UIt depens on how the existing code is structured, but it's certainly not impossible if that's what you're implying.19:57
rwwFloodBot did it by having multiple floodbots and doing lag detection between them, which was not exactly fun19:58
rwwI'm not sure how else to do it in a way that will detect inter-server lag as well as client-server lag19:58
tsimpsonit's not impossible to work around, but it's practically impossible with spaghetti^Wsupybot19:59
rwwhehe19:59
Jordan_Urww: I would think of it less as detecting lag and more as preventing redundant operations. If you've already tried to quiet someone, don't try to quiet them again (unless of course they've since been unquieted). Only send a message to a user after quieting them. Don't try to unquiet someone if you've already tried to unquiet them, etc.20:03
tsimpsonthe trouble is when the state is not updated because of the lag20:04
Jordan_UHence why I talked about "don't quiet if you've already tried to quiet" rather than "don't try to quiet if they're already +q", but I'm not planning to look at the actual code, so meh :)20:06
tsimpsonso it needs to add another layer of state, probably not simple to refactor20:09

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!