"50m or 100m, which are adequate for any practical purpose. Above that you're paying for fantasy value. Watches rated at 200m and above might as well claim a gazillion meters; you'll never be the wiser."

I thought that these ratings have more to do with the reliability/longevity. At least, I've owned two 300 euro "100m" Seiko watches that lost their water-tightness over the course of a few years, because the seals of the crown degraded from exposure to sweat, soap, and the occasional sea water. Repairs were quoted as 150 euros, so I didn't bother.

Now I have a a Pebble.

With a rainbow table you can brute-force a password if you know the password hash. You need only one login attempt -- and you need the hash, for which you normally need root access to start with, at least for the last 20 years. Unix/Linux passwords have always been stored as salted hashes, which makes rainbow tables not practical. The practical way to brute-force a password is therefore a dictionary attack.

Of the equal options, I see 7 3 5 9 9 6 (in %). The last and first ones are not the highest values. The peak is just before the end. With your desctiption I'd expect 9 3 6 7 5 9: highest on the outer options and a minor peak half-way.

"he first and last results in a poll will get the most votes, with a curve between them and a small spike in the middle"

Years ago, slashdot had a poll like that. It didn't look like that at all.

http://m.slashdot.org/poll/119...

If we ever do invent time travel, I figure it's going to be routine for people to show up from the future for important historical events and discover they're an hour off.

And image that you have the right location, and you discover upon arrival that you missed Planet Earth some 100,000 km in its orbit around the sun and you see it around the size of a fist at an arm's length as you suffocate...

Locking the bootloader only prevents replacing the bootloader. For both the TWRP and the ClockworkMod boot loaders: locking does not prevent going into the bootloader (on devices that let you do this by pressing the volume button on power on, such as the Nexus 5 and Nexus 7 (2012)) and making a backup of the data partition, e.g. onto an SD card. Moreover, ClockworkMod cannot handle encrypted data partitions, which seems to make it impossible to do upgrades on a device without SD card. TWRP does support encryption, but it does not do adb authentication.

I don't see your point about killing recovery options. With an encrypted device, it's still possible to do a factory reset. With an encrypted device + TWRP, you can even make a backup of the data partition. (My N7-2012 with stock Android corrupted the encrypted data partition on upgrade to Lollipop; only way out was a factory reset. Grrr. I flashed CyanogenMod+TWRP+encryted data, but the bug in the flash memory controller hit me and made the whole tablet unbearably slow. Grrrr!)

if it happens on every mail sync, podcast download

In that case, the bottleneck is the data transfer over Wifi or 3G. At least, I'm pretty sure that I never reach 27 MiB/s (270 Mbit/s) data transfer rates. The wake time will not be affected in such cases. I think it's only activities such as app startup and media indexing that are affected by slow storage bandwidth.

And otherwise, encryption is really a must for me. With a custom ROM and bootloader (and no encryption), it's too easy for someone else to extract all personal data from the device, including credentials for my Gmail account and my banking app, both of which can have actual financial consequences.

Whether in hardware or software, it's still a fair amount of computation, which means battery usage and latency.

I wouldn't be so sure about that. Android will only encrypt the /data partition, not /system. That's why you can still do a factory reset on an encrypted device. I'd guess that a lot of the I/O is in /system.

Anyway, here is a 100 MiB write test (Nexus 5, Cyanogenmod 11, Android 4.4, rooted), to the /data ("sdcard") partition and to /cache (not encrypted):

sync; sync
time sh -c 'dd if=/dev/zero of=/sdcard/foo.bin bs=1048576 count=100; sync; sync'
3.67 seconds
sync; sync
time sh -c 'dd if=/dev/zero of=/cache/foo.bin bs=1048576 count=100; sync; sync'
2.13 seconds

At 27 MiB/s versus 47 MiB/s it seems to be fast enough for me. Most apps are below 15 MB (apk size).

On a low-end, but fairly recent, LG L40/D165 phone, it's 11.2 seconds for a 100 MB encrypted write. (No root here, so I can't write to /cache for comparison). Still fast enough for me.

"Our average ting bill is So with proper management"

Looks like slashcode ate the less-than sign and the rest of the paragraph...

But with your point about the coating, I'm only off by a factor of ten...

1000 times smaller beam diameter means 10^6 times higher irradiance. With 1% absorbance it's still a factor 10^4 off.

how much power do we really need on target to make it overheat given that it's designed to cycle between daylight and night

The solar panels are designed to receive 1500 W/m2 irradiance from the sun, of which maybe 500 W/m2 comes out as electricity and the other 1 kW/m2 is heat load. A black-body radiator against 4 K background temperature on one side and earth (279 K) on the other side will reach an equilibrium temperature of 330 K (57 C). To heat the solar panel to a damaging 150 C (just a guess), you'd need about 2.5 kW/m2 extra (on top of the solar irradiance).

It wouldn't surprise me if the back side of the solar panels is used as a radiative heat exchanger to get rid of the heat generated inside the body of the satellite. The gold-coated foil around the satellite body acts as a kind of thermos bottle to insulate the electronics inside from extreme temperature swings, but still the electronics need to get rid of its own dissipation, so you would not only destroy the solar panels but indirectly also the electronics.

I doubt that it's practical to aim specifically for the solar panels for an object that's travelling at 7 km/s, with a mechanism that can do that within 1 microrad. It might be more practical to have a 10 m diameter spot size, which would require 250 kW, which might be doable with a CO2 laser at 10.6 micrometer wavelength (the atmosphere seems to be fairly transparent at that wavelength).

If the solar panels have a mass of 15 kg/m2 (just a guess), then you would need to maintain this 2.5 kW/m2 for about 10 minutes, over which time the satellite will be travelling 4200 km. This doesn't sound easy...

"A 1um laser fired out of a 1m aperture spreads to an 800m circle at an altitude of 800km"

You're off by a factor 1000. The divergence is about 1e-6 rad, which makes 0.8 m diameter at 800 km.

Now another issue is that satellites tend to be wrapped in gold-coated foil, which will reflect 99% of the light at 1 micrometer. It would be difficult to overheat the body of the satellite, although the solar panels might be damaged more easily.

Having a conflict of interest is understandable; hiding a conflict of interest is problematic.

The strange thing is that his management (Alcock and Kress) is claiming that they were unaware of his funding. The research grants pass through the accounting department of the institute, right? Large sums of money deposited onto or withdrawn from the institute's bank account need to have proper paperwork in place and be signed off by the management? His management must have been actively looking the other way.

It has been possible for decades to recover serial numbers by chemical etching, which is sensitive to changes in the crystal structure. All you need is a polishing implement and a bottle of etching gel. What is the added value of this EBSD technique? I can see a big disadvantage: you need equipment (a scanning electron microscope) worth a few hundred kEUR and the object with the erased serial number needs to fit into the vacuum chamber of said equipment.

The article mentions that etching techniques don't always work, but they don't state that their technique does work on samples for which the etching method doesn't work...