Amen. I cannot count the number of times my phone has woken me up in the middle of the night just to tell me it is running out of batteries.

There are people who memorize key commands for accessing menu items so thoroughly that they use the keyboard almost exclusively even in gui programs. Also, there ~are programs with a build-in application specific shell; cad programs have a long tradition of this. Gvim is also a good example, illustrating both a built-in shell, as well as menus that make a wide variety of commands easily discoverable for noobs.

Wow, the fragility of an encrypted file system plus the instability of a GPU, implemented in the kernel. Do not even read TFA without doing a full backup of your system.

Cpu is more like 6 cores, with 4 (or soon 8) single precision width vector units. For cuda, it's more like 16 cores, with 32 (or 64 depending on how you're counting) width single precision vector units. Nvidia marketing uses a funny definition of "core"; an cuda SMP is roughly analogous to a cpu core running at a much slower clock, but with a much wider vector unit.

They are targeting 1 Watt mobile applications to start with. For reference, a high-end gpu these days is ballpark 500W.

I think a lot of people are downplaying the historic value of this device as the first stereo camera that the vast majority of consumers (and especially kids) will lay their hands on.

It is cheap,
It fits in your pocket,
It records images to standard media,
it doubles as a glasses-free viewer for the images it takes.

The resolution isn't great, there is a better (but almost twice as expensive) digital stereo camera on the market for stereo enthusiasts, and film stereo photography is as old as the sun, but the kids don't care about any of that. For the most part they will view the 3DS as the birth of home stereo photography.

Just about any application involving computer vision will gobble up as many cores as you throw at it. Think face recognition, product recognition, augmented reality, computational photography, and so on. The list of conceived but not yet commercialized vision-related applications is rather long.

It's because all of the open hardware/software geeks have been naughty this year...

http://xkcd.com/838/

... and superior space heating capacity!

Yes it is compatible in the sense that with some temporal filtering you can probably convert the event-based representation to a difference image representation (and this is probably what I'd do if someone forced me to use this sensor for my work), but then you're stuck with the disadvantages of both representations.

I have seen this demo in person and chatted at length with its creator. It uses a custom sensor chip that does some analog temporal filtering and thresholding of light intensity at each pixel, sending events when the threshold is crossed. The intent of the authors seems to be to mimic the human visual system in silicon, even if it makes no engineering sense whatsoever. The demo was extremely sensitive to fluorescent lighting; the author had to run out and buy an incandescent desk lamp to get it to work at all. The event-based image representation makes it incompatible with everything that has been learned in computer vision over the last decade.

Are you a programmer? Intelligently choosing the layout of your data is a significant part of writing high performance code. It is not some exotic hack. It is supported in all of the languages one uses for writing high performance code (C, C++, Fortran, CUDA, OpenCL, etc.).

None of those languages have a ~standard strided array type, and library writers have produced a huge mess of incompatible matrix types as a result. Golang is headed down the same path.

Here's another example... They currently have an image reading library that has its own image type.

It doesn't support slicing out a sub-array to get a sub-image, i.e. im[10:20, 10:20, :]. It doesn't support slicing out the channel you want, i.e. im[:,:,0] for Red channel. It doesn't support even basic math operations, i.e. adding together two images. All of this is stuff that should get implemented in a very general, standardized way. The same will go for multi-channel audio data. If someone core to the project doesn't act quickly, it will be increasingly difficult to even achieve uniformity within the Go standard library.