This Sheerwind Invelox sets off my BS meter as well. The Venturi effect (a special case of the Bernoulli principle) won't magically let you harvest more energy then what was already in the airflow. In a Venturi device, flow velocity increases temporarily in exchange for a pressure drop (to less than atmospheric pressuee). Downstream, the velocity lowers and the kinetic energy exchanged back into pressure, reaching atmospheric pressure. If you were able to harvest the kinetic energy, you would end up with a slow gas velocity and still subatmospheric pressure, which wouldn't be able to flow back into the atmosphere.
This is also worth reading: http://www.gizmag.com/dodgy-wi...
"Folks walk out into traffic staring at the samsung. Go 10 blocks in Manhattan, you will get at least a dozen of these folks. No spatial awareness at all."
If you're on foot, you can usually have pretty good spatial awareness of cars from your ears. Doesn't work well for bicycles and e-cars at low speed, though.
When I'm cycling abroad (I'm from Netherlands) on the countryside, it's weird how some car drivers seem to think that it's necessary to announce themselves by honking the horn even though I could already identify them as truck, passenger car, or agricultural vehicle before they were aware of me.
"The study compared Neonicotinoids laced pollen to sugar water."
What are you talking about??
From the actual paper in Nature: "bees of both species prefer to eat more of sucrose solutions laced with IMD or TMX than sucrose alone."
Telecom is hugely profitable, mobile telecom even more so.
Could you provide some data to support that statement? Not that I think the roaming charges are reasonable (since they are completely disconnected from actual costs for the operators), but that would just mean that domestic charges should go up and international/roaming rates should go down.
Look for example at the Vodafone annual report (big PDF), income statement on page 96. On 38 bn UK pounds annual revenue, the made 5 bn loss (before taxes, not including the profitable sale of their stake in Verizon).
Or the T-mobile US numbers on 2014 (full year). Page 6: US$ 14 bn revenue; net income US$ 0.25 bn. That does not look like a hugely profitable business to me. Or the balance sheet on page 5: US$ 57 bn assets, and only US$ 16 bn of stockholder's equity; a ratio of 3.6:1, which I'd consider pretty large for a company that is not making a large profit and that has to deal with rapidly depreciating infrastructure.
Here's Verizon 2014 full year: US$ 127 bn revenue, US$ 12 bn net income. That looks more healthy. But look at the balance sheet: US$ 232 bn assets, and just US$ 14bn in equity (16:1 ratio). I would be very hesitant to invest in a company with such a balance sheet. To my surprise, the stock market thinks differently with a P/E of 21.
I'm not a finance expert, so if I misinterpret the numbers, please correct me.
example is the AES-NI instructions, which exist on essentially all modern desktop and laptop CPUs, and many of the newest mobile CPUs as well.
What's the difference between "mobile CPU" and "laptop CPU"? In any case, most 4th generation i3 mobile/laptop CPUs don't support AES-NI, nor do the current Intel Celeron CPUs. Many of those have been released as recently as 2014, so I would count them as "modern".
You can build a sophisticated cypher that does not require polynomials, massive primes or any of the stuff that RSA uses
That stuff is for secure key exchange over an untrusted channel. The actual ciphers that are used to process the bulk of the data is not much more complicated than what you describe. You can look up the algorithms for RC4, AES, and blowfish.
Create a two dimensional array each dimension being 64K in size of 64 bit integers (...) If you exhaust the length of the key simply wrap it around.
Several big problems with that: 1. You'll need to calculate 2^32 (4 billion) 64-bit entries, i.e. 32 GiB, which is a lot of CPU time and memory if you just wanted to encrypt 10 kB of plaintext. (I'm not completely sure how you want to implement it; maybe you "only" need to calculate 64 k random values for each word of plaintext). 2. You need a really good (cryptographic-grade) random generator. If you have one, you could just as well use it directly - it's called "stream cipher". 3. If you wrap around your 32 GiB "two-time" pad over a low-entropy plaintext source, it is broken, since you can xor the plaintext at offset 0 with itself at offset 32 GiB to cancel out the pad. If you know that the message is plain English language, that may be enough reconstruct the two plaintext messages. [English has about 1 bit of entropy per character; xoring two texts with itself wlil result in about 2 bits of entropy per byte (8 bits) of message.] 4. If you encrypt two plaintext messages with the same key, your encryption is broken, for the same reason as under #3.
RC4 is simple, it's fast, (...) and it is *broken*.
It's only provably broken if you don't use the straightforward workaround for its weakness, i.e., discarding the first few hundred bytes (2 KiB to be on the safe side) of cipher stream. This was a problem in WEP encryption and may be a problem in the SSL implementation (not sure about today's status) and it kind of negates the speed advantage if RC4 is used for transmitting short messages. But run ssh with RC4 (it will drop the first 2 kB of the key stream) for large file transfers and you're safe and fast.
"Why would the cabin crew have the code? The code is for the pilots."
Here is airbus's own explanation: http://m.youtube.com/watch?v=R...
TL;DW: if the pilots are incapacitated, the cabin crew can punch a code to save the day; the door will unlock after 30 seconds unless the pilot pushes the button to deny access. (the pilots are alerted by a beeping signal.) Actually, a pretty sensible way to do it.
"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
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.