I doubt it would be trivial: you can sacrifice capacity for some speed by reducing the amount of platter area you use(and thus how far back and forth the read/write head assembly needs to move); but RPM is still a serious constraint, and bumping that tends to get rather costly. 15k RPM has been the effective ceiling for years, and while increases in data density improve best-case read and write speeds they have no effect on how long you have to wait for a given chunk of disk to finish its rotation and come back under the read head.

It also doesn't help that SSDs are aggressively moving into the high speed area. If you applied the engineering tricks used in ultracentrifuges you could probably build a damn fast HDD; but doing so for less than the price of a really nice SSD would be a great deal more challenging.

New Hampshire runs a very similar operation. I've never quite understood why a state whose motto is "Live Free or Die" lets The Man control their booze supply; but I imagine that the indirect tax of a state liquor monopoly is more popular than some direct tax levied elsewhere.

Between manufacturer avarice and customer stupidity I hold out very little hope; but it would warm my cold, black, shriveled, heart if somebody would standardize a key-fill interface (like the DS-101/DS-102 devices that the DoD has for connection to U-229 ports on communications gear and other things that need crypto keys; but actually remotely suitable for end users, unlike those systems) for dealing with this class of problems...

Right now, it seems like everything is either "Oh, totally wide open, maybe papered over with some pitiful little obfuscation attempt" or "So damn much asymmetric key crypto that you'll need to beg the vendor for permission to do anything"; but options are very, very, thin on the ground if you want something as secure as a mothership-bound lockdown device; but obedient to your crypto keys, not the ones burned in at the factory.

It's like the 'secure boot' controversy that erupted a while back. "Well, you can have Microsoft's keys and protection against certain types of OS tampering, or you can turn it off entirely(x86 only other restrictions may apply); but set your own root of trust? Ha!"

It's insane that it isn't easier to re-key/re-pair with a replacement device; but I suspect that it is otherwise very much for the best to move some functions to the iPod.

Apple has spent a Lot of money designing iDevices and perfecting them over multiple generations. Hard to say how much; but it's a large number. Conveniently for you, they'll sell 'em to you in quantities of 1 for a only a modest premium over production cost.

