=== Fujitsu [n=fujitsu@ubuntu/member/fujitsu] has joined #ubuntu-ops === Fujitsu [n=fujitsu@ubuntu/member/fujitsu] has joined #ubuntu-ops [01:40] gnomefreak Amaranth nalioth, around? [01:40] square [01:41] hehe [01:41] triangle? [01:45] nalioth: 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] the 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] for every upgrader, they'll have to be told where to go, and possible helped there === fdoving [n=frode@edge.lnix.net] has joined #ubuntu-ops === mode/#ubuntu-ops [+v fdoving] by ChanServ [01:46] er, possibly helped in #ubuntu to get to #ubuntu+1 [01:46] we are not dealing with internet (or computer) savvy people [01:46] is there a limit to the number of peope in a channel? [01:46] we need to keep the 'new stuff' to a minimum [01:46] nalioth: yes, that is true, but it's one message ("join #ubuntu+1 please") compared to, in many cases, a long exchange [01:46] they auto join #ubuntu and expect help there, not to be told to do something they may have never heard of [01:47] and would it be sensible to have a #ubuntu-upgrading instead [01:47] LjL: but what if they don't know how to /j #ubuntu+1 ? [01:47] Seeker`: that's exactly what i'm proposing to use #ubuntu+1 for [01:47] nalioth: you tell them: type /join #ubuntu+1. as we already do with a good 50% of them [01:47] LjL: I was thiking that the rename may make it simpler [01:47] I'd assume people that have been using feisty and want to upgrade to gutsy are relatively computer savvy. [01:47] Seeker`: i doubt that's really the issue [01:48] what is the issue then? [01:48] PriceChild: 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 sience [01:49] Seeker`: 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 #ubuntu [01:49] If people have problems upgrading... its 9 times out of 10 going to require more than a one line solution. [01:49] I'm pretty sure they'd relish the chance of a quieter channel [01:50] nalioth: 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] LjL: The reason I suggested a rename is because it is relatively obvious what -upgrading would be for, whereas +1 is less so [01:50] Seeker`, people wouldn't *look* for the right channel anyway, you'd always have to *tell* them. so what difference does the name make? [01:51] Seeker`: "type /join ubuntu+1 for help with upgrading". "type /join #ubuntu-upgrading for help with upgrading". [01:51] LjL: fair enough [01:51] Seeker`: 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 handy [01:52] Seeker`: and it also solves the problem of everyone in +1 moaning that the channel gets closed (they always do) [01:52] LjL: in that case, I reckon a split is a good idea [01:53] i'm not proposing to make it longer than say a week [01:53] but 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 support [01:53] !modes [01:53] There are many different channel and user modes on Freenode (see !freenode). Here's a list: http://freenode.net/using_the_network.shtml [01:54] now, maybe nobody will care about Gutsy like they did about Feisty, and the channel won't have a spike at all :) [01:54] but i'm assuming it will. [01:54] Its better to plan and it not explode, than have a huge spike and be unprepared === Seeker` wonders if someone will be able to answer his suspend problem after launch [01:55] that'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 it [01:55] I ask periodically in +1, but never get a response [01:56] Seeker`: you'll never get suspend to ram working, get on with life. [01:56] LjL: well, it works to an extent, but when it resumes it logs me off [01:56] Seeker`: then consider yourself lucky. [01:56] LjL: Unless there is something I dont know about IRC channels, splitting is the only sensible way of keeping the number of users manageable [01:57] Seeker`: it does also have serious drawbacks [01:57] if we're gonna split it, don't split it into #ubuntu+1 [01:57] when a permanent split of #ubuntu was proposed, i opposed it completely. [01:57] nalioth: then what? [01:57] but do the drawbacks outweigh > 1600 people trying to ask questions at the same time? [01:58] #ubuntu-upgrading or w/e [01:58] Seeker`: that's what i'm thinking. for the next couple of weeks, i think not === Seeker` agrees [01:58] #ubuntu+1 needs to stay for 'the next version' [01:58] nalioth: 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] i'd prefer to just use #ubuntu [01:59] you guys are the one talking of splitting and such [01:59] nalioth: we don't *have* to split. i've proposed it. there have been at least three negative reactions to that, on the ML. [02:00] nalioth: 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 idea [02:00] if i fail to do both, then #ubuntu it is [02:01] but 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:02] don't forget DR instances on other networks to be safe :) [02:02] i.e. if if people start pushing for a *permanent* splitting in order to avoid a *temporary* one, then i'll strangle them. [02:03] LjL: no, any splits would be temporary. Closing #ubuntu-upgrading at the same time #ubuntu+1 reopened perhaps [02:04] nalioth: 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* problem [02:04] but who cares, if you prefer to have #ubuntu-upgrading, then fine, but the issue is that you don't prefer either thing [02:05] (neither do gnomefreak and amaranth so if i have to take that as a sample, i'd have to say nobody likes the idea) === Madpilot [n=brian@ubuntu/member/madpilot] has joined #ubuntu-ops === mode/#ubuntu-ops [+v Madpilot] by ChanServ [02:08] I haven't read everything above, but I think we should forward #ubuntu+1 to #ubuntu on release day and deal with it [02:09] no need for a permanent split imo :) [02:09] rob: I think everyone is against a permanent split [02:10] you see, if you start sending folks to +1 for upgrading, they'll continue to go there after it switches over to hardy beta talk [02:10] we 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+1 [02:11] 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 :P [02:11] or a new channel, like #ubuntu-2 :) whatever.. [02:11] how long have we got to go until the release? [02:11] day and a bit [02:11] rob: 18th is the day [02:12] so ~ 30 hrs [02:12] roughly === Madpilot prepares a large rock to hide under in 28hrs [02:12] more like 36 ish :) [02:12] rob: I'd say more like 36 [02:12] usually about midday utc [02:12] mc44: have there been enough releases for a "usually"? [02:13] in #ubuntu-offtopic is about to earn a ban I think... [02:13] that means about 8pm my time tomorrow [02:13] I will be here :) [02:13] rob: East coast USA? [02:14] Seeker`, no, Australia [02:14] rob, read the mailing list rather than reading everything above [02:14] I'm +10, so midday utc = 8pm my time [02:14] http://ubuntuforums.org/showthread.php?p=3546058#post3546058 [02:14] erm [02:14] 12 + 10 != 20 [02:15] hmm I didn't get a mailing list [02:15] err mail on the mailing list, actually I don't think I am subscribed yet [02:15] woah PriceChild! [02:15] rob: https://lists.ubuntu.com/archives/ubuntu-irc/2007-October/thread.html [02:15] that's crazy [02:15] Seeker`, 10am my time is midnight utc. +10 hours on that makes it 8pm [02:16] PriceChild: wait Carmony resigned? [02:16] Clearly I don't read enough /, [02:16] PriceChild: Looks like that topic may require a bit of moderation [02:16] only read the first post === rob reads [02:17] rob: midnight utc + 10 hours = 10am utc [02:17] 8pm my time. === Seeker` gives up [02:18] = 10am utc [02:18] rob: i thought you were in the US? [02:18] mneptok, nope, Aussie born and bred [02:18] Seeker`, trust me, I convert timezones for a job :) [02:19] rob: its this comment that got me: rob+: I'm +10, so midday utc = 8pm my time === Seeker` thinks he broke the room [02:22] utc 0001 = 10am my time. Midday utc (10am + 12hours) = 10pm my time. I was wrong by two hours, but yes, close enough :) === Seeker` just wanted to know he wasn't going insane :) [02:23] +12 hours? [02:23] 12 hours from midnight is midday [02:23] mneptok: midnight + 12 hours is midday, so 10am + 12 hours is 10pm [02:23] he is +10 === LjL is starting to feel a headache [02:24] my timezone is +10, so midnight + 10 hours is when utc midnight falls my time [02:24] if it's 12 noon UTC, it's 10pm in eastern .au [02:24] mneptok: thats what we just worked out :) [02:24] ypu [02:24] err yup [02:24] +10. just add ten hours. this isn't rocket science. :) [02:25] heh [02:25] 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 difficult [02:25] for me anyway [02:25] this is where rob tells us he's in Perth and we kill him [02:25] dam it I want to play ETQW but after going though synaptic I have an hour of downloading to go.. [02:26] mneptok, heck no, Brisbane :) [02:26] I 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:27] damned right. you stay in that +10 Syd/Melb/Bris/Canb tz [02:29] how many ops are from GB? [02:29] seciboi4u pm'd me earlier, asking asl and everything [02:30] PriceChild: oooh, someone likes you ;) [02:30] Seeker`, me, davi, me.z, pop.ey, i think [02:30] wow, a little bit of overkill maybe LjL for release.. [02:30] he's in -offtopic [02:30] PriceChild: how many that aren't just -uk ops? [02:30] rob, do you not remember the days after feisty or edgy release? [02:31] Seeker`, me and me.z i assume [02:31] PriceChild: cool [02:31] LjL, did you see what happen on I think efnet during 911? That was mayhem :) [02:31] Seeker`, probably missing one or two... st.din i think [02:31] rob: this is not efnet... and #ubuntu is a support channel. i'd like to be able to keep giving real support [02:31] rob: and i was on ircnet during 911 :) [02:32] i 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 lags === Seeker` was standing at a bus stop when the towers went down [02:34] rob: 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] sure, splitting is big, but then again having 2000 users of which 500 speaking in a channel is "big" too [02:35] LjL, 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 to [02:35] 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] rob: sounds sensible [02:36] rob, we tried +J a while ago but it fails badly in server deaths iirc [02:36] the #ubuntu+1 channel should be forwarded back to #ubuntu until hardy has people using it [02:36] rob, 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] which is why we didn't use it much after [02:37] my suggestion about +J and also flooding, maybe consider running debian's bot, it handles both pretty well [02:37] 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] Seeker`, the latter [02:37] rob: 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 works [02:37] not going to hit a server limit, the latter [02:38] LjL, the Debian bot dynamically sets +J as needed [02:38] rob: define "as needed" [02:38] doesn't it set +l? [02:38] also, something to kick/remove pasters would be nice too [02:38] (or whatever it is that limits the total number of users) [02:38] rob, heh, that's an old one :) [02:39] LjL, +J to iirc [02:39] we never did that for one reason or another [02:39] I think last time I was manually messing with +J a bit [02:39] rob: i'm not sure how it would know when to set +J... i mean, how can you know until the bots come? [02:40] LjL, it is hard to second guess bots, don't rely on +J alone [02:40] I always thought we never liked the idea of "bots with ops"? [02:40] rob: the debian bot doesn't do +J, it does +L [02:40] nalioth, ah ok [02:40] er, whatever 'channel user limit" is [02:40] PriceChild: 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] rob: it keeps it 10 or 20 above the current user base [02:40] 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:41] however +J and +L are unlikely to give you proper decent protection against most botnets anyway [02:41] rob, +J worked nicely when we used it... except for the server death problem [02:41] +L will stop a 10+ clone swarm join attack [02:41] rob: having 5 bots join is something *very* different from having 50 bots join [02:41] for starters, 5 bots can't cause people to excess flood [02:41] 50 can [02:41] and do [02:42] well, 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] rob: they did that once, yes [02:42] I even wrote a script that would do it like that in a moment of boredom [02:42] or twice === Seeker` suggests that the other ops keep an eye on rob :P [02:42] /kb rob === Vorian [n=Steve@ubuntu/member/pdpc.supporter.active.Vorian] has joined #ubuntu-ops [02:42] heh === mode/#ubuntu-ops [+v Vorian] by ChanServ [02:42] rob: but neither +J or +L will stop the slow join attacks [02:42] you're giving them ideas now [02:43] nalioth, my point exactly [02:43] nalioth: will anything stop slow join attacks? [02:43] Seeker`: not much [02:43] rob: 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 advance [02:43] thus +JL does not give you all that great of protection, you might just slow them down [02:43] the point of +J or +L is to stop the kiddies who use the mass-clone-swarm-join attack [02:43] yup [02:43] hmm - do bot nets generally send the same message at the same time? [02:43] often. [02:44] so just set +J manually as needed, it shouldn't have to be altered all that often === Daviey suggests monitoring multiple joins from 1 IP... I expect few malicious flooders will bother using multiple boxes [02:44] 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 them [02:45] as for +L, it could be used on a temporary basis if a sustained attack happens [02:45] Seeker`: we could implement many things, but 1) we don't have time 2) there are countless arguments against doing that sort of thing [02:46] we'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 way [02:46] Seeker`, 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 thereafter [02:47] because, often botnets flood the same line over and over again :) [02:47] rob: I thought that most scripts only caught user a repeating line b, not multiple users and the smae line [02:47] Theres some flood detection stuff built into irssi, but nothing hooks into the events by default. [02:47] Daviey, botnets usually come from several IPs. but yes, that's a clone detection script. [02:47] Seeker`, exactly, my script is better :) [02:48] but 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 them [02:48] Seeker`, oh and for a slightly different purpose [02:48] 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:49] LjL, of cause, but that doesn't mean one can't discuss them at all [02:49] Seeker`, I think that's what people are trying to do but it is hard to get everyone together when we are all over the world [02:50] rob: agreed- I meant more than 24 hours in advance of launch though [02:50] oh, LjL, and I already have some of these scripts that I mention [02:50] rob: and thats why regular irc council meetings and ML discussions should be conducted :D [02:50] rob: 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 bots [02:51] rob, 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] LjL, sure, but +J and +L are not going to prevent attacks, only potentially take some steam out of the dumber ones [02:52] rob: but you cant prevent attacks, only react [02:52] yup [02:52] and whatever system is implemented will have holes === 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 [02:52] rob, +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, anyway [02:53] my 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 that [02:54] J controls join rate, not total? [02:55] rob, 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] Seeker`: the former. [02:56] so what is the highest number of users you would want to join in, say, 10 seconds? [02:57] or am I looking at it too simplistically? [02:57] For tips and information on channel and user modes and management, see http://freenode.net/using_the_network.shtml Seeker` [02:58] 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 seconds [02:58] Seeker`: that is how +J works [02:59] /mode #channel +J 2,10 [02:59] or whatever [02:59] nalioth: yeah, but why hasn't someone suggested a figure like that? [02:59] Seeker`: it has been used before and is being discussed now [03:00] Seeker`: because it depends on the channel. [03:00] i have suggested 2,5 [03:00] but i don't really know [03:00] it worked well last time, but last time wasn't release time [03:00] i cant imagine you will get a huge rush of people joining, even if it is release [03:00] last release seemed to be a fairly gradual curve up to 1600 [03:01] Seeker`: 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 differ [03:01] fairly gradual like in 6 hours, yeah [03:01] and then it kept steady for quite a while [03:01] guys, take a look at http://stoffers.id.au/dancer/ [03:01] mainly the channel mode section :) [03:02] yeah, but what I mean is that is wasn't like at midday, 300 people joined [03:02] so something like ~5 users in 10 seconds sounds reasonably justified [03:02] Seeker`: i think we all agree. possibly even less. [03:03] Seeker`: 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 part [03:03] but a reasonable +J setting doesn't stop being reasonable, no [03:04] depends :) Just come up with something you think as reasonable and adjust it as needed on the fly. [03:04] 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 limit [03:05] Seeker`: join #ubuntu-unregged. [03:05] it's exactly what we used to do. [03:05] was there a problem with that method? [03:05] and -unregged never got huge, for the record - quite the contrary [03:05] Seeker`: yes. on server deaths, +J causes terrible problems. [03:06] it's a rare event, but when it happens it's apparently a nightmare [03:06] that's the only real problem [03:06] beecause everyone tries to rejoin? [03:06] hopefully server deaths won't happen :) [03:06] rob: that's what i say, but pessimism reigns :) [03:06] a) what is the likely hood that all ops will be on the same server [03:06] b) how quickly can someone -J? [03:07] LjL, a netsplit is an example of a time where you might want to alter or remove +J completely for a bit [03:07] Seeker`: a) zero, but does it matter? b) not quick enough [03:07] rob, it seemed that netsplits were handled well actually, it was only netsplits caused by servers going down that were a problem... [03:08] %login [03:08] OK [03:08] if a server dies properly, surely you are talking up to a min before people start rejoinig? [03:08] Seeker`, honestly, i've never experienced that. [03:08] i'd have kept +J if it had been for me [03:08] but it was removed because of that issue. [03:09] 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 retry [03:09] Seeker`: if the server gives a FIN, then clients will immediately try to reconnect to another server [03:10] but 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. === Seeker` nods, "I'm no expert" [03:11] all 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] so, *temporarily*, +J should be fine. permanently, that's another matter, but not one i'm concerned about right now === Seeker` agrees, "the chances of a mass-join bot attack are much higer than the risk of a bad crash" [03:12] exactly. [03:12] i just had a mass-join bot attack ... [03:12] ... in my pants. [03:12] mneptok: you fail :P [03:12] and a good bot attack can cause probably somewhere around 200 clients to disconnect (taking the increased number of users into account), which is bad enough [03:13] do the attacks usually rely on making the clients send so much data that the server kicks them? [03:13] Seeker`: they do. [03:13] disconnect... then immedietly reconnect - circle continues [03:13] someone should write a server to stop that :P [03:13] any volunteers? [03:14] Seeker`: not very feasible... it should be the *client's* task to avoid flooding out [03:14] Seeker`, the problem is it starts to impact on freedom of speech and privacy when the ircd starts trying to filter things [03:14] but most clients aren't, uhm, very good at that [03:14] that was more of a joke than a real suggestion [03:14] Seeker`, trust me Freenode has discussed it at great length :) [03:15] rob: 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] LjL, problem with that is /me is a CTCP. [03:15] rob: surely one that can be told apart by the server [03:15] 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 low [03:15] again, filtering, it also would put a lot of stress on the servers. [03:16] rob: true. [03:16] rob: really, if only irc clients wouldn't be so dumb, it would be a non-issue [03:16] LjL, yep. [03:16] rob: xchat just happily replies to the CTCPs, and excess floods === Seeker` wonders what irssi does by default [03:17] LjL, one way to protect yourself from it is to disable automatic replying to ctcp, its what I have done [03:17] rob: 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 anything [03:17] rob: yes, i've been thinking of doing that [03:17] Seeker`: floods. [03:17] any nice ways to stop it? [03:18] Seeker`: most likely... irssi can be scripted in about every thinkable way [03:18] in xchat, blank out all the automatic replies in the CTCP dialog and set irc_hide_version to 1 [03:19] rob, 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, though [03:19] in xchat there is also flood_ctcp_num and flood_ctcp_time you can fiddle with [03:20] and 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 weaknesses [03:20] at least some of them [03:20] i just need to bother doing it [03:20] I'm yet to find a decent irc proxy that works with xchat well enough for continued use, muh comes close [03:21] rob: muh comes close...?! then i'm hopeless [03:21] there is a fork of muh that is even better [03:21] muh is what i'm using, and what i'm finding terrible [03:21] LjL, try the fork [03:21] in the repos? [03:22] I doubt it [03:22] i might be better off just writing a script i think [03:22] why not just use irssi on a remote box? [03:22] LjL, miau [03:22] rob: muh doesn't even auto set /away on detach, heck... not to mention its log format, ugh [03:22] http://miau.sourceforge.net/ [03:23] Daviey: because i want to use a darn gui client. [03:23] heh [03:23] One 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] X-Chat + SOCKS proxy? === Seeker` thinks irssi has some protection from CTCP [03:24] Daviey, eh? what good would that do? [03:24] but i dont know how to test it [03:24] also note that the ugly logs are probably because of freenode's ircd and not the bouncer, but I think miau can fix that too [03:24] LjL: why are you running a proxy? [03:24] rob, it shows times without dates. i doubt that's freenode's fault :) [03:25] oh? I don't remember miau having that problem [03:25] Daviey: 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 limitations [03:26] rob: they have .deb packages of miau for etch anyway it seems, so i could try it [03:26] nice [03:26] Oh.. i assumed it was just because you couldn't connect to IRC - ie restrictive firewall [03:26] last time I used it I had to compile it myself [03:26] rob: 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:27] when i grep my logs, i always have to | grep -v "has quit" | grep -v "is now known as" [03:27] talk about elegant :) [03:27] Daviey: nope, my firewall is restrictive but it's fine for irc :) [03:27] LjL, I'm pretty sure miau was forked from muh because the author hated certain things like that in muh and wanted to fix them [03:29] rob: 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 filesystems [03:29] move a slider, and see every channel exactly as you had it at the given date [03:29] LjL, the latest xchat has backlogs inbuilt [03:30] rob, 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 happen [03:30] no, its backlog replay. [03:30] rob: actually, i'd be able to completely *replay* things that happened, in real time (or accelerated time) [03:30] reading logs, even if you're careful to look at the timestamps, is a totally different thing from *being there* [03:30] when you join a channel you were in previously, it replays the log files [03:31] rob: konversation does that too... it shows the last N lines of last time you joined [03:31] that's useful but in a limited way [03:31] yes, 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 something [03:32] Daviey: does irssi log by default? [03:32] Seeker`: it does not [03:32] good [03:32] rob, 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 time [03:33] and if i click "play", it replays the stuff in real time [03:33] it shows it *for all channels*. [03:33] why? Most of what goes on is boring :) [03:33] LjL: that probably would'nt be /too/ hard to program [03:33] Seeker`: logs are useful.. [03:34] rob: 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 grep [03:34] if 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 on [03:35] Seeker`: well it involves GUI programming, something i'm totally unfamiliar with [03:35] actually 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 it [03:36] rob: a script wouldn't really work because you couldn't *quickly* jump back and forth, you'd have to restart the client every time [03:36] LjL: but if you made the bit behind it, you could probably get someone to do the front end [03:37] rob: have you never noticed how the *delays* between messages can be much more meaningful than the messages themselves? [03:37] Seeker`: i kind of doubt it :) [03:37] not true. Just have a command that accepts start and end times then just replays in whatever window/s you want [03:37] LjL: and why does it have to be in your clinet? why not a seperate app [03:37] Seeker`: yes, it could be a separate app [03:37] I agree with Seeker`, it really would be a few hours programming.. but I can't find the time as i see little usefulness [03:37] LjL, you can judge that pretty easily from timestamps [03:38] Daviey: I feel that my spare programming time should go towards mootbot atm [03:38] rob: 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] rob, timestamps are very easily missed. you have to check each one of them. [03:38] LjL, build on the script :) [03:38] LjL: a script can be interactive [03:38] rob, how can a script erase what was previously in the window? [03:38] why bother erasing it? [03:39] and /clear will do it :) [03:39] LjL: apt-get update countdown timer in the right hand corner? [03:39] pyGTK supports tabs v. easily... [03:39] Seeker`: 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 script [03:40] rob, think looking at a film - i mean actually looking at the strip of plastic - versus actually playing the movie in it. [03:40] LjL, whats what you have a scrollbar for :) [03:40] 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:41] rob: 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 stuff [03:41]