Those percentages are out of date. The percentages from the latest update are:

It's not achievable in the near future, because the speed at which the batteries can absorb energy isn't the sole limiting factor. Charging an 85 kWh battery pack in 5 minutes requires a charging cable/port that is dumping slightly more than a megawatt into the car, which isn't practical. The limitations are things like the cable, the connector, the power grid, etc.

A far more likely scenario is that charging will get a little bit faster, and battery swaps will be used when more speed is required.

There's enough in that comment that is verifiable bullshit that it makes me question the parts of it that don't seem ridiculous at first glance.

Yet another development stack? Some of us have been using it for more than a decade. When .NET was released, most of today's popular Linux distros (Ubuntu, Gentoo, Fedora, CentOS, Arch, OpenSUSE, or any of the popular mobile Linux distros like Android or ChromeOS) didn't even exist. I realize that many of those distros are forks of previous distros, but the point is that .NET isn't exactly the new kid on the block.

The C# version is using Linq. Which, as a C# developer, I've never really been able to wrap my head around. Now, that might be due to lack of trying, in that I've never really been forced to deal with Linq in a manner where I couldn't just work around it, and I've never put any serious effort into training on it, but an awful lot of it seems to be of the non-obvious-way-to-do-things variety. The entire X => X.Something syntax seems confusing and illogical to me. Where does the type of X come from? Where are the properties coming from? What's with the X => bit? If "IsCar" is a property of the members of the myVehicles array, why can't I do something like "myVehicles.where(IsCar).select(LegRoom).sort().foreach(display)?

Perhaps my aversion to Linq is because my exposure to it has been having very complex use of it randomly thrown at me in large projects without having learned it first, and then having to make changes in that Linq code without having been given the time to properly understand it in the first place.

Microsoft is opensourcing the vast majority of the .NET framework, but if they're focusing on the server-side stuff, there may be some client-side bits that aren't, such as Windows.Forms. So Mono might not so much go away as it could end up just focusing on the bits that Microsoft hasn't opensourced.

They're opensourcing the entire server stack... which happens to contain nearly the entirety of the client-side stack. You'll miss Windows.Forms and WPF, sure, but Windows.Forms already has opensource implementations courtesy of Mono (which I would imagine should run on Microsoft's implementation of .NET), and WPF never really took off, leaving Windows.Forms still more popular. The reason that Mono never implemented WPF was apparently due to lack of interest and resources... Well, Microsoft may have just removed the necessity for Mono to do work on anything *but* the client-side bits, so those resources may now be available.

That said, I believe that there is far more software out there written using server-side .NET than client-side.

Real gamers often do their gaming on a desktop, and have an Ultrabook for portability. Said gamers might not want or need the bulk of a gaming notebook 99% of the time, but might still appreciate the ability of an Intel iGPU to handle basic game rendering on the rare occasion when they want to keep themselves busy while on the go.

I'm a gamer, and I do all my gaming on a relatively high-end desktop. I've got a Macbook Air, because I only have a desire to fire up a game on my notebook a handful of times a year. But at the same time, I appreciate that I can run Civ V or Civ: BE on said notebook when it's called to do so.

It's not US retailers, generally, who are overcharging Australians. If the retailers also do business in Australia, they might care. But if you buy something from a company with no presence in Australia who previously wouldn't ship there themselves, then it'll be fine.

Browsers weren't running javascript at two third the speed of native code in the 90s, nor were they fast enough to run ports of recent games that are virtually indistinguishable from their native brethren. It stopped being an hypothesis when it started actually happening in the wild.

People make a big deal about replaceable batteries, but how often do users actually replace the battery in modern devices? Sure, I managed to wear out the battery in my Dell laptop after three or four years of heavy use, but by then it was time to replace the notebook for other reasons anyhow. The quality of lithium ion batteries has also improved since then, such that they don't wear out as fast.

I can't seem to recall having ever replaced the battery in a mobile device, so when my mobile devices started having non-replacable batteries, it didn't make any difference. The idea of keeping spare fully charged batteries around is also a non-starter, as it's far more convenient (and flexible) to use an external battery pack that can be recharged independently and used with multiple devices.

I'd be happy to give the Surface Pro 3 a try, but it isn't a replacement for my tablet, it's a replacement for my notebook. It's an ultrabook without a built-in keyboard, the evolution of Microsoft's TabletPC. And there's nothing wrong with that, I've heard good things about the product... but as a notebook, not a tablet.

Is it really so obtuse? As JavaScript engine efficiency improves, the gap between what you can accomplish with a native app and a JavaScript app narrows, and as CPU performance continues to improve, what you can accomplish with JavaScript increases. Lots of apps on iOS and Android these days are just thin wrappers around a browser anyhow, and the user never notices.

Eventually, sure, but NAND hasn't reached that point yet, and we're just starting to see 3D flash memory hit the market, offering dramatic increases in density.

Facebook is generating 4 PB per day *now*, while the LHC will be generating 400PB per year by *2023*. 27PB to 400PB in 9 years is MUCH slower than Moore's Law, so their annual storage costs/space requirements will decrease each year.

With the highest density servers I know of (1U 136TB SSD servers), LHC generates around five racks of data per year today. By 2023, they will only be generating around one rack of data per year, based on an 18-month Moore's Law.