I know, I know, it's damn near impossible to believe, but the Firefox developers voluntarily chose to write a huge portion of Firefox in JavaScript and XML (XUL). The rendering engine and network stack are written in C++, but just about everything else is implemented using JavaScript and XUL, including all of the UI.
This is why JavaScript performance is so important to Firefox. While other browsers didn't make the same mistake, and wrote the bulk of the browsers in a real language like C++, the Firefox developers chose what is probably the stupidest architecture possible. A slow JavaScript implementation means their entire browser is slow, rather than just any web pages that might use JavaScript in some way.
Writing Firefox's UI in JavaScript makes it scriptable. That allows the plugin system they have, which is more flexible than the competition's. It also means it's easier to write custom UIs - mobile Firefox is basically Firefox with different JS for the UI. It's much quicker to do that than write C++ UIs for everything.
But as you said, it does have downsides as well, mainly speed. There's a tradeoff here, pick the one you prefer.
Going back several millennium - I've consistently had this problem with FireFox. On Windows (2000, XP, Vista), Linux, and OS X. It's not a specific version. It has nothing to do with platform.
Firefox has speed and memory issues that have been there for eons, that keep getting brushed off with, "Oh, plugins!"
I'm a Firefox dev. Please file a bug with a reproducible case, so we can fix this!
We test very carefully for memory leaks and that sort of thing today, so while I agree that was an issue in the past, it should not be now. But there may be specific corner cases and bugs. Please report them, and we'll work to fix those.
Re:Need a better client-side scripting language
on
How Do Browsers Scale?
·
· Score: 5, Interesting
Why not a VM that runs bytecode, and JIT compiling, so your favourite language can be used?
Several reasons. First, all such VMs - the JVM,.NET, Mono - have far worse startup performance than JavaScript. That's why Java applets never took off. While those VMs improved in that respect, they still lag far behind JS in startup time. They are optimized for long-running processes, not small client scripts that should get going instantaneously. Different goals here.
Second, there is no clear open standard for such a VM anyhow. The JVM and CLR are known to have various patents around them; we have recently seen Oracle sue Google, and Microsoft execs have admitted that Mono is only free from risk because it is licensed by Microsoft. So neither is a good foundation for something meant to be truly open and free, like the Web should be.
Third, existing JavaScript engines are, by far, the fastest implementations of dynamic languages out there (much faster than such languages running on the JVM,.NET or Mono - Jython, IronPython, etc.). IMHO it makes sense to have a low bar for writing scripts for websites. You shouldn't need to do C/C++ memory management, or write lots of static typing definitions, to add a little scripting to your website. So something like JavaScript, Python or Ruby makes sense. But again, this last point is clearly debatable, that's just my opinion.
Why, oh why did javascript become the defacto client-side scripting language for the browser
If you want to scale horizontally across multi-cores, you need a language that allows easy multi-threading and concurrency
About the only thing JS offers for concurrency is that horrid settimeout function
setTimeout has nothing to do with concurrency. That stuff runs on the main thread. In other words, that's asynchronicity, not concurrency.
But JavaScript does support concurrency, you can access native OS threads using web workers.
Why not incorporate a Python interpreter into browsers, and develop a stripped down sub-set of python for use on the web
I love Python, but JavaScript has better support for concurrency than Python at this point. Python's main implementation also has the Global Interpreter Lock.
I'm looking at this two ways: What could MS use SL technology for?
It's more of, "how can Microsoft push its agendas better by buying SL?" Here is how.
Currently the SL main grid runs on Linux servers, with Mono powering the scripting engine. However, there is an open source reverse-engineered replacement server for the official SL servers, called OpenSim. OpenSim is written in C#, and has gotten some support and interest from Microsoft. You can currently only use the official servers in the SL main grid, while people outside tinker with OpenSim.
Microsoft can buy SL, scrap all those Linux servers and the official SL server code, and switch it all to OpenSim on.NET on Windows Server. This would be somewhat like switching Hotmail to Windows (which did not go at all smoothly...). The overall goal would be to kill off the existing SL server code, and position OpenSim as the 'Apache of virtual worlds'. And that Apache happens to run much better on.NET/WIndows Server than Mono/Linux (simply because Mono's performance is much poorer than.NET - the OpenSim developers complain about this). For this reason it was not the best decision to write OpenSim in C#.
So, if virtual worlds take off and become a huge market, Windows Server will be in a position to gain. Will that actually happen? Who knows. But it's worth a few million $ to Microsoft, they made that in the time it took me to write this comment.
For example, Microsoft could sell off one of the relevant patents to a proxy agent, which would then sue anyone and everyone (but Microsoft).
You are just forgetting a small detail. And so is your Internet groklaw echo-chamber: Selling off a patent does not absolve the buyer from the licenses granted for the patent.
The point is that a license has *not* been granted. There is just a promise that *Microsoft* (and it alone) will not sue you. So there is nothing to transfer to the buyer.
Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation, to the extent it conforms to one of the Covered Specifications, and is compliant with all of the required parts of the mandatory provisions of that specification ("Covered Implementation")
As explained in many places on the web, this "Microsoft will not sue you" is very different from actually granting a license. Even if this promise is irrevocable and perpetual. For example, Microsoft could sell off one of the relevant patents to a proxy agent, which would then sue anyone and everyone (but Microsoft). If you think that's a crazy idea, then (1) there are good reasons to suspect this or very close to it happened with Microsoft and SCO, and (2) just the other day we saw Paul Allen sue everybody in tech - but Microsoft, which led many to suspect this was Microsoft starting a patent war by proxy (so it can't be sued back. Paul Allen is a non practicing entity at this point, so nothing to sue him over).
Re:If they can do it to Google, they can do it to
on
The Case For Oracle
·
· Score: 1
Languages are (sadly) patentable. There are patents on, for example, Java and C#.
So I am not sure this gets Google off the hook.
Re:If they can do it to Google, they can do it to
on
The Case For Oracle
·
· Score: 3, Insightful
Since Google never claimed it was Java
Maybe Google never formally said that, but here is how Wikipedia describes Android:
The Android operating system software stack consists of Java applications running on a Java based object oriented application framework on top of Java core libraries running on a Dalvik virtual machine featuring JIT compilation.
Even clearer, Google says
The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
in developer.android.com.
I suppose you can call it The-Language-Previously-Known-As-Java or such (worked for Prince, til his contract ran out), but it is Java in every way that counts, except it has some differences that make Java the platform as a whole less standard. This irked Sun, and for good reason, but they got over it. Oracle is not over it. Sadly they decided to enforce this using patents, which is an abhorrent thing to do. But that they are irked by Google's actions - very understandable.
Re:History Repeating Itself
on
The Case For Oracle
·
· Score: 2, Interesting
I agree. I guess Google went with Java because mobile phone devs were already familiar with Java (ME), but by not partnering with Sun on that, they took a big risk. Exactly the risk Novell would be taking with Mono had they not made the Novell-Microsoft pact. (Of course, we in the FOSS community didn't like that pact for other reasons. But it made sense for Novell, as far as Mono goes at least.)
If Google wasn't willing to partner with Sun on Java (maybe because Google wanted a pure FOSS implementation, without Sun having a privileged position?) then Google should have ditched Java and gone with JavaScript or Python. But again, I guess they didn't because Java was the easy route. Since then though we've seen WebOS with JavaScript.
That's because the market has chosen to give a care only about these instruction sets. Can you name a computing product sold this month that 1. runs a web browser, 2. isn't marketed primarily as a video game console, and 3. uses something other than ARM or x86 as its primary CPU?
How many of those "pirates" live in places where $20 is a more than a whole day's wage?
That depends. Into the native languages of how many such places have the games in question been localized?
Most if not almost all games can be played by people anywhere on the globe. For one thing, most games (maybe except for RPGs) don't involve a lot of language. The UIs are made as language-free as possible exactly for that reason - icons for different guns, etc. And secondly, the little amount of language present is generally English, which most people in the world can speak at least a tiny amount of. In fact they tend to learn the tiny amount they actually need, which for most games is just a few words if that.
There are far more people on the 'net that can't afford to pay full price for games than can. So why should it be surprising that piracy rates are high?
The only way to rule this out as the explanation for high piracy rates would be to sell localized versions at extremely low prices, that most internet users can actually afford. Did this indie game get sold that way? I doubt it.
Don't get me wrong, I love FF but I am worried about what happens after the deal with google expires.
Realistically, it won't expire anytime in the foreseeable future. Google is very happy about the deal with Firefox - they get put as the default search engine for 25% of web users. If that translates into any positive amount of search share - and it does - then Google won't stop the deal with Mozilla.
The Google-Mozilla deal isn't charity from Google. It helps them to compete with their actual competitors - Bing, Baidu, Yahoo, etc.
Symbian could be nice, but it seems like targeting MeeGo would be a better bet, especially as they already have a Maemo version done and MeeGo is the heir apparent for Symbian.
The real question is why bother to bring out a version for Maemo when Maemo is an evolutionary dead end, that will have no future versions? MeeGo is the replacement for Maemo! Typical Mozilla timing... well behind where it needs to be.
99% of Firefox Mobile development is platform-agnostic. You can flip a switch at compile time and it builds against GTK or Qt, and/or on Maemo/Meego or Android.
The only 'focus' on Maemo might be that there is a current userbase there, so it's cool to have official updates for them.
It's a matter of degree. From a practical point of view, there are only a certain set of languages/frameworks that you can write in, that will produce appropriate bytecode for WP7. So in that sense, they have simply taken away entire languages/frameworks that developers could previously use, just like Apple did. Apple just did more of that. But both actions are very anti-developer (it's just that Windows Mobile is becoming irrelevant, so people don't care. But if it were dominant, they would).
Imagine Microsoft demanding all windows apps to be written only in C# and compiled only with Visual Studio. It would be an outrage. But hey, it's Steve Jobs, the Big Brother himself, and he knows what's best for us, right?
Funny you should mention that. Microsoft recently announced that apps for Windows 7 phones *must* run on.NET. No native code at all. This has screwed over lots of people, since Windows Mobile used to allow native code. For example Mozilla wrote a version of Mobile Firefox for Windows phones, which now cannot run anywhere.
So get over your sense of outrage. It isn't just Apple. And if you don't like it, don't buy their stuff or develop for it. They don't have a monopoly, so you are free to go to their competitors (Android/MeeGo).
C'mon apple. You have to allow unity. You can't want games but require everyone to make them from scratch.
Jobs believes that people will write *new* game frameworks for Apple products, ones that are custom-made for that platform. That's what he wants. And given the marketshare he has, it will likely happen. In fact I would start writing one myself the instant it is official that Unity etc. are banned (if I weren't busy with other stuff).
I am not a fan of deterrence, as I mentioned earlier. But the point of it here would be, that you deter people by saying, "if you leave guns around recklessly, you get punished." The punishment is legal. That, in this particular instance, in addition there was a horrific personal punishment as well - death of a child - is not a legal issue.
To forgo legal punishment because of the personal loss implies there are cases where the legal punishment can be waived. Which reduces deterrence.
It is a sad day when one decides to value the dollar worth of a human life.
It is indeed sad, but life is sad that way. If you don't think about the dollar worth, more human lives are lost. As she said in the article, the deceased himself, had he known the costs of his care could be used to vaccinate a tremendous amount of third-world children - he would have preferred the money be spent that way.
It's important to realize, as you do, that human life is not equal to any monetary amount. But it's also important to realize that we have a limited amount of resources, and we need to think about how to utilize them, to have the best possible effect on people, including saving their lives. That includes calculating how much it costs to keep a person alive.
You can't copy the AI algorithm - it is never sent to the client, in the idea I suggested. The client sends position info to the server; the server does the complex AI stuff; the server sends back just the final output of the AI calculations, just enough to move the enemies. And since each game is slightly different, the queries sent to the server - and the responses - are unique.
There is basically no way to break that, except to reverse-engineer the AI.
(Of course it comes with a cost - CPU time on the server for the AI.)
Vogel's point was only that it would take longer to hack, which would lead to more sales during the first early weeks - basically when all the money is made.
But, taking this a little further, it would be possible to make this sort of 'DRM' very secure. As I said elsewhere, how about doing enemy AI on the server (and not just game saving/loading). AI doesn't need to be super-responsive like physics, so adding a little lag due to client-server communication is not the end of the world. Hacking such a game would mean reverse engineering a very complicated part of the game - basically forcing the hacking team to do something as difficult as writing the game itself (or more specifically a crucial, complex part of it). Hacking such a game is not feasible.
Slashdot Mirror
I know, I know, it's damn near impossible to believe, but the Firefox developers voluntarily chose to write a huge portion of Firefox in JavaScript and XML (XUL). The rendering engine and network stack are written in C++, but just about everything else is implemented using JavaScript and XUL, including all of the UI.
This is why JavaScript performance is so important to Firefox. While other browsers didn't make the same mistake, and wrote the bulk of the browsers in a real language like C++, the Firefox developers chose what is probably the stupidest architecture possible. A slow JavaScript implementation means their entire browser is slow, rather than just any web pages that might use JavaScript in some way.
Writing Firefox's UI in JavaScript makes it scriptable. That allows the plugin system they have, which is more flexible than the competition's. It also means it's easier to write custom UIs - mobile Firefox is basically Firefox with different JS for the UI. It's much quicker to do that than write C++ UIs for everything. But as you said, it does have downsides as well, mainly speed. There's a tradeoff here, pick the one you prefer.
Going back several millennium - I've consistently had this problem with FireFox. On Windows (2000, XP, Vista), Linux, and OS X. It's not a specific version. It has nothing to do with platform.
Firefox has speed and memory issues that have been there for eons, that keep getting brushed off with, "Oh, plugins!"
I'm a Firefox dev. Please file a bug with a reproducible case, so we can fix this!
We test very carefully for memory leaks and that sort of thing today, so while I agree that was an issue in the past, it should not be now. But there may be specific corner cases and bugs. Please report them, and we'll work to fix those.
Why not a VM that runs bytecode, and JIT compiling, so your favourite language can be used?
Several reasons. First, all such VMs - the JVM, .NET, Mono - have far worse startup performance than JavaScript. That's why Java applets never took off. While those VMs improved in that respect, they still lag far behind JS in startup time. They are optimized for long-running processes, not small client scripts that should get going instantaneously. Different goals here.
.NET or Mono - Jython, IronPython, etc.). IMHO it makes sense to have a low bar for writing scripts for websites. You shouldn't need to do C/C++ memory management, or write lots of static typing definitions, to add a little scripting to your website. So something like JavaScript, Python or Ruby makes sense. But again, this last point is clearly debatable, that's just my opinion.
Second, there is no clear open standard for such a VM anyhow. The JVM and CLR are known to have various patents around them; we have recently seen Oracle sue Google, and Microsoft execs have admitted that Mono is only free from risk because it is licensed by Microsoft. So neither is a good foundation for something meant to be truly open and free, like the Web should be.
Third, existing JavaScript engines are, by far, the fastest implementations of dynamic languages out there (much faster than such languages running on the JVM,
Why, oh why did javascript become the defacto client-side scripting language for the browser If you want to scale horizontally across multi-cores, you need a language that allows easy multi-threading and concurrency About the only thing JS offers for concurrency is that horrid settimeout function
setTimeout has nothing to do with concurrency. That stuff runs on the main thread. In other words, that's asynchronicity, not concurrency.
But JavaScript does support concurrency, you can access native OS threads using web workers.
Why not incorporate a Python interpreter into browsers, and develop a stripped down sub-set of python for use on the web
I love Python, but JavaScript has better support for concurrency than Python at this point. Python's main implementation also has the Global Interpreter Lock.
I'm looking at this two ways: What could MS use SL technology for?
It's more of, "how can Microsoft push its agendas better by buying SL?" Here is how.
.NET on Windows Server. This would be somewhat like switching Hotmail to Windows (which did not go at all smoothly...). The overall goal would be to kill off the existing SL server code, and position OpenSim as the 'Apache of virtual worlds'. And that Apache happens to run much better on .NET/WIndows Server than Mono/Linux (simply because Mono's performance is much poorer than .NET - the OpenSim developers complain about this). For this reason it was not the best decision to write OpenSim in C#.
Currently the SL main grid runs on Linux servers, with Mono powering the scripting engine. However, there is an open source reverse-engineered replacement server for the official SL servers, called OpenSim. OpenSim is written in C#, and has gotten some support and interest from Microsoft. You can currently only use the official servers in the SL main grid, while people outside tinker with OpenSim.
Microsoft can buy SL, scrap all those Linux servers and the official SL server code, and switch it all to OpenSim on
So, if virtual worlds take off and become a huge market, Windows Server will be in a position to gain. Will that actually happen? Who knows. But it's worth a few million $ to Microsoft, they made that in the time it took me to write this comment.
For example, Microsoft could sell off one of the relevant patents to a proxy agent, which would then sue anyone and everyone (but Microsoft).
You are just forgetting a small detail. And so is your Internet groklaw echo-chamber: Selling off a patent does not absolve the buyer from the licenses granted for the patent.
The point is that a license has *not* been granted. There is just a promise that *Microsoft* (and it alone) will not sue you. So there is nothing to transfer to the buyer.
Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation, to the extent it conforms to one of the Covered Specifications, and is compliant with all of the required parts of the mandatory provisions of that specification ("Covered Implementation")
As explained in many places on the web, this "Microsoft will not sue you" is very different from actually granting a license. Even if this promise is irrevocable and perpetual. For example, Microsoft could sell off one of the relevant patents to a proxy agent, which would then sue anyone and everyone (but Microsoft). If you think that's a crazy idea, then (1) there are good reasons to suspect this or very close to it happened with Microsoft and SCO, and (2) just the other day we saw Paul Allen sue everybody in tech - but Microsoft, which led many to suspect this was Microsoft starting a patent war by proxy (so it can't be sued back. Paul Allen is a non practicing entity at this point, so nothing to sue him over).
Languages are (sadly) patentable. There are patents on, for example, Java and C#.
So I am not sure this gets Google off the hook.
Since Google never claimed it was Java
Maybe Google never formally said that, but here is how Wikipedia describes Android:
The Android operating system software stack consists of Java applications running on a Java based object oriented application framework on top of Java core libraries running on a Dalvik virtual machine featuring JIT compilation.
Even clearer, Google says
The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
in developer.android.com.
I suppose you can call it The-Language-Previously-Known-As-Java or such (worked for Prince, til his contract ran out), but it is Java in every way that counts, except it has some differences that make Java the platform as a whole less standard. This irked Sun, and for good reason, but they got over it. Oracle is not over it. Sadly they decided to enforce this using patents, which is an abhorrent thing to do. But that they are irked by Google's actions - very understandable.
I agree. I guess Google went with Java because mobile phone devs were already familiar with Java (ME), but by not partnering with Sun on that, they took a big risk. Exactly the risk Novell would be taking with Mono had they not made the Novell-Microsoft pact. (Of course, we in the FOSS community didn't like that pact for other reasons. But it made sense for Novell, as far as Mono goes at least.)
If Google wasn't willing to partner with Sun on Java (maybe because Google wanted a pure FOSS implementation, without Sun having a privileged position?) then Google should have ditched Java and gone with JavaScript or Python. But again, I guess they didn't because Java was the easy route. Since then though we've seen WebOS with JavaScript.
However, using another language will present all kinds of issues - which language do they use?
Why not JavaScript? It's extremely well-known, Google already has an excellent implementation (V8), and it is free of licensing worries.
WebOS went that route, I'm surprised Google didn't, especially given that Google's livelihood is the Web.
v8 only runs on ARM and x86.
That's because the market has chosen to give a care only about these instruction sets. Can you name a computing product sold this month that 1. runs a web browser, 2. isn't marketed primarily as a video game console, and 3. uses something other than ARM or x86 as its primary CPU?
x86_64 :P
How many of those "pirates" live in places where $20 is a more than a whole day's wage?
That depends. Into the native languages of how many such places have the games in question been localized?
Most if not almost all games can be played by people anywhere on the globe. For one thing, most games (maybe except for RPGs) don't involve a lot of language. The UIs are made as language-free as possible exactly for that reason - icons for different guns, etc. And secondly, the little amount of language present is generally English, which most people in the world can speak at least a tiny amount of. In fact they tend to learn the tiny amount they actually need, which for most games is just a few words if that.
There are far more people on the 'net that can't afford to pay full price for games than can. So why should it be surprising that piracy rates are high?
The only way to rule this out as the explanation for high piracy rates would be to sell localized versions at extremely low prices, that most internet users can actually afford. Did this indie game get sold that way? I doubt it.
Don't get me wrong, I love FF but I am worried about what happens after the deal with google expires.
Realistically, it won't expire anytime in the foreseeable future. Google is very happy about the deal with Firefox - they get put as the default search engine for 25% of web users. If that translates into any positive amount of search share - and it does - then Google won't stop the deal with Mozilla.
The Google-Mozilla deal isn't charity from Google. It helps them to compete with their actual competitors - Bing, Baidu, Yahoo, etc.
Symbian could be nice, but it seems like targeting MeeGo would be a better bet, especially as they already have a Maemo version done and MeeGo is the heir apparent for Symbian.
The real question is why bother to bring out a version for Maemo when Maemo is an evolutionary dead end, that will have no future versions? MeeGo is the replacement for Maemo! Typical Mozilla timing... well behind where it needs to be.
99% of Firefox Mobile development is platform-agnostic. You can flip a switch at compile time and it builds against GTK or Qt, and/or on Maemo/Meego or Android.
The only 'focus' on Maemo might be that there is a current userbase there, so it's cool to have official updates for them.
It's a matter of degree. From a practical point of view, there are only a certain set of languages/frameworks that you can write in, that will produce appropriate bytecode for WP7. So in that sense, they have simply taken away entire languages/frameworks that developers could previously use, just like Apple did. Apple just did more of that. But both actions are very anti-developer (it's just that Windows Mobile is becoming irrelevant, so people don't care. But if it were dominant, they would).
Imagine Microsoft demanding all windows apps to be written only in C# and compiled only with Visual Studio. It would be an outrage. But hey, it's Steve Jobs, the Big Brother himself, and he knows what's best for us, right?
Funny you should mention that. Microsoft recently announced that apps for Windows 7 phones *must* run on .NET. No native code at all. This has screwed over lots of people, since Windows Mobile used to allow native code. For example Mozilla wrote a version of Mobile Firefox for Windows phones, which now cannot run anywhere.
So get over your sense of outrage. It isn't just Apple. And if you don't like it, don't buy their stuff or develop for it. They don't have a monopoly, so you are free to go to their competitors (Android/MeeGo).
C'mon apple. You have to allow unity. You can't want games but require everyone to make them from scratch.
Jobs believes that people will write *new* game frameworks for Apple products, ones that are custom-made for that platform. That's what he wants. And given the marketshare he has, it will likely happen. In fact I would start writing one myself the instant it is official that Unity etc. are banned (if I weren't busy with other stuff).
I am not a fan of deterrence, as I mentioned earlier. But the point of it here would be, that you deter people by saying, "if you leave guns around recklessly, you get punished." The punishment is legal. That, in this particular instance, in addition there was a horrific personal punishment as well - death of a child - is not a legal issue.
To forgo legal punishment because of the personal loss implies there are cases where the legal punishment can be waived. Which reduces deterrence.
We were not talking about this person, but about punishing him deterring *other* people.
the chance that prosecuting him will scare others into being more careful is also just not there
Why not? Seems like a classic case for deterrence to work, at least if you believe deterrence in general is a worthwhile concept. What am I missing?
It is a sad day when one decides to value the dollar worth of a human life.
It is indeed sad, but life is sad that way. If you don't think about the dollar worth, more human lives are lost. As she said in the article, the deceased himself, had he known the costs of his care could be used to vaccinate a tremendous amount of third-world children - he would have preferred the money be spent that way.
It's important to realize, as you do, that human life is not equal to any monetary amount. But it's also important to realize that we have a limited amount of resources, and we need to think about how to utilize them, to have the best possible effect on people, including saving their lives. That includes calculating how much it costs to keep a person alive.
You can't copy the AI algorithm - it is never sent to the client, in the idea I suggested. The client sends position info to the server; the server does the complex AI stuff; the server sends back just the final output of the AI calculations, just enough to move the enemies. And since each game is slightly different, the queries sent to the server - and the responses - are unique.
There is basically no way to break that, except to reverse-engineer the AI.
(Of course it comes with a cost - CPU time on the server for the AI.)
Vogel's point was only that it would take longer to hack, which would lead to more sales during the first early weeks - basically when all the money is made.
But, taking this a little further, it would be possible to make this sort of 'DRM' very secure. As I said elsewhere, how about doing enemy AI on the server (and not just game saving/loading). AI doesn't need to be super-responsive like physics, so adding a little lag due to client-server communication is not the end of the world. Hacking such a game would mean reverse engineering a very complicated part of the game - basically forcing the hacking team to do something as difficult as writing the game itself (or more specifically a crucial, complex part of it). Hacking such a game is not feasible.