Jump to content

Talk:IRCd

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Stability

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.
It is unlikely we (IRCd coders) will ever make public stability testing and such between different IRCds. A lot of information on this article from stability to numeric channels can currently only be proven by reading the sourcecode. In my opinion, this article probably shouldn't exist on wikipedia since it breaks the majority of citation rules, what is citable (outside of sourcecode) isn't really worth an article. Ash-Fox (talk)

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)[reply]

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)[reply]

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.)

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)[reply]

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)[reply]

No notable sources whatsoever

This article has no notable sources whatsoever, just a bunch of stuff that fail WP:SOURCE at the bottom and most of the article is inaccurate. William Ortiz (talk) 10:56, 6 August 2008 (UTC)[reply]

A lot of things mentioned in the article are true, such as numeric channels, but there is no real evidence beyond the original sourcecode of "irc", which probably cannot be submitted as evidence on a wiki. What annoys me is the bit about official ports, the "irc-serv" port is not related to Internet Relay Chat. Ash-Fox (talk) —Preceding undated comment added 20:58, 1 April 2009 (UTC).[reply]

Source code and the RFCs can be cited, its just no one has done so yet. Tothwolf (talk) 23:12, 1 April 2009 (UTC)[reply]
I am unable to find the "irc" and "irc-serv" ports in the RFCs (funny enough, 6667 is actually mentioned). So I really wonder who decided they should be standard IRC ports and if they have ever been used somewhere. I wasn't able to find any good sources on the web so far. Yarcanox (talk) 20:59, 14 May 2009 (UTC)[reply]
You'll probably have to dig into the IANA site for information on the official ports. [2] Tothwolf (talk) 23:22, 14 May 2009 (UTC)[reply]
Thanks for the tip, found the sources now and referenced them. Yarcanox (talk) 15:00, 21 May 2009 (UTC)[reply]

Ports

While the assertion that running servers on privileged ports (<= 1024) is true, it bears no practical relevance. Server software on Unix systems can acquire the privileged listen() port and then drop all privileges using setuid() - it should just make sure to do as little as possible while it is privileged. —Preceding unsigned comment added by 131.234.21.37 (talk) 16:28, 11 November 2008 (UTC)[reply]

The main reason for this in the past was actually to allow regular users to run a IRCd on shell accounts which did not have root access. Ash-Fox (talk) —Preceding undated comment added 20:56, 1 April 2009 (UTC).[reply]
Well, mainly to allow IRCd to be run anywhere without requiring root. Given the nature of the software it is much more secure when run as a non-root user. Tothwolf (talk) 23:19, 14 May 2009 (UTC)[reply]

Very strange organization regarding the *-lines - what to do?

I noticed the K-lines is merged into the IRCd article while the G-line isn't, but again the O-line is. Then K-line has a proper redirect and O-line just redirects to the whole article, and the G-line article is written as "Gline" and not "G-line", while all the others are written with that hyphen.

That some *-lines are merged into the IRCd article and others are not is IMHO pretty undesirable. I would love to change this, but I am not entirely sure what to do. Why did the K-line article get merged at all? Is there any reason why it shouldn't be separated? Or what about one article talking about the lines and merging and redirecting also the G-line article into it?

We could also finally merge all lines into the IRCd article but I think that's a bad idea. So either

  • have a separate article for every line or
  • one article with all the configuration stuff (jupe, g-line, k-line,...) in it (how should it be named?).

And is now G-line or Gline the proper term? (I'd vote for the latter actually, but it should at least be consistent across the different *-lines)

Please add your comment and if there are any clear opinions I will just be glad to get it done myself as it is imho ugly in the current mixed form and I am very willing to change this. So just shoot and tell me what you think. Yarcanox (talk) 15:05, 2 July 2009 (UTC)[reply]

Yes, it is indeed quite a mess. I did some preliminary work on it awhile back and had planned to start merging/rewriting this section about a month ago (shortly before the mIRCStats AfD happened). I had planned to merge and redirect Gline and Zline into this article and cleanup/restructure the configuration section. As for naming, there are all sorts of variations in common use: kline, Kline, K:line, KLine, k-line, K-line, K-Line. I'm not sure which we should standardize on but I had planned to look at the original IRCd distribution to see what it used and possibly use that. --Tothwolf (talk) 16:21, 2 July 2009 (UTC)[reply]
Looking at the common usage in the original IRCd, K line seems to be the most common (along with specific references to kill line for this particular configuration setting) with K-line and K:line also in common use elsewhere. This makes sense since the option was historically set in the plaintext config file as: K:<host|ip>:<time|comment>:<user|ident>:<port>: --Tothwolf (talk) 16:45, 2 July 2009 (UTC)[reply]
Going over my notes, I found I noted that there was even more in Internet Relay Chat operator#Ban Types. This is going to be an extremely complex split/merge process (while maintaining the attribution requirements for the GFDL) but I may have a go at it once I wrap up the other one I was working on. --Tothwolf (talk) 13:09, 3 July 2009 (UTC)[reply]
I think I've got it mostly straightened out now. I also discovered that Jupe (IRC) was merged as IRCd#Jupe and I'm not too sure if that really belongs in this article. --23:42, 5 July 2009 (UTC)
Wow great that you've fixed most of it already. I just didn't come around to work at it myself so soon (school ate a lot of my time). I think Juping is not too wrong in this article as some IRCds offer it in their main config to reserve nicks as described there (just my thoughts on it). Yarcanox (talk) 07:37, 10 July 2009 (UTC)[reply]
It is still far from complete, we still need to add information on all the different '*: lines'. If jupes are stored in some IRCd's config files then we should probably mention which common IRCds do that to clarify it. I think the IRCd comparison article is going to need a table to show which IRCd variants support which '*: line' as I don't see a way to work that in here and it would be best done in the comparison article anyway. I found some information on that in a book (although outdated) which can probably be used to start off the table. --Tothwolf (talk) 16:46, 10 July 2009 (UTC)[reply]

Definition of IRC daemon

If I write a PHP daemon that logs into IRC, joins #en.wikipedia, and collects data that is put out on that feed, is that program an IRC daemon within the meaning of this article? Thanks, Tisane (talk) 07:45, 8 May 2010 (UTC)[reply]

No, it would still be an IRC client because it is connecting to the IRC server (daemon) and it wouldn't matter if the program itself is run as a daemon or interactively. More specifically, it would be considered an IRC bot. --Tothwolf (talk) 08:49, 8 May 2010 (UTC)[reply]

Three of the seven external links shown at the bottom of the article (at the time of writing) appear to be broken. Two (GLine, KLine, QLine and ELine syntax and DarkFire IRC Manual (network specific)) lead to a 404 error. EFnet FAQ simply comes back with "No data received" when using the Chromium web browser. I'm unable to get to another computer to check if these issues are on my end or if they're more widespread. Can anyone else confirm these problems?

ihatefile007 (talk) 17:11, 21 February 2014 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified 6 external links on IRCd. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 09:24, 10 November 2017 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:IRCd&oldid=1207736988"