Nicknames serve two purposes on IRC: they are both a means of identifying the person, and a shorthand identifier to perform actions on that person (like sending messages).
The former purpose requires long, descriptive identifiers. The latter requires short, concise identifiers. So there is a fundamental conflict.
What I am proposing is that there should be two identifiers. A longer one, global, which identifies the individual the way user@host used to; and a short nickname, local to each channel, used for messaging commands.
I know about nickname registration--did you miss the bit where I mentioned I was a DALnet user?
Nickname registration is the wrong solution, because it isn't scalable. Look at AIM, where you have people resorting to stupid nicknames because none of the reasonable ones are available.
Why they couldn't just stick the OS 7/8/9 Platinum interface on Unix, like they did with AUX, I'll never know.
Well, that's a matter of taste. Personally I hated Platinum, to the extend that I ran with a monochrome theme on my Mac to avoid it. I was absolutely delighted to see the back of its ugly grey visage. Aqua, on the other hand, is beautiful.
I also find the dock works well for me. I wish I could get the KDE kicker to be more like it. So not all Mac addicts share your distate for the X UI...
Many non-profit charities pay their CEO's millions in salary and bonuses. [...] Non-profits can pretty much do anything they want with their money. Large paychecks, bonuses, wasteful spending, whatever...
Yes, whereas you'd never see a for-profit corporation throwing obscene salaries and bonuses at its CEOs, or spending money wastefully.
1. Each server knows which channels the clients connected to it are on. It's pretty easy to turn that information into one list, which would then be used to filter server-to-server connections. Effectively, the server would work like a client of other servers.
2. It *might* be, in the current tree topology. It clearly isn't for the "leaf" servers, even in the current topology.
3. Users not being able to get a preferred nickname means users having a different nickname every time, which means users not recognizing each other. Plus, it doesn't matter if two people with the same nickname meet; all that matters is when two people with the same nickname both join the same channel, and that contention can be handled when the join is performed.
4. Have a mesh of servers, and those servers provide the connectivity for the clients. Servers can operate rather like Gnutella nodes, except that since there's a central list of servers which make up the network, it's easier to do authentication and to find another working node to connect to.
5. Clients not being able to interoperate due to lack of standardization may not be a problem for IRC-the-protocol, but it's a big problem for IRC-the-chat-system.
OK, based on my own experience having used IRC for ten years for both work and play, here are 10 ideas to massively improve it:
1. Nicknames need to be per channel. Users should be able to specify a list of preferred nicknames, and the system would then deal with contention by scanning down the list for one not in use on the channel, or as a last resort by appending numbers or underscores or whatever.
2. There needs to be a persistent identifier for users, so I can tell that the person who was madpope yesterday is freshgoat today. The user@host worked back in 1988 when everyone was using shared UNIX boxes to IRC, but now most users are on random dialup or dynamic DNS addresses it's useless.
3. There needs to be smart routing. If #warez_jp is only used by people on two servers in Asia, the network needs not to send the traffic everywhere else.
4. There needs to be rate limiting on the server to prevent abuse and stupidity. Not just bandwidth rate limiting, but limits to stop bots that spam by changing the topic every 0.1 seconds, auto-rejoiners, and annoying trolls who type one word per line.
5. There needs to be a way to indicate when users are busy typing, so people aren't tempted to break up a single sentence into lots of annoying tiny bits. Either that, or the client software needs to be able to reassemble the pieces on the fly if no other user has made an intervening comment.
6. Actions, file transfer, user info query, idle time/away, busy flags, font styles, and colors need to be part of the core standard, as well as user icons for graphical clients.
7. The server network needs to be a mesh, not a two-headed tree, so there's no single point of failure.
8. There needs to be permission-based message approval, like in Jabber, to prevent spambots. For person-to-person, a "do you accept?" and for channels, a way to require (optionally of course) that at least one person on the channel agrees to let the person in. Yes, you can do the latter via +v or channel keys, but it's a pain and users don't understand it because the entire protocol is visible to them rather than being handled automatically.
9. Once you have persistent identifiers (see above), there needs to be an ACL mechanism for channels.
10. Ideally channel nicknames would be locally assigned. When I find a channel I like and join it based on the description, I should be the one to pick the #whatever alias. (Of course, the channel operators could suggest one, like with user nicknames.) This would prevent channel wars caused by people wanting the same convenient channel nicknames, and stupid bots that exist only to stop people using a channel name and advertise some other channel.
If anyone actually doing development on IRC-like chat systems wants to talk to me about the above, I'd be happy to provide more detail, thoughts on how to implement, and so on, when I have time. meta@pobox.com
OK, let me outline a few of the problems with IRC:
1. It's a double-tree structure, which means all IRC networks have a single point of failure.
2. There's no smart routing, so the servers have to carry traffic even for channels that nobody connected to them is using.
3. Nicknames are global, which means there's contention for popular ones, even if the ten people who want to use mine would never otherwise run across me.
4. It's centralized on a few servers, so it's easy to DoS out of existence. (I know all about this; I was a DALnet user.)
5. There's insufficient standardization of everyday stuff people expect to have like colors, fonts, file transfer, away messages, and the like--so I see garbage instead of messages because they have colors in, people don't use/away because it doesn't work in all clients, actions don't always work, there are three or four different ways of getting idle time info, and so on.
Consider the same situation for IRC:
clients sends message to room.
room knows 'i have users from servers 1, 2, 3'
room relays message to servers 1, 2, 3 (three messages)
1, 2, 3 relay message to their client (3000 messages)
Resulting traffic: 3000 * sizeof(message)
Except (a) IRC doesn't do that, servers have to carry traffic even for groups that none of their users are in; and (b) there's nothing stopping you doing that in a later revision of XMPP by allowing group-addressed messages to be sent once to a server.
I own my Internet connection, and simple cost/benefit analysis suggested that the number of Taiwanese people sending me legitimate e-mail was close to zero, whereas the cost of dealing with spam from China and Taiwan ran into hours per month.
I fully appreciate that there are nice Taiwanese people who know how to run a server and are competent and responsible and don't spam... However, the cost of continuing to accept their e-mail is too high, because of their countrymen's bad behavior. So I block everything with Asian character sets in it, everything on the blacklists, and so on.
Similarly, there's some nice useful Windows software--but the cost of running Windows exceeds the benefit I'd get from running the software.
Yeah, that was my thought too. It's very much a case of rearranging the deck chairs on the Titanic.
The IRC protocol is flawed. Not just superficially broken, but horribly, fundamentally broken in numerous ways. As a result it's unreliable (prone to network splits), puts massively unnecessary load on servers, has problems with contention for nicknames, and so on. It really needs complete replacement.
Mind you, now that we have XMPP, there's a strong case for just letting IRC slowly die and having XMPP chat rooms take over.
Apostrophes are used to mark missing letters (amongst other things). Since "ho" is a shortened version of "whore", "ho's" is legitimately written with an apostrophe to mark the missing 'r' and 'e'--just like "we're" has an apostrophe to mark the missing 'a' of "we are".
If you're going to post stupid punctuation flames, get it right, dumbass.
The story also says they have to be able to drive a stick shift. I don't really understand why--we're talking engineers, not valet parking. Do aircraft engineers have to be trained pilots? Do TV repairmen have to have their own daytime chat show?
Sounds like an idea I posted here a while back. What it needs is a chance to pimp other characters in order to collect enough bling to get a fly pimpmobile. If the other characters don't cooperate, instead of drowning them in the pool you just bust a cap in their asses.
I don't see what your response has to do with my (sarcastic) comment. The point is that Naughty Dog's games run LISP, yet they don't sit and pause for garbage collection.
a) AIDS is hard to cure because HIV mutates a lot. It's hard to target because there are so many variants. They've recently discovered that HIV+ people can even become infected with multiple different mutations of HIV.
b) HIV infects the immune system. It's incredibly difficult to target the HIV virus without destroying the immune system in the crossfire, and once you destroy the immune system the person is pretty much dead in the long term. In fact, that's what makes AIDS deadly--the immune system is destroyed, the body can't fight off the dozens of illnesses we're exposed to every day, and the victim has a long slow lingering death from multiple diseases.
The combination of the two problems makes AIDS particularly tough to fight. You need incredibly specific drugs to target a constantly mutating virus.
Try Objective-C. 100% native code, total C compatibility, and you can freely mix manual (C-style) memory allocation, reference-counting semi-automatic memory allocation, and full garbage collection (with add-on libraries). Plus it only takes a weekend to learn if you already know C.
So, no, we won't (realistically) be able to turn off the garbage collector, which means that we won't be able to write real-time programs, and it'll even be touchy writing programs, such as, oh, audio or video players, that require near real-time performance
Slashdot Mirror
Nicknames serve two purposes on IRC: they are both a means of identifying the person, and a shorthand identifier to perform actions on that person (like sending messages).
The former purpose requires long, descriptive identifiers. The latter requires short, concise identifiers. So there is a fundamental conflict.
What I am proposing is that there should be two identifiers. A longer one, global, which identifies the individual the way user@host used to; and a short nickname, local to each channel, used for messaging commands.
I for one welcome this advanced Plutonian technology.
So long as Emory remembers to label the levers this time.
I know about nickname registration--did you miss the bit where I mentioned I was a DALnet user?
Nickname registration is the wrong solution, because it isn't scalable. Look at AIM, where you have people resorting to stupid nicknames because none of the reasonable ones are available.
Well, that's a matter of taste. Personally I hated Platinum, to the extend that I ran with a monochrome theme on my Mac to avoid it. I was absolutely delighted to see the back of its ugly grey visage. Aqua, on the other hand, is beautiful.
I also find the dock works well for me. I wish I could get the KDE kicker to be more like it. So not all Mac addicts share your distate for the X UI...
Yes, whereas you'd never see a for-profit corporation throwing obscene salaries and bonuses at its CEOs, or spending money wastefully.
1. Each server knows which channels the clients connected to it are on. It's pretty easy to turn that information into one list, which would then be used to filter server-to-server connections. Effectively, the server would work like a client of other servers.
2. It *might* be, in the current tree topology. It clearly isn't for the "leaf" servers, even in the current topology.
3. Users not being able to get a preferred nickname means users having a different nickname every time, which means users not recognizing each other. Plus, it doesn't matter if two people with the same nickname meet; all that matters is when two people with the same nickname both join the same channel, and that contention can be handled when the join is performed.
4. Have a mesh of servers, and those servers provide the connectivity for the clients. Servers can operate rather like Gnutella nodes, except that since there's a central list of servers which make up the network, it's easier to do authentication and to find another working node to connect to.
5. Clients not being able to interoperate due to lack of standardization may not be a problem for IRC-the-protocol, but it's a big problem for IRC-the-chat-system.
And similarly, the majority of large JPEG images transferred via HTTP are porn. So what is your point?
OK, based on my own experience having used IRC for ten years for both work and play, here are 10 ideas to massively improve it:
1. Nicknames need to be per channel. Users should be able to specify a list of preferred nicknames, and the system would then deal with contention by scanning down the list for one not in use on the channel, or as a last resort by appending numbers or underscores or whatever.
2. There needs to be a persistent identifier for users, so I can tell that the person who was madpope yesterday is freshgoat today. The user@host worked back in 1988 when everyone was using shared UNIX boxes to IRC, but now most users are on random dialup or dynamic DNS addresses it's useless.
3. There needs to be smart routing. If #warez_jp is only used by people on two servers in Asia, the network needs not to send the traffic everywhere else.
4. There needs to be rate limiting on the server to prevent abuse and stupidity. Not just bandwidth rate limiting, but limits to stop bots that spam by changing the topic every 0.1 seconds, auto-rejoiners, and annoying trolls who type one word per line.
5. There needs to be a way to indicate when users are busy typing, so people aren't tempted to break up a single sentence into lots of annoying tiny bits. Either that, or the client software needs to be able to reassemble the pieces on the fly if no other user has made an intervening comment.
6. Actions, file transfer, user info query, idle time/away, busy flags, font styles, and colors need to be part of the core standard, as well as user icons for graphical clients.
7. The server network needs to be a mesh, not a two-headed tree, so there's no single point of failure.
8. There needs to be permission-based message approval, like in Jabber, to prevent spambots. For person-to-person, a "do you accept?" and for channels, a way to require (optionally of course) that at least one person on the channel agrees to let the person in. Yes, you can do the latter via +v or channel keys, but it's a pain and users don't understand it because the entire protocol is visible to them rather than being handled automatically.
9. Once you have persistent identifiers (see above), there needs to be an ACL mechanism for channels.
10. Ideally channel nicknames would be locally assigned. When I find a channel I like and join it based on the description, I should be the one to pick the #whatever alias. (Of course, the channel operators could suggest one, like with user nicknames.) This would prevent channel wars caused by people wanting the same convenient channel nicknames, and stupid bots that exist only to stop people using a channel name and advertise some other channel.
If anyone actually doing development on IRC-like chat systems wants to talk to me about the above, I'd be happy to provide more detail, thoughts on how to implement, and so on, when I have time. meta@pobox.com
OK, let me outline a few of the problems with IRC:
/away because it doesn't work in all clients, actions don't always work, there are three or four different ways of getting idle time info, and so on.
1. It's a double-tree structure, which means all IRC networks have a single point of failure.
2. There's no smart routing, so the servers have to carry traffic even for channels that nobody connected to them is using.
3. Nicknames are global, which means there's contention for popular ones, even if the ten people who want to use mine would never otherwise run across me.
4. It's centralized on a few servers, so it's easy to DoS out of existence. (I know all about this; I was a DALnet user.)
5. There's insufficient standardization of everyday stuff people expect to have like colors, fonts, file transfer, away messages, and the like--so I see garbage instead of messages because they have colors in, people don't use
Except (a) IRC doesn't do that, servers have to carry traffic even for groups that none of their users are in; and (b) there's nothing stopping you doing that in a later revision of XMPP by allowing group-addressed messages to be sent once to a server.
I own my Internet connection, and simple cost/benefit analysis suggested that the number of Taiwanese people sending me legitimate e-mail was close to zero, whereas the cost of dealing with spam from China and Taiwan ran into hours per month.
I fully appreciate that there are nice Taiwanese people who know how to run a server and are competent and responsible and don't spam... However, the cost of continuing to accept their e-mail is too high, because of their countrymen's bad behavior. So I block everything with Asian character sets in it, everything on the blacklists, and so on.
Similarly, there's some nice useful Windows software--but the cost of running Windows exceeds the benefit I'd get from running the software.
Yeah, that was my thought too. It's very much a case of rearranging the deck chairs on the Titanic.
The IRC protocol is flawed. Not just superficially broken, but horribly, fundamentally broken in numerous ways. As a result it's unreliable (prone to network splits), puts massively unnecessary load on servers, has problems with contention for nicknames, and so on. It really needs complete replacement.
Mind you, now that we have XMPP, there's a strong case for just letting IRC slowly die and having XMPP chat rooms take over.
"Vcr" isn't a word, dumbass. (How would you pronounce it? "vuh-curr"?)
If you think "vcr" and "dvd" are words, I'm not playing Scrabble against you...
Leading apostrophes are commonly omitted; people write "He picked up the phone" and not always "He picked up the 'phone".
Apostrophes are used to mark missing letters (amongst other things). Since "ho" is a shortened version of "whore", "ho's" is legitimately written with an apostrophe to mark the missing 'r' and 'e'--just like "we're" has an apostrophe to mark the missing 'a' of "we are".
If you're going to post stupid punctuation flames, get it right, dumbass.
The story also says they have to be able to drive a stick shift. I don't really understand why--we're talking engineers, not valet parking. Do aircraft engineers have to be trained pilots? Do TV repairmen have to have their own daytime chat show?
And he's gonna find out the specific registry keys the application accesses how, exactly?
Having spent time with journalists, I'd think the main purpose of the NUJ would be to get bulk discounts on booze and cigarettes...
Sounds like an idea I posted here a while back. What it needs is a chance to pimp other characters in order to collect enough bling to get a fly pimpmobile. If the other characters don't cooperate, instead of drowning them in the pool you just bust a cap in their asses.
The point isn't whether the entire system was written in LISP, or whether Java may or may not be worse than LISP.
The point is that LISP clearly is suitable for both performance-critical and memory-tight systems, in spite of its use of automatic memory management.
Hence the original claim, that automatic memory management means bad performance and memory bloat, is false.
I don't see what your response has to do with my (sarcastic) comment. The point is that Naughty Dog's games run LISP, yet they don't sit and pause for garbage collection.
I couldn't get my 82xxx sound to work until 2.6, but now it's fine. I can send you config files if you like.
a) AIDS is hard to cure because HIV mutates a lot. It's hard to target because there are so many variants. They've recently discovered that HIV+ people can even become infected with multiple different mutations of HIV.
b) HIV infects the immune system. It's incredibly difficult to target the HIV virus without destroying the immune system in the crossfire, and once you destroy the immune system the person is pretty much dead in the long term. In fact, that's what makes AIDS deadly--the immune system is destroyed, the body can't fight off the dozens of illnesses we're exposed to every day, and the victim has a long slow lingering death from multiple diseases.
The combination of the two problems makes AIDS particularly tough to fight. You need incredibly specific drugs to target a constantly mutating virus.
Try Objective-C. 100% native code, total C compatibility, and you can freely mix manual (C-style) memory allocation, reference-counting semi-automatic memory allocation, and full garbage collection (with add-on libraries). Plus it only takes a weekend to learn if you already know C.
Ah, the eternal anti-GC FUD of the ignorant.
Yes, clearly it would be complete lunacy to write video games in garbage-collected LISP, like Jak and Daxter, Ratchet and Clank and so on.
Obviously AT&T were insane to write their telephone exchange control software in garbage collected LISP.
And those massive overheads ensure that we'll never see NASA using LISP to control space probes.