Talk:IRCd

From Wikipedia, the free encyclopedia

Codebase Stability is a matter of relative opinion recent Unreal IRCDs for instance are quite stable and function modularly allowing features to be added or not as the Server Administrator desires.


Bahamut's stability might also be questionable.

I will admit to a bit of bias in this regard (i maintain bewareserv see my user page for more info). However in response to your post bahamut held together what was the worlds largest irc network (and so far only one network has beaten that record) and kept reasonally stable in doing so. the largest unreal net i have ever seen was only a mere 5000 and was extremely splitty. That net has dumped unreal since i was there. Even on smaller nets i have seen stability problems with unreal and this wasn't on windows either (though unreal on windows is even worse). I have never seen such issues with the likes of ircu.
Bias should be eradicated on wikipedia! Anecdotal evidence isn't good enough to assess the comparative strengths and weaknesses of each ircd, either. -- Joolz 11:06, 6 Apr 2005 (UTC)
I've rewritten the article to remove any POV statements, however it is now shorter, so some work needs to be done to add more information. -- Joolz 13:10, 6 Apr 2005 (UTC)
I've further rewritten the article, removing all references to daemons -- though perhaps they may be added later as a list. There was *still* POV statements there ("unreal focuses on features, hybrid on stability") -- this is *wrong*. For reference, I've managed to get 60k users onto a single Unreal ircd, though it wasn't entirely pleasant. This is beside the point, however -- there should be no such statements. I've added a history section too, though it's not as complete as I would like. -- Anon.
A further consideration may be to simply redirect this article to 'Internet Relay Chat' - as much of the information here is also there, in more expanded form as I just discovered. -- Anon.

Contents

[edit] Page Name

Shouldn't this page be at IRCD, or perhaps IRCd, or maybe even Internet Relay Chat daemon? 'Ircd' just looks wrong. -- Joolz 17:13, 11 Apr 2005 (UTC)

IRCd or Internet Relay Chat daemon would be most correct in holding with the use of lowercase d for daemon in *nix --ShadowMaster 03:42, 8 May 2005 (UTC)

[edit] Socket Engine

Could we move the technical (socket engine) talk to its own section, away from the introduction? It's interesting technical information and relevant, but doesn't really fit into the introduction. Also, I'll try to write a "Standards compliancy" section later today (with a NPOV, focusing to the general state of things rather than pointing out things about individual ircds). Pasi 17:47, 24 May 2006 (UTC) (Update: haven't done this yet because the standards compliancy is somewhat addressed on the IRC article. I'll give it a second thought, even though I still believe it belongs to the IRCd article)


This is especially a good idea since the portion about multithreading is self-contradictory. That many operations need to *read* global state is not an argument against multi-threading. Essentially all modern computers permit caching of and concurrent access to unmodified data. Besides, there are numerous tasks IRC servers need to do that don't involve manipulating global IRC state, for example, parsing received data into lines and sending already-queued data to other servers. (And, of course, handling encryption if the server supports that.)


[edit] External Links

Hi everyone. I've replaced the external links section at the bottom of the page, however it now only references the 4 or 5 ircds mentioned on the article, and some technical pages linking to information about TS and ND protocols. In my humble opinion, it should stay this way, listing only whats relevent to the article, but should not be completely removed.

Braindigitalis 00:46, 8 April 2007 (UTC)

[edit] Juping

I just noticed that Jupe now redirects here, which is OK I guess, but I think it is inaccurate--Specifically, this part, as it reads now:

One possible explanation of how this term came about is that it is named after the user Jupiter, who did it to NickServ on dalnet. Most likely it originated on EFnet, out of the policy that nobody on EFnet owns any single nick or channel.

(emphasis mine)

First, that does not make much sense to me, but worse, I also believe it to be inaccurate.

Here is how it read for a pretty long time, in the Jupe article:

In Internet Relay Chat (IRC), juping a server, a channel, or a nickname refers to the practice of blocking said channel or nickname on the server or network. This is named after the user Jupiter on EFnet, who did it to NickServ.

[1]

It was changed here by an anon (that anon also made this edit). I believe that Jupiter juped the nickname NickServ on EFnet, because of the fact that EFnet does not have NickServ. The last time I was on EFnet, IRC ops do "jupe" the nicknames that some of the other networks use for services, because EFnet does not offer those services. They just "jupe" the nicks so that others cannot have them.

I believe the term "jupe" did orginate on EFnet, and it was because they do not offer NickServ...they did it so not anyone could hold the nick "NickServ", which could allow people to steal the passwords of nicknames for other networks.

I've typed this rather quickly, so I hope I am making sense...This is probably one of those things there will be no sources for, though I do not think that is an excuse to have inaccurate information. What do others think? daveh4h 22:13, 18 April 2008 (UTC)