This is about right. MLC flash normally is rated for between 1k and 10k cycles. Newer flash is generally less as transistor sizes are shrunk to fit in more gbytes in the same die area.

A home PC will only write a couple of gigs a day under typical workloads, which turns out to about 5 full writes a year for even the small sizes. That would last you 4000 years assuming ideal wear leveling...

Basically, what they're saying is this will be absolutely fine for everything except outgoing mail servers and a few other specialist things.

The capacitor backup and write cache make wear leveling much much easier, since all frequently written to cells can be cached in ram, and only written once on shutdown, and the capacitor backup means even an unclean shutdown will save your data.

Having shipped something once, if your container happens to end up on the top of the ship, it can get _very_ hot.

One of the devices I shipped had a thermometer in, and it got to 83 C (181 F). Lots of things melted, and all the rubber seals became all sticky and useless. Lots of other bits of plastic became hard and cracked. Lots of bottled products either expanded and split or evaporated. Lots of batteries split and broke the things they were in. The shipping company didn't care...

I'd say, make sure you have some kind of data logger in there logging at the very least pressure, temperature, and wetness, and then if they drop your container in the sea you at least know what happened to it...

When someone buys a design from ARM, they buy one of two things:

1. A Hard macro block. This is like an mspaint version of a cpu. it looks just like the photos here. The CPU has been laid out partially by hand by ARM engineers. The buyer must use it exactly as supplied - changing it would be neigh-on impossible. In the software world, it's the equivalent of giving an exe file.

2. Source Code. This can be compiled by the buyer. Most buyers make minor changes, like adjusting the memory controller or caches, or adding custom FPU-like things. They then compile themselves. Most use a standard compiler rather than hand-laying out the stuff, and performance is therefore lower.

The articles assertion that hand layout hasn't been done for years outside intel as far as I know is codswallop. Elements of hand layout, from gate design to designing memory cells and cache blocks have been present in ARM hard blocks since the very first arm processors. Go look in the lobby at ARM HQ in Cambridge UK and you can see the meticulous hand layout of their first cpu, and it's so simple you can see every wire!

Apple has probably collaborated with ARM to get a hand layout done with apples chosen modifications. I can't see anything new or innovative here.

Evidence: http://www.arm.com/images/A9-osprey-hres.jpg (this is a layout for an ARM Cortex A9)

Considering this is Nature, the lack of any numbers, or even a link to a paper are very disappointing. The writing style itself makes it sound like they've just turned lead into gold as well...

I want diagrams, temperatures, power figures, etc. Not waffle. I expect better.

The general public don't use desktop mail clients...

They use webmail.

Geeks use desktop mail clients, and geeks can install their own. I'm surprisedMicrosoft even included a mail client really.

Amazon could do same-day delivery without any in-state infrastructure. Just pay another warehousing company to store and deliver the goods when asked to. Even paying a little premium for that, it's gotta cost way less than probably hundreds of millions of dollars of sales tax.

I see nothing wrong with this.

It's not so different from a good number of music videos, and those are seen as fine by most young guys and girls alike. Considering who this is targeted at, it seems all good to me!

Does the video advertise to guys more than gals? Perhaps, but it certainly addresses the feeling that science isn't sexy enough amongst the younger generations...

It is approximately valid. He put a bandwidth simulator between him and his proxy.

His comment about the average site requiring ~ 30 different SPDY connections seems excessive though. I suspect this is why he's seeing such bad results. Maybe he is assuming no benefit from the removal of domain sharding which providers would likely do if they rolled out SPDY.

Neither of those sound like unsolvable problems.

People don't like being bounced around either, so we use suspension and soft seats for them.

The combustion chamber in a gas engine gets to around 1000 degrees C as well, and that isn't a problem. We can get rid of the heat if necessary, or if it needs to stay hot we can stick it in an insulating box. Either way, it sounds doable.

2kW isn't enough for a car though, and if you were to scale it up to the 100kW to fulfil a cars peak demand, it might prove too big and heavy.

(I suspect the error in this research is the method used to keep the LED at 135 C. If the leads are connected to a circuit which is cooler, they might cause one side of the silicon in the LED to be slightly cooler than the rest. If that were the case, it would form a peltier effect unit, which would drive the LED even without any electrical energy.)

The laws of thermodynamics say you can't simply extract energy from heat. You have to extract energy from a temperature difference. Seemingly this research goes against that, so I suspect there has been some error in the measurement somewhere until I see further evidence.

indeed, but if someone could get the key they could sign a message saying "uninstall yourself".

The security of the system relies in the bot-maker never revealing his private key. HTTPS security relies on having secure private keys in the same way, and that works...

By the way, I think you were mixing up encryption with authentication. You are right that the control messages can't be encrypted, since they must be able to be decrypted by any node in the network, and hence security researchers have access to whatever key they are encrypted with, and can also decrypt them.

They can however be signed (authenticated) to prevent anyone but the real botnet owner from sending them.

(note, all of this is assuming assymetric (eg. RSA) cryptography - where one key is used for encryption, and another for decryption, or equally one key for signing, and another for validating)

I'm not sure about your comments re: keys.

It seems relatively easy to design a botnet to be peer to peer and yet not able to be taken over by a rogue node. Consider a P2P overlay network where each node plays "chineese whispers" and forwards any packet to all neighbours (with some TTL limit).

The botnet owner creates a public private keypair, and uses his private key to sign control messages. Each host takes each incoming packet and checks if it is signed by the botnet-owner, which requires the public key of the botnet owner, and is built into the code. If someone reverse engineers a node, all they have is the public key, so can't sign messages (since signing requires a private key).

An attacker could still DoS this network with unsigned Control messages, but that can easily be thwarted by:
a) never forward any unsigned message
b) forward signed messages only if it's version number is higher than the last forwarded message.

To hide himself and operate the network, the botnet owner can use TOR or some other anonymising service to connect randomly to any node in the network (rather like utorrent DHT does), and send a signed control message with a version number higher than any seen before by the network.

But each of those limitations improves approximately with moores law. the brain hasn't changed much this century. At some point one will surpass the other.