If this is actually the only thing keeping them back, a good solution is to just watermark the downloads with the purchaser's name/email/account name. Do it in an obvious manner (like a comment field) in addition to a hidden watermark that at least requires some work to remove.

This won't stop the pirates, of course - I don't know of any watermarking scheme that is resistant to a coalition of people with different watermarks - but it will require another step of comparable difficulty to ripping the DVD if you don't want to share the watermarked version.

Once that's done, they just have to send threatening letters to (or cancel the accounts of) people who uploaded in order to force people to put in the effort to remove the watermarks. Maybe they'll get a few convictions of the people too stupid to remove the watermarks prior to uploading to p2p, but those people (should) understand the risks involved with uploading.

I know I would jump at getting unencumbered versions of various movies, they're a lot easier to use than DVDs or DRM'd downloads.

Depends on what the DRM is trying to protect. Music players, video players for downloadable content, and basically anything where the content isn't tied to a physical object like a game disc will need a private key of some kind to encrypt the data on their volatile storage. While most of this will probably be done using symmetric encryption, you still need some way for the server that hands out the content to prove that it is a real device and not an emulated device, and that's normally done with a locally stored private key.

This attack is relevant when you are trying to extract the private key of something like a TPM, in order to defeat the DRM protections it is trying to provide, or decrypt the drive whose key it is holding.

The cookie is not to identify you (what do you think your username is for?) but to identify the browser/computer that you are using. Obviously, since you're signing in to an account, the privacy issues of storing a cookie are rather irrelevant.

At least on all the systems like this that I have used, the username and password are still required; the cookie just bypasses that additional email/question/whatever. That means that stealing the cookie doesn't get you anywhere useful, as compared to not having the system at all. Requiring this cookie does make some attacks harder (for example, phishing attacks that impersonate/proxy the real site), so it's not a useless measure or just to irritate you.

Look into the CookieCuller extension for firefox; it will let you keep the cookie for your bank's site while still deleting all other cookies on exit.

You can turn off overcommit in Linux if want to - most people find the default behavior more useful since many applications allocate memory they do not need to use, and don't handle out of memory errors gracefully. Change the sysctl "vm.overcommit_memory" to 2, and see "Documentation/vm/overcommit-accounting" in the linux kernel source for related sysctls.

There are occasions where you might want to use a lot of swap, if there are one-time-run applications that use a ton of RAM to do something like image manipulation/scientific computing/whatever. Those might be rare, but it would be very irritating to get out-of-memory errors just because the kernel doesn't feel like using swap.

When the OOM killer is invoked, the application isn't usually allocating memory - it's using memory that it has allocated before and that the kernel overcommitted on. So there's no good way to send an out-of-memory error other than by something like a signal handler. I think the reason this isn't done is because the signal handler would likely need to allocate RAM to run (maybe to get its code paged off disk) and this wouldn't help with the memory pressure.