"like that will collect dust in megaton quantities. And you can't hard-seal the device away to avoid moisture because it'll overheat in short order."

Dust and moisture are being mentioned again and again here. I don't get that. Most dust is generated in places where humans shed skin flakes, rub clothes, and walk over carpets. Where does all that dust come from in a crawlspace? From that tiny amount of airflow? Spores of massive fungal growth? (then you have another problem to deal with first).

As for humidity: a running server will always be slightly higher in temperature than the environment. I don't see how water vapor that has been flowing along lots of cooler surfaces can condense on the server. It would only be a problem if you put the server very close to a ventilation opening, if warm humid air enters from there. Or if condensation is actually dripping from the crawlspace ceiling, onto the server.

"That would reduce the fans work (and their own heat!)"

Years ago, I bought a Shuttle barebones Pentium 4 with a heat pipe, hoping that it would be as quiet as the Mac Minis of the time. It was disappointing. It saved having separate CPU and PSU fans and it was a bit less noisy than the average beige box pc, but still very noticeable.

A problem with heat pipes is that they are not flexible, so the motherboard, case-mounted fan, and heat pipe must match exactly. Not so suitable for do-it-yourself pc building. And in order to reduce noise, you still need to spread the heat over a large surface, i.e. attach a lot of lamellas to the heat pipe, that you could just as well have attached directly onto the cpu cooler.

I don't know about TWRP though, stcok CM does

ClockworkMod (if that's what you mean by "Stock CM" bootloader) on my older Android-2.3 device has an option "Backup", which will write a backup of /data on the removable SD card; I don't even need to connect over adb (but if I try, it doesn't complain). Maybe this has changed with more recent CWM releases, but for me this was a major reason to encrypt /data on all my Android 4.x devices that run CM.

I'm using TWRP because CWM cannot handle an encrypted data partition, so it has nowhere to store the new ROM image on devices without a physical unencrypted SD card. TWRP will happily accept an ADB connection from an unknown device. (Just to make sure: I just revoked all ADB authentications, rebooted into Fastboot (Power+Volume), selected Recovery, and connected over adb.) Anyway, because the device is encrypted with a long passphrase, I don't care that much.

If a watch is watertight for 50 m static water pressure, then it is also watertight for 45 m static water pressure in combination with an enormous amount of dynamic pressure. So that cannot be the reason why usually the depth ratings are translated as "splash proof" (30 m), "you can swim" (50 m), and "you can dive to the bottom of the swimming pool" (100 m).

You also need to take into account peak water pressures; the rating is measured as a static object in water, doing something like diving into a swimming pool subjects the watch to significantly more water pressure

That's a common misconception. The dynamic pressure is additive (not multiplicative) and amounts to about 0.5 rho v^2, where rho=1000 kg/m3 is the densitiy and v the velocity. For example, at v = 10 m/s, the added dynamic pressure is 50 kPa, equivalent to only 5 m extra depth under water.

The rotation speed of a wind turbine is not proportional to wind speed. It typically increases a bit with wind velocity, but not so much. A large turbine with 70 m rotor blades that make one turn per 5 seconds already reaches such tip velocities.

"Also, if a bird is so stupid to get killed by a relatively slow moving wind turbine, I would consider: Darwin at work."

It only appears to be slow if you're watching from a distance. The tip speed can reach 320 km/h (200 mph).

"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.