=== Fujitsu [n=fujitsu@ubuntu/member/fujitsu] has joined #ubuntu-ops
=== Fujitsu [n=fujitsu@ubuntu/member/fujitsu] has joined #ubuntu-ops
LjLgnomefreak Amaranth nalioth, around?01:40
LjLnalioth: well the others will see later, hopefully. amaranth has a valid point i think: will the traffic created by redirecting upgrade questions to #ubuntu+1 overwhelm the traffic that is saved by it? i'm not sure i can answer, and this is a concern.01:45
LjLthe other point is, the users will be confused and not know where to go. is it that much more confusing than, say, effects in -effects? "if it's something that happened while trying to upgrade, or if you just want to know how to upgrade, it's #ubuntu+1"01:45
naliothfor every upgrader, they'll have to be told where to go, and possible helped there 01:45
=== fdoving [n=frode@edge.lnix.net] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v fdoving] by ChanServ
naliother, possibly helped in #ubuntu to get to #ubuntu+1 01:46
naliothwe are not dealing with internet (or computer) savvy people01:46
Seeker`is there a limit to the number of peope in a channel?01:46
naliothwe need to keep the 'new stuff' to a minimum01:46
LjLnalioth: yes, that is true, but it's one message ("join #ubuntu+1 please") compared to, in many cases, a long exchange01:46
nalioththey auto join #ubuntu and expect help there, not to be told to do something they may have never heard of01:46
Seeker`and would it be sensible to have a #ubuntu-upgrading instead01:47
naliothLjL: but what if they don't know how to /j #ubuntu+1 ?01:47
LjLSeeker`: that's exactly what i'm proposing to use #ubuntu+1 for01:47
LjLnalioth: you tell them: type /join #ubuntu+1. as we already do with a good 50% of them01:47
Seeker`LjL: I was thiking that the rename may make it simpler01:47
PriceChildI'd assume people that have been using feisty and want to upgrade to gutsy are relatively computer savvy.01:47
LjLSeeker`: i doubt that's really the issue01:47
Seeker`what is the issue then?01:48
LjLPriceChild: you assume a lot. they have a point here. but... i still think it would lighten the traffic in #ubuntu by a perceivable amount. and it's just a matter of telling users where to go - maybe they don't know, but once you tell them, it's not rocket sience01:48
LjLSeeker`: the issue is fear that a split would confuse the users, and that we'd waste more characters in telling them to join the right channel rather than just helping them in #ubuntu01:49
PriceChildIf people have problems upgrading... its 9 times out of 10 going to require more than a one line solution.01:49
PriceChildI'm pretty sure they'd relish the chance of a quieter channel01:49
LjLnalioth: anyway the problem is this. do you remember last release? i assume so. face it, the channel was unusable for everyone for a while. unusable. so, maybe my idea isn't the best possible, but what else?01:50
Seeker`LjL: The reason I suggested a rename is because it is relatively obvious what -upgrading would be for, whereas +1 is less so01:50
LjLSeeker`, people wouldn't *look* for the right channel anyway, you'd always have to *tell* them. so what difference does the name make?01:50
LjLSeeker`: "type /join ubuntu+1 for help with upgrading". "type /join #ubuntu-upgrading for help with upgrading".01:51
Seeker`LjL: fair enough01:51
LjLSeeker`: the issue here is whether to make the split or not make it, the channel name doesn't really much matter. we already have #ubuntu+1, people using gutsy are already there, so it's handy01:51
LjLSeeker`: and it also solves the problem of everyone in +1 moaning that the channel gets closed (they always do)01:52
Seeker`LjL: in that case, I reckon a split is a good idea01:52
LjLi'm not proposing to make it longer than say a week01:53
LjLbut somehow we need to keep #ubuntu manageable. or we may as well set +i and avoid giving users the *illusion* that they may get some support01:53
ubotuThere are many different channel and user modes on Freenode (see !freenode). Here's a list: http://freenode.net/using_the_network.shtml01:53
LjLnow, maybe nobody will care about Gutsy like they did about Feisty, and the channel won't have a spike at all :)01:54
LjLbut i'm assuming it will.01:54
Seeker`Its better to plan and it not explode, than have a huge spike and be unprepared01:54
=== Seeker` wonders if someone will be able to answer his suspend problem after launch
LjLthat's what i'm trying to do, and while i do realize that splitting and using +1 for upgrades isn't optimal, i just can't think of another sane way to handle it01:55
Seeker`I ask periodically in +1, but never get a response01:55
LjLSeeker`: you'll never get suspend to ram working, get on with life.01:56
Seeker`LjL: well, it works to an extent, but when it resumes it logs me off01:56
LjLSeeker`: then consider yourself lucky.01:56
Seeker`LjL: Unless there is something I dont know about IRC channels, splitting is the only sensible way of keeping the number of users manageable01:56
LjLSeeker`: it does also have serious drawbacks01:57
naliothif we're gonna split it, don't split it into #ubuntu+101:57
LjLwhen a permanent split of #ubuntu was proposed, i opposed it completely.01:57
LjLnalioth: then what?01:57
Seeker`but do the drawbacks outweigh > 1600 people trying to ask questions at the same time?01:57
nalioth#ubuntu-upgrading or w/e01:58
LjLSeeker`: that's what i'm thinking. for the next couple of weeks, i think not01:58
=== Seeker` agrees
nalioth #ubuntu+1 needs to stay for 'the next version'01:58
LjLnalioth: uh again, but what difference does it make? i mean, since it doesn't make any difference, it's ok with me but...01:58
naliothi'd prefer to just use #ubuntu 01:58
naliothyou guys are the one talking of splitting and such01:59
LjLnalioth: we don't *have* to split. i've proposed it. there have been at least three negative reactions to that, on the ML.01:59
LjLnalioth: taking those into account, i'd retract my proposal. but i'm still concerned about the non-manageability of #ubuntu... so i'd like to either convince you that splitting is a good idea, or find a better idea02:00
LjLif i fail to do both, then #ubuntu it is02:00
LjLbut for heaven's sake i don't want to even hear anyone saying "#ubuntu is too much of a mess, we need to create many separate channels! #ubuntu-networking! #ubuntu-video! load balance, #ubuntu1 #ubuntu2 #ubuntu3!"02:01
bbrazildon't forget DR instances on other networks to be safe :)02:02
LjLi.e. if if people start pushing for a *permanent* splitting in order to avoid a *temporary* one, then i'll strangle them.02:02
naliothLjL: no, any splits would be temporary.  Closing #ubuntu-upgrading at the same time #ubuntu+1 reopened perhaps02:03
LjLnalioth: ok i still don't see why just using #ubuntu+1 wouldn't cut it... there's already people in there who are already using gutsy and who always dislike having to leave the channel... i think using #ubuntu+1 rather than something else would solve *one more* problem02:04
LjLbut who cares, if you prefer to have #ubuntu-upgrading, then fine, but the issue is that you don't prefer either thing02:04
LjL(neither do gnomefreak and amaranth so if i have to take that as a sample, i'd have to say nobody likes the idea)02:05
=== Madpilot [n=brian@ubuntu/member/madpilot] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v Madpilot] by ChanServ
robI haven't read everything above, but I think we should forward #ubuntu+1 to #ubuntu on release day and deal with it02:08
robno need for a permanent split imo :)02:09
Seeker`rob: I think everyone is against a permanent split02:09
naliothyou see, if you start sending folks to +1 for upgrading, they'll continue to go there after it switches over to hardy beta talk02:10
robwe will get a lot of questions obviously which will mean we will have to keep on our toes. +m may need to be used occasionally and if we have too we could have a temp overflow to #ubuntu+102:10
Seeker`hmm, maybe there should be an irc entrance exam - that way people will read topics etc, and this would be much less of a problem :P02:11
robor a new channel, like #ubuntu-2 :) whatever..02:11
robhow long have we got to go until the release?02:11
mc44day and a bit02:11
naliothrob: 18th is the day02:11
robso ~ 30 hrs02:12
=== Madpilot prepares a large rock to hide under in 28hrs
mc44more like 36 ish :)02:12
Seeker`rob: I'd say more like 3602:12
mc44usually about midday utc02:12
Seeker`mc44: have there been enough releases for a "usually"?02:12
PriceChild<seciboi4u> in #ubuntu-offtopic is about to earn a ban I think...02:13
robthat means about 8pm my time tomorrow02:13
robI will be here :)02:13
Seeker`rob: East coast USA?02:13
robSeeker`, no, Australia02:14
LjLrob, read the mailing list rather than reading everything above02:14
robI'm +10, so midday utc = 8pm my time02:14
Seeker`12 + 10 != 2002:14
robhmm I didn't get a mailing list02:15
roberr mail on the mailing list, actually I don't think I am subscribed yet02:15
Vorianwoah PriceChild! 02:15
LjLrob: https://lists.ubuntu.com/archives/ubuntu-irc/2007-October/thread.html02:15
Vorianthat's crazy02:15
robSeeker`, 10am my time is midnight utc. +10 hours on that makes it 8pm02:15
mc44PriceChild: wait Carmony resigned?02:16
mc44Clearly I don't read enough /,02:16
Seeker`PriceChild: Looks like that topic may require a bit of moderation02:16
PriceChildonly read the first post02:16
=== rob reads
Seeker`rob: midnight utc + 10 hours = 10am utc02:17
rob8pm my time.02:17
=== Seeker` gives up
rob= 10am utc02:18
mneptokrob: i thought you were in the US?02:18
robmneptok, nope, Aussie born and bred02:18
robSeeker`, trust me, I convert timezones for a job :)02:18
Seeker`rob: its this comment that got me: rob+: I'm +10, so midday utc = 8pm my time02:19
=== Seeker` thinks he broke the room
robutc 0001 = 10am my time. Midday utc (10am + 12hours) = 10pm my time. I was wrong by two hours, but yes, close enough :)02:22
=== Seeker` just wanted to know he wasn't going insane :)
mneptok+12 hours?02:23
rob12 hours from midnight is midday02:23
Seeker`mneptok: midnight + 12 hours is midday, so 10am + 12 hours is 10pm02:23
mneptokhe is +1002:23
=== LjL is starting to feel a headache
robmy timezone is +10, so midnight + 10 hours is when utc midnight falls my time02:24
mneptokif it's 12 noon UTC, it's 10pm in eastern .au02:24
Seeker`mneptok: thats what we just worked out :)02:24
roberr yup02:24
mneptok+10. just add ten hours. this isn't rocket science. :)02:24
Seeker`mneptok: you'd think so, wouldn't you :P However, it being 1:30am, and me having had 2 bottles of cider, it gets quite a bit more difficult02:25
Seeker`for me anyway02:25
mneptokthis is where rob tells us he's in Perth and we kill him02:25
robdam it I want to play ETQW but after going though synaptic I have an hour of downloading to go..02:25
robmneptok, heck no, Brisbane :)02:26
robI went down to Surfers the other day, bloody mayhem and the racing hasn't even started. Got to look at some sweet indy cars close up though.02:26
mneptokdamned right. you stay in that +10 Syd/Melb/Bris/Canb tz02:27
Seeker`how many ops are from GB?02:29
PriceChildseciboi4u pm'd me earlier, asking asl and everything02:29
Seeker`PriceChild: oooh, someone likes you ;)02:30
PriceChildSeeker`, me, davi, me.z, pop.ey, i think02:30
robwow, a little bit of overkill maybe LjL for release..02:30
PriceChildhe's in -offtopic02:30
Seeker`PriceChild: how many that aren't just -uk ops?02:30
LjLrob, do you not remember the days after feisty or edgy release?02:30
PriceChildSeeker`, me and me.z i assume02:31
Seeker`PriceChild: cool02:31
robLjL, did you see what happen on I think efnet during 911? That was mayhem :)02:31
PriceChildSeeker`, probably missing one or two... st.din i think02:31
LjLrob: this is not efnet... and #ubuntu is a support channel. i'd like to be able to keep giving real support02:31
LjLrob: and i was on ircnet during 911 :)02:31
LjLi remember that the server i was connected to went down, since it was right in the wtc, but i could connect from another server, although i had more than 5 minutes of lags02:32
=== Seeker` was standing at a bus stop when the towers went down
LjLrob: and aside from the +1 split, there's nothing i think particularly huge that i say in that mail. we've had +J during "normal" times before, kick-as-warning is something we've often encouraged...02:34
LjLsure, splitting is big, but then again having 2000 users of which 500 speaking in a channel is "big" too02:34
robLjL, just saying.. My take on it is that a second channel should be set up and once it gets to hectic we should forward people to it, splitting the channel up some but only temporarily until it dies down a bit. The channel should not be #ubuntu+1 or any existing channel, just a channel we can easily set up and forward once the release is over back to #ubuntu. In addition to that join throttling will be needed and I will personally be running a script to02:35
rob watch out for common things like dcc sends and taking action against them pretty quickly (I will be personally monitoring it the whole time), Yes +J is needed just like it is needed at all times.02:35
Seeker`rob: sounds sensible02:35
PriceChildrob, we tried +J a while ago but it fails badly in server deaths iirc02:36
robthe #ubuntu+1 channel should be forwarded back to #ubuntu until hardy has people using it02:36
LjLrob, i fear that "until it dies down a bit" means without interruption for a week at least. but ok, the concept is sound.02:36
PriceChildwhich is why we didn't use it much after02:36
robmy suggestion about +J and also flooding, maybe consider running debian's bot, it handles both pretty well02:37
Seeker`are we actually at risk of hitting a server limit, or is it just making the channel unusable due to the sheer number of msgs?02:37
PriceChildSeeker`, the latter02:37
LjLrob: nalioth said that to me too. i don't know, i'm not familiar with it, honestly i thought +J, being a freenode-wide solution, would tend to be a better solution. but as long as it works02:37
robnot going to hit a server limit, the latter02:37
robLjL, the Debian bot dynamically sets +J as needed02:38
LjLrob: define "as needed"02:38
LjLdoesn't it set +l?02:38
robalso, something to kick/remove pasters would be nice too02:38
LjL(or whatever it is that limits the total number of users)02:38
LjLrob, heh, that's an old one :)02:38
robLjL, +J to iirc02:39
LjLwe never did that for one reason or another02:39
robI think last time I was manually messing with +J a bit02:39
LjLrob: i'm not sure how it would know when to set +J... i mean, how can you know until the bots come?02:39
robLjL, it is hard to second guess bots, don't rely on +J alone02:40
PriceChildI always thought we never liked the idea of "bots with ops"?02:40
naliothrob: the debian bot doesn't do +J, it does +L02:40
robnalioth, ah ok02:40
naliother, whatever 'channel user limit" is02:40
LjLPriceChild: that's one point. the other point is that stuff like that needs to be tested. sure, it's tested in #debian, but do we have the time to take it and deploy it in a safe manner?02:40
naliothrob: it keeps it 10 or 20 above the current user base02:40
Seeker`i thought +J was meant to be there to stop floods happening - isn't setting +J reactively is effectively just closing the channel when it hits the limit (ie doing +J semi-manually)02:40
robhowever +J and +L are unlikely to give you proper decent protection against most botnets anyway02:41
LjLrob, +J worked nicely when we used it... except for the server death problem02:41
nalioth+L will stop a 10+ clone swarm join attack02:41
LjLrob: having 5 bots join is something *very* different from having 50 bots join02:41
LjLfor starters, 5 bots can't cause people to excess flood02:41
LjL50 can02:41
LjLand do02:41
robwell, personally if I were running a bot net I'd have them join a few at a time anyway then launch the attack :)02:42
LjLrob: they did that once, yes02:42
robI even wrote a script that would do it like that in a moment of boredom02:42
LjLor twice02:42
=== Seeker` suggests that the other ops keep an eye on rob :P
LjL /kb rob02:42
=== Vorian [n=Steve@ubuntu/member/pdpc.supporter.active.Vorian] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v Vorian] by ChanServ
naliothrob: but neither +J or +L will stop the slow join attacks02:42
Seeker`you're giving them ideas now02:42
robnalioth, my point exactly02:43
Seeker`nalioth: will anything stop slow join attacks?02:43
naliothSeeker`: not much02:43
LjLrob: but - although i've never been attentive enough to spot it myself - other ops *have* been able to see that there were "too many users" and set +R in advance02:43
robthus +JL does not give you all that great of protection, you might just slow them down02:43
nalioththe point of +J or +L is to stop the kiddies who use the mass-clone-swarm-join attack02:43
Seeker`hmm - do bot nets generally send the same message at the same time?02:43
robso just set +J manually as needed, it shouldn't have to be altered all that often02:44
=== Daviey suggests monitoring multiple joins from 1 IP... I expect few malicious flooders will bother using multiple boxes
Seeker`hmm, you could implement a script to watch for multiple users saying the same thing within x seconds, if the number of users is > x, kick them02:44
robas for +L, it could be used on a temporary basis if a sustained attack happens02:45
LjLSeeker`: we could implement many things, but 1) we don't have time 2) there are countless arguments against doing that sort of thing02:45
LjLwe've gone over and over such arguments many times, it's pointless to bring them up now - we just don't have the time either way02:46
robSeeker`, its called a flood protection script, I had an idea that would expand on that which would do if ANY user repeats the same text more then x times in x seconds, kick everyone who says the same line of text thereafter02:46
robbecause, often botnets flood the same line over and over again :)02:47
Seeker`rob: I thought that most scripts only caught user a repeating line b, not multiple users and the smae line02:47
PiciTheres some flood detection stuff built into irssi, but nothing hooks into the events by default.02:47
LjLDaviey, botnets usually come from several IPs. but yes, that's a clone detection script.02:47
robSeeker`, exactly, my script is better :)02:47
LjLbut really now... talking about "smart" scripts is pointless, they have their merits, but we just can't implement any for release time, not to mention *agreeing* on using them02:48
robSeeker`, oh and for a slightly different purpose02:48
Seeker`i'll probably get shot down for suggesting this, as its obvious, but would some sort of planning session further in advance of hardy be a good idea?02:48
robLjL, of cause, but that doesn't mean one can't discuss them at all02:49
robSeeker`, I think that's what people are trying to do but it is hard to get everyone together when we are all over the world02:49
Seeker`rob: agreed-  I meant more than 24 hours in advance of launch though02:50
roboh, LjL, and I already have some of these scripts that I mention02:50
Davieyrob: and thats why regular irc council meetings and ML discussions should be conducted :D02:50
LjLrob: no, i'd just like that everyone kept in mind that we have to deal with an immediate spike of users in #ubuntu, though, rather than devising new/old ways to detect clones and bots02:50
LjLrob, using them won't get approved. i could approve it, i don't know, i'd have to know what they do exactly and how, but i assure you that, aside from me, they wouldn't get approved in time. perhaps after a(nother) *long* discussion about it.02:51
robLjL, sure, but +J and +L are not going to prevent attacks, only potentially take some steam out of the dumber ones02:51
Seeker`rob: but you cant prevent attacks, only react02:52
Seeker`and whatever system is implemented will have holes02:52
=== Dave2 [i=dave@freenode/staff/dave2] has left #ubuntu-ops ["FIXING]
=== Dave2 [i=dave@freenode/staff/dave2] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v Dave2] by ChanServ
LjLrob, +J has been *very* effective, seriously. it just has problems. sure, bots could join slowly, but most of them don't -- and if they do, you have a chance of spotting them before they start flooding, anyway02:52
robmy thought is +J is going to have to be set slightly higher then normal just due to the normal traffic we are going to have to contend with anyway, so +J starts getting less useful when you do that02:53
Seeker`J controls join rate, not total?02:54
LjLrob, as long as you can keep the number of bots that can join at a time below 10, i think it's still quite useful. how many CTCP VERSIONs does it take to flood out the average xchat user?02:55
LjLSeeker`: the former.02:55
Seeker`so what is the highest number of users you would want to join in, say, 10 seconds?02:56
Seeker`or am I looking at it too simplistically?02:57
naliothFor tips and information on channel and user modes and management, see http://freenode.net/using_the_network.shtml Seeker` 02:57
Seeker`nalioth: Just read that, but I didn't know if there was a reason why someone couldn't just say roughly x users in y seconds02:58
naliothSeeker`: that is how +J works02:58
nalioth  /mode #channel +J 2,1002:59
naliothor whatever02:59
Seeker`nalioth: yeah, but why hasn't someone suggested a figure like that?02:59
naliothSeeker`: it has been used before and is being discussed now02:59
LjLSeeker`: because it depends on the channel.03:00
LjLi have suggested 2,503:00
LjLbut i don't really know03:00
LjLit worked well last time, but last time wasn't release time03:00
Seeker`i cant imagine you will get a huge rush of people joining, even if it is release03:00
Seeker`last release seemed to be a fairly gradual curve up to 160003:00
LjLSeeker`: i'm sorry i can't dig up the stats of the feisty release for you, as my logs are a mess, but i do beg to differ03:01
LjLfairly gradual like in 6 hours, yeah03:01
LjLand then it kept steady for quite a while03:01
robguys, take a look at http://stoffers.id.au/dancer/03:01
robmainly the channel mode section :)03:01
Seeker`yeah, but what I mean is that is wasn't like at midday, 300 people joined03:02
Seeker`so something like ~5 users in 10 seconds sounds reasonably justified03:02
LjLSeeker`: i think we all agree. possibly even less.03:02
LjLSeeker`: but keep in mind that 1600 people doesn't mean the *same* 1600 people all the time... a lot of people join, and a lot of people part03:03
LjLbut a reasonable +J setting doesn't stop being reasonable, no03:03
robdepends :) Just come up with something you think as reasonable and adjust it as needed on the fly.03:04
Seeker`how does this sound: set it to something like 2,5, redirect overflow to a channl with a topic explaining that the channel is overcrowded and to try again soon. If the channel starts getting huge, alter the limit03:04
LjLSeeker`: join #ubuntu-unregged.03:05
LjLit's exactly what we used to do.03:05
Seeker`was there a problem with that method?03:05
LjLand -unregged never got huge, for the record - quite the contrary03:05
LjLSeeker`: yes. on server deaths, +J causes terrible problems.03:05
LjLit's a rare event, but when it happens it's apparently a nightmare03:06
LjLthat's the only real problem03:06
Seeker`beecause everyone tries to rejoin?03:06
robhopefully server deaths won't happen :)03:06
LjLrob: that's what i say, but pessimism reigns :)03:06
Seeker`a) what is the likely hood that all ops will be on the same server03:06
Seeker`b) how quickly can someone -J?03:06
robLjL, a netsplit is an example of a time where you might want to alter or remove +J completely for a bit03:07
LjLSeeker`: a) zero, but does it matter? b) not quick enough03:07
LjLrob, it seemed that netsplits were handled well actually, it was only netsplits caused by servers going down that were a problem...03:07
Seeker`if a server dies properly, surely you are talking up to a min before people start rejoinig?03:08
LjLSeeker`, honestly, i've never experienced that.03:08
LjLi'd have kept +J if it had been for me03:08
LjLbut it was removed because of that issue.03:08
Seeker`because it wont go "ooh, netsplit, lets try again", the client will just have no more connection, so it has to time out before it will retry03:09
LjLSeeker`: if the server gives a FIN, then clients will immediately try to reconnect to another server03:09
LjLbut really i don't know about the details. i'm just telling you that +J was voted down at some stage, because that was felt to be a problem.03:10
=== Seeker` nods, "I'm no expert"
LjLall i'm saying is: what is the likelyhood of a bad server crash during the week after release? murphy's law would say "high", but rationality says "low enough".03:11
LjLso, *temporarily*, +J should be fine. permanently, that's another matter, but not one i'm concerned about right now03:11
=== Seeker` agrees, "the chances of a mass-join bot attack are much higer than the risk of a bad crash"
mneptoki just had a mass-join bot attack ...03:12
mneptok... in my pants.03:12
Seeker`mneptok: you fail :P03:12
LjLand a good bot attack can cause probably somewhere around 200 clients to disconnect (taking the increased number of users into account), which is bad enough03:12
Seeker`do the attacks usually rely on making the clients send so much data that the server kicks them?03:13
LjLSeeker`: they do.03:13
Davieydisconnect... then immedietly reconnect - circle continues03:13
Seeker`someone should write a server to stop that :P03:13
Seeker`any volunteers?03:13
LjLSeeker`: not very feasible... it should be the *client's* task to avoid flooding out03:14
robSeeker`, the problem is it starts to impact on freedom of speech and privacy when the ircd starts trying to filter things03:14
LjLbut most clients aren't, uhm, very good at that03:14
Seeker`that was more of a joke than a real suggestion03:14
robSeeker`, trust me Freenode has discussed it at great length :)03:14
LjLrob: although the suggestion to have some mode, let's call it +C, to stop people from CTCP'ing the channel sounds reasonable to me. we have a similar mode for users.03:15
robLjL, problem with that is /me is a CTCP.03:15
LjLrob: surely one that can be told apart by the server03:15
Seeker`rob: It may be in the standard to allow CTCP to many users frequently, but in reality, the chances of it being used on a big server like freenode for a "legitimate" purpose is pretty low03:15
robagain, filtering, it also would put a lot of stress on the servers.03:15
LjLrob: true.03:16
LjLrob: really, if only irc clients wouldn't be so dumb, it would be a non-issue03:16
robLjL, yep.03:16
LjLrob: xchat just happily replies to the CTCPs, and excess floods03:16
=== Seeker` wonders what irssi does by default
robLjL, one way to protect yourself from it is to disable automatic replying to ctcp, its what I have done03:17
LjLrob: my konversation manages to avoid the excess flood, but still it doesn't give *my own* messages priority over the CTCP replies, so i'm blocked from doing anything03:17
LjLrob: yes, i've been thinking of doing that03:17
LjLSeeker`: floods.03:17
Seeker`any nice ways to stop it?03:17
LjLSeeker`: most likely... irssi can be scripted in about every thinkable way03:18
robin xchat, blank out all the automatic replies in the CTCP dialog and set irc_hide_version to 103:18
LjLrob, i'm afraid there's nothing to disable CTCP replies in konversation (i could perhaps /ignore them, but then i wouldn't see them coming anymore). there's the freenode umode, though03:19
robin xchat there is also flood_ctcp_num and flood_ctcp_time you can fiddle with03:19
LjLand anyway, i'm running on a proxy now. it's a terrible proxy, and i should get some better one, so i should be able to bypass konversation's weaknesses03:20
LjLat least some of them03:20
LjLi just need to bother doing it03:20
robI'm yet to find a decent irc proxy that works with xchat well enough for continued use, muh comes close03:20
LjLrob: muh comes close...?! then i'm hopeless03:21
robthere is a fork of muh that is even better03:21
LjLmuh is what i'm using, and what i'm finding terrible03:21
robLjL, try the fork03:21
LjLin the repos?03:21
robI doubt it03:22
LjLi might be better off just writing a script i think03:22
Davieywhy not just use irssi on a remote box?03:22
robLjL, miau03:22
LjLrob: muh doesn't even auto set /away on detach, heck... not to mention its log format, ugh03:22
LjLDaviey: because i want to use a darn gui client.03:23
robOne of Miau's features is: Can set user away when client quits and can also use user's quit-message as away-message.03:23
DavieyX-Chat + SOCKS proxy?03:23
=== Seeker` thinks irssi has some protection from CTCP
LjLDaviey, eh? what good would that do?03:24
Seeker`but i dont know how to test it03:24
robalso note that the ugly logs are probably because of freenode's ircd and not the bouncer, but I think miau can fix that too03:24
DavieyLjL: why are you running a proxy?03:24
LjLrob, it shows times without dates. i doubt that's freenode's fault :)03:24
roboh? I don't remember miau having that problem03:25
LjLDaviey: 1) because it takes an age to join channels like #ubuntu, given the /names list  2) because i'd like to have full logs  3) because i might connect from other machines  4) because, although i can't do that yet, it may help overcoming konv's limitations03:25
LjLrob: they have .deb packages of miau for etch anyway it seems, so i could try it03:26
DavieyOh.. i assumed it was just because you couldn't connect to IRC - ie restrictive firewall03:26
roblast time I used it I had to compile it myself03:26
LjLrob: oh another terrible thing in muh's logs: when users quit the server or change their nickname, it's shown in *every* log file, including ones for channels those people were not in.03:26
LjLwhen i grep my logs, i always have to | grep -v "has quit" | grep -v "is now known as"03:27
LjLtalk about elegant :)03:27
LjLDaviey: nope, my firewall is restrictive but it's fine for irc :)03:27
robLjL, I'm pretty sure miau was forked from muh because the author hated certain things like that in muh and wanted to fix them03:27
LjLrob: you know what i'd love? a gui irc client that can go back in time. you know, like those new GUI file managers that support versioning filesystems03:29
LjLmove a slider, and see every channel exactly as you had it at the given date03:29
robLjL, the latest xchat has backlogs inbuilt03:29
LjLrob, konversation has something too, i can right-click on the channel and open the log in a konversation tab... but that's not the same thing as actually seeing the stuff happen03:30
robno, its backlog replay.03:30
LjLrob: actually, i'd be able to completely *replay* things that happened, in real time (or accelerated time)03:30
LjLreading logs, even if you're careful to look at the timestamps, is a totally different thing from *being there*03:30
robwhen you join a channel you were in previously, it replays the log files03:30
LjLrob: konversation does that too... it shows the last N lines of last time you joined03:31
LjLthat's useful but in a limited way03:31
robyes, but if you had the whole entire log there it would be even less useful, you are better off grepping them from the command line if you want to find something03:31
Seeker`Daviey: does irssi log by default?03:32
naliothSeeker`: it does not03:32
LjLrob, you're right, if i had the whole entire log, i'd understand nothing and grep would be better.  but imagine not having the entire log, but rather: i set a date and time (or search for a phrase), and my irc clients shows *exactly* what it showed at that time03:32
LjLand if i click "play", it replays the stuff in real time03:33
LjLit shows it *for all channels*.03:33
robwhy? Most of what goes on is boring :)03:33
Seeker`LjL: that probably would'nt be /too/ hard to program03:33
DavieySeeker`: logs are useful..03:33
LjLrob: because 1) reading logs doesn't give you the information about *time*, which is vital, much more so than one would think  2) there's no easy way to cross-check logs, i.e. if i want to see what was happening in #ubuntu-ops while we had, say, a bot attack in #ubuntu, it's hard to do with just grep03:34
LjLif i could just tell me client "ok, now give me the situation exactly as it was on 14 october at 20:00, and start playing it at 2x" - that'd give me an idea of what was *actually* going on03:34
LjLSeeker`: well it involves GUI programming, something i'm totally unfamiliar with03:35
robactually you could probably just write a script that could do it for an existing client, but to be honest I don't see too much value in it03:35
LjLrob: a script wouldn't really work because you couldn't *quickly* jump back and forth, you'd have to restart the client every time03:36
Seeker`LjL: but if you made the bit behind it, you could probably get someone to do the front end03:36
LjLrob: have you never noticed how the *delays* between messages can be much more meaningful than the messages themselves?03:37
LjLSeeker`: i kind of doubt it :)03:37
robnot true. Just have a command that accepts start and end times then just replays in whatever window/s you want03:37
Seeker`LjL: and why does it have to be in your clinet? why not a seperate app03:37
LjLSeeker`: yes, it could be a separate app03:37
DavieyI agree with Seeker`, it really would be a few hours programming.. but I can't find the time as i see little usefulness03:37
robLjL, you can judge that pretty easily from timestamps03:37
Seeker`Daviey: I feel that my spare programming time should go towards mootbot atm03:38
LjLrob: and how do i say "stop", and "now go back by 30 seconds", and "switch to the #kubuntu tab", and "now highlight the regexp xyz"03:38
LjLrob, timestamps are very easily missed. you have to check each one of them.03:38
robLjL, build on the script :)03:38
Seeker`LjL: a script can be interactive03:38
LjLrob, how can a script erase what was previously in the window?03:38
robwhy bother erasing it?03:38
roband /clear will do it :)03:39
Seeker`LjL: apt-get update countdown timer in the right hand corner?03:39
DavieypyGTK supports tabs v. easily...03:39
LjLSeeker`: if it's interactive to the point where it has to use ncurses, it's hardly a "script" in the form i usually think of a script03:39
LjLrob, think looking at a film - i mean actually looking at the strip of plastic - versus actually playing the movie in it.03:40
robLjL, whats what you have a scrollbar for :)03:40
Seeker`LjL: but the UI doesn't have to be tied to the back end - write something that outputs the text you want, and then code the UI to deal with deleting stuff etc.03:40
LjLrob: but the movie isn't *one* channel, it's *all* the channels i'm in, since they may (and often are) correlated. and a scrollbar rarely works for a log that comprises 2 years of stuff03:41
LjLSeeker`: yes sure that would be perfectly feasible. but eventually the gui would have to be written03:41
robyeah, that's what grep is for03:41
=== rob fades out
LjLrob: then what's the grep command to tell me what was happening #ubuntu-ops when someone said "duck!" in #kubuntu?03:41
LjLs/happening #/happening in #/03:42
Seeker`LjL: couldn't you just link two windows, and do some clever maths with timestamps to work out how much eahc window needs to scroll by03:42
robcat logfile.log | grep duck!03:42
Davieygrep + awk the timestamp + grep the other log :D03:42
Seeker`so if you move the #ubuntu window by 30 secs, it will recalculate what to display on each of the other windows03:42
=== rob goes to get lunch
LjLrob: erm, logfiles usually comprise *one* channel03:43
robLjL, use sed03:43
robLjL, its the same silly logic they recently applied to everything under /etc/atp/sources.d from sources.list03:43
LjLDaviey: and you call that quick and easy? i hope not. what i call quick and easy is: i come to IRC, i see there has been a mess, i want to understand what happened... i don't type 150 grep awk and sed commands, i just replay the parts that matter03:44
LjLrob: are you saying one should keep every channel in the same logfile?03:44
DavieyLjL: unless you want to develop a GUI for this - i think a shell/perl script is the best way to achieve what you want03:44
=== Seeker` goes to find bed
Seeker`I'm at home tomorrow, so i can help spot trolls etc.03:45
LjLDaviey: i'm precisely saying that i would like a GUI for this. and the others are saying it's pointless. i'm simply saying that i think it's not -- and it's not like i started grepping logfiles yesterday, i've done it for a while, and i know i sometimes find it cumbersome =)03:45
DavieyLjL: don't get me wrong.. I see why it can be useful.03:46
LjLi don't even think it'd be very hard to write, it's just that i've never done any GUI programming. sometime i really should start, it's limiting.03:47
DavieyLjL: pyGTK will make it pretty damn easy IMO03:48
LjLDaviey: i'm on KDE, but i suppose there's something similar. but then i don't know python :)03:51
LjLof course it's not hard to learn python03:51
LjLand for that matter i suppose it's not hard to learn basic gui programming with a sane toolkit03:51
LjLit's just a matter of actually getting at it03:51
LjLreally, all i was arguing was that such a program *can* be useful. when i feel less lazy (which doesn't happen often), i'd probably learn the stuff needed to write it03:52
DavieyQt _can_ be easier to script + GUI03:54
Davieybut i _hate_ Qt03:55
stdinbut Qt loves you, can't you love it back :)03:55
DavieyQt can go to /dev/hell03:56
Davieyanyway.. time for bed.. nn03:56
LjLDaviey: i don't know really, i know there's kommander if one just wants to kludge something together, but when i tried it it didn't look as easy as the VB-style interface leads one to believe... so perhaps one is better off just programming without the fancy GUI widgeter03:56
LjLDaviey: well, to each one his own, seeker is right in that i should write a backend, then i can write a kde frontend and you write a gtk one :)03:57
DavieyLjL: I have little experience with kommander.. one app i did poke at the src was http://www.luckies.nl/remotekommander/03:57
Davieyand that is pretty simple.. 03:57
Davieybut really - going to bed /now/03:57
=== nzero [n=nreynold@] has joined #ubuntu-ops
nzerohey its been 24 hours uban me so i don't have to unplug my dsl modem04:13
nzero!hi | gnomefreak04:16
ubotugnomefreak: Hi! Welcome to #ubuntu-ops!04:16
ubotulife is something very few people know about in this channel - and anyway, it's probably offtopic, perhaps you want to try #ubuntu-offtopic04:24
nzerowhatever i will restart my modem tommorow  on be on ruining your lives04:25
=== nzero [n=nreynold@] has left #ubuntu-ops []
=== Vorian [n=Steve@ubuntu/member/pdpc.supporter.active.Vorian] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v Vorian] by ChanServ
ubotuposingaspopular called the ops in #ubuntu-chicago05:05
=== tonyyarusso [n=anthony@ubuntu/member/tonyyarusso] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v tonyyarusso] by ChanServ
=== tonyy [n=anthony@ubuntu/member/tonyyarusso] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v tonyy] by ChanServ
=== Jucato [n=jucato@] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v Jucato] by ChanServ
=== Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v Hobbsee] by ChanServ
=== jdong glares at chaky joining in #uf...... so far he hasn't started speaking talagog or whatever that was
naliothjdong: you don't speak tagalog ?06:22
jdongnalioth: unfortunately I don't. It's on my list of things to learn06:22
robnalioth, they are not back again are they? They got several warnings yesterday and one was even kicked out over it.06:24
ubotuastro76 called the ops in #ubuntu06:25
jdong00:25 -!-  channels : #ubuntu @#cisco-hr #ubuntuforums #ubuntu-hr #deluge 06:25
naliothrob: no tagalog speakers sighted by me06:26
naliother, typers06:27
ubotujdong called the ops in #ubuntu06:30
=== tonyy [n=anthony@ubuntu/member/tonyyarusso] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v tonyy] by ChanServ
=== Madpilot_ [n=brian@ubuntu/member/madpilot] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v Madpilot_] by ChanServ
=== Madpilot_ [n=brian@ubuntu/member/madpilot] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v Madpilot_] by ChanServ
=== Starting logfile irclogs/ubuntu-ops.log
=== ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #ubuntu-ops
=== Topic for #ubuntu-ops: Welcome to the home of the operators of all Ubuntu (and derivatives) channels | This channel is for operator/abuse questions only | Support in #ubuntu, #kubuntu etc... | IRC team info: https://wiki.ubuntu.com/IrcTeam | The IRC council reserves the right to remove idlers from the channel
=== Topic (#ubuntu-ops): set by Mez at Sun Sep 30 18:13:35 2007
=== nixternal [n=nixterna@ubuntu/member/pdpc.active.nixternal] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v nixternal] by ChanServ
=== Amaranth [n=travis@ubuntu/member/Amaranth] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v Amaranth] by ChanServ
=== rob [i=rob@freenode/staff/rob] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v rob] by ChanServ
=== Jucato [n=jucato@] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v Jucato] by ChanServ
=== jussi01 [n=jussi@oul088-gw3.netplaza.fi] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v jussi01] by ChanServ
ubotuIn #ubuntu-ca, rouben said: ubotu: that is brilliant! :)08:51
=== elkbuntu [n=melissa@ubuntu/member/elkbuntu] has joined #ubuntu-ops
=== mode/#ubuntu-ops [+v elkbuntu] by ChanServ
MyrttiFYI irssi users: http://www.pthree.org/2007/07/11/irssi-chanserv-and-nickserv-helper-aliases/#comment-7293710:13
MyrttiI thought that might be nice in addition to the earlier aliases published in that blog post10:13
Myrttiin re: recent discussions on the mailing list10:13
rob/remove is a server function, yes10:16
Myrttithough I'm not sure if all the irc ops using irssi are aware of that post at all10:17
robit forces the other user to /part :)10:17
robI've seen other ircds with lots of wicked things like that, very evil10:17
Myrtti/me ponders whether the link to the original blog entry should be mailed on the mailing list10:17
Myrttirob: I noticed an email on the mailing list that suggested the usage of /remove over /kick on #ubuntu-domain channels10:18
robMyrtti, typically ubuntu ops use /remove rather then /kick as it does not trigger the clients auto-join ability10:18
Myrttiso there you have it10:19
robsometimes they just use it an not /ban as well10:19
Myrttiif you're using irssi10:19
=== tonyyarusso prefers auto_bleh
=== rob prefers his own custom stuff
Myrtti/me has used auto_bleh and was unhappy with it10:23

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