In an ideal world, the prosthesis would require no 'interface' at all(your arm doesn't, after all); but if it does, a company specializing in prosthetics doesn't have a prayer of delivering an interface device nearly as good as an iDevice or Android unit for less than they could just buy one and develop the necessary software on top of it. (In practice, they'd probably be lucky to develop something substantially worse for three powers of ten more, if they tried it.)

If it turns out that timing-critical control and feedback loop stuff is being done over bluetooth, by an 'app', somebody needs a hell of a beating; but if it's just a UI/Configuration/etc. interface using an off-the-shelf device is extremely logical.

It tends to be discouraged, out of concern that states aren't very good at it, or that they might be inclined to use their other powers to make themselves more competitive; but there isn't anything architecturally precluding a state from earning money. They can have employees, own and operate R&D and production facilities, sell products, same as a company.

There are reasons to discourage that, and have them focus on things that the private sector can't do or does poorly; but those are pragmatic considerations, not fundamental obstacles.

I'd be totally unsurprised by incredibly bad design; but that incredibly bad design would also tend to make it relatively trivial to access whatever memory holds the UID or key used to establish the pairing and blank or rewrite it to establish a new pairing with a new device. Probably not in the owner's manual; but likely something that an EE undergrad could do with access to a few hundreds to thousands of dollars worth of borrowed test equipment and a congratulatory couple of six-packs. Definitely for less than replacing the hardware.

Design that is both appallingly ill thought out and too ironclad to subvert would be fairly surprising. Now, if it were a prosthetic eye, and needed to appease the MPAA when handling Premium Content, I'd be more concerned...

Given the work they've put into having clients for most things, and broad 3rd party integration, they probably have some room to overcharge for small amounts of space (sure, you could just go shove S3 buckets yourself; but we've already done the integration work for you...); but they seem strangely overconfident about their ability to set prices for larger blocks of storage that just emphasize the discrepancy in per GB price.

That may actually be part of how Google and Amazon and Apple are hitting them hard now: DropBox offers a reasonably compelling deal if you don't need too much space. Sure, it costs too much per GB; but it's all nicely wrapped up and integrated with the programs you use, and life is just too short to go tinkering or comparison shopping to save a small amount. However, Google, Amazon, and Apple will all give you a modest amount of storage for nothing, as part of their respective plans to sell stuff, achieve platform dominance, or whatever. That obviously cuts the knees out from under DropBox's formerly cushy margins on small accounts; and, as you say, their price/GB has always been sufficiently high that they really start to look bad if you need nontrivial amounts of storage(which nobody will give you for free; but which players like Amazon will sell impressively close to cost).

You mean like my mousepad becoming non-functional when I bring my Windows 8.1 notebook up from sleep?

I suspect that, aside from the high costs (and even higher PR costs) of air crashes, the way most contemporary flights are scheduled makes maximum-granularity/low-predictability information less valuable than lower granularity and higher predictability.

As much as you wouldn't guess it from a trip to Baggage Claim, mass market air travel is very much a 'just in time' operation. Every minute an aircraft spends sitting on the ground and waiting for something is money lost. Every minute one spends circling around and waiting for a landing slot is even more money lost. Customers who miss connecting flights are either foregone sales, pissed off, or people that unexpectedly need to be crammed onto later flights. Airplanes themselves have connections to make. After doing one route, the plane is almost certainly scheduled for a deeply cursory cleaning and another destination.

In such an environment, you do want timely alerts of unexpected emergencies(since the cost of having to replace multiple glassed engines, or an entire airplane and passengers is really bad); but the value of unexpected or unreliable good news is much less obvious unless it can be slotted neatly into an overall schedule that would survive if the news is bad(which definitely could happen, if a landing slot can be arranged to suit, learning that a flight will be faster and burn less fuel than expected would be good news; but not necessarily news you could bet the scheduling of the flight's next leg on).

It should take approximately no time at all for this to become an abject illustration of the adage that "Hell is other people". Definitely going to go well.

Even if MS and Google aren't willing to lose money on storage(they certainly are in the short term; but as a long game that strategy will not sell well), it isn't terribly obvious why repackaging AWS should be a particularly sustainable niche.

There is room(and dropbox exploited it) for the outfit that makes using AWS trivial and bodges together clients for OSes that allow fairly low level integration and 'app' integration for those that don't; but that's a goal where reaching 'adequate' is not a terribly high barrier to entry and where it isn't obvious what novel features one can add to continue justifying one's profit.

Once there are multiple players who have adequate client integration available what remains but to sell on price?

There is at least an argument to be made if one looks at how much...encouragement...the platform vendors, especially on the mobile side, provide to use their own blessed and proprietary 'cloud' service; depending on how closely controlled the OS is the advantage of being the platform-blessed option can be fairly substantial.

However, TFS seems to be worked up about the fact that the price/GB of deeply undistinguished storage has cratered over time. Yes, yes it has. Advances in disk density and datacenter operations have sharply reduced the absolute cost, and unless your service offers something really cool, or an airtight SLA, or some other nice feature, why wouldn't your margins reflect the fact that you provide a commodity?

If the only language you have proficiency in is C#, then you have a problem that may very well interfere with your employability.

Reading at -1 is like having your soul sucked out and replaced by liquid nitrogen.

Not to mention the fantastic Dune/Star Trek crossover. The best scenes are where Nurse Chapel seduces Baron Harkonnen (and much hilarity ensues) and Paul Atreided and Captain Kirk compare whether the Weirding way or the monkey kick are more effective. Best catchphrase "dammit Jim, I'm a doctor, not a Bene Tleilax facedancer."