Not having read the article or not knowing anything about how an event is detected... It rather sounds if CPUs are not the best tool for the job. FPGAs should be able to run data acquisition and filtering in real time, doing most of the heavy lifting. A single FPGA (rather large FPGA like the Virtex range from Xilinx) can do thousands of multiply accumulates in parallel. GPUs like the Tesla or similar may also be a better fit.

The cynic in me thinks the NSA/GCHQ will use this as an oppurtunity to engineer more 0-day malware for their own use. Much easier if you can have eyes on the code...

The general term is GNSS - Global Navigation Satellite System.

Typically the different systems of GPS, GLONASS, Galileo, Beidou, etc. is referred to as GNSS (global navigation satellite systems).

If you use a cloud service, use a layer of encryption that is under your control, e.g. truecrypt with dropbox. Problem is that is usually breaks the service. A possible alternative is to build your own cloud with OwnCloud. Note though that nothing as good as Evernote is yet available as a private server.

Oh, forgot to mention that C is really the only language if you are doing truly embedded (running on the metal) work. Other languages are fine when you have an operating system running, but C (and usually in some form or another assembler to get things started) is the most prevalent embedded language out there.

My whole problem with the whole Arduino universe is the price. You essentially pay an extremely large markup for the libraries and community. There are other much cheaper developer platforms out there, e.g. TI's MSP430 launchpad (essentally a $4 development board with a built-in emulator) and the corresponding community ww.43oh.com, but you are much closer to the hardware. So the learning curve is steeper, but you probably going to learn much more. Another option is the Discovery platform by ST, a very capable ARM platform. The platform you choose will be determined by what you want to do, i.e. turning LEDs on and off you will go for a simple microcontroller e.g. the MSP430; building an IMU for a quadrocopter you will probably need to go for an ARM-like device.

?ew era, tfel ot thgir gnidaeR

Sorry that is 8-15 um.

Nope, the kinect uses near infrared (somewhere between 900 and 1400nm). So no body heat detection (that requires sensitivity to 8–15 m) and is fairly expensive, os I doubt it will be in a consumer product. In theory a photo made with near infrared paints should be able to fool the unit, depending whether or not it uses motion detection combined with a human movement model to actually detect a human.

I'm guessing the invocation of Godwin's law is inevitable for this article...

You're missing the point - this is to cover areas with broadband access that previously did not have access (or had really slow access because they are located so far from an exchange). This won't give you coverage in your garden (that is what WiFi is for), it is more to get a bigger internet pipe to your house so that you can get some decent speeds.

The local population probably wants to live next to a coal power plant even less. Power stations need to be built somewhere and people usually argues the NIMBY (not in my back yard) principle even though they want what the power station provides. Would you rather prefer developing countries build coal power stations? Because renewables are probably more than an order of magitude off from actually providing the type of power that a nuclear power station provides (GW vs tens of MW) and are typically unable to provide base load. I bet though, that if you poll the larger engeering populace that at least 80% of them will think that nuclear is our ONLY answer right now.

Actually, the spectrum was never intended for terrestrial use at all. Lightsquared applied for an exemption to apply the spectrum for terrestrial use, but they had to prove that it did not intefere with GPS. Most RF engineers would have told you that they where doomed from the start to fail, as the physics does not allow you to do this. All RF equipment have to contend with a thing call adjacent channel rejection - i.e. whilst tuned to its own channel a device must reject inteference from channels adjacent to its own by using a bandpass filter. Bandpass filters are not perfect (i.e. it is not a brickwall) and some interference always leaks through. The specific issue here is that the terrestrial signal would have been so large compared to the signal received from the GPS sattelite that the bandpass filters would have been unable to suppress the signal in the adjacent channel. This is akin to someone shouting in your ear, while you are trying to listing to someone whispering 20meters away.

So long as an API sticks to Init(), Get/Set/Execute/Calculate() and Deinit() it doesn't really matter, people will learn it sooner or later. What *does* matter, however, is that an API does not break "unwritten" conventions like always returning true even when the operation was unsuccessful (yes, I am looking at you Microsoft for that awful Windows Media Player COM interface - that was just evil!)