Not really, since the government can (and does) order wiretaps, the google glass now allows the wiretapper to see what the target sees. Wiretapping is strictly for governments (well, and criminals).

So if you pay with cash, you pay the fee twice: Once at the ATM, once in the store. When paying with a debit card, you only pay it at the store.

He's talking about PS2, you're talking about the PS3

Don't forget to wipe out the BIOS, or disable netbooting... Security ain't easy

But the boat still sunk, right ?

Quite true, but what happens when China spends, say, twice as much on R&D ? They will overtake US at some point, if the current trends in both US and China continue.

The one thing that trips me up with python is the link to C++. Cython seems a bit hakish, ctypes requires plain C. Plus, I'd like to be able to move algortihms from high level to low-level once profiling indicates that it's a performance critical part. That's easier if both high- and low-level are the same language. Keeping everything in one language is simple. Once a build-system is set-up, re-compiling+running a C++ program takes about as much time as starting a python script. Both C++ and python applications can be fast or slow to startup, determined by how many dll's/dependencies are loaded. So for a quick test, I'd prefer python, for anything serious I use C++.

I've always wondered about the dynamic typing: How does that hold up in large projects, with dozens of programmers ? For me, the static typing of c/c++ catches a lot of errors/typos in function call arguments.

On the other hand, it's the only mainstream language I know that supports both very low-level and very high-level programming style. This can be a real plus for compute intense signal processing, were a small minority of the code really requires low-level implementations. Being able to mix that with high-level abstractions (e.g. linear algebra factorizations) can give both efficient and maintanable code.

It used to be that stress-testing HD's with random disk access for one day could flush out a lot of bad ones. The ones that did survive tended to last many years. It's a tricky thing with RAID drives. If you happen to have bought a 'bad' batch, chances that more than one will fail before you replace one are pretty high. So testing makes sense sometime. A while ago, google published some research to show that drives do not fail randomly, but in clusters. Making RAID a bit more susceptible to data loss than one might expect.

The square waves part is really wrong. That's how the data is often displayed on a screen, but really not how it is played back. There is a low-pass filter in a D/A converter which guarantees that the output is smooth (and band-limited)

Yes it does make sense. He's talking about dynamic range compression though, not digital compression as in zip-files. The same word for 2 totally different concepts can easily cause confusion

The same holds for these apps. Same difference.

MMm google gives 112km/h, which is a zippy commute... try googling for: 0.000000032 parsecs per leap year in km/h

Well, you could test. wipe the disk, write a known pattern, pull the plug, dump to screen the last byte that is written according to NCQ, re-plug, read.