ideas?
Michael
spam, that isn't the original intention of the email. I am just interested
to know peoples views and thoughts on IRC, if you get a chance could you
reply to this.
Why do you IRC?
What made you choose to IRC on your network?
What do you think makes a good IRC network?
Do you think that IRCops should be able to intervene in channel matters?
What else would you like to see done as far as networks
go? (policy/technical wise)
Do you like IRC services (any variant) ? why ?
thanks to anybody who takes the time to give some feedback on this :)
__
Michael Ross
Shard sh...@shadowfire.org
http://shard.cjb.net irc.shadowfire.org
-------------------------------------------------------------
"Friends are the part of our family we get to choose."
--unknown
-------------------------------------------------------------
Chika
Michael <s35...@student.uq.edu.au> wrote:
> Why do you IRC?
I get to talk to folks.
> What made you choose to IRC on your network?
I didn't. IRC has been around on the Internet almost as long as the
Internet itself has existed, and if anyone did the choosing, it certainly
wasn't me!
> What do you think makes a good IRC network?
Users.
> Do you think that IRCops should be able to intervene in channel matters?
Yes. Otherwise there would be no point in having ops. Mind you, what do
you mean by "intervene in channel matters"?
> What else would you like to see done as far as networks
> go? (policy/technical wise)
Technically speaking, I see no problem with IRC itself. The biggest
problems are lags and splits, most of which are caused by the Internet
itself which is overloaded. Hence my biggest wish would be to increase
free bandwidth/reduce bottlenecks and increase general reliability. As far
as policy goes, I don't really see that policy has a great deal to do with
network provision.
> Do you like IRC services (any variant) ? why ?
That's a big question. You might want to take in the amount of services
and recast that question, especially if you want to take in such questions
of preference as client, server, nick/chanserv, scripting, bots and so
forth.
Michael
> > Do you think that IRCops should be able to intervene in channel matters?
> Yes. Otherwise there would be no point in having ops. Mind you, what do
> you mean by "intervene in channel matters"?
I mean should they be able to override the normal chan-ops and issue
things like /kills to settle issues. Or should they just let channels
fight it out for themselves?
> Technically speaking, I see no problem with IRC itself. The biggest
> problems are lags and splits, most of which are caused by the Internet
> itself which is overloaded. Hence my biggest wish would be to increase
> free bandwidth/reduce bottlenecks and increase general reliability. As far
> as policy goes, I don't really see that policy has a great deal to do with
> network provision.
What do you think of the suggestion that was issued here earlier about
mesh linking, so each IRC server has got a series of backup links to send
data over. Do you think that would improve network reliability?
> > Do you like IRC services (any variant) ? why ?
> That's a big question. You might want to take in the amount of services
> and recast that question, especially if you want to take in such questions
> of preference as client, server, nick/chanserv, scripting, bots and so
> forth.
More what I meant here (okay - this question was done badly) is do you
think a network can survive without services bots like nick/chanserv? also
on networks that have those bots what other features do you think services
could be doing?
thanks for replying :)
--
Chika
> > > Do you think that IRCops should be able to intervene in channel
> > > matters?
> > Yes. Otherwise there would be no point in having ops. Mind you, what
> > do you mean by "intervene in channel matters"?
> I mean should they be able to override the normal chan-ops and issue
> things like /kills to settle issues. Or should they just let channels
> fight it out for themselves?
Ahhh.... I see the misunderstanding. You refer to server operators rather
than opped channel folk. I often see this word IRCop misinterpreted as
some kind of lawgiver. The answer to that one is no, and unless he is
detailed specifically to a help channel and can be arsed, I don't see how
he could, let alone why! A busy IRC network is too much for that, and
besides that, the channel op is supposed to be the arbiter of justice. If
someone doesn't like that channel because they don't agree with that op,
then they can go set up another channel!
<snip>
> What do you think of the suggestion that was issued here earlier about
> mesh linking, so each IRC server has got a series of backup links to
> send data over. Do you think that would improve network reliability?
Could be good if it can be made to work fast enough. The problem is more
often not that a server isn't connected but that the network doesn't
physically see the server as gone from a specific link immediately, and
one danger of mesh linking will always be packet duplication, hence such
protocols as spanning tree, etc.
> > > Do you like IRC services (any variant) ? why ?
> > That's a big question. You might want to take in the amount of
> > services and recast that question, especially if you want to take in
> > such questions of preference as client, server, nick/chanserv,
> > scripting, bots and so forth.
> More what I meant here (okay - this question was done badly) is do you
> think a network can survive without services bots like nick/chanserv?
> also on networks that have those bots what other features do you think
> services could be doing?
I think that Efnet and IRCnet, among others, prove that nick/chanserv is
not an indispensible requirement, as long as you have reasonable
alternatives (eggdrop bots, etc.) Indeed some folk I know even object to
eggies on a channel and will avoid them like the proverbial plague! As for
extra services, I'm not sure that I really need anything more. One of the
pleasures of IRC is the simplicity of it all, and clogging up the works
with extra service droids could kill all that. But that's me, the classic
Gates-hater! :)
skold
>I'm not all familiar with other IRCD's, but the one on the network I IRCop
>on lets you ping server->server and measure pack speeds. I was thinking
>that you would more get each server to ping each of its other links on
>like 1-2 minute intervals, then off that build up a dynamic routing table.
All IRCds ping the server->server links, the problem is when a server drops
off between pings. (and while the server waits for the ping to timeout)
The easiest way I can think of to avoid having serveral servers split
because of one is for all servers to have lines for the other servers, so
any server on the network can connect to any other server. (Which pretty
much eliminates leaves..)
I'd still prefer to do the routing manually though ..
Michael
> Could be good if it can be made to work fast enough. The problem is more
> often not that a server isn't connected but that the network doesn't
> physically see the server as gone from a specific link immediately, and
> one danger of mesh linking will always be packet duplication, hence such
> protocols as spanning tree, etc.
I'm not all familiar with other IRCD's, but the one on the network I IRCop
on lets you ping server->server and measure pack speeds. I was thinking
that you would more get each server to ping each of its other links on
like 1-2 minute intervals, then off that build up a dynamic routing table.
That should allow it to change roughly as the links change, also, since
the server will only send the packet out over the best path at any one
time there will only be one packet kicking around for it. That way you
shouldn't get a problem with duplication.
> But that's me, the classic Gates-hater! :)
*applause*
Ian Westcott
: In article <Pine.OSF.4.21.000112...@student.uq.edu.au>,
: Michael <s35...@student.uq.edu.au> wrote:
:> Why do you IRC?
: I get to talk to folks.
:> What made you choose to IRC on your network?
: I didn't. IRC has been around on the Internet almost as long as the
: Internet itself has existed,
Not quite true. }:> The Internet is about 30 years old. In it's modern
form, the "Internet Protocol" (which we still use) was established in...
roughly '80 or '81 or so (have to check the RFC). Irc however... '89?
--
Ian Westcott Rakarra@IRC
rak...@pacbell.net
Stephen Mercer
The RFC is dated May '93, although I think you could be right, I seem to
remember it kicked around in non RFC'd form a few years before...
--
Quality scripts, no SlowDrown style lameless:
http://www.flatworld.u-net.com/mirc/
uni...@cal16a011.student.utwente.nl
>> Not quite true. }:> The Internet is about 30 years old. In it's modern
>> form, the "Internet Protocol" (which we still use) was established in...
>> roughly '80 or '81 or so (have to check the RFC). Irc however... '89?
> The RFC is dated May '93, although I think you could be right, I seem to
> remember it kicked around in non RFC'd form a few years before...
What is IRC?
IRC stands for "Internet Relay Chat". It was originally written by
Jarkko Oikarinen (j...@tolsun.oulu.fi) in 1988. Since starting in
--
Arnold Hendriks
I have no opinion and no employer.
David Rientjes
On Wed, 12 Jan 2000, Chika wrote:
>> I mean should they be able to override the normal chan-ops and issue
>> things like /kills to settle issues. Or should they just let channels
>> fight it out for themselves?
>
>Ahhh.... I see the misunderstanding. You refer to server operators rather
>than opped channel folk. I often see this word IRCop misinterpreted as
>some kind of lawgiver. The answer to that one is no, and unless he is
>detailed specifically to a help channel and can be arsed, I don't see how
>he could, let alone why! A busy IRC network is too much for that, and
>besides that, the channel op is supposed to be the arbiter of justice. If
>someone doesn't like that channel because they don't agree with that op,
>then they can go set up another channel!
Channel operators deal with channel issues while IRC operators deal with
server issues. It's always been this way and should never change...
-- David-R
Vegard Engen
David Rientjes <rien...@mail.whidbey.net> wrote:
>
>Channel operators deal with channel issues while IRC operators deal with
>server issues. It's always been this way and should never change...
...however, those two MAY overlap. A person might well use a bunch of clones,
flooding the hell out of a channel, thereby gaining op. The act of the
clones/flooding is server abuse, the act of gaining op afterwards is not...
This is an important difference. As a server-administrator, I might decide to
K-line a person for the first offence. But, after that is done, I should NOT
do anything about the ownership of the channel, as I do not know who it
"belong" too.
I've numerous times seen that an incident as the one described here are just
the last of a series of incidents, often part of a dispute between several
groups. Thus, he might just be retaking a channel that was taken from him
yesterday, which he took the day before that. In this case, it *is* important
to separate server-abuse from channel-abuse. Channel-abuse is the
responsibility of channel-ops. If you lose your op-ship through that abuse,
that's too bad, but such happens. And it's not within IRC-operators
responsibilities to do something with that.
This is at least how it traditionally has been, at least since the net gained
SOME mass. In the early days, it was a little different, as everyone could
pretty much have a full view on what was going on....
- Vegard