[Coder-Com] GNUWorld Compilation error
When i was trying to compile GNUWorld getopts.h was not found, required by main.cc The system is FreeBSD 4.6-Release with gcc 2.95.3 Any ideas? Thanks for your time, Andreas Louca [EMAIL PROTECTED] Http://www.etechnova.net/
Re: [Coder-Com] Patch idea.. any thoughts?
I think i have a soloution to your problem which would requier much less upheavel first you add a channel mode which redirects limit blocked clients to another channel then you have a bot which replicates the traffic >From: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: Re: [Coder-Com] Patch idea.. any thoughts? >Date: Sun, 28 Jul 2002 01:42:31 +0100 >MIME-Version: 1.0 >Received: from mc2-f17.law16.hotmail.com ([65.54.237.24]) by >mc2-s14.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 27 >Jul 2002 17:48:01 -0700 >Received: from trek.sbg.org ([66.134.137.28]) by mc2-f17.law16.hotmail.com >with Microsoft SMTPSVC(5.0.2195.4905); Sat, 27 Jul 2002 17:47:47 -0700 >Received: (from undernet@localhost)by trek.sbg.org (8.12.1/8.12.1) id >g6S0gbRd032709for coder-com-outgoing; Sat, 27 Jul 2002 17:42:37 -0700 >Received: from mercury.stbarnab.as ([212.115.48.196])by trek.sbg.org >(8.12.1/8.12.1) with ESMTP id g6S0gZJs032706for <[EMAIL PROTECTED]>; >Sat, 27 Jul 2002 17:42:36 -0700 >Received: from ground.stbarnab.as ([212.115.48.200] ident=mail)by >mercury.stbarnab.as with esmtp (Exim 3.36 #2)id 17Yc8o-00027l-00for >[EMAIL PROTECTED]; Sun, 28 Jul 2002 00:42:34 + >Received: from davidm by ground.stbarnab.as with local (Exim 3.35 #1 >(Debian))id 17Yc8l-0001UP-00for <[EMAIL PROTECTED]>; Sun, 28 Jul 2002 >01:42:31 +0100 >Message-ID: <[EMAIL PROTECTED]> >References: <[EMAIL PROTECTED]> ><[EMAIL PROTECTED]> >In-Reply-To: <[EMAIL PROTECTED]> >User-Agent: Mutt/1.3.28i >Sender: [EMAIL PROTECTED] >Precedence: bulk >Return-Path: [EMAIL PROTECTED] >X-OriginalArrivalTime: 28 Jul 2002 00:47:48.0052 (UTC) >FILETIME=[64CE8140:01C235D0] > >On Sat, Jul 27, 2002 at 02:43:11AM -0400, Py Fivestones wrote: > > > Doesn't that pretty much destroy the concept behind IRC, that is to >allow > > people to chat with each other? Also, don't people on a channel have the > > right to see who they are keeping company, and thus being associated >with? > >The mode under discussion is only for use for very large channels (and if >implemented would probably only be settable on channels at least 500 users >or something). Under these circumstances the points you mention are less >important (particularly if without the mode the users can't stay on the >network!). > > > The other question is, will this channel mode break IRC clients? > >If the implementation works as I envisage it, not really. There would be >users on the channel that the ircd knows about but the client doesn't, but >there is no way for the client to find out about them anyway (they can't >talk or anything, and nick changes etc. would be supressed). Enabling ops >to see all channel members would allow bots to function normally, too. > >splidge _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: [Coder-Com] GNUWorld Compilation error
Where on your system is getopt.h located? The legend of the darkness wrote: > When i was trying to compile GNUWorld > getopts.h was not found, required by main.cc > > The system is FreeBSD 4.6-Release with gcc 2.95.3 > > Any ideas? > > Thanks for your time, > Andreas Louca > [EMAIL PROTECTED] > Http://www.etechnova.net/
Re: [Coder-Com] Patch idea.. any thoughts? [restarted]
hmmm: Channel has 2000 users in it with, 5 ops 5 voiced Anyone whose anyone knows that if someone were to join that channel from anything less than a dual channel ISDN line (and probably including) is not going to handle the flood of /names, and the ensuing irc clients doing things like /who or /userhost for everyone in that channel. And for the situation requested, it is also unfair to expect all the users will know how to set there clients to not get extra information on the nicknames from /names. Also a channel mode for "auditorium" mode is impracticle because in order to not break the protocol in the example above 1995 people would have to be sent 1995 joins/parts when the channel mode is removed/set (respectively). (that¹s 3980025 messages that would have to be sent, if you are wondering) However this would be fine for those being opped/deopped because, only the person being opped/deopped would need to see everyone join/part (that¹s 3989 messages, made up of 1 per client that couldn't/wont see them (1995) plus 1994 for the person being opped/deopped) So I am suggesting, if someone really wants this, they are better off creating a channel type (ie -channel instead of #channel), not a mode, simply because the semantics of the channel mode would create too much server load (which is probably why IRCPlus didn't like the channel mode being removed). > Doesn't that pretty much destroy the concept behind IRC... As for the above line, so does channel modes +m +k +s +p +i +l +n. It was my understanding this was being aimed at another network out there that could actually use such a feature, and I am only trying to answer them. -- http://www.mediadesign.school.nz/ CAUTION: This communication is confidential and may be legally privileged. If you have received it in error you must not use, disclose, copy or retain it. Please immediately notify us by return email and then delete the email. This message has been scanned for viruses and dangerous content by MailScanner with McAfee UVScan, and is believed to be clean.
Re: [Coder-Com] Patch idea.. any thoughts?
One line of options might be to offer some user specific server mode, similar +d (but only blocking joins/parts from a channel -- still leaving the issue of quits), or some channel specific (rather than host specific) server side utility such as +silence (again, modified to filter joins/parts, and in this case possibly even quits). Client side solutions could not work because they, at best, filter or redirect incoming information. This still leaves the bandwidth issues for truely large channels. Undernet definitely has a need for a utility like this for their #class services. I have been trying to view these for years and have been driven out by the mass of joins/parts/quits. pzl - Original Message - From: "peter green" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, July 28, 2002 3:13 AM Subject: Re: [Coder-Com] Patch idea.. any thoughts? > I think i have a soloution to your problem which would requier much less > upheavel > > first you add a channel mode which redirects limit blocked clients to > another channel > > then you have a bot which replicates the traffic > > >From: [EMAIL PROTECTED] > >To: [EMAIL PROTECTED] > >Subject: Re: [Coder-Com] Patch idea.. any thoughts? > >Date: Sun, 28 Jul 2002 01:42:31 +0100 > >MIME-Version: 1.0 > >Received: from mc2-f17.law16.hotmail.com ([65.54.237.24]) by > >mc2-s14.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 27 > >Jul 2002 17:48:01 -0700 > >Received: from trek.sbg.org ([66.134.137.28]) by mc2-f17.law16.hotmail.com > >with Microsoft SMTPSVC(5.0.2195.4905); Sat, 27 Jul 2002 17:47:47 -0700 > >Received: (from undernet@localhost)by trek.sbg.org (8.12.1/8.12.1) id > >g6S0gbRd032709for coder-com-outgoing; Sat, 27 Jul 2002 17:42:37 -0700 > >Received: from mercury.stbarnab.as ([212.115.48.196])by trek.sbg.org > >(8.12.1/8.12.1) with ESMTP id g6S0gZJs032706for <[EMAIL PROTECTED]>; > >Sat, 27 Jul 2002 17:42:36 -0700 > >Received: from ground.stbarnab.as ([212.115.48.200] ident=mail)by > >mercury.stbarnab.as with esmtp (Exim 3.36 #2)id 17Yc8o-00027l-00for > >[EMAIL PROTECTED]; Sun, 28 Jul 2002 00:42:34 + > >Received: from davidm by ground.stbarnab.as with local (Exim 3.35 #1 > >(Debian))id 17Yc8l-0001UP-00for <[EMAIL PROTECTED]>; Sun, 28 Jul 2002 > >01:42:31 +0100 > >Message-ID: <[EMAIL PROTECTED]> > >References: <[EMAIL PROTECTED]> > ><[EMAIL PROTECTED]> > >In-Reply-To: <[EMAIL PROTECTED]> > >User-Agent: Mutt/1.3.28i > >Sender: [EMAIL PROTECTED] > >Precedence: bulk > >Return-Path: [EMAIL PROTECTED] > >X-OriginalArrivalTime: 28 Jul 2002 00:47:48.0052 (UTC) > >FILETIME=[64CE8140:01C235D0] > > > >On Sat, Jul 27, 2002 at 02:43:11AM -0400, Py Fivestones wrote: > > > > > Doesn't that pretty much destroy the concept behind IRC, that is to > >allow > > > people to chat with each other? Also, don't people on a channel have the > > > right to see who they are keeping company, and thus being associated > >with? > > > >The mode under discussion is only for use for very large channels (and if > >implemented would probably only be settable on channels at least 500 users > >or something). Under these circumstances the points you mention are less > >important (particularly if without the mode the users can't stay on the > >network!). > > > > > The other question is, will this channel mode break IRC clients? > > > >If the implementation works as I envisage it, not really. There would be > >users on the channel that the ircd knows about but the client doesn't, but > >there is no way for the client to find out about them anyway (they can't > >talk or anything, and nick changes etc. would be supressed). Enabling ops > >to see all channel members would allow bots to function normally, too. > > > >splidge > > > > > _ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com >
[Coder-Com] Allowed Hostnames Patch Required?
#ZT Recently had a security issue caused by an 'interesting' hostname. theZoMBiE is qqlaw@#!/bin/sh.B-S-D.org was not Hostnames with ! in them are going to break clients, scripts and Coding are they not? Shouldnt these be disallowed?
Re: [Coder-Com] Allowed Hostnames Patch Required?
> #ZT Recently had a security issue caused by an 'interesting' hostname. I am still out on that ... I honestly need to see the Tcl script being used in #zt to say if it was an exploit or not. I can confirm 100% it wasn't a bug in Eggdrop .. and it's doubtful it's a bug in a Tcl script .. but I need to see the Tcl script in question to confirm that also. > > theZoMBiE is qqlaw@#!/bin/sh.B-S-D.org was not > > Hostnames with ! in them are going to break clients, scripts and Coding are > they not? Only if badly coded. > Shouldnt these be disallowed? Yes. Jeff
