zynk/irssi
2
0
Fork 0
mirror of https://github.com/irssi/irssi.git synced 2026-08-22 18:12:12 +02:00
Code Issues Projects Releases Packages Wiki Activity

Add documents of historical interest

Browse source
This commit is contained in:
Christine Dodrill 2015-11-25 15:35:17 -08:00
commit 1567cd46bb
5 changed files with 5730 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/historical/README.md Normal file
View file

@ -0,0 +1,4 @@
Documents of Historical Interest
================================
The documents in this folder are largely irellevant to the scope of this project, but are included here as they may be of historical interest based on the cultural development of the IRC community.

272
docs/historical/Tao-of-IRC.940110 Normal file
View file

@ -0,0 +1,272 @@
The Tao of Internet Relay Chat
Copyright (C) Ove Ruben R Olsen 1994
Version of 940110
Contributing masters: Master ScottM
-----
Something is formed by the electrons, born in the silent cable. Shaping
and growing and ungrowing. It is there yet not there. It is the source of
Internet Relay Chat. I do not know the name, thus I will call it the Tao
of Internet Relay Chat.
If the Tao is great, then the IRC is running ceaselessly. If the IRC is
great then the server is running without ever stoping. If the server is
great then the client will always be the server. The luser is then pleased
and there is Chat in the world.
The Tao of IRC squits far away and connects on returning.
-----
The genetic potential of birth, a lot to know, yet unknown.
In the begining there was nothing.
Out of nothing the Tao gave birth to tolsun.oulu.fi. tolsun gave birth to
OuluBox.
OuluBox gave birth to rmsg.
rmsg was not Tao, so MUT gave birth to IRC.
No one knows when IRC came into existance, the mighty master WiZ have it
to be at the end of the eight month in the year of the Dragon.
-----
Each channel has its purpose, however humble. Each channel is the Yin and
Yang of IRC. Each channels has it's place within the IRC.
In the beginning there was only channel 0, thus channel 0 is the soil of
IRC.
Channel 1 to channel 10 then was open as the sea. Channel 11 to 999 was the
trees and forests of IRC. Channels above 999 should not be mentioned, and
channels below 0 were unborn and contained many secrets.
This was not the right Tao, so IRC gave birth to +channels.
+channels had the yin and yang. Mode does not.
This was not the right Tao still, so IRC gave birth to #channels.
#channels have the yin and yang.
Only channel 0 is the right path to Tao, but avoid speaking on channel 0.
-----
There was a great dispute among the Broom-Walkers of the Relay. Some of them
wanted neither yin nor yang. Out of this Eris came into existance. Some of the
Broom-Walkers then created Eris Free-net.
This was the right Tao.
Kind Gentle and Boring Net was another wrong path to the Tao of Internet Relay
Chat.
Some time later there was a quantity of some lusers who wanted to be
Broom-Walkers also. The Eris Free Broom-Walkers did not agree with them,
thus a new IRC was born. This IRC is called the Undernet.
But this is not the right Tao, either.
-----
There will always be disputes among the Broom-Walkers of Internet Relay Chat.
This is the very nature of the IRC.
-----
Lusers that do not understand the Tao is always using the yang of Mode on
their channels. Lusers that do understand the Tao are always using Ignore
on their channels.
How could this not be so ?
-----
The wise sage luser is told about the Chat and uses it. The luser is told
about the IRC and is looking for it. The flock are told about the Tao and
make a fool of the IRC.
If there was no laughter, there would be no Tao.
-----
The master says:
"Without the Tao of Internet Relay Chat, life becomes meaningless."
The Relay of the old time was mysterious and sacred. We can neither imagine
its thoughts nor path; we are left but to describe.
-----
The sage luser must be aware like a frog crossing the highway.
-----
The great master Wumpus once dreamed that he was an automaton. When he awoke
he exclaimed:
"I don't know whether I am Wumpus dreaming that I am a client,
or a client dreaming that I am Wumpus!"
So was the first Automata born.
The master Nap then said:
"Any automata should not speak unless spoken to.
Any automata shall only whisper when spoken to."
Thus replied the master Gnarfer:
"The lusers shall keep in mind that a automata can be either good or
bad. Create good automata, and the IRC will hail you and you will
gain fame and fortune. Create bad automata and people will start to
hate you, and finaly you will be /KILLed to ethernal damnation"
Many lusers have fallen into the clutches of ethernal damnation. They where
not following the Tao.
-----
There once was a luser who went to #BotSex. Each day he saw the automatons.
The luser decided that he also would have such a automata.
He asked another luser for his automata. The other luser gave his automata
away.
The luser was not within the Tao, so he just started the automata. The automata
had only Yang inside so all the lusers files where deleted.
Some moons laither the same luser then had become a sage luser, and did create
his automata from the very grounds with materials found inside the IRC.
The luser was now within the Tao and his automata lived happily ever after.
-----
There once was a master who wrote automatons without the help of master Phone.
A novice luser, seeking to imitate him, began with the help of master Phone.
When the novice luser asked the master to evaluate his automata the master
replied: "What is a working automata for the master is not for the luser.
You must must BE the IRC before automating."
-----
Master BigCheese gave birth to master Troy; his duty clear. Master Troy gave
birth to master Phone, for the Tao of Irc must be eternal and must flow as the
ceaseless river of Time itself.
-----
Master Phone once said about the ircII client:
"public_msg is for a message from someone NOT on the channel
public_other is for a message on a channel that doesn't belong to
a window. public is for a message on a channel that belongs to a
window!"
Out of this raised the mighty chaos.
-----
The sage luser came to the master who wrote automata without the help of
master Phone. The sage luser asked the master who wrote automata: "Which is
easiest to make. A automata with the help of master Phone or an automata
made with the help of a language ?"
The master who wrote automata then replied:
"With the help of a language."
The sage luser was disapointed and exclaimed: "But, with master Phone you
do not need to know anything about the soil of IRC. Is not that the easiet
way ?"
"Not really" said the master who wrote automata, "when using master Phone
you are closed inside a box. For sure, it is a great box for the lusers,
but the master will need more power, thus a language is the only path to go.
With the language the master will never have to limit himself. When using
such a language the master will seek the best between the need and the
availibility."
"I see", said the sage luser.
This is the essence of Tao of IRC automatas.
-----
A client should be light and be used for communication. The spirit of a good
client is that it should be very convinient for the luser to use, but hard
for the luser who want to create automata.
There should never ever be too many functions or too few functions.
There should always be a ignore.
Without ignore the client is not within the Tao of Chating.
The client should always respond the luser with messages that will not
astnonish him too much. The server likewise. If the server does not, then it
is the clients job to explain what the server says.
A client which fails this, will be useless and cause confusion for the lusers.
The only way to correct this is to use another client or to write a new one.
-----
A luser asked the masters on #IrcHelp: "My client does not work".
The masters replied: "Upgrade your client".
The luser then wondered why the master knew. The master then told him about
the Protocol.
"Your client does not work beaucse it does not understand the server. Why
should it always work ? Only a fool would expect such. But, clients are made
by humans, and humans are not perfect. Only Tao is.
The IRC is solid. The IRC is floating, and will always be dynamic. Live with
that or /quit."
-----
The luser came to the masters of #IrcHelp, asking about the Tao of IRC within
the client.
The masters then said that the Tao of IRC always lies inside the client
regardless of how the client connects to the server.
"Is the Tao in irc ?" asked the luser.
"It so is" replied the masters of #IrcHelp.
"Is the Tao in the ircII, Kiwi, rxirc, vms, rockers and msa ?" asked the
luser.
"In all of them and in the TPC, irchat, zenirc, zircon X11-irc and even the
dos irc has the Tao" said the master quietly.
"Is the Tao in a telnet connection directly to the server ?"
The master then was quiet for a long time and said. "Please leave, such
questions are not within the Tao of IRC".
-----
The master says: "Without the Protocol of TCP the messages will not travel.
Without the client, the server is useless."
-----
There once was a luser who used the ircII client. "ircII can do anything I
ever need for using IRC" said the emacs client user, "I have /ON's, I have
assignments, I have aliasing. Why don't you use this instead of the huge
emacs client, which also has a messy screen?"
The emacs client user then replied by saying that "it is better to have a
scripting language that is the client instead of have a client that has
a scripting language." Upon hearing this, the ircII client luser fell silent.
-----
The master Wumpus said: "Time for you to leave. I did, now I'm happy."
The master Gnarfer replied: "Use, but never overuse IRC, then you will also
be happy within IRC"
-----
A luser came unto the masters of #EU-Opers and asked, "How can I be, yet not
be, a user@host within the IRC?"
The masters of #EU-Opers replied: "To be Tao is to be ones true self. To hide
ones self is not Tao, and is not IRC, you have much to learn before you shall
be at rest within the Flow of Irc. Please leave"

