Be carefull with your statement about false positives. Checking the code segment is not as easy as you think: There are shared libraries (e.g. DLLs) loaded in the code segment at runtime. You would have to check them too. Some of these libraries are always provided by the OS and are regularily updated.

Then there are also some completely legit reasons to change the code opf the game: Some AV software embedds itself into programs by changing their bnary code. Some virtualization software changes the code in the VM at runtime. The OS might change some parts of the code to prevent security leaks.

It is not easy to distinguish these actions from hacking the game. But if you don't, legit customers might get hit, after an update of their OS or their AV software.

And in a completely unrelated story, Google builds a city for its employees

Possible solution: Type the password in Notepad and then copy and paste it in the password field.

It is even harder than that. You have to deal with proxy servers, connection limits and the missing "flush" support in http.

You can find a good summary of the problems in the GWT Server Push FAQ.

Summary:

1. Use only one connection for the event notification. Multiplex all events on this single connection. (Reason: Usually limit for 3 connections to the same server).
2. Close the connection after each event. (Reason: No flush in http).
3. About each 50 seconds close the connection and create a new one (Reason: Timeouts in proxy servers).

The reasons for this are mainly improvements in the thread handling in modern operation systems. With the event based approach you must handle the states for multiple sessions all for your self. Usually the space for state handling is stored on the heap. Communication between the sessions must be impelemnted by hand. And when you are not carefully when implementing how the sessions output data, you might add artificailly latency.

With the 1:1 approach (one thread for one session) the state for each session is stored on the stack, the synchronisation can be done by the operating system, and each thread can write its output as soon as it is ready. You only have problems when managing threads is quite expensive, especially when you have thousands of them. And this is where operation systems have improved in the last few years, e.g. Linux with the O(1) scheduler.

A good analysis of this subject together with some numbers can be found in the paper Why events are a bad idea for high performance servers from Microsoft research.

Here in Germany we usually have a mixed model. You pay for the amount of data you have at full speed (3 Mbit/s or 7 Mbit/s depending on provider). When you you have reached that limit you get the rest of the data for free, but your speed is capped (usually 64 kbit/s, sometimes at 300 kbit/s).

For example with Vodafone you get a complete mobile flat with 200 MB per month full speed (7 Mbit/s) and the rest capped at 64 kbit/s for 5,55€ (including 100 telephon minutes, source, English translation.

With O2 you pay 5,58€ for 5GB per month at maximum speed (3 Mbit/s) and the rest capped at 64 kbit/s (only data, no speech, for use with notebooks etc., tethering and VoIP especially allowed, source, English translation).

Here in Germany the providers are regulated by the government but not subsidized. The providers have to pay the government for the permit to use frequencies for the mobile transmissions. For the UMTS frequencies to providers had to pay over 16 billion Euros each for the permit (source in German, English translation).

The regulation has the nice effect that you can easily transfer your phone number from one provider to the other and that costs for roaming have an upper limit. Both helps to keep prices down. These rules are currently unified for the whole EU.

In short: The state doesn't pay the providers but the providers have to pay the state.

Don't forget the fake kernel drivers signed with a stolen certificate. Stealing or breaking the digital certificate used by JMicron to sign Windows kernel drivers should be out of range for even a skilled single hacker.

Oh and apparently there was a second certificate stolen/broken, this time from Realtek.

This thing is really scary. Even when you follow best practice for security in every detail, you would have no protection against something like Stuxnet.

Thanks a lot.

My slashdot "workflow":

1. Read the headline
2. Skip the summary
3. Look for a comment that references the real source of information or has a link to a mirror of the slashdotted article (The article linked in the summary is usually either a summary split on multiple pages with lots of adds or readworthy but slashdotted)
4. Read the fine article
5. Go back to slashdot, read the comments and try to add some value

PS: Sorry for the meta discussion. I still have to read the article for this story.

Sorry, that is not correct. An encryptred file has the entropy of the unencrypted file plus the entropy of the encryption program plus the entropy of the encryption key.

Of course this is the theoretical entropy. In praxis you will not be able to measure it correctly without decrypting the file.

The definition of entropy: Entropy effectively bounds the performance of the strongest lossless (or nearly lossless) compression possible. In this case this theoretical compression would have to break the encryption. But this is a pure implementation detail.

That's not completely true. The stomach digests proteins and to some degree fat. Sugar is processed in the mouth and in the small intestine. And there lies the problem: Your body can control how fast it has to absorb the sugar by regulating the flow from stomach to intestine. And in the intestine it can contol the speed of digestion through the pancreas. But this control only works with disaccharides (table sugar) but not with monosacharides (fructose).

So while the metabolism is the same in theory, in praxis there is a big difference in the timing. It is much easier to flood your organism with fructose than with table sugar. And flooding the organism with sugar will affect the processes running in the organism.

The morale? Don't flood your organism with sugar. Drink pure water. Even the water from your tap will usually be much healthier than any sugar drink. And it is usually cheaper.

You can't win an arms race in cheating using technology. But you can change the problem space.

I think it's not so much about how it was made but how it will be "decomposed". If something can be easily composted, I would call it natural.

Of course how it was made is also important. If something needs an industrial process to be made with lots of unwanted byproducts, I will call it "artificial". When there a natural organism can produce the exactly same substance, I still will call the substance made by man "artificial". This is not because of the substance itself but because of the byproducts produced when it was made.

So in my point of view "artificial" or "natural" is not so much about the substance itself, but about the processes to create and dispose that substance. The wording is not perfect, but I think the concept is clear to most people.

Java is quite popular for enterprises, I think because you can get Java programmers cheapes than C++ programmers. Mainly because Java abstracts away a lot of the hard stuff. Hence more people manage Java and the higher supply of poeple drives down the prices.

Ruby is even easier than Java, but in my opinion it's often too limited (yet). It doesn't have all the enterprise tools and frameworks that Java has. But with a little more time Ruby might catch up.

Scala has access too all the Java goodies but it doesn't come with the supply of cheap, exchangeabel programmers. Having lots of cool concepts from te functional world it is quite hard too manage.

So in theory your point is valid. But Java got a good mix of powerful language and frameworks with being easy enough to master to create a cheap supply of programmers. Technically Java is usually not the best choice. But when you consider the total costs it is hard to find anything cheaper. .NET comes close to Java, but you are limited to Microsoft products for development and hosting. Especially for the hosting part this can get quite expensive.

An expesinve possibilty would be something like building a robot with Lego Mindstorms. If you are on a budget, let them integrate some web services, using Yahoo Pipes. You can even spilt them into different groups. An advanced group can add a custom stream to the pipe using Google App Engine.

By just piping existing components together, they can quickly build an useful web application. With a web application they can cooperate and even show their creation to others. When the application is really useful for them, they will be motivated to tweak it and extend it. Thus they might even be motivated to dive deeper into IT.

I think the hardest part is converting them from computer and internet consumers to producers.