Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment: Re:Computers Kill Trees (Score 1) 105

by hankwang (#49788859) Attached to: Computer Chips Made of Wood Promise Greener Electronics

Your EPA document is about sequestration rates PER TREE in (sub)urban setting. Under such circumstances, the CO2 sequestration rate would depend mostly on the amount of sunlight that it can capture, which increases as the tree grows. A typical urban tree looks like a short stick with a strongly branched green ball on top.

In a production forest, trees are planted closely together and compete with each other for light. You'd expect the photosynthesis rate per unit of ground area to level off once a full leaf coverage is reached, which could well happen within 20 years. My idea of a production forest is lots of tall stems with little branching, most leaves near the top, and not enough light to support plant growth at ground level.

Secondary effects could be that the trees waste more energy on forming new leaves every spring that capture a smaller and smaller fraction of the sunlight as the competition for light increases. That could well lead to a reduction in net sequestration rate over time.

To me it seems plausible that you're both correct, but comparing apples and oranges.

Comment: Re:How? (Score 2) 333

by hankwang (#49721047) Attached to: Genetically Engineered Yeast Makes It Possible To Brew Morphine
"any home brewer can replicate the yeast with ease." I wouldn't be so sure of that. If this yeast is slow to replicate compared to wild yeast strains that float around in the air, it may be quite difficult to keep your strain from getting outcompeted by other strains unless you have a cleanroom facility at home.

Comment: Re:Sheerwind "bladeless" wind generators (Score 1) 164

by hankwang (#49709513) Attached to: Wind Turbines With No Blades

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:

Comment: Re:160 characters to die for (Score 1) 247

by hankwang (#49566481) Attached to: The Engineer's Lament -- Prioritizing Car Safety Issues

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

Comment: Re:Good! (Score 3, Interesting) 25

by hankwang (#49415191) Attached to: Google In Talks To Create International Roaming Network

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.

Comment: Re:The big advantage of XOR (Score 2) 277

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

Comment: Re:What are you protecting? (Score 1) 277

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.

Comment: Re:xor unbreakable with long (stretched) key (Score 1) 277

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.

Comment: Re:Don't make it impossible, just make it hard (Score 1) 385

by hankwang (#49355915) Attached to: Modern Cockpits: Harder To Invade But Easier To Lock Up

"Why would the cabin crew have the code? The code is for the pilots."

Here is airbus's own explanation:

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.

Comment: Re:Waste of time (Score 1) 253

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

Comment: Re:Do that for the laptops as well (Score 2) 51

by hankwang (#49265319) Attached to: Fujitsu Could Help Smartphone Chips Run Cooler

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

Comment: Re:Speed penalty of encryption (Score 1) 124

by hankwang (#49263165) Attached to: Google Backs Off Default Encryption on New Android Lollilop Devices

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.

Invest in physics -- own a piece of Dirac!