4950
docs/historical/bigmatix Normal file
View file

File diff suppressed because it is too large Load diff

367
docs/historical/operguide.txt Normal file
View file

@ -0,0 +1,367 @@
EFnet Oper Guide
Last update: 02-21-2002
Written and maintained by Riedel
E-Mail: dennisv@vuurwerk.nl
1. Commands you should know about
2. The client of your choice
3. Your primary responsibilities
4. Re-routing
4.1 Re-routing other servers and remote connects
5. Kills and klines
6. Kill and K-Line requests
7. Happy birthday!
8. Security
9. Know who your friends are
10. The TCM bot
11. Services
12. G-Lines
1. Commands you should know about
This is no longer covered here. IRCD-hybrid is changing too rapidly, so
this section would be outdated in no time ;) For an up-to-date version,
please download the latest hybrid at www.ircd-hybrid.org.
2. The client of your choice
There are many IRC clients around for a wide variety of operating systems.
Being an IRC Operator doesn't *require* you to use a UNIX client, however
I personally prefer UNIX-based clients. If you're familiar with UNIX and
use UNIX for opering, I suggest ircII / epic. There are a lot of scripts
available for those two clients, and it's not that hard to write scripts
yourself to suite your needs. It is important that you know how to operate
your client, and familiarize yourself with the options and features. For
whatever client you chose this goes for any of them: You should be in
control of your client, instead of the client being in control of you.
Resources :
www.mirc.co.uk - mIRC (MS-Windows)
www.irchelp.org - a variety of clients and scripts
ftp.blackened.com - several UNIX based clients available
3. Your primary responsibilities
As an IRC Operator, you're responsible for maintaining the server on a
real-time basis. You represent your server, and you represent the network.
Irresponsible / rude / offensive / stupid behavior may discredit your server
and the network. You should focus on the task you were chosen for...
maintainance. Sounds simple, no? It means getting rid of users that abuse
the service, enforcing the server's policy and keeping the server linked.
Users will ask you questions, and expect you to know all the answers.. after
all, you're the oper!
Be prepared for users trying to fool you, sweet talk you into things you
don't want, lie and deceive. Most users are handling in good faith...
however, the abusers have learned how to manipulate opers. They have studied
the alien creature 'oper' for ages like biologists study animals. Be
paranoid, be curious and be suspicious. I can't stress the importancy of that
often enough.
Second priority has the network. You were not chosen to maintain the network
but you were chosen to maintain the server. However, you may want to be able
to reroute servers. If you see something broken, don't be afraid to fix it.
If you do, be sure you fix things and don't make it worse. Before you
step into routing, be sure you've familiarized yourself with the network's
topology, and be confident enough to perform such actions. (re)routing is
covered in the next chapter.
Opers on the network depend on a trusting relationship. You can usually take
the word from an oper. Other opers are considered -trusted-, however, there
are exceptions. Sometimes even opers lie to opers to get things done. Don't
be afraid to ask for proof of a certain statement, such as logs.
This doesn't mean you distrust the oper in question, but -you- and you alone
are responsible for your actions. You call the shots on your server, unless
your admin says otherwise.
4. Re-routing
Re-routing is not hard, and it's not scary but it is important that you do it
right. The commands you'll use are SQUIT and CONNECT. First, a very simple
example. Let's say your server, irc.yourserver.com is lagged to it's uplink,
irc.uplink.com and you want to reroute your server. You have to think about
where you want your server to be linked, and you have to time your reroute.
An example topology :
irc.yourserver.com ---- irc.uplink.com
| | \
B C D
/ \
E F
/ \
G H --- O
/ | \ | \
I J K L M
\
N
In this case, you're uplinked by irc.uplink.com
irc.uplink.com also hubs B, C and D. Server B functions as hub for E and F;
F hubs G and H; H hubs L, M and O. G hubs I, J and K. M hubs N.
Your server is allowed to connect to server B, F and G. So you consider the
servers you're able to connect to. Is the lag caused by a server that uplinks
irc.uplink.com ? Use /stats ? irc.uplink.com to determine lag to the other
servers. If irc.uplink.com does not respond, the lag is to your uplink. If
so, you cannot be sure about the state of the other uplinks, so you'd have to
get on a remote server and determine lag by using /stats ? and /trace. For
example, you could connect to server N, and /trace yournick. Yournick, being
the nick on your server. You'll see which route it takes, and what the
problem server is. Example /trace output :
S:[SERVER-N ] V:[2.8/hybrid] U:[SERVER-M ]
S:[SERVER-M ] V:[2.8/hybrid] U:[SERVER-H ]
S:[SERVER-H ] V:[2.8/hybrid] U:[SERVER-F ]
S:[SERVER-F ] V:[2.8/hybrid] U:[SERVER-B ]
S:[SERVER-B ] V:[2.8/hybrid] U:[irc.uplink.com ]
S:[irc.uplink.com ] V:[2.8/hybrid] U:[irc.yourserver.com ]
The trace doesn't complete... server-b announces irc.uplink.com, and
irc.uplink.com announces your server. Your server should return something
like :
S:[irc.yourserver.] OPER [yournick!user@yourhost]
If it doesn't, we know the lag is only between yourserver and uplink.
Usually if there is lag between your server and your uplink, the send-queue
rises. This is not always the case. Sometimes your server can write perfectly
to your uplink, but not reverse. That is called one sided lag.
We pick server B to link to. It means we have to SQUIT and CONNECT.
To unlink from irc.uplink.com and connect to SERVER_B we'd type:
/quote SQUIT irc.uplink.com :reroute
/connect SERVER_B
we *DON'T* SQUIT irc.yourserver.com... and I'll try to explain why:
If we wanted to remove hub M from the network, and with it N, we'd issue
a SQUIT M. An SQUIT follows a path, relays the SQUIT request to each server
in that path. Finally it reaches server H, which is the hub for M. Server H
sees the SQUIT and drops the link to M.
Now a different situation, we want to separate yourserver, uplink, C and D
from the rest of the network, in order to reroute. We'd have to SQUIT server
B, since we want the -uplink- of server B (being irc.uplink.com) to drop the
link to server B.
If you'd SQUIT irc.yourserver.com, you ask yourserver.com to drop the link to
itself, which is impossible. If you SQUIT irc.uplink.com, you ask yourserver
to drop the link to uplink, which is what we want to do.
After the SQUIT and CONNECT, the new situation looks like this :
irc.uplink.com
| | \
irc.yourserver.com -- B C D
/ \
E F
/ \
G H --- O
/ | \ | \
I J K L M
\
N
If yourserver is a Hub, it makes the situation more complex, since your
actions have more impact.
4.1 - Re-routing other servers and remote connects
Example topology :
irc.uplink.com
| | \
irc.yourserver.com -- B C D
/ \
E F
/ \
G H --- O
/ | \ | \
I J K L M
\
N
Let's say, hub H is way lagged to F, but G to F is fine... we want to reroute
H, and stick H to G.
We'd do :
/quote SQUIT serverh :re-routing you babe
/connect serverh 6667 serverg
A global wallops will be sent :
!serverg! Remote CONNECT serverh 6667 from ItsMe
When re-routing, always give the server some time to prevent nick collides.
When there is lag, people will connect to another server. When you SQUIT and
CONNECT to fast, a lot of those clients will be collided. Also, stick to your
territory. How enthusiastic you may be, you cannot route the world. If you're
an oper on the US side, stick to the US side when re-routing. Needless to
say, if you're EU, keep it to EU ;)
5. Kills and klines
As an oper, you're given the incredible power *cough* of KILL and KLINE.
/kill nick reason disconnects a client from IRC with the specified reason.
A /quote kline *evil@*.dude.org :reason here bans the user from your server.
Abusive kills and klines may draw attacks to your server, so always consider
if a kline or kill is deserved. If the server gets attacked after a valid
kill or kline, well.. tough luck. You should never be 'afraid' to kline
anyone on your server. If it's a good reason, make it so. Even if you know
it may cause the server to be attacked. Maybe good to think about is this:
- if /ignore solves the problem rather than a kick, /ignore
- kick if a ban is unneeded
- ban if a /kill is unwarranted for
- kill rather than kline if that solves the problem
- kline when a server ban is really needed.
You kline a user when you absolutely don't want this user to use the service
your server is providing.
Crosskills (killing users on another server) are another issue. Some admins
don't care if users get /kill'ed off their server, for any reason or no
reason at all... and other admins are very anal about it. A good way to go
(IMO) is to issue a KILL if there is an absolute need for the target user to
be disconnected. If there are active opers on that server, let them handle
it. They'll be upset if you /kill a user off their server, without
contacting them. /stats p irc.server.here shows the active opers on a
particular server. Some opers have multiple o-lines and are not watching all
sessions. If you can't find an active oper on a server, you can
/quote operwall a request for opers from that server.
Ghost KILLs are another story, an often misunderstood one.
When you see a /KILL from an oper with the reason 'ghosted' they usually
KILL a client that's about to ping timeout. That is not what a ghost is!
To quote Dianora: "a ghost happens because a client misses being killed when
it should be. Its a race condition due to nick chasing". In other words,
Server X thinks client A has been KILLed, while server Y missed the KILL
for that client.
6. Kill and K-Line requests
As previously mentioned, if an oper from another server contacts you and
requests a kill or a kline for a local client with a good reason, you can
usually trust this request. Opers depend on a trusting relationship. However,
since you're responsible for the kill or kline, it is not rude to ask for
proof. It depends on the oper making the request how thats interpreted, but
the way they respond to asking for proof tells more about them than about
you.
The more and longer you oper, how better you get to know the other opers.
You know who is honest, you'll know who are lying and deceiving. Before
you acquire this knowledge, you can merely rely on common sense and
instincts. You'll probably make mistakes occasionally, and thats nothing to
be ashamed of. Opers are - despite contrary believes - human.
Users occasionally will ask you to kill or kline a user/bot too. Some
requests are straight-forward and clear, others require you to be cautious. I
recommend to always investigate such requests, and when you're confident the
request is valid, issue the kill or kline.
7. Happy birthday!
It is a custom on EFnet to birthday /kill opers of whom it is his/her
birthday. Not all opers like this, but typically those opers don't let
others know about their birthday. You'll notice that the KILLS say a lot
about who likes who and who is friends with who. Whether you want to
participate, is entirely up to you.
8. Security
As with any privilege, you have to handle it cautiously and responsibly.
Be sure that your o/O line doesn't get compromised! Oper only from secure
hosts. You and only you should know your password. Don't share your oper
account, and make your oper password a UNIQUE one. If your o/O line gets
compromised, nasty things may/will happen. Imagine an oper with crosskill
capabilities who's operline gets 'hacked'... the results are often
disastrous and you will lose respect and trust from others. It can cause
your oper privileges to be revoked, or even the server to be (temporarily)
delinked.
9. Know who your friends are
As an oper you will get a lot of users that want to be 'friends' with you.
Users offer you free* access to their *nix servers, ops in channels,
unlimited leech access to the biggest and fastest warez sites *gasp* and
more. They want favors in return. They say they don't but they truly want
something in return. They -expect- something in return. You could either
don't respond to such offers, or use them. The last option creates an even
more distorted image of opers and doesn't do any good for the user <-> oper
relationship. Your *real* friends are usually the persons who were your
friends _before_ you acquired the extra privileges.
10. The TCM Bot
A TCM bot can be a valuable tool for opers. It keeps record of all connected
clients, flags clients with multiple connections and has all sorts of other
useful commands. There are three different kind of TCM's in use on EFnet,
being OOMon, TCM-Dianora and TCM-Hybrid. Every one of them requires you to
log in to be able to access the privileged commands. On OOMon you DCC chat
the TCM bot and do '.auth yournick yourpass' where yournick is your oper
name in your o/O line. In TCM-Dianora and TCM-Hybrid you register with:
'.register yourpass', where yourpass is your password ;)
All TCM commands start with a period. If you forget the period, the text goes
into the 'partyline', where it is echoed to all connected opers.
Resources : http://toast.blackened.com/oomon/help
http://www.db.net/~db/tcm.html
11. Services
A recent addition to EFNet is Channel Fixer, aka ChanFix. This is an
automated service that re-ops clients on opless channels. There are a few
restrictions. First, the channel has to be of significant size for ChanFix
to store it in its database. Second, it only logs static addresses.
How does it work? Periodically it stores information about the channel state
in its database, for every channel in there. On every 'run', a channel
operator gets one point. These scores make a top-5 of 'most frequent opped
clients'. When a channel becomes opless, ChanFix will join and op the top-5
opped clients CURRENTLY IN THE CHANNEL.
Chanfix can be invoked manually by server administrators. /msg ChanFix
chanfix #channel is the command to do it. ChanFix will join, and treat the
channel as if it were opless. It lowers TS by one (resulting in a deop of
the entire channel) and re-ops the top-5 clients currently in the channel.
The Channel Fixer won't log or actively fix channels when there's a split of
significant size. Needless to say, the chanfix command must be used with
caution.
12. G-Lines
Oh yes! A G-Line section. Currently, a part of EFNet (EU-EFnet) has G-Lines
enabled. This was decided by the EU admin community and is now mandatory
within EU-EFnet. In order for a G-Line to be activated, three opers from
three different servers need to issue the _exact_ same G-Line. The reason
is not counted.
G-Lines work best when the EU side of EFNet is not fragmented. G-Lines
will, however, propogate through a Hybrid 6 hub (but not a CSr hub) even
if the hub server has G-Lines disabled. This propogation allows two halves
of EU-EFnet to have concurrent G-Lines set even when split by US hub servers.
Questions / Comments / Suggestions are welcome.
You can e-mail me: dennisv@vuurwerk.nl
Best regards,
--
Dennis "Riedel" Vink ___~___ Email - dennisv@vuurwerk.nl
Unix System Administrator \ | / Phone - +31 23 5111111
Vuurwerk Internet '|.|' PGP - 0xD68A7AAB
And on the seventh day, He exited from append mode.

