[00:54] <ubottu> nedbat called the ops in #ubuntu ()
[00:54] <rww> false alarm ^
=== Captain_h00k is now known as h00k
[06:00] <rww> lol i scared off a troll with my scariness
[06:00] <rww> rawr
[06:00] <elky> i like how he joined a channel of fake users to educate them about their fakeuserness
[06:01] <rww> elky: he's the Holden Caufield of IRC
[06:01] <rww> and equally tedious
[06:01] <elky> heh
[06:07] <Flannel> WWHCD?
[06:08] <Flannel> (He'd call everyone phony, that's what he'd do.)
[06:08] <valorie> and put on his people shooting hat
[06:08] <valorie> not unlike chanops
[06:08] <valorie> ;-)
[07:44] <DJones> IdleOne: 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 wide
[08:09] <bazhang> <alteregoa> i am looking for a ubuntu versio without systemd
[16:50] <bazhang> <alteregoa> darmok and jalad at tanagra
[17:12] <bazhang> * [IamSoSad] #ubuntu #freenode
[17:12] <Pici> maybe he wants to crosspost to #debian or something (hes not there, but whatever)
[17:56] <DJones> Possible troll .... sexappeal> how does one patch KDE2 under FreeBSD? (from #ubuntu)
[19:14] <Jordan_U> unopaste repeated itself in #ubuntu, http://pastebin.ubuntu.com/7412089/ (note that the +q is not repeated, but the message and -q both are).
[19:53] <tsimpson> it probably lagged
[19:54] <Jordan_U> Still, lag should not cause it to repeat itself like that.
[19:56] <rww> it would if the user said enough to trigger it twice
[19:56] <Jordan_U> I'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] <rww> so 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 changes
[19:57] <rww> how would you code around that?
[19:57] <tsimpson> if it sent both +q in the same message (/mode +qq host host) the server will combine them
[19:57] <Jordan_U> It depens on how the existing code is structured, but it's certainly not impossible if that's what you're implying.
[19:58] <rww> FloodBot did it by having multiple floodbots and doing lag detection between them, which was not exactly fun
[19:58] <rww> I'm not sure how else to do it in a way that will detect inter-server lag as well as client-server lag
[19:59] <tsimpson> it's not impossible to work around, but it's practically impossible with spaghetti^Wsupybot
[19:59] <rww> hehe
[20:03] <Jordan_U> rww: 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:04] <tsimpson> the trouble is when the state is not updated because of the lag
[20:06] <Jordan_U> Hence 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:09] <tsimpson> so it needs to add another layer of state, probably not simple to refactor