Actually, the key thing for them is "cheap". They need to keep costing sub-$1k missiles in the ballpark of these Iron dome systems - the more, the better. They might as well just omit the warheads to save money and increase range. Every $50k shot Israel fires with those systems costs 25 Israelis' annual tax contribution to the IDF. Every $55m system they deploy costs 27.500 Israelis' IDF tax contributions.

Palestinians are poor, but they're not *that* poor that they can't leverage those kind of lopsided financial ratios.

I can't help but picture a sign on the door at the exit of an airport in Israel. It reads "Thank-you for not stirring up ancient inter-tribal conflict".

Now I can't help but think of this excellent video :)

Using a nuclear device at high altitude? You do know what happens if you do that, right? That one test bomb knocked out street lights and long distance phone service nearly 1000 miles away and took out a third of all satellites in orbit around Earth at that point in time.

No, in the case of Iron Dome, that's only PR too. They're shooting $50k+ missiles at $800 rockets. Even after factoring in that Israel's per-capita GDP is 20 times that of Palestine's, that's still a losing proposition, even *if* they had a 100% hit rate (which this article is suggesting it's anything-but) and assuming that you get the launcher, radar, etc for free instead of the actual $55 million per unit. It's in Palestine's best interests that Israel deploy as many of them as possible and try to shoot down every last rocket, because every shekel they spend on Iron Domes and missiles is a shekel they don't spend on jets, tanks, and bombs.

This. Exactly this. Everytime I hear someone apologize for Microsoft, I can't help but stare at them blankly. It's like Dumbledore and Harry Potter (this is news for NERDS still, right?) .. are you sure you ever really knew them at all?

Well a lot of money was spent to no particular effect. That's kind of like change.

Meanwhile some of us actually want to develop multiplatform software.

The issue, in the long term, is does it really matter? Microsoft still had a big chunk of the enterprise workstation and groupware market, but in many other ways they're becoming irrelevant. Despite throwing boatloads of money at the search and tablet markets, they're not moving those products. To make up for that they're hiking the prices of the very enterprise offerings they need to survive. Volume licensing, Server, Exchange, SQL Server and the like have Alli been jacket up to fund their failures. The last batch of Server licenses I bought may very well be the last.

Let's be blunt. Microsoft is all but irrelevant in the mobile and tablet markets. About the only thing they have going for them is the scam patent tax they have on Android devices.

I think we can sum up the whole letter with "We're going to keep imitating Google and Apple."

OOXML is a great example of a standad, and of how to move a standard through an international standards committee.

(This is irony, for those who may be impaired in its recognition)

... the greater your capacity, the less cycle life matters. If you want an EV that battery that will run a 250Wh/mi vehicle for an average 20 miles a day for 15 years, then you want it to cycle through about 30MWh. If you use a 100 mile (25kWh) battery pack, then that's 1100 cycles. If you use a 200 mile (50kWh) battery pack, then that's 550 cycles. If you use a 400 mile (100kWh) battery pack, then that's a mere 275 cycles. Actually, the improvement is even better than that in the real world, because the greater your capacity vs. how far you're actually driving, the more you can cycle the cells through a less destructive state of charge range rather than doing deep discharges.

A lot of people picture battery packs in EVs backwards, they think that things like hybrids stress the packs the least, PHEVs moderately, and EVs the worst. But it's reversed. If you look at how big hybrid packs are vs. how much electric range they hold, you'll see that they're disproportionately large, even after you factor in any differences in Wh/kg. The reason is that because hybrid packs get cycled so much, they have to keep the cycling in a very narrow state of charge range, only allowing shallow discharges. So if you only have a narrow discharge range, you have to make your pack bigger to make up for it. EVs can discharge through much more of their pack because they need fewer total cycles and only rarely go down toward the lower end of their allowable discharge range. Some EVs also let you limit the max that your pack charges up to to further extend lifespan (it's usually destructive both to use the very top end and the bottom end of the discharge range).

1024 mAhg1 is excellent capacity even vs. brand new graphite or amorphous carbon, about 3x as much as graphite's maximum. Silicon's theoretical max is 8-10x that of graphite, but the main problem with it is durability, it tends to tear itself apart on loading. There are silicon anodes in some newer li-ion cells on the market, but the tech is in its infancy.

That said, the real papers you want to be on the lookout for are cathode improvements, there's a lot more potential for volume/mass reduction there than in the anode. But it seems to be a more difficult challenge. Getting a 3x improvement in anode density is absolutely not the same a getting a 3x improvement in battery life.

Commercial li-ion battery energy densities have continued to improve during that time period, including the commercial introduction of cells with silicon anodes. Of course, silicon anodes are a new tech, so there's a great deal of room for improvement, which probably won't come close to "maxing out" for a decade or more.

Of course, that said, this article is your typical fluff piece following the guidelines of fluff science reporting.

1. Present an oversimplified version of one technology challenge that may or may not address the biggest issue and certainly doesn't address all of them - but don't mention that.
2. Introduce an outside-the-establishment loner with a passion - or at least someone you can try to present as "outside the establishment" and glaze over anyone who helped him.
3. Loner gets a "vision" based on some everyday activity
4. Present their solution and make it out to be a huge revolution that will certainly solve all our problems - if they can only get corporate backing / funding!

I think these sort of articles hurt the image of science because people read them, think "OMG, all our problems are solved!", then when everything's not solved afterward, fail to trust science in the future. For example, in this case, the most important element to improve is the cathode, not the anode. And cathode improvements are less common and usually less major than anode improvements. There's also tons of different anode improvements out there in various stages of research. Pretty much all of the silicon ones get way better than graphite or amorphous carbon.

That doesn't mean that this isnt an important paper - actually, from looking at it, it looks pretty good. It's just not "all that".

BTW, anyone know how credible this journal is? I see it's hosted on Nature.com but not part of Nature, and I tried to find an impact rating for it but couldn't.

Oh boy, there is so much wrong here... Where to start?

First of all, OpenSSL problems are not ''getting fixed''. Part of the problem is that funding for OpenSSL was primarily based on company XYZ sponsoring function ABC. This gave incentives to the OpenSSL devs to add more functionalities on top of the cruft, the horrible mess that was the code base. More funding equals more developpers equals more eyeballs, but we haven't seen the progress so far.

Second of all, OpenBSD has given a HUGE amount of (BSD licensed) code to the rest of the world, Linux included. Try typing "ssh -V" on any Linux machine and I can guarantee you will get OpenSSH. And if you are like me, this is something you use EVERY. FREAKING. DAY. So please stop the trolling about OpenBSD, mmmmkay?

Third, the amount of code that has been cleaned up, improved, deleted and just plain scrubbed is simply amazing. You can say whatever you want about OpenBSD cranky devs, they know their stuff and they know their way around C code.

Fourth, OpenSSL is BSD/Apache licensed, and not GPL, so stop spouting off about supporting GPL software - not everything has to be blessed by Stallmann to be acceptable. And, yes, the Linux Foundation recognizes this - while you don't.

There is not just ''cruft'' in the code base: if I remember correctly, they removed thousands upon thousands of lines of code from OpenSSL - think VMS, Borland C, Windows 3.x, MS Visual C++ (etc) support.

And they tested the whole thing on the OpenBSD ports - so far, nothing has been broken.

Oh and FIPS support? Not gonna happen. Bob Beck has been very very clear on that subject. OpenBSD does not care too much about US government standard.