Meanwhile, I've been running the same Gentoo install for ~9 years now (having migrated through 5 different machines). Rolling upgrades are awesome.

(It would be >10 years, but I did have to reinstall early on to migrate from x86 to x86-64).

The MHz number on the box is the bandwidth, not the sample rate. The sample rate is measured in samples per second (GSps). A 100MHz scope is probably adequate for analog signals up to 100MHz. However, if you're debugging a digital signal, you want a scope that has 3x the bandwidth of your signal's base frequency or more, because square waves are composed of the base frequency and an infinite number of harmonics. If you only have bandwidth for the base frequency, your square wave will be distorted into a sine wave and you won't be able to accurately see ringing, glitching, and other artifacts.

I have a 1GSps, 100MHz scope. I wouldn't use it for serious digital signal debugging above 30MHz (which is 33x lower than the sample rate), due to the bandwidth constraint. It's adequate for seeing if stuff up to 100-150MHz is "there" though (and for reading the bits out if you just want to use it as a poor man's logic analyzer), just don't expect to diagnose signal integrity and timing issues at those speeds.

Low-speed 1.8V and high-speed 0.5V LVDS mode, 800MHz... a MIPI-DSI display? :-)

Or one of these (it also passes through USB 3.0, which is nice):
http://www.amazon.com/Centech-USB-Power-Meter/dp/B00DAR4ITE

This isn't new.

You can correct for chromatic aberration in software, to a varying degree. You can approximate it (so the aberration is ~1/3 of what it would normally be, by aligning the centers of the primary colors) for arbitrary inputs, e.g. a photograph captured with an imperfect lens (image editing software can do this). You can do it on the output side with perfect accuracy if you're displaying an image using three monochromatic light sources (e.g. a laser display), since the three wavelengths involved would then be distorted by three discrete amounts that are perfectly correctable. For RGB panels like LCDs and OLED displays the primaries aren't monochromatic, but they are more concentrated around the dominant wavelength than a natural light source with a uniform frequency distribution, so you get a result that's somewhere in between. This is what the Rift does to correct for chromatic aberration in software.

Uneven pixel density is only a problem if the pixel density at the sparsest point is too low. Today's displays already exceed visual acuity when viewed at a reasonable distance (e.g. a Nexus 10 or an iPad with a Retina display at a normal operation distance), though of course that is without covering a large fraction of the FOV. Give it a few more years and it'll only get better - once we have 8K phone-sized displays this will probably be a non-issue.

Obviously you were concerned enough to measure if there was any imminent danger

I wasn't concerned. I'm just a curious geek who happens to own a logging Geiger counter.

The issues is not radiation emitted, it's the radionuclides emitting them.

That is true. Ingesting radionuclides is definitely a much bigger problem than external exposure.

That's great but it's more likely that Japan now has very high concentration of radionuclides in very specific places in the ocean or land or sea, some of that area will be producing food. The likelihood of encountering in the food chain is now higher than the initial accident because the radionuclides have propagated further up the foodchain so if you ate food in Japan the likelihood of ingesting it has increased. The longer you stay there the more you will increase your chances of a permanent dose in your body, the more times you get one of those means the probability of some sort of cancer increases. A big problem for the locals, but not really a worry for you.

It's hard to get real data about these issues, as there is a ridiculous amount of fearmongering in the media. For example, there are plenty of articles talking about the spread of radiation in the Pacific Ocean from Fukushima to other countries, but a simple dilution argument shows that any claim of danger from that effect is nonsense - the ocean is ridiculously bigger than the quantity of radioactive water released, and even if you can measure the effect, it's going to be negligible in practice.

Locally produced food is another issue, and yes, the possibility for concerning contamination exists. Supposedly, food is tested in Japan, and the limits are stricter than in the US. Converting that into the probability that you will eat something that exceeds the limit (and by how much) is tricky. If you know of any serious studies attempting to calculate this, please do let me know.

FWIW, I do plan on moving to Japan in the not too distant future.

Interesting. I didn't stop at Fukushima station, but I went past it on the Shinkansen with my Onyx in the outer pocket of my backpack (obviously it won't be picking up any alpha radiation there, but still useful data). Looking closely at the logs it is possible that one spike correlates with roughly the time I'd have been in that area, though I really would have to check the times closely. The Onyx was set to log every 10 minutes so it's also possible that it just missed the interesting times. The peak readings were about 0.2uSv/h, and that wasn't near Fukushima. Tokyo averaged somewhere around 0.11 uSv/h, while Hakodate (where I stayed a couple of days) was around 0.07uSv/h.

Interestingly, my return flight hit 3.0uSv/h, higher than the first flight (I just dumped the last chunk of the log which I hadn't done yet).

These readings seem to be using the default calibration of the Onyx. I haven't delved into the details yet (the firmware is still WIP as far as I can tell), but AIUI they are supposed to come calibrated, so either the default calibration is spot on, or the firmware isn't using the calibration data, or my firmware upgrade wiped the calibration data, or the calibration data was never there. Either way, I assume the default conversion factor is good enough for rough measurements of background radiation.

Somewhat amusingly, he typoed the one relevant box in there - "Extra dose to Tokyo in weeks following Fukushima accident" should probably be 40uSv (not 40mSv) if he means per person (and even then it sounds a bit high), or be in the orange chart if he means the total dose delivered to all of Tokyo.

Using my Safecast Onyx (hi Safecast folks!) I measure ~0.32 uSv/h in Dublin, next to a granite wall (granite is everywhere around here, and naturally radioactive). The article speaks of of 0.484 uSv/h, not much higher than that. On an airplane at cruising altitude I get about 2.0uSv/h. At home I might see 0.08uSv/h, and in the middle of the street somewhere around 0.15uSv/h. *

I just visited japan and took the Safecast everywhere I went. At no point did it go significantly above what were normal background radiation readings in Dublin (not even when I was passing by Fukushima station, though admittedly that was on a high-speed train).

Radiation is everywhere. Unless you can identify the source as the Fukushima disaster, it might be perfectly normal. Even if the source is Fukushima, at low levels, at some point you have to stop worrying about it and realize that plenty of other places on Earth have higher naturally occurring background radiation.

* Rough numbers pulled from memory in CPM and converted to uSv/h using the conversion factor in the firmware source code, since my Onyx battery is dead at the moment. Take with a grain of salt.

I started doing this after getting a dozen Vodafone marketing calls. Except instead of just leaving the phone off-hook, I said "please hold while I transfer you" and then treated them to an endless random shuffle of Never Gonna Give you Up, Friday, Trololo, Caramelldansen, and Nyan Cat, played via a voice modem.

They stopped calling after they got that a couple of times.

EVE doesn't use IronPython. It uses Stackless Python. And yes, it is possible to decompile the code, and it has been done in the past.

http://evesupernerf.blogspot.co.uk/2012/05/decompiling-eve-client.html
https://github.com/wibiti/evedec/blob/master/evedec.py

Mod parent up. The 40% figure is bullshit claimed by a single stats agency.

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.