Are these outdated specs worth your privacy and freedom?
No - but the Market will ultimately decide that.
It's too cold? Override. Too hot? Override. In the end, the programmable thermostat reverts to a plain old one because no one can be bothered to reprogram the damn thing..
Damn straight! That's why I did this with my Honeywell!
It's a good start - in the "trolls" who hold patents but don't have any actual products wouldn't be able to meet this bar. However, it still would not prevent a troll from selling said patents to someone who HAS such an infringing product - to whom violation of such a patent would be valuable, and valid for suit.
So in other words...WTF??
(P.S. I'm not really educated in any of this kind of stuff and don't really know what I'm talking about - so don't bother correcting me)
Just because the two may have the same CPU ( which let's say for the sake of argument - they will) - it'doesn't mean people want an "iOS experience" on a MacBook pro. Chances are if they did - they would have bought an iPad. If they want a keyboard and a mouse (which they probably do - or they'd by an iPad) - they are probably doing things that are less condicive to the iOS-type "touch" interface. They want mouse control (which is more accurate than "touch", and doesn't require lifing one's hands up or far from the keyboard for extended or repetitive sets of time) - a keyboard - and possibly a multi-windowed environment - which they can do for a lot of stuff. They might be doing a lot of word processing, layout - or running XCode. They need to install their OWN SOFTWARE (without the restrictions and complications of Apple's certificates, licensince, AppStore, etc).
So I could see them packaging it as an "iPad with a keyboard" - but it would be a different product - and not a "replacement" for the Air or any other laptop.
Outside of Android - I believe use and acceptance is waning heavily. As a client-side web tool (where it got most of it's early predominance) it has been cockblocked by iOS, and is becoming overshadowed by native HTML5 (JavaScript) stuff. As a server-side tool it has been getting taken over by Ruby/Rails, Python and the stuff mentioned in the OP.
But to insist on using "biometric" data for "online" purchases - how are they expecting to receive the biometric data? Through a scanner on the *users* computer? Even if it was done by some sort of credit-card hardware - you are now relying on not *biometric* data - but just *data* - as the users' computer has to send the data - and therefore who's to say if it's really "biometric" or not. (i.e. Some sort of reply attack - or something like it). My point is - there is no way to assure that it's really the user's fingerprint - just data matching the user's fingerprint. So how is this different than a conventional password?
At least a the grocery store - if you stick a "fake" finger on the scanner - you're going to at least create some suspicion - at minimum.
Remember, UNIX spelled backwards is XINU. -- Mt.