| |
| |
| |
|
<wfl> oh :p
<wfl> we should probably remove that :)
<AndroSyn> heh
<jilles> I had noticed it more than a week ago
<jilles> ;p
<AndroSyn> i got asked if it was a bug yesterday
<wfl> um
<wfl> when we're collecting zipstats..
<wfl> do we actually write something on the wire?
<AndroSyn> we collect those over the control channel
<wfl> ah
<AndroSyn> i have quite the distaste for the control channel stuff in servlink..
<wfl> (im just moving ctrlfd to struct servlink_data..)
<AndroSyn> gotcha
<wfl> personally, the servlink stuff seems complicated for what it does :p
<AndroSyn> agreed
<AndroSyn> well most of the complex stuff is the control channel crap
<AndroSyn> which also ends up dealing with shoving out the zip data we received in the ircd itself
<AndroSyn> and shoving it over to servlink
<jilles> yeah
<jilles> with linebuf there's necessarily quite a bit of complexity there, and it's worse because of the separate servlink process
<wfl> I swear this samba problem is annoying
<wfl> I can connect to a share fine using smbclient
<wfl> as soon as I try using mount, itll connect once, as soon as I umount it, it wont let me reconnect for 5 mins
<AndroSyn> damn bots..
<SiD3WiNDR> o_O
<wfl> dont set that +e :)
<wfl> at least while youre at that provider :p
<AndroSyn> that means i'd have to unstick it on the bots :P
<wfl> so do it :)
<AndroSyn> i'm lazy
<AndroSyn> and tired :P
<wfl> whoever added the ZipStats struct needs a smack with a 2x4 :p
<wfl> did you notice that itd been statically allocated as part of LocalUser?
<anjuta> is it possible that ratbox will hand on and wait forever on some I/O ?
<AndroSyn> it shouldn't
<AndroSyn> but i could see it happening
<jilles> I think there have been bugs like that
<sjk> Hrm, I like csircds /resv which also removes users from the channel being /resvd
<spoogle> that could cause havoc on efnet though
<sjk> How come?
<AndroSyn> if it only removed local users, it wouldn't be too much of a problem..
<sjk> Yeah, local only, of course
<sjk> Perhaps have a seperate resv command for it.
<AndroSyn> though instead of just parting the users it would probably be better to quit them
<AndroSyn> if you needed something like that, i could hack up something and possibly put it in contrib/
<jilles> i.e., Connection closed ? ;-)
<AndroSyn> but i don't think i'd put it as a default command
<AndroSyn> something like that
<sjk> Hrm, I reckon it could be useful
<AndroSyn> i don't think i'd allow remotes though :P
<sjk> No
<sjk> But hrm. Perhaps just parting them would be good? Most drones would try rejoin later etc while real clients wouldnt
<jilles> i.e. send PART messages to the client?
<jilles> several clients in their default setting close the window if an unexpected PART happens
<jilles> so the user can't see any kind of reason or whatever
<AndroSyn> and other clients go goofy
<AndroSyn> and doing a server kick would be evil :P
<sjk> Why so? :)
<jilles> probably at least 50% of non-drones rejoins on any kick
<sjk> Sometimes one has to resv channels where there are drones, but also legitimate users
<sjk> klining them all would probably be wrong
<jilles> try to detect the drones in another way than that they join that channel then
<AndroSyn> quitting them is probably the safest option..
<sjk> Perhaps
Return to ratbox
or
Go to some related
logs:
100mb.bin
body 0px
wireless
|
|