Google uses ephemeral Diffie-Hellman key exchange for its SSL implementation, as long as the client is modern enough (i.e. everything except IE on Windows XP). That provides forward secrecy. Even if the NSA had the private keys, they wouldn't be able to snoop on anyone's traffic by passively sniffing - they'd have to mount an active MITM attack, and that is much harder to do, and even harder to do undetectably.

Yup.

There's two problems with the current crop of 3D printers. First, the printers are fiddly. It is possible to print out decent objects on a good printer (personally, I'm a fan of the Ultimaker). However, it requires tuning the printer and the software and maintaining them. It's a solution for tinkerers, not for Joe Average. Companies like MakerBot are deluding themselves when they think they've got a RepRap-class printer they can sell already assembled "for the masses". They still need too much maintenance.

Second, you can't just print anything and expect it to look good. If your object doesn't require support material (overhangs are all under a reasonable angle), and the slices don't contain more than one connected surface, then it will look beautiful on a decent printer. If you need support material though, then you have to deal with removing it, which is nontrivial. If you have more than one surface per slice, then you have to deal with stringing. That's not too bad if the surfaces are far apart (you can remove it easily), but it's difficult if they are close together. These are the limitations of plastic extrusion printers today, and you need to design models taking them into account.

On decent prints: http://www.flickr.com/photos/marcan42/8542507791/in/photostream/ . That's a gear, about 8cm across. You have to get up really close to be able to see those layers with the naked eye (they're 0.1mm tall). The roughness on the top and bottom surfaces is probably on the order of 50 microns. It is possible to go smaller on this printer.
On fiddling: http://www.flickr.com/photos/marcan42/8543920590/in/photostream/ . Left print is before tensioning belts, right print after. Of course, one of the cool aspects is that I was able to print the belt tensioners on the printer itself.

I'm very happy with my printer, but I would never recommend it to someone who isn't already a hardware hacker.

I've written DRM that is good for the "customer" (user). It's a bit bizarre, though. More like reverse DRM. It's purpose is to ensure that the software isn't "pirated" and sold for money, instead of downloaded for free, as it should be.

I'm one of the authors of BootMii and The Homebrew Channel for the Nintendo Wii. It's a free (as in beer) piece of software that you can use to run untrusted code on your console (what people like to call jailbreaking these days). Before it had any kind of security, we found out that scammers were selling it (in violation of our license) along with "piracy packs". We added a big "scam warning" to the installer to clue users into the fact that the software is free, and if they have paid for it they have been scammed. However, the scammers started telling users to use the same tools used to pirate WiiWare games to install The Homebrew Channel itself - this bypasses our installer and the scam warning. So we added DRM that ties each install to a given console (if you try to copy it, it still works, but then you get the scam warning every time you try to use the software instead, until you reinstall it using the proper installer). There's enough obfuscation to stop the (generally clueless) scammers from working around it.

I'm nominally very anti-DRM, but I've thought long and hard about this and I really can't see a significant downside for users. It doesn't affect normal users in the slightest, as far as I can tell. It doesn't actually prevent anything from working (sometimes, you can damage system firmware such that The Homebrew Channel is one of the few or the only option left to repair it, and you can't run the installer - we never want the DRM to accidentally close off a user's last hope for their console, so it's designed to be extremely annoying if the check fails, but not actually stop working). Of course, it doesn't prevent you from installing it on as many consoles as you want - just use the installer (which is a great idea for many other reasons anyway - it's so paranoid about system checks and safety that it has never bricked a single console in millions of installs) and you're fine.

As far as I can tell, this only adds support for using the nvidia card for everything (rendering the whole desktop) while sending its final framebuffer to the Intel for scanout. This is a strictly different use case from what bumblebee enables (rendering *specific apps* on the nvidia card while using the Intel for everything else).

Personally, since I only need the performance of the nvidia card one in a blue moon, the bumblebee approach is much more useful to me. Otherwise, I'd have to deal with tearing on everything (the current version of the nvidia RandR output provider does not support vsync) and increased power consumption.

I think what nvidia calls "render offload" in their README (which is currently not supported) is what would in fact replace bumblebee, if/when implemented. I'm curious as to how it would interact with power management, though. One of the very nice things about Bumblebee is that it doesn't even power up the nvidia card (via ACPI) until required, and that's easy because it starts up a background X server on demand to do the rendering. It's probably trickier to puil this off if you have to load the nvidia driver into your primary X server to take advantage of the direct integration.

