You are looking at posts that were written in the month of September in the year 2006.
Posted on September 30th, 2006 by Tim.
Categories: Programming, Tim.
Truly, this function name could only exist in the Win32 API. Apparently the documentation for this function is inaccurate. According to this sample by Raymond Chen, you can call MsgWaitForMultipleObjectsEx with an empty list of handles. Presumably, the object that the function is waiting on becomes the current thread (considering how he is using the function), but there is nothing to indicate this in the MSDN documentation.
The reason I need this function is because I’m fixing an application that doesn’t implement a proper message loop. Too many programs decide to use PeekMessage instead of GetMessage so that they can continue to process messages while using 100% CPU. The problem is that this totally borks the power management. This means that on laptops, the fans will be constantly going. It also borks the thread scheduler (so that background threads get starved) and the working set (polling will keep at least several pages of memory resident even when completely unneeded).
So, for our sakes, please do not use PeekMessage unless you really need to. Remember, polling is evil.
Posted on September 30th, 2006 by Chris.
Categories: Chris, General/Misc., Liu's Reviews.
No need to make a big kerfuffle.
But yes, I ate my iPod shuffle.
Posted on September 25th, 2006 by Tim.
Categories: Games, Tim.
I just downloaded nethack again and came to the startling realization that nethack was meant to be played widescreen. You think I’m joking, don’t you? Well it’s true. If you’re playing in windowed character-mode (as opposed to playing it with those sissy sprites), you’ll notice that the screen is much wider than it is high. Which is perfect, because I’m currently on my Dell 24″ widescreen monitor. This thing was made for nethack!
In other news, my GPA just went inthe corner and shot itself.
-Tim
Posted on September 19th, 2006 by Tim.
Categories: General/Misc..
There’s a fundamental problem with DRM. DRM is just a sleek marketing word for “Obfuscation”. In order to understand why this is the case, you need to have a basic understanding of cryptosystems.
A “cryptosystem” is any system designed to ensure secrecy of a piece of data. In security jargon, the data to be encrypted is called the “plaintext” (not the same thing as “plain text”, but similar). To encrypt and decrypt a plaintext, we use an “encryption function” and a “decryption function”. An encryption function takes a plaintext and a “key” and returns the encrypted text, which is known as “ciphertext.” The decryption function takes the ciphertext and the key, and returns the plaintext. In some systems, the decryption and encryption functions are the same, or the encryption and decryption keys are different, but every cryptographic system follows this general pattern.
So what does this have to do with DRM? Digital Rights Management is a term for any system that allows a user to encrypt data, and place restrictions on that data. The most familiar DRM is used to protect against the unauthorized distribution audio files. However, there are other uses for DRM, such as for email, where one can place restrictions on whether an email may be forwarded, or whether the text of an email can be copied and pasted. A DRM protected piece of data includes: a ciphertext, a key, and a set of rules about how the data may be used. Do you see the problem yet?
If DRM gives us the ciphertext and key, what prevents us from decrypting it and not obeying the rules? The problem is that we still lack the third element, the decryption function. This function exists in, say, Windows Media Player, but media player is trusted to follow the rules of the DRM, and only decrypt the data when it is allowed. The only reason that DRM works at all is because the decryption method is kept a secret. In security, there’s another name for a “secret” crypto algorithm. Security professionals call it “security by obfuscation”. There’s a saying among security and open source advocates: “Obscurity is not security”.
So on the one hand we have DRM, which revolves around secrecy and obfuscation, and on the other hand, we have open source software, which revolves around open standards and fredom of information. Obviously, these two concepts are completely incompatible. One cannot simultaneously have a truly open source software that simultaneously implements DRM. If DRM software was open source, it would be very easy to change the code so that the data was simply decrypted and left in an unencrypted state.
So it comes as no surprise that FOSS advocates are so vocally opposed to DRM. If DRM wins, Open Source loses. Unfortunately, it’s really that simple. The justification for opposing DRM on music files rests on some very sound argument. However, DRM has been portrayed as a morally wrong concept, despite the fact that it can be used for very positive purposes. One such purpose is using DRM with e-mail, which can be used to prevent private customer data from accidentally getting forwarded outside a company domain for instance.
I think open source advocates realize how incompatible the ideas of DRM are with open source software. They choose to oppose it by lumping it together with their opposition of the evil RIAA and MPAA. By associating DRM with RIAA, open source advocates have successfully given DRM a bad name.