137
docs/historical/opermyth.txt Normal file
View file

@ -0,0 +1,137 @@
Date: Thu, 30 Jul 1998 16:21:40-0700 (MST)
To: operlist@the-project.org
From: rayp@primenet.com (Ray Powers)
Subject: The myths of opers....
I've always wanted to write something like this.. Its half rant, half
fact, so bear with it. Hopefully it will be worth reading.
There's a lot of hate for opers for a lot of reasons. Some are directly
oper related (i.e. 99% of us are colossal assholes), some are directly
user related (i.e. 99% of you are raving lunatics), and some is just plain
misconceptions. I'd like to take a minute to talk about part three in
hopes of clearing a few things up. This will kind of be in a FAQ form,
maybe you'll like it, maybe not, but its worth a shot.
Q: What can an oper on EFnet do.
A: This is an EXACT list of what we can do:
1) /squit a server, separating it from the rest of the net
2) /die our server
3) /kill a user, this disconnects them from the server they are on
4) /kline a hostmask, this bans them from our server
5) /dline an ip, this bans them from our server, regardless of
hostmask
6) See all invisible users on our server
7) Mass Msg/CTCP/notice a hostmask
8) Mass Msg/CTCP/notice a server
9) See and send Operwall/wallops notices
That's it. We can see more server messages than you, but that's not the
point.. The point to be shown here is very simple, *none* of these things
have anything to do with channels. Which leads us to our next question.
Q: What can opers *NOT* do, but keep being asked to anyways?
A: We can *NOT*:
1) Enter a channel that is +i or +k without being invited or
having the key
2) See who is inside a +s channel
3) Op ourselves or op you on a channel (unless of course we are a
channel op for that channel)
4) Tell you what XXXX's new nick is since they changed it to hide
from you.
5) Deop someone for you on a channel (unless of course we are a
channel op for that channel)
Notice a trend, with the exception of 4, all of these are 100% channel
related. EFnet is made so that opers have *NO* power of channels, for
better or worse. If we don't help you with these requests, its not because
we won't, its because we are completely incapable doing so. On the other
hand....
Q: What can opers do, but won't?
A: This will be a bit differently done, because I figure I should explain
why opers don't do these things, when they may normally make sense.
1) Why won't they kill somebody who has stolen your nick.
EFnet has gone on the basis of nicks not being owned, which is
why there is no nickserv on EFnet. Of course we see opers kill
all the time for nicks, though, so it seems rather hypocrital,
doesn't it?
An oper who kills for his nick will tell you its because the
other person was a bot, was juping his nick, or was imitating an
oper. It may be true, but it really comes down to the same
feeling you get when your nick is taken "Hey! that's my name! I
don't want that person using my name!"
I personally, do not kill for nicks. If someone takes my nick,
they can have it. Let them get my several hundred messages a day.
:P But the problem with the oper is this: How does an oper know
that you are really the person that uses that nick, or are you
the guy that wants to nick jupe that nick out from the real guy?
Unless the oper knows you well, they don't.. And saying that
people generally tell the truth means you haven't been on EFnet
very long.
I would prefer to think I am one of the more well respected
people on the net and people still lie to me on a regular basis.
So, the oper is stuck refusing to help because he can't tell who
is who. Remember this line of reasoning, its going to be coming
up a lot. :P
2) Why won't they kill that guy nuking/smurfing/ping -f'ing me?
This one is simple. There is no way to prove that somebody is
doing any of these things to you from an opers point of view. All
logs are fakeable, and the oper has no way to firsthand prove its
happening. Your best bet in this situation is to log what you can
and complain loud and long to their ISPs.
3) Why won't they help me take my channel back?
There's a bunch of answers to this. First, it is popular
opinion at EFnet that channels are not owned, and therefore, if
you lose a channel, you should go make another one. Notice I
say popular instead of official, because EFnet has never had an
"official" policy on much of anything.
But more and more you see opers killing for takeovers, so why
are they helping their channels and not yours.
Well, first, let's say your channel was taken over, and is now
+smtinlk. How exactly is the oper supposed to find out who is
oped in the channel right now to mass kill them? Even if they do get
all the nicks, they have to somehow manage to kill them all in
one hit, or they'll all just op each other again and it will be
fruitless. Or worse, they could have it all set up, and some
other oper could kill them halfway through because they don't
like mass-kills and it would be all ruined.
Or, let's say the mass-kill goes off, then the channel is
opless and generally speaking, chaos begins. People start
mass-nuking or flooding the channel to clear it out, or just to
be annoying. And there's still a 50/50 chance that takeover
people will get the channel back on a split and we'll have to try
to do it all over again.
If you're about to ask why they don't split their server,
the answer is very simple: We are not about to screw up roughly
30,000 peoples chatting for your channel. Its rude. This of
course is all based on the fact that we can prove its taken over,
as per the conversation about nicks, we often can't.
4) But.. its obvious they took it from me! The topic says
"Ha ha, we took your channel Rick!" for Pete's sake! And
there's only One op, so you can kill him and get the channel
back immediately!
This one is a bit more complex, but its really a personal
call. That one op could be a rampant smurfpup with a penis so
tiny he has no choice but to rampantly smurf and synflood anyone
that gets in his way. This is popularly known on irc as SPS, or
Small Penis Syndrome. In this case, if the oper does help you
out, they could end up with their server being downed for a day
or two, and it really isn't worth it for your channel, no
offense.
Keep in mind that this is all spoken from the perspective of someone who
*DOES* help with channels when possible, but understands greatly the
reasons not to, and judges each situation very carefully.
That's the gist of the information I was trying to get across. If you
were cluefull enough to get on operlist, a lot of this may be common
knowledge to you, but sometimes its good to step back and see why opers do
what they do a lot of the time.
Hoping this is of value to SOMEONE....
Ray Powers
Monkster/MimePunk/PrimeMonk/PacMonk/MtgMonk/Ihavefartoomanynickstonickjupe