The active noise cancellation indeed only works for low frequencies, but noise-cancelling headphones muffle higher frequency noise by design too. I find them quite acceptable in very noisy environments, and I suspect they will work well anywhere where there's a wall between you and the noisy human anyway. If you must, feed them white noise to drown out what remains.

Clicking a link to a page containing a textbox containing File:/// will. So this is also a remote DoS for Safari.

First of all, you mention the TCP/IP checkum, at the same time as key exchanges, long PSKs, and money transfer. Which is it, simple message integrity or message authentication? If you need authentication, you shouldn't even be mentioning TCP/IP checksums. If all you need is integrity, then just append an MD5.

Assuming you need authentication: I don't have any opinion on Blake2, but you should use an HMAC instead of just appending the shared secret key and taking the hash. HMAC can be built on top of any hash function, including Blake2. You should also make your MACs at leasts 128 bits long, preferably 192 or 256. 64 bits is definitely bruteforceable these days. I wouldn't settle for anything shorter than 256 for a protocol that involves money.

Keep in mind that a basic message authentication code is only one piece of a secure protocol. There are many possible attacks that might slip through (e.g. replay attacks, MITM, timing attacks, ...). For example, you need to ensure that an attacker can neither reinject a message from the current session back into it (e.g. by using a sequence number in the signed payload) nor reinject a message from a different session (e.g. by ensuring that there is a random component to the shared secret) nor somehow guess the right MAC code (e.g. by making sure that the wrong-MAC responses do not leak any information, neither in contents nor timing), and of course there's always the host identification problem (preventing a simple MITM where the attacker performs a key exchange with both sides and resigns/reencrypts traffic both ways). Honestly, your first choice should be to use an existing well-tested protocol, such as TLS (you can build your own host verification rules on top of it, you don't have to use the "well-known" root CA list). Failing that, consult a real crypto expert.

For password hashing, that is correct. However, cryptographic hash functions are not designed for such use (and yes, all the websites and services out there using plain hashes for passwords are Doing It Wrong, even if they are using a salt). You can build a good password hashing scheme out of a cryptographic hash function (for example, PBKDF2), but plain hash functions are not suitable (precisely because they are too fast).

Fast cryptographically secure hash functions are a Good Thing, so you can hash a given block of data (and thus compute its digest and e.g. verify its digital signature) as fast as possible. This speeds up things like GPG, SSL, Git*, good old sha1sum checksums, etc. If you then want to use such a hash function as the core of a password hashing scheme, you can compensate for the extra speed by simply increasing the number of iterations. Making a hash function slower is always easy.

*Git is pretty much stuck with SHA-1 for now, but future incompatible versions of the repo format could conceivably switch to a faster hash function if it made sense.

Wrong. You shouldn't be using port 25 to submit mail to the SMTP server of your e-mail provider these days. You should be using port 587 (mail submission). Works just fine with smtp.gmail.com.

Which means the Optimus solution isn't actually all that bad. I have the opposite viewpoint: I bought an Optimus laptop assuming the nvidia wouldn't work, simply for the other specs and the Intel video. When it turned out that bumblebee worked fairly painlessly and I was able to use the nvidia to accelerate 3D while the Intel drove my displays, I was pleasantly surprised. The solution is a bit of a hack, but honestly, I don't really have anything bad to say about it. It's the best of both worlds: open Intel drivers which are stable and support modern interfaces like XRandR 1.3 and KMS driving the displays, and the clunky proprietary but fast nvidia driver sandboxed in its own backgrond X server doing 3D acceleration only.

It is true that the law grants the copyright owner the right to restrict the creation of copies, but It can be reasonably argued that by posting the code on GitHub you've implicitly given consent to the mere creation of a copy (as would automatically happen if you view the code or download it). For most practical purposes, the limitation on distribution is what matters.

You can take any code which you find and put it into your project, or even combine bits of code with incompatible licenses. What you can't do is distribute the result. Distribution is where copyright law kicks in.

Ah, one of those stupid Windows-only features. Sigh.

There seems to be a reverse-engineered driver for Linux but support is sketchy for the X220. I guess I'll try it and see.

How did you measure the power usage? If you used a cheap power meter that does not have accurate power factor measurement, then your measurements are completely useless. Idle switching power supplies have very low power usage, but a very low power factor, because they act as capacitive loads. This means that a naive current meter will measure all of that out-of-phase current and you'll end up with a grossly inflated power figure. A proper power meter measures both instantaneous voltage and current many times during each AC power cycle, and can therefore report both real power and apparent power. If you measure an idle switching wall wart with such a meter, you will see a low W (real power) figure and a high VA (apparent power) figure. Residential customers are usually charged for real power only.