and now I can't stop thinking about Jenny Agutter's tits.
You say that like it's a bad thing.
They are missing a perfect opportunity to conduct testing on the effects of alcohol on the human body while weightless!
You do realize half the station personnel at any time are Russian, right? And that they get a personal baggage allowance? Which is inspected by other Russians? That was practically the first experiment conducted on the human body in space, aside from just living and breathing.
"Results inconclusive. More testing needed."
Small memory leaks are very hard to find in testing. Most testing cycles involve testing a particular feature, looking for pass/fail for that feature. Say the feature is window display, as the summary seems to imply. Okay, does the window pop up when the command is given? Does it contain the right contents? Does it go away when commanded? Check, check, and check. Ship it! It's very unusual to test a feature long enough that a smallish memory leak adds up to anything noticeable. "System crashes when window is opened and closed 256 times in a session." QA is just plain never going to get to that point. It may take weeks of heavy use to get to the breaking point. Sure, it would be *nice* if there was a month-long burn-in period where the system was used heavily to expose any slow leaks, but that never happens.
From the summary I can't tell if the leak is anything that could be fixed by garbage collection. Was a block simply not freed and lost? Or was a reference to it still in a list somewhere, so that it would never get garbage collected even if that was a feature of the language? Is the memory in question on the regular heap so that something like valgrind could find that blocks weren't freed? Is the memory part of a specialized buffer pool managed by some other means? There's nowhere near enough information to go on, but that's not stopping anyone here from jumping to conclusions about the development and QA process.
Pretty much any car with a system like OnStar is going to be remotely accessible even if you don't use it, and the car companies have admitted this.
In fact, it's an intended feature, not just an unfortunate side-effect. Remote unlock and theft immobilization are first-class features of OnStar and similar systems. It is logically impossible to have those features and not be remotely accessible. You just have to hope that the link back to the mothership can't be spoofed and that the support personnel can't be socially engineered to doing the attacker's dirty work.
Some good stuff in there, and at the very least it's a starting point for manufacturers that actually care about consumer privacy and trust. Whether any such manufacturers exist is still an open question...
The only way this is going to turn into something consumers can use is if the Online Trust Alliance sets up a certification program. Certification would involve demonstrating that care has been taken to meet each of the points in the framework, and a passing grade gets you the right to paste a shiny "OTA Certified!" logo on your widget. That'd be good, until the Association of Trusted Onlineness comes out with its much weaker set of standards and its own "ATO Certified!" logo. How's the consumer to know which privacy certification is worth the pixels it's printed on?
(Maybe it would work out. I often wonder why Underwriter's Laboratories has a near-monopoly on safety certification, and why no one has come up with a much more "manufacturer-friendly" certification process. Maybe there's regulation involved, I don't know.)
Love Google Voice. On their own most of the transcripts are laughably bad, but if you know who is calling and can imagine them speaking as you read the jumble of words you can usually understand it well enough. Can't remember the last time I had to actually listen to my voice mail.
Of course, knowing Apple they're going to claim that this is all a remarkable invention on their part. Just think, now it's Siri asking you to leave a message at the tone instead of some nameless generic voice. Innovation!
Which of the "tons of apps" do you actually use? I'm trying find a reason to buy a smart watch (of whatever variety) but I just haven't found a use case that justifies the cost.
things will change as the watch becomes untethered from the iphone. first, over wifi, and then with a cellular connection. that's when the benefits really grow.
What benefits? I'm not being snarky, I'm genuinely curious. What would you want an untethered wrist-worn computer to do? I can't think of anything, myself. It'd be nice to get notifications and texts, but the form factor is too small to actually respond to them. Maybe if voice recognition technology improved by a couple orders of magnitude it'd be useful.
Perhaps most people "cheat" without their spouses knowing about it?
That is the reason it's called "cheating", after all. I would never cheat on my wife. That's not to say I'd never sleep with anyone else, just that I'd never do it without her knowledge and consent. It's only cheating if it's against the rules.
Men's desirability rises over time
 up to around age 55-60. At which point it stabilises, then drops slowly.
That's right, ladies, you heard him. I'm nearing peak desirability! Queue forms to the left. No pushing or shoving please, there's plenty of me to go around.
There's nothing said anywhere in the source code or docs about authentication or authorization. There's an Encrypt() hook in the source code but it's merely a stub function in the section commented "Configurable hooks for use as an application library", which implies to me that encryption is intended to be completely up to the the application.
So the idea is that you're passing around executable bytecode from node to node in the clear, to be unquestioningly executed by the receiving node. Does anyone else see a problem here?
Sure, it's a brand-spanking-new language. It's incomplete. I get that. But the security model cannot be an after-thought for something like this! It needs to be designed into the foundation of a serious IoT framework. As far as I can tell it hasn't even been considered.
Whom computers would destroy, they must first drive mad.