Well, there are people who don't like the preprocessor and have been coding for quite a while. I've been coding C++ for 7 years and as time goes on I like the preprocessor less and less. The main reason is that it is an obstacle to tools that help development. One common example is the debugger--not even Microsoft's Visual C++ could render macros transparent.
Another problem is tools that do automatic code-folding have a much more difficult job with macros. I was using jGRASP because it does a great job of code-folding. The only problem is that it couldn't handle macros. So a macro that expands with a semi-colon to make a complete statement would be seen instead as the first token of the next statement. Now you may fault the programmer for not figuring out how to do code-folding with macros, but I believe the difficulty is inherent in the language itself. In order to handle macros properly, it would have to have a built-in preprocessor.
The third problem is code I'm reading or writing. It is often infuriating to try to figure out syntax problems that involve macros. The macros are supposed to make things easier, but instead they just make them opaque. One of the worst offenders is MFC, with macros like IMPLEMENT_DYNAMIC and AFX_*.
It seems problematic that to figure out the proper syntax of the language a preprocessor must be run first. The existence of the preprocessor has many advantages, but it has many detriments too. It invites API programmers to create macro-shortcuts that hide the syntax. These attempts at abstraction introduce all the problems of abstract languages (opaque-ness) while avoiding all the benefits of abstract syntax (safety, simplicity).
Yes, that's the point. Math is an algorithmic process, one that gives answers to various well defined questions. You can ask an unanswerable question, such as "What percentage of 0 is X?" or you can ask an answerable question, such as "What is X% of 0?". The first question will literally have no answer, the second will always be zero.
100% of 0 is 0. And everyone gets a hundred percent of the total, including me. Math is fun.
(It all depends on how you ask the question. If you ask "How much is 100% of 0?" you have a well defined answer. If you ask, "What percentage of 0 is 0?" you have a problem with division. The solution: be a little more charitable and allow yourself to laugh every once in a while.)
You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
"Licensed as a whole at no charge" seems to include use as well as copying.
This also:
...the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
Besides, I've never heard of a license to own but not to use. Is such a license even legal?
You cannot impose any restrictions on the redistribution of GPL software. "Redistribution" can be defined as to another entity, or to yourself. Just as you cannot force royalties on top of GPL software, you cannot force contract agreements on it either. If you try to do this, the GPL still holds effect, basically invalidating any use of the software altogether.
It really seems that RHAT is violating the GPL here. This is a serious issue, one that RHAT should clarify and correct immediately.
No, I believe you have it wrong. This engineer had the task of making a compatibility layer between Linux and SCO. Many of the functions in the compatibility layer were "one-liners". That means that they just passed through the call to the SCO function, which operated in an exact manner.
Now, the engineer could have interpreted the similarities between SCO code and Linux code to be the result of previous copying by SCO from Linux, but this seems unlikely. The calls existed in SCO first, and SCO existed before Linux. Furthermore, it is unlikely that SCO changed the function calls much since their inception, because that would break backwards compatibility.
On the other hand, this same argument makes it unlikely that the code got from SCO into Linux. Unless someone was copying code into Linux from the very beginning, the system calls would have originally been written without SCO code. And again, to preserve backwards compatibility (as much as Linux does), it would have been unwise to take a totally different version from another operating system.
What is most likely is that most sets of API implementations have a common anscestor--BSD. The system calls actually do not change much, and if I am reasoning correctly, are not as likely to differ between operating systems. This means they could easily be taken from BSD into Linux. I haven't undertaken the actual verification of this, but Linus himself says that much of Linux comes from BSD.
The reason I don't think the system calls usually differ is this. The more complicated parts of the kernel, such as virtual memory management and task scheduling, are actually not exposed via the API. As such, these architectural pieces of code would not be necessary to reimplement for the system calls.
I think you are underestimating IBM's interest in Linux. IBM is doing well largely due to Linux. What do customers want? Freedom from lockin. The only way to give that to them is by selling services around non-proprietary software. I don't think IBM would settle this for a dollar and let SCO take control of Linux. It doesn't make sense.
Besides, I have never heard of any public domain, BSD, or GPL copyright being slurped up into a propriety product because of the proprietary product's "overriding interest", or what have you.
It's basically neccessary to actually read the GPL source when doing this since none of it is documented well enough.
Why should they get that benefit? WINE certainly doesn't get that benefit, except for header files. And "needing to read it to reverse engineer it" isn't going to sit well with a judge.
maybe they could have been tempeted to use the Linux source for that function
Indeed. From the article:
"These system call implementations had to be quite compatible with the behavior of the real Linux kernel, otherwise Linux applications would not work on SCO Unix. It is quite obvious to argue that in order to get these right, Linux kernel code had to be studied and possibly copied into the SCO Unix kernel to implement the Linux Kernel Personality. How else would you get the Java Hotspot VM or the X-window server (Linux binaries) to work on SCO Unix?" the source questioned.
It doesn't establish the origin. It just establishes that they have the same origin. UnixWare has been around longer than Linux, so I think it is safe to say that these functions were in UnixWare first. But I do believe that their path into Linux was almost certainly via the common parent of BSD licensed code. Especially given their age.
Now it's possible some coders in the mid nineties decided to beef up SCO's unix by copying code over from Linux, but why? It would break backwards compatibility. And similarly, why would these functions change much from the beginning of Linux? They probably did not. So unless SCO's code got into Linux from the near beginning, I think it is much more likely that BSD is the common descendant.
THe source does not say they copied the code itself. they just added ts functionality in to SCO.
Yes he does. Read again:
"These system call implementations had to be quite compatible with the behavior of the real Linux kernel, otherwise Linux applications would not work on SCO Unix. It is quite obvious to argue that in order to get these right, Linux kernel code had to be studied and possibly copied into the SCO Unix kernel to implement the Linux Kernel Personality.
"How else would you get the Java Hotspot VM or the X-window server (Linux binaries) to work on SCO Unix?" the source questioned.
It seems fishy. They were writing SCO code while having the Linux code in front of them. That is a big No-No if you want to avoid violating the GPL.
I imagine most of the system calls were pretty basic stuff, stuff that has probably been in BSD since early 90's. Note that FreeBSD also has a pretty happenin' Linux compatibility layer. Has anyone ever compared FreeBSD to Linux? I imagine Linux borrowed a bit from FreeBSD, especially for the basic calls that.
Full control (SCO owns Linux copyright) may be established by asserting Linux is a combination of public domain work (GPL stuff) and copyrighted SCO stuff. In other words, they want the courts to assign them OVERALL COPYRIGHT FOR LINUX.
This didn't happen when BSD code was found in UNIX, and I seriously doubt it will fly now. Can you point to any examples where this has actually happened?
The difference hear is that SCO is basically asking us to take their word for it. It's like the proselytizer who asks us to believe in his god on "faith". If I balk at the proselytizer, he will tell me that the "truth will be seen" when I die. Similarly, SCO will show us the "evidence" when we sign an NDA that basically prevents us from practicing our livelihoods. It's an unexceptable condition to see the evidence. And just as god will "test" us by not showing evidence of his existence, similarly bizarre reasons exist for SCO not showing evidence of infringement.
Things will hopefully wrap up on Friday, when SCO is supposed to revoke the AIX license. If they take IBM to court, they will have to show evidence. If they don't, then they lose credibility. Either way, they lose.
When I'm in this situation, I just do it. My dignity is at stake, so I'll even put in extra time to do it on off hours and weekends. If the solution already exists, then the boss will be very reluctant to pay for a second implementation.
On the other hand, if it would be too much work to get done on your own time, then your boss is probably correct in getting it outsourced.
You need to fight the root of the cause, rather than simply checking the harddrive:
Only inform each client of players visible to that client--prevents wall-hacks.
Track the accuracy of each weapon. Not the shots, but the aiming of the weapon. There should be an expected variance that is a function of the relative velocity of two players. If the relative velocity is high, and the aim remains perfect, it's probably a cheater.
Create a global anti-cheat list, which will be similar to the open-relay black-lists. If the game is purchased, and each copy comes with a unique ID, then a person who is caught cheating can be added to the blacklist. An admin should record a demo of the cheating, which can be reviewed and appealed.
For a free game like America's Army, use the MAC address. Can still be spoofed, but not too easy.
There are other things that can be done, but are less desireable:
Prevent perfect accuracy. Make it so that a certian percentage of shots always miss, no matter how good the player is.
Give each weapon "kick". If aim is perfect even with a kicking weapon, it's definitely a cheater.
Each weapon reduces damage the more accurate you are with it.
These last three are less desireable. But simply doing a CRC for files on the system that enable cheating is not a good strategy.
Even more interesting is that at the same time that Kolody was pitching Simon, Coke failed to renew their copyright on a very famous image that appeared on their first soda can in 1961: the 'contour bottle on the Coca-Cola can' image. When Coke failed to renew the 1961 copyright (as they must do after 28 years) Kolody, the suit claims, became the de facto rights holder because he had created a derivative work of the image for his pitch with Simon.
Uhh, that's not how copyright works anymore, as much as some here at slashdot wish it would. It is similar to how copyright used to work in 1800, but not 1961. You'll find other questionable statements in this article. Take it with a grain of salt.
Not praising Coca-Cola, they basically sell carbonated sugar-water. But I saw nothing in this article that made me offended at what Coca-Cola was doing, though plenty to make me think that Bob Kolody was a strange and irrational man.
If you don't want your employer to find out personal details about you, don't use their computers, or phones, for personal things.
Back in the heyday of phones, some employers started snooping on personal conversations of their employees. This was made illegal. But now, you can snoop on someone using VoIP, though you can't snoop on someone using the hard line phone. It's an inconsistency in the law.
The legislator back then realized that you have some privacy even at work. Due to the evolutionary path of computers in the work-place, it'll be longer for the same regulations to govern some of the more complex communications devices. But regardless, your employer does not own all your communication, even if you use their hardware to make it.
I don't know about you, but not all agreements carry weight. Most of the NDA agreements basically amount to an EULA. Orwellian agreements should be unenforceable. Luckily, they usually are not enforced. Are you telling me that your CEO never emails his family from work, or talks to his kids on the work phone?
The company therefore has a right in saying how you use the things it owns.
The company owns the computer, but not all the information on it. Let's go back to the phone. Does the company own every conversation you have on the work phone? No. So what if your company is using VoIP. Suddenly it owns all the content of all your calls?
You must realize that there is little functional difference between different modes of communication. When the computer is used as a communications tool, the company does not own all the information that goes through it. And it's a mere matter of implementation that a web browser maintains a damning history of activity where a simple phone does not.
Consider this scenario: You log into a webmail account through work. The GET/POST information from your session with the webmail server is stored on either the proxy logs or the machine's cache. Would the company be justified in sniffing out that information and using it to log into your webmail account and read all your personal correspondence?
Information is not a physical thing. There is much information that a company has access to but still does not own. They own the physical machines used to store that information, but not the information itself.
No one is arguing that this distinction doesn't hold. Let's say I put an MP3 on my work computer. Does the company suddenly own all rights to that MP3? No. Just because something is on a work computer does not mean that it is owned by the company. What you're arguing is that this distinction doesn't hold for workers. Why you're holding this, I don't know. It doesn't seem a very rational belief.
I haven't written a regex parser in Java, although I've used APIs written by others. They worked fine. I have designed languages, and used Java as the development language for the parser/compiler. Again, it worked quite well, and I doubt I would've had a noticeable gain by using C (especially since it would've been slower).
You're changing the topic. Yes, a regular expression parser can be written efficiently in Java, as I did. But you basically have to leave OO aside (minus the API). If the entire point of your application is to do regular expression parsing, then why use Java when it's more complicated than using C/C++. Besides, the tasks I needed to perform were especially stressful--they involved evaluation of a single regular expression that was about 200 lines or 5000 characters long against successive files. This will crash many regular expression parsers (MKS's AWK is an example).
But this is all moot because you were accusing me of failing to program trivial tasks correctly. Writing a regular expression parser is by no means a trivial task. You do not realize the complexity of the task by simply using an API. First you have to construct a NFA using lamba transitions, then you have to make it a DFA by collapsing the lambda transitions and removing any duplicate transitions. Ok, not too bad. Now you have to come up with a way to track the "back refs", so you have some info about what was just parsed.
If I used lex and yacc I would've learned how to use lex and yacc. I wouldn't have learned to parse a language. It's nice to have an API that helps with some tasks. But what about when you have a task for which no cookie-cutter is provided by the API. I know I'd be able to still come up with a solution, but you seem to rely too heavily on APIs.
This could go on forever. The point is, for most applications Java performs quite well. Especially parsing a few MB of text, doing some basic financial stuff (ie. not derivatives analysis), there's no reason to have performance issues with Java (other than poor programming).
Yes, this could go on forever. If you are programming a database intensive application, or a network intensive application, then, in most circumstances, you application will be so bottlenecked on the database or the network that Java will take 5% CPU time while C++ will take 2.5% CPU time. But these are not the tasks I'm talking about. I'm talking about categorizing and movement of significant amounts of data. For example, interfacing with Taxware required creation of char buffers of several thousand characters for each transaction. Maybe this comes close enough to the "numerical tasks" you keep referencing.
One financial company I knew could only get appropriate performance by creating a Berkeley style DB and leaving it in RAM. Everything was coded in C/C++. And I know these people didn't have 3 million concurrent users. So I must wonder what the complexity of the task is that your application was so smoothly able to perform.
Java does slash development time for some tasks. But for many, it takes more development to do something in Java. Then Java loses in performance and development time. So why use it for these tasks? I guess it shouldn't be.
Not getting upset? Jesus, man, then how do you explain your last post?
You can call my work trivial when you show me your own regular expression parser written in Java (no help from the API allowed). It's not trivial, I don't care how smart you are. Incidentally, I've programmed my own languages before, so I have some decent understanding of how computer languages work. Nothing complicated language wise, but it doesn't take much for the task to be extremely complicated to implement. And no, I didn't use lex or yacc.
I think you have a differing opinion of what is "just fine" than I do. You'd probably look at my program and see nothing wrong with it. But that I could optimize it and get 80% better performance by avoiding allocation altogether tells me that something is wrong with the garbage collection of Java.
Just accept the fact that you don't understand it. Not everyone can understand everything (some less than others). You've had problems implementing some relatively simple things in Java (the kind of stuff it's traditionally pretty good at). Stop trying to place the blame elsewhere. [Mirror test]
Servers for cellular phone systems. When I was last involved, they were spec'd at 3,000,000 simulataneous users (worst case scenario), with a typical load somewhere around 1/3 of that.
Java server for such a task? I highly doubt it. Java client I could understand. In any case, using Java probably necessitated about 10 times the hardware that a lower level language would demand. I mean, you could make it as efficient, but only if you avoid java.util.* and any serious allocations.
String objects are immutable. Yes, I had a typo in one of my posts.
When facing a troll, you can do something called the "mirror test". If something makes sense when redirected at the person saying it, then it has no relevance to the conversion. Let's partake in this exercise:
You seriously do not know what you are talking about. Take a class or something, because you're way out of your league. I doubt you can really program in C++, because I don't think you understand object-orientation. I think you were programming C++ as if it were C. It sounds like your problems are a result of poor programming for OO.
The supposed examples you give are bullshit, and prove that you're fucking incompetent.
See, that was easy. No content. And what you say afterward makes me know you're full of shit:
There are tons of transaction-based systems in Java. I see no reason why you're application is that special. I've worked on ones that support millions of concurrent users, manipulating 50+kB files, at thousands of transactions per second.
I'll bite. What type of fucking system can process millions of users concurrently? Tell me, please. If you mean a stateless web app, then you're simply lying, because there is no concurrency going on for any significant percentage of those million cookies you have stored in a table somewhere. If you have a million concurrent users, then the data stored for each user can't be more than a few ints. If your user data isn't in memory, then it's not concurrent. That is, the user operations are not operating concurrently, and thus cannot said to be "concurrent".
This is very common. Lots of programs do similar things. If it's not working, it's your fault.
You're right. It was my fault for using Java. Java does many things well, but when performance is an issue, Java should be the last choice.
I just had to reply to this, because your obvious ignorance (and associated arrogance) are really irritating. [See, that's the mirror test again.]
Even in C, though, you wouldn't call malloc() in a tight loop if you wanted optimal performance.
Java doesn't give you the choice. In C++, objects can be on the stack, which doesn't have to be allocated. Of course, you can just bring all your variables out of the loop, but that could end up complicating your code more than porting it from Java to C++ would.
And again, I said it wasn't a great test, just better. Replicating the conditions that I was experiencing naturally occur probably after about two thousand lines of code. And if I knew what was causing it, I might be able to reduce it to a few hundred lines. But thanks for checking it out.
I have a limited amount of attention and effort I can spend. The whole point of computers is to take the boring parts and have a machine do them, freeing me to think about the important, interesting parts. For the kind of stuff I code, memory allocation is in the boring category about 99.99% of the time. For the 1 time in 10,000 where it really matters, then fine, I'll write native code. But the rest of the time, let the machines do the donkey work.
Well, this is the point I've been trying to make. Java was supposed to make this stuff invisible. But for programs of even moderate complexity it shines through. So I have to write my code in a way that would makes it more complicated in Java than it would be in C++. When I have to do this, the argument about saving time is moot because I'm not saving time. So why am I using Java? I shouldn't be, at least for these tasks. And that's the point.
This isn't a real test. You have to actually do something with o that will spike your CPU. As it is, the compiler could see that o is never used and optimize it away. I've even seen compilers optimize away objects that are modified and used, but never reach the user through printing or screen display.
Some people working on the core of the product for our dot-bomb a couple of years ago had many "load" tests like this:
Create some object; Do nothing important with object; Repeat
Everything looked great! Then they ran a load test against the server as a whole and suddenly everything sucked. People who write the compiler certainly thought of all the simple cases. The more difficult cases are different.
I don't have javac on my machine right now. But I would suggest doing something like:
String s = new String("abcdefghijklmnopqrstuvwxyz"); while (true) {
System.out.println(s);
String t = new String();
for(int i=0; i<s.length(); ++i)
{
t += ((s.charAt(i) + 1) % 26) + 'a';
}
s = t; }
This still isn't a great test, because there are very few object types. But it's better. In your test, even if o is not optimized away, the runtime can just keep giving you the same Object each and every time without actually ever deallocating it. A garbage collector that doesn't do some form of object pooling isn't worth it's weight in salt.
I do agree that it might be a good idea to allow more tuning to the garbage collector. Instead of telling it "delete, now" though, I'd prefer something along the lines of "force the GC to run now."
Here's what you're looking for. Don't expect your program to be able to do anything for a few seconds when you run it. Using System.gc() or equivalent has been in my experience a bad way to keep memory usage down.
Slashdot Mirror
Well, there are people who don't like the preprocessor and have been coding for quite a while. I've been coding C++ for 7 years and as time goes on I like the preprocessor less and less. The main reason is that it is an obstacle to tools that help development. One common example is the debugger--not even Microsoft's Visual C++ could render macros transparent.
Another problem is tools that do automatic code-folding have a much more difficult job with macros. I was using jGRASP because it does a great job of code-folding. The only problem is that it couldn't handle macros. So a macro that expands with a semi-colon to make a complete statement would be seen instead as the first token of the next statement. Now you may fault the programmer for not figuring out how to do code-folding with macros, but I believe the difficulty is inherent in the language itself. In order to handle macros properly, it would have to have a built-in preprocessor.
The third problem is code I'm reading or writing. It is often infuriating to try to figure out syntax problems that involve macros. The macros are supposed to make things easier, but instead they just make them opaque. One of the worst offenders is MFC, with macros like IMPLEMENT_DYNAMIC and AFX_*.
It seems problematic that to figure out the proper syntax of the language a preprocessor must be run first. The existence of the preprocessor has many advantages, but it has many detriments too. It invites API programmers to create macro-shortcuts that hide the syntax. These attempts at abstraction introduce all the problems of abstract languages (opaque-ness) while avoiding all the benefits of abstract syntax (safety, simplicity).
Yes, that's the point. Math is an algorithmic process, one that gives answers to various well defined questions. You can ask an unanswerable question, such as "What percentage of 0 is X?" or you can ask an answerable question, such as "What is X% of 0?". The first question will literally have no answer, the second will always be zero.
100% of 0 is 0. And everyone gets a hundred percent of the total, including me. Math is fun.
(It all depends on how you ask the question. If you ask "How much is 100% of 0?" you have a well defined answer. If you ask, "What percentage of 0 is 0?" you have a problem with division. The solution: be a little more charitable and allow yourself to laugh every once in a while.)
This also:Besides, I've never heard of a license to own but not to use. Is such a license even legal?
You cannot impose any restrictions on the redistribution of GPL software. "Redistribution" can be defined as to another entity, or to yourself. Just as you cannot force royalties on top of GPL software, you cannot force contract agreements on it either. If you try to do this, the GPL still holds effect, basically invalidating any use of the software altogether.
It really seems that RHAT is violating the GPL here. This is a serious issue, one that RHAT should clarify and correct immediately.
No, I believe you have it wrong. This engineer had the task of making a compatibility layer between Linux and SCO. Many of the functions in the compatibility layer were "one-liners". That means that they just passed through the call to the SCO function, which operated in an exact manner.
Now, the engineer could have interpreted the similarities between SCO code and Linux code to be the result of previous copying by SCO from Linux, but this seems unlikely. The calls existed in SCO first, and SCO existed before Linux. Furthermore, it is unlikely that SCO changed the function calls much since their inception, because that would break backwards compatibility.
On the other hand, this same argument makes it unlikely that the code got from SCO into Linux. Unless someone was copying code into Linux from the very beginning, the system calls would have originally been written without SCO code. And again, to preserve backwards compatibility (as much as Linux does), it would have been unwise to take a totally different version from another operating system.
What is most likely is that most sets of API implementations have a common anscestor--BSD. The system calls actually do not change much, and if I am reasoning correctly, are not as likely to differ between operating systems. This means they could easily be taken from BSD into Linux. I haven't undertaken the actual verification of this, but Linus himself says that much of Linux comes from BSD.
The reason I don't think the system calls usually differ is this. The more complicated parts of the kernel, such as virtual memory management and task scheduling, are actually not exposed via the API. As such, these architectural pieces of code would not be necessary to reimplement for the system calls.
I think you are underestimating IBM's interest in Linux. IBM is doing well largely due to Linux. What do customers want? Freedom from lockin. The only way to give that to them is by selling services around non-proprietary software. I don't think IBM would settle this for a dollar and let SCO take control of Linux. It doesn't make sense.
Besides, I have never heard of any public domain, BSD, or GPL copyright being slurped up into a propriety product because of the proprietary product's "overriding interest", or what have you.
It doesn't establish the origin. It just establishes that they have the same origin. UnixWare has been around longer than Linux, so I think it is safe to say that these functions were in UnixWare first. But I do believe that their path into Linux was almost certainly via the common parent of BSD licensed code. Especially given their age.
Now it's possible some coders in the mid nineties decided to beef up SCO's unix by copying code over from Linux, but why? It would break backwards compatibility. And similarly, why would these functions change much from the beginning of Linux? They probably did not. So unless SCO's code got into Linux from the near beginning, I think it is much more likely that BSD is the common descendant.
It seems fishy. They were writing SCO code while having the Linux code in front of them. That is a big No-No if you want to avoid violating the GPL.
I imagine most of the system calls were pretty basic stuff, stuff that has probably been in BSD since early 90's. Note that FreeBSD also has a pretty happenin' Linux compatibility layer. Has anyone ever compared FreeBSD to Linux? I imagine Linux borrowed a bit from FreeBSD, especially for the basic calls that.
The difference hear is that SCO is basically asking us to take their word for it. It's like the proselytizer who asks us to believe in his god on "faith". If I balk at the proselytizer, he will tell me that the "truth will be seen" when I die. Similarly, SCO will show us the "evidence" when we sign an NDA that basically prevents us from practicing our livelihoods. It's an unexceptable condition to see the evidence. And just as god will "test" us by not showing evidence of his existence, similarly bizarre reasons exist for SCO not showing evidence of infringement.
Things will hopefully wrap up on Friday, when SCO is supposed to revoke the AIX license. If they take IBM to court, they will have to show evidence. If they don't, then they lose credibility. Either way, they lose.
When I'm in this situation, I just do it. My dignity is at stake, so I'll even put in extra time to do it on off hours and weekends. If the solution already exists, then the boss will be very reluctant to pay for a second implementation.
On the other hand, if it would be too much work to get done on your own time, then your boss is probably correct in getting it outsourced.
- Only inform each client of players visible to that client--prevents wall-hacks.
- Track the accuracy of each weapon. Not the shots, but the aiming of the weapon. There should be an expected variance that is a function of the relative velocity of two players. If the relative velocity is high, and the aim remains perfect, it's probably a cheater.
- Create a global anti-cheat list, which will be similar to the open-relay black-lists. If the game is purchased, and each copy comes with a unique ID, then a person who is caught cheating can be added to the blacklist. An admin should record a demo of the cheating, which can be reviewed and appealed.
- For a free game like America's Army, use the MAC address. Can still be spoofed, but not too easy.
There are other things that can be done, but are less desireable:- Prevent perfect accuracy. Make it so that a certian percentage of shots always miss, no matter how good the player is.
- Give each weapon "kick". If aim is perfect even with a kicking weapon, it's definitely a cheater.
- Each weapon reduces damage the more accurate you are with it.
These last three are less desireable. But simply doing a CRC for files on the system that enable cheating is not a good strategy.Not praising Coca-Cola, they basically sell carbonated sugar-water. But I saw nothing in this article that made me offended at what Coca-Cola was doing, though plenty to make me think that Bob Kolody was a strange and irrational man.
The legislator back then realized that you have some privacy even at work. Due to the evolutionary path of computers in the work-place, it'll be longer for the same regulations to govern some of the more complex communications devices. But regardless, your employer does not own all your communication, even if you use their hardware to make it.
I don't know about you, but not all agreements carry weight. Most of the NDA agreements basically amount to an EULA. Orwellian agreements should be unenforceable. Luckily, they usually are not enforced. Are you telling me that your CEO never emails his family from work, or talks to his kids on the work phone?
You must realize that there is little functional difference between different modes of communication. When the computer is used as a communications tool, the company does not own all the information that goes through it. And it's a mere matter of implementation that a web browser maintains a damning history of activity where a simple phone does not.
Consider this scenario: You log into a webmail account through work. The GET/POST information from your session with the webmail server is stored on either the proxy logs or the machine's cache. Would the company be justified in sniffing out that information and using it to log into your webmail account and read all your personal correspondence?
Information is not a physical thing. There is much information that a company has access to but still does not own. They own the physical machines used to store that information, but not the information itself.
No one is arguing that this distinction doesn't hold. Let's say I put an MP3 on my work computer. Does the company suddenly own all rights to that MP3? No. Just because something is on a work computer does not mean that it is owned by the company. What you're arguing is that this distinction doesn't hold for workers. Why you're holding this, I don't know. It doesn't seem a very rational belief.
But this is all moot because you were accusing me of failing to program trivial tasks correctly. Writing a regular expression parser is by no means a trivial task. You do not realize the complexity of the task by simply using an API. First you have to construct a NFA using lamba transitions, then you have to make it a DFA by collapsing the lambda transitions and removing any duplicate transitions. Ok, not too bad. Now you have to come up with a way to track the "back refs", so you have some info about what was just parsed.
If I used lex and yacc I would've learned how to use lex and yacc. I wouldn't have learned to parse a language. It's nice to have an API that helps with some tasks. But what about when you have a task for which no cookie-cutter is provided by the API. I know I'd be able to still come up with a solution, but you seem to rely too heavily on APIs.
Yes, this could go on forever. If you are programming a database intensive application, or a network intensive application, then, in most circumstances, you application will be so bottlenecked on the database or the network that Java will take 5% CPU time while C++ will take 2.5% CPU time. But these are not the tasks I'm talking about. I'm talking about categorizing and movement of significant amounts of data. For example, interfacing with Taxware required creation of char buffers of several thousand characters for each transaction. Maybe this comes close enough to the "numerical tasks" you keep referencing.
One financial company I knew could only get appropriate performance by creating a Berkeley style DB and leaving it in RAM. Everything was coded in C/C++. And I know these people didn't have 3 million concurrent users. So I must wonder what the complexity of the task is that your application was so smoothly able to perform.
Java does slash development time for some tasks. But for many, it takes more development to do something in Java. Then Java loses in performance and development time. So why use it for these tasks? I guess it shouldn't be.
You can call my work trivial when you show me your own regular expression parser written in Java (no help from the API allowed). It's not trivial, I don't care how smart you are. Incidentally, I've programmed my own languages before, so I have some decent understanding of how computer languages work. Nothing complicated language wise, but it doesn't take much for the task to be extremely complicated to implement. And no, I didn't use lex or yacc.
I think you have a differing opinion of what is "just fine" than I do. You'd probably look at my program and see nothing wrong with it. But that I could optimize it and get 80% better performance by avoiding allocation altogether tells me that something is wrong with the garbage collection of Java.
Just accept the fact that you don't understand it. Not everyone can understand everything (some less than others). You've had problems implementing some relatively simple things in Java (the kind of stuff it's traditionally pretty good at). Stop trying to place the blame elsewhere. [Mirror test]
Java server for such a task? I highly doubt it. Java client I could understand. In any case, using Java probably necessitated about 10 times the hardware that a lower level language would demand. I mean, you could make it as efficient, but only if you avoid java.util.* and any serious allocations.
When facing a troll, you can do something called the "mirror test". If something makes sense when redirected at the person saying it, then it has no relevance to the conversion. Let's partake in this exercise:
You seriously do not know what you are talking about. Take a class or something, because you're way out of your league. I doubt you can really program in C++, because I don't think you understand object-orientation. I think you were programming C++ as if it were C. It sounds like your problems are a result of poor programming for OO.
The supposed examples you give are bullshit, and prove that you're fucking incompetent.
See, that was easy. No content. And what you say afterward makes me know you're full of shit:
I'll bite. What type of fucking system can process millions of users concurrently? Tell me, please. If you mean a stateless web app, then you're simply lying, because there is no concurrency going on for any significant percentage of those million cookies you have stored in a table somewhere. If you have a million concurrent users, then the data stored for each user can't be more than a few ints. If your user data isn't in memory, then it's not concurrent. That is, the user operations are not operating concurrently, and thus cannot said to be "concurrent".
You're right. It was my fault for using Java. Java does many things well, but when performance is an issue, Java should be the last choice.
I just had to reply to this, because your obvious ignorance (and associated arrogance) are really irritating. [See, that's the mirror test again.]
And again, I said it wasn't a great test, just better. Replicating the conditions that I was experiencing naturally occur probably after about two thousand lines of code. And if I knew what was causing it, I might be able to reduce it to a few hundred lines. But thanks for checking it out.
Some people working on the core of the product for our dot-bomb a couple of years ago had many "load" tests like this:Everything looked great! Then they ran a load test against the server as a whole and suddenly everything sucked. People who write the compiler certainly thought of all the simple cases. The more difficult cases are different.
I don't have javac on my machine right now. But I would suggest doing something like:This still isn't a great test, because there are very few object types. But it's better. In your test, even if o is not optimized away, the runtime can just keep giving you the same Object each and every time without actually ever deallocating it. A garbage collector that doesn't do some form of object pooling isn't worth it's weight in salt.