It wasn't Darwin, it was Galileo. Faith entails belief without reason and thus is the enemy of science, there are no two ways about it. Most (all?) religions make distinctly scientific claims, like that Jesus existed, or people continue to live after their brain has decomposed. These claims are generally false, and even worse, unsupported. Science demands that all assertions be supported, and that when the support of a assertion fails, it be rejected. Faith demands no support; only that evidence against an assertion be ignored. It is absolutely irreconcilable with science.
I do not have faith that I will not get hit by a car walking down the street -- I have good reason to believe that (i.e. that such events are fairly unlikely). I do not have faith that my water is safe -- I have good reason to believe that too (i.e. that the people responsible for keeping water safe are generally capable of doing so, and the instances otherwise are rare). Faith is not making statistical predictions, because those are based on reason. Or, if that's faith, there must be some other word for what Christians do.
What are you smoking? Faith is belief without reason, DEFINITIVELY. They're only not mutually exclusive in that you can use faith for some things and reason for others. But in that sense, no two traits are ever mutually exclusive.
Again, a one true OS is just stupid. Different applications have different requirements. Various operating systems fulfill those different requirements.
It's like you're not even reading my posts. Different applications have different requirements, but practically all applications share *some* requirements; requirements that only need to be implemented once. A single kernel source can be both optimized for 386 and p3. Indeed, a single kernel source can run on both 386 and AXP. So what is this shit about "different requirements"? You have yet to show that a single kernel source base can't provide for different requirements.
a) OpenBSD spends a lot of their development cycle worrying about security design and testing. Developers of the linux kernel and whatever is specifically available for it may not be. The problem here is weighing time to market and security and stability.
I don't see how this is relevant. "Time to market" doesn't matter when you have CVS. If linux users want the feature-of-the-week and OpenBSD users don't think it's ready, where's the conflict? Every release doesn't need to be for every person. Linux kernel 2.0.x are still maintained, and 2.2.x will be maintained long after 2.4.x; this is precisely analogous to the situation you describe, but any problems caused are minor.
b) FreeBSD developers may like a completely standard system where they control everything. Linux developers may not.
It doesn't matter, because when the source is free, nobody can "control everything". If someone wanted to fork FreeBSD he could, so what's your point?? Nobody has any control anyway, except for what they can convince other people to do.
FreeBSD developers may like long articulate man pages while linux developers may not.
OK, I can't imagine anybody *not* wanting long articulate man pages (more likely not bothering to *write them*); but even then, some people might want fatfs in their kernel, and some people might not. If both are going to be done *anyway*, both should be done *to the same kernel*. If FreeBSD folks want to write long man pages for the super-kernel, they can; if someone else doesn't like they're style of man pages, she can write her own separate man pages, and the users can choose. That may seem like a waste of work (it is), but it's still less wasteful than the current situation, where the same thing is done for non-technical reasons.
As to linux developers making a "dash for the desktop", I don't understand what that means. Do you mean adding features that desktop users would like? And other people don't want those features? Well then they shouldn't compile those features in.
but there's no technical reason to have multiple unixes
False. There are many technical reasons. The first is hardware support.
Hardware support? Seriously, the best way to organize the code is to separate the hardware-specific code from the hardware-neutral code. There's no need to re-do hardware-neutral code *by definition*, and there is a *LOT* of hardware-neutral code in modern kernels. Hence NetBSD's existence.
They aren't all equal and they all have idiosyncracies (e.g. filesystem differences, SMP, what databases/particular software is available/works best, personell preference and experience, security issues, support, et al).
The super-kernel should support all filesystems, it should be able to compile-time optimize for uniprocessor or SMP, and it should be able to optimize for all the necessary types of applications. Doing this is no more difficult than doing it in multiple forks. If FreeBSD can be optimized for a certain type of application, the optimization can be added as a compile-time option as easily as a new fork (and etc).
Given *any* two OS, there is assuredly going to be tasks common to both: those tasks *should* be done with the same code, and that code *should* be maintained *only in one area*.
Not every project has the same goals. Stating that is naive and stupid.
Nobody stated that.
Any compelling technical reason not to [unify ls]?
-divergence of design ideaology
ls could be made to optimize at compile time for all the various ideologies.
-different requirements
Ditto.
-licenses
Exactly. This isn't a technical reason.
-different development cycles
Why would we WANT to maintain different development cycles? Don't you understand that that just means the code is going to get there later?
BSD and Linux... will never be able to collaborate
Not true.
It was true before you took it out of context. With context I said, "[...] will never be able to collaborate like *BSD collaborates among themselves", which is absolutely true.
Once people, especially in the Open Source community, realize "one OS everywhere" is bad regardless of which OS it is we will make some real progress toward truly great computing systems.
Funny, I would say the opposite. One OS everywhere means MUCH less redundant (i.e. wasted) effort. One OS everywhere would have incredible advantages if the OS weren't *too* bad (though if it were controlled by a single corporation that would probalby outweigh all advantage) for everyone: easier to develop and easier to develop for, which means a larger software base for end-users. The main obstacle is stupid legal bullshit: BSD/GPL interoperability problems, and the fact that most OS aren't free software at all. The ideal would be a single source base that could optimize for all possible configurations, or at least most of the similar ones. Radically different hardware or applications might require different OS, but there's no technical reason to have multiple unixes. All the features of all the unixes could be compile-time options in one unified unix kernel, and it wouldn't matter upon which current kernel the super-kernel was based: if all unix kernel developers focussed their effort and previously-written code on that one kernel it would far surpass all current offerings very quickly.
Furthermore, the MORE unixes that exist, the more effort is being wasted, in redundant kernel code, in redundant kernel-specific user code, and in porting. Do we really need Sun, GNU, IBM, HP, and *BSD all maintaining "ls"? ("ls" isn't even kernel specific! Everyone could use - and maintain together - the *BSD or GNU version *right now*, if everyone agreed. Any compelling technical reason not to?)
'course it doesn't really matter. Proprietary unix vendors aren't going to release their source code, and *BSD and Linux (or any other two OSes, for that matter) will never be able to collaborate like *BSD collaborates among themselves (which, while not ideal, is much closer to ideal than any other current situation between multiple OSes).
According to ZDNET, Inprise will "release its upcoming InterBase 6.0 database under the open-source Mozilla Public License 1.1". They're probably just removing all the sexist jokes from the comments before they go public with it.
...the laws of physics which govern *all* inventions have existed since the beginning of time, so the difference is always going to be a matter of scale, with no distinct line. The cotton gin was based on a bunch of basic laws of physics that nobody had used in that way before. Likewise with Wildcard DNS: it existed before, but it was never used for session management. And it's not as if/nothing/ was created: there still had to be an implementation behind the scenes (though I'm sure it was trivial).
But using technologies in combination to do what they were invented to do is not patentable, even if it's clever.
But DNS was never intended for session management.
I suppose it's moot. No amount of novelty is going to get me to support a patent anyway;)
The entire purpose of an "invariant section" is that the author maintains control. Even if not malicious, translations can be done poorly and that can cause some serious problems in expressing the original meaning. I wouldn't want you to take something I've written, translate it into German, and put my name on it.
I don't see how this would cause problems for the LDP (or anybody). ??
Damn, wish I hadn't posted, I'd have moderated you up. Anyway, I obviously can't speak for the FSF, but I really don't think they're about providing "incentive" or business models -- that's ESR and "open source". FSF makes its money not by providing support, but by selling CD's of GNU and other free software, and t-shirts (and donations). The FSF is more worried about offering complete flexibility to the users of software than incentive for the original author to write it (for better or worse).
Documentation does get written, though, and the reward (in many cases) is promotion of the program. Gnome needs documentation because it wants to (eventually) be THE desktop for all people (hacker or otherwise). The reward for them is a larger target audience. This same reward applies to anybody writing software with a non-technical audience, or with a project that requires documentation for some other reason. If there's a commercial incentive to write a word processor for Linux/etc, there's the same incentive to document it. Documentation is just another feature for a program and, just as any feature, it can attract and keep users if it's good.
The GDL has the same virus-like behavior as the GPL license for software. And like the GPL prevents the inclusion of e.g. BSD licensed software in a GPL software, the GDL prevents the same for including documentation. Not a too clever move from the FSF.
The GPL doesn't prevent the inclusion of BSD licensed software in GPL software, it's the other way around. (The GPL prevents inclusion of GPL code in BSD software). BSD allows you to redistribute under a new license, for instance the GPL. That's why they call the GPL a virus: if you include GPL code in a BSD program, it's not illegal, but the program (in its entirety) can only be legally distributed under the GPL. By "BSD", btw, I mean the new BSD license. What is more precisely called Xfree-style.
As long as I'm posting, regarding "quot[ing] two paragraphs from the GDL'd Widgets Manual": this is what is called "fair use"; copyright restrictions do not apply to small snippets of a large document.
This is really a very clever hack. It's only obvious once you hear it. I'm against "intellectual property" in general, but I still recognize that this is a novel idea. I honestly can't see the patent being attacked on the basis that it is "obvious". (Though I can see it being attacked on other grounds: the very idea of patents is absurd, no research went into "inventing" this, someone must have done it already, and it obviously would not do all that much good for society if this were restricted). But it's still not "obvious".
Yeah, you're "all against censorship", but you have no problem declaring what speech is dangerous and what speech is not. Obviously "fuck" is "profane", and corrupts childrens' fragile little minds, but you have no problem with the "push" nature of television telling kids to worship a mass murderer every Sunday morning, eh? I guess censorship's OK if you're only going to censor the bad speech.
Television is no more "push" than any other medium. Nobody is forced to watch it, and ANYBODY who does watch it is going to see some views with which he or she disagrees. I think if you really understood free speech, you might realize that the solution to bad speech is more speech. If the supposed damage of "profanity" can't be undone with an explanation of why certain words are "profane", perhaps it's not damage at all. Perhaps the word "fuck" is harmless, and censorship only prevents the truth on the matter from surfacing.
It may not look it, but your defense of censorship (or whatever you want to call it) is the same as any other: you (or the king, church, majority, etc) have decided that certain information is harmful (or subversive, immoral, heresy, etc), and thus you assert the right to prevent that information from being distributed. Well it ain't so. In order to decide what to censor from children, we have to decide what speech is harmful, and nobody can claim the ability or right to do this. You say "fuck" harms your children, well I say Sprite commercials harm my children. And I want 'em off the air, or at least a warning before they come up. Can you think of any reason I shouldn't get this, besides that we should really only be censoring the bad speech?
Having everything except for the private keys is not security by obscurity. You have the code, you have the algorithms. There's nothing obscured. By your definition all cryptography would be security by obscurity.
What? THE PRIVATE KEYS ARE AVAILABLE TO ANYONE WITH THE CLIENT. The only thing obscuring them is the closed-sourceness of the binary. All information required is available to the client, if he can disassemble the binary enough. That's exactly what security through obscurity means. Unlike other crypto, where the snoopers DON'T have the private key at all. That's not obscurity. But if the snooper DOES have the key, but it's just DIFFICULT TO ACCESS, i.e. OBSCURE, then that's obscurity.
This shouldn't be that easy. I think there could be a few tricks to avoid including it in the clear (mostly making it dependend on the rest of the code so that it really authenticates the binary and not the key alone).
If those tricks are open source, they'll be easy to break. If they aren't, it's just more obscurity.
Netrek uses RSA encryption. Every rsa-enabled binary has a public/private key pair with which it authenticates against the server, and a time limit after which the key pair expires. The server has a list with public keys that it will allow to connect. This list is updated by the sever admin choosing which clients can play.
Oh I get it! So the authorized client's source is different from the publically available source (the difference being the key). Well IMHO that doesn't count, because it's not/totally/ open source... But it's a nifty solution. Unfortunately, it's still security through obscurity. Somebody will disassemble the binary and find the keys, then plug them into a modified client. With a game like netrek this obscurity is probably going to last years; with quake it'll be days.
You've missed the point. You don't have to reverse-engineer the client because it's open source. "Some authentication method within the client" isn't going to be able to send anything that a modified client can't.
If the server expected something based on what it sent, that wouldn't make any difference at all. The modified client would be able to respond in exactly the same way as the original one.
means that the case can be brought up again, if there is new evidence. Though I can't imagine how there would be new evidence. Ahh the insane justice system.
Disclaimer: IANAL, but I watch CourtTV and LAW&ORDER.
Actually the problem isn't the protocol; that would be very easy to modify. The client isn't using the information it doesn't need, it could be left almost the same. The problem would be that the server would then have to detect whether the client should have certain information, and this would require some SERIOUS CPU... It would have to do all kinds of real-time computations for each user. Totally impractical. And besides, protecting against one cheat and not others is just more obscurity.
Also, see-through-walls can be prevented by not disclosing information, but the information that *must* be disclosed can still be recorded and interpreted with perfect accuracy by the computer, resulting in unpreventable extra-info cheats. The loudness of a grunt or other sfx tells distance, the trajectory must be provided for 3d sound, and the computer can record this and put a blip on your radar. And even if fov 360 is prevented, a client can spin around instantly and record everything it sees. You couldn't possibly limit the turn speed and find a balance between disallowing this cheat and allowing good mouse aim. Not that you could even prevent fov 360; the information needs to be at the client already if its to turn without network latency having effect. Not to mention, current 3d hardware expects it. So there's no way to prevent rear-view mirror or bots that fire backwards as easily as forwards.
The way they guard against bots (it's server policy, not all do) is to accept connections only from authenticated binaries. Some trusted parties compile, sign and distribute binaries which authenticate themselves via RSA to game servers.
Uhm? A modified client can send exactly the same information to the server as can an unmodified one. In this case, one could download authenticated binaries, create the md5sum based on them (or whatever it uses), and then use a modified client that just sends the md5sum from the auth'd binaries instead of from its own binary. There's really no way to guard against this, even theoretically, without an on-site referee.
Even more specifically, here's the transaction:
Server expects connect
Modified client connects
Server expects md5sum of client binary
Modified client sends md5sum of unmodified client binary
Server sends position of enemy
Server expects trajectory for aim
Modified client takes position of enemy, sends perfect trajectory for aim
Server sends scores: modified client wins!
All of that is totally possible for a modified client. Is there any step I missed that is not possible for the modified client?
at least partially. The port is called wine (I'm sure you've heard of it). It runs plenty of Windows games already, e.g. StarCraft, Unreal, Half-life, etc. Native linux apps can also use DirectX, through winelib. Just FYI:)
...because security is impossible. Closed source security is impossible, but obscurity can buy you at least a few weeks before a breech (ahem).
The only way to secure against bots is to have a referee sitting behind every client playing the game (and even then he might be payed off). This is the same principle with computer chess -- there's absolutely no way to prevent a person from having big blue (or Kasparov for that matter) choosing his moves for him, without physically observing the match. When it gets down to it, someone could make a physical robot that plays FPS by monitoring video output visually and physically typing on a keyboard (or, more realistically, by replacing video drivers and monitoring in software, and replacing keyboard/mouse drivers for input and inputting in software). Nobody's taken this approach yet, but the only thing stopping them is obscurity. With open source, none of that roundabout shit would be necessary, so it's easier (though always possible); there truly is *no* way to secure against bots.
The most viable solution, which is actually an alternative to security, is to privatize every game. Have every player sign his logins with public key crypto, and if he starts cheating he gets manually put on the blacklist. In order to prove he's not on the blacklist he would have to be authenticated by a trusted server that maintains blacklists before he could play. Something similar is already used in Q3/halflife to prevent piracy (so-called). Extending this system to blacklist cheaters would probably be trivial; it wouldn't even require modification of the client (only server). Of course, server admins would be able to use whatever subset of the blacklist they want, or whatever alternative blacklist servers, or no blacklist at all.
I still don't consider that real security though. It's just an imperfect but easier version of the personal referee. It's the equivalent of not having any file permissions, but only letting close friends use the computer. And one major potential problem might be people getting blacklisted who shouldn't. Anyway, security in the traditional sense is impossible for these games. The only total solution is that people learn to have some consideration for others, and not to take games so seriously. Hey, it could happen;)
Slashdot Mirror
It wasn't Darwin, it was Galileo. Faith entails belief without reason and thus is the enemy of science, there are no two ways about it. Most (all?) religions make distinctly scientific claims, like that Jesus existed, or people continue to live after their brain has decomposed. These claims are generally false, and even worse, unsupported. Science demands that all assertions be supported, and that when the support of a assertion fails, it be rejected. Faith demands no support; only that evidence against an assertion be ignored. It is absolutely irreconcilable with science.
I do not have faith that I will not get hit by a car walking down the street -- I have good reason to believe that (i.e. that such events are fairly unlikely). I do not have faith that my water is safe -- I have good reason to believe that too (i.e. that the people responsible for keeping water safe are generally capable of doing so, and the instances otherwise are rare). Faith is not making statistical predictions, because those are based on reason. Or, if that's faith, there must be some other word for what Christians do.
What are you smoking? Faith is belief without reason, DEFINITIVELY. They're only not mutually exclusive in that you can use faith for some things and reason for others. But in that sense, no two traits are ever mutually exclusive.
Looks like PCs are finally catching up with c64!!
As to linux developers making a "dash for the desktop", I don't understand what that means. Do you mean adding features that desktop users would like? And other people don't want those features? Well then they shouldn't compile those features in.
Most accurately, copyleft/non-copyleft. The GPL isn't the only GPL-like license, after all.
Given *any* two OS, there is assuredly going to be tasks common to both: those tasks *should* be done with the same code, and that code *should* be maintained *only in one area*.
Nobody stated that. ls could be made to optimize at compile time for all the various ideologies. Ditto. Exactly. This isn't a technical reason. Why would we WANT to maintain different development cycles? Don't you understand that that just means the code is going to get there later? It was true before you took it out of context. With context I said, "[...] will never be able to collaborate like *BSD collaborates among themselves", which is absolutely true.Oh, the title ("world domination")? I didn't mean to imply Linux world domination. The phrase just seemed fitting to the topic.
Furthermore, the MORE unixes that exist, the more effort is being wasted, in redundant kernel code, in redundant kernel-specific user code, and in porting. Do we really need Sun, GNU, IBM, HP, and *BSD all maintaining "ls"? ("ls" isn't even kernel specific! Everyone could use - and maintain together - the *BSD or GNU version *right now*, if everyone agreed. Any compelling technical reason not to?)
'course it doesn't really matter. Proprietary unix vendors aren't going to release their source code, and *BSD and Linux (or any other two OSes, for that matter) will never be able to collaborate like *BSD collaborates among themselves (which, while not ideal, is much closer to ideal than any other current situation between multiple OSes).
<sigh>
According to ZDNET, Inprise will "release its upcoming InterBase 6.0 database under the open-source Mozilla Public License 1.1". They're probably just removing all the sexist jokes from the comments before they go public with it.
I suppose it's moot. No amount of novelty is going to get me to support a patent anyway ;)
I don't see how this would cause problems for the LDP (or anybody). ??
Documentation does get written, though, and the reward (in many cases) is promotion of the program. Gnome needs documentation because it wants to (eventually) be THE desktop for all people (hacker or otherwise). The reward for them is a larger target audience. This same reward applies to anybody writing software with a non-technical audience, or with a project that requires documentation for some other reason. If there's a commercial incentive to write a word processor for Linux/etc, there's the same incentive to document it. Documentation is just another feature for a program and, just as any feature, it can attract and keep users if it's good.
As long as I'm posting, regarding "quot[ing] two paragraphs from the GDL'd Widgets Manual": this is what is called "fair use"; copyright restrictions do not apply to small snippets of a large document.
This is really a very clever hack. It's only obvious once you hear it. I'm against "intellectual property" in general, but I still recognize that this is a novel idea. I honestly can't see the patent being attacked on the basis that it is "obvious". (Though I can see it being attacked on other grounds: the very idea of patents is absurd, no research went into "inventing" this, someone must have done it already, and it obviously would not do all that much good for society if this were restricted). But it's still not "obvious".
Television is no more "push" than any other medium. Nobody is forced to watch it, and ANYBODY who does watch it is going to see some views with which he or she disagrees. I think if you really understood free speech, you might realize that the solution to bad speech is more speech. If the supposed damage of "profanity" can't be undone with an explanation of why certain words are "profane", perhaps it's not damage at all. Perhaps the word "fuck" is harmless, and censorship only prevents the truth on the matter from surfacing.
It may not look it, but your defense of censorship (or whatever you want to call it) is the same as any other: you (or the king, church, majority, etc) have decided that certain information is harmful (or subversive, immoral, heresy, etc), and thus you assert the right to prevent that information from being distributed. Well it ain't so. In order to decide what to censor from children, we have to decide what speech is harmful, and nobody can claim the ability or right to do this. You say "fuck" harms your children, well I say Sprite commercials harm my children. And I want 'em off the air, or at least a warning before they come up. Can you think of any reason I shouldn't get this, besides that we should really only be censoring the bad speech?
What? THE PRIVATE KEYS ARE AVAILABLE TO ANYONE WITH THE CLIENT. The only thing obscuring them is the closed-sourceness of the binary. All information required is available to the client, if he can disassemble the binary enough. That's exactly what security through obscurity means. Unlike other crypto, where the snoopers DON'T have the private key at all. That's not obscurity. But if the snooper DOES have the key, but it's just DIFFICULT TO ACCESS, i.e. OBSCURE, then that's obscurity.
This shouldn't be that easy. I think there could be a few tricks to avoid including it in the clear (mostly making it dependend on the rest of the code so that it really authenticates the binary and not the key alone).
If those tricks are open source, they'll be easy to break. If they aren't, it's just more obscurity.
Oh I get it! So the authorized client's source is different from the publically available source (the difference being the key). Well IMHO that doesn't count, because it's not /totally/ open source... But it's a nifty solution. Unfortunately, it's still security through obscurity. Somebody will disassemble the binary and find the keys, then plug them into a modified client. With a game like netrek this obscurity is probably going to last years; with quake it'll be days.
If the server expected something based on what it sent, that wouldn't make any difference at all. The modified client would be able to respond in exactly the same way as the original one.
That's the opposite. Eheheh. Silly me. Told you IANAL.
Disclaimer: IANAL, but I watch CourtTV and LAW&ORDER.
Also, see-through-walls can be prevented by not disclosing information, but the information that *must* be disclosed can still be recorded and interpreted with perfect accuracy by the computer, resulting in unpreventable extra-info cheats. The loudness of a grunt or other sfx tells distance, the trajectory must be provided for 3d sound, and the computer can record this and put a blip on your radar. And even if fov 360 is prevented, a client can spin around instantly and record everything it sees. You couldn't possibly limit the turn speed and find a balance between disallowing this cheat and allowing good mouse aim. Not that you could even prevent fov 360; the information needs to be at the client already if its to turn without network latency having effect. Not to mention, current 3d hardware expects it. So there's no way to prevent rear-view mirror or bots that fire backwards as easily as forwards.
Uhm? A modified client can send exactly the same information to the server as can an unmodified one. In this case, one could download authenticated binaries, create the md5sum based on them (or whatever it uses), and then use a modified client that just sends the md5sum from the auth'd binaries instead of from its own binary. There's really no way to guard against this, even theoretically, without an on-site referee.
Even more specifically, here's the transaction:
All of that is totally possible for a modified client. Is there any step I missed that is not possible for the modified client?
Open source, but incredibly easy to cheat.
at least partially. The port is called wine (I'm sure you've heard of it). It runs plenty of Windows games already, e.g. StarCraft, Unreal, Half-life, etc. Native linux apps can also use DirectX, through winelib. Just FYI :)
The only way to secure against bots is to have a referee sitting behind every client playing the game (and even then he might be payed off). This is the same principle with computer chess -- there's absolutely no way to prevent a person from having big blue (or Kasparov for that matter) choosing his moves for him, without physically observing the match. When it gets down to it, someone could make a physical robot that plays FPS by monitoring video output visually and physically typing on a keyboard (or, more realistically, by replacing video drivers and monitoring in software, and replacing keyboard/mouse drivers for input and inputting in software). Nobody's taken this approach yet, but the only thing stopping them is obscurity. With open source, none of that roundabout shit would be necessary, so it's easier (though always possible); there truly is *no* way to secure against bots.
The most viable solution, which is actually an alternative to security, is to privatize every game. Have every player sign his logins with public key crypto, and if he starts cheating he gets manually put on the blacklist. In order to prove he's not on the blacklist he would have to be authenticated by a trusted server that maintains blacklists before he could play. Something similar is already used in Q3/halflife to prevent piracy (so-called). Extending this system to blacklist cheaters would probably be trivial; it wouldn't even require modification of the client (only server). Of course, server admins would be able to use whatever subset of the blacklist they want, or whatever alternative blacklist servers, or no blacklist at all.
I still don't consider that real security though. It's just an imperfect but easier version of the personal referee. It's the equivalent of not having any file permissions, but only letting close friends use the computer. And one major potential problem might be people getting blacklisted who shouldn't. Anyway, security in the traditional sense is impossible for these games. The only total solution is that people learn to have some consideration for others, and not to take games so seriously. Hey, it could happen ;)