Games are still largely gated by a single thread because graphics APIs still don't allow multiple threads to share a context[1]. When you're only allowed to talk to the GPU from a single thread, it's no surprise that thread is going to be CPU bound.

1. Yes I know you can do limited resource sharing between contexts and such for background uploading of resources like textures, but the actual act of issuing all the drawing commands to produce the frame has to happen from a single thread.

Google did not copy millions of books with little regard for the law. They were found by a court of law to have fully complied with the law. They copied millions of books *LEGALLY*. They followed copyright law. They may have gone right up to the edge of the law, but they respected it and did not cross it.

This is why you don't comment on an article without reading it - you look stupid as a result.

The clocks *ARE* being increased, and the device is being kept awake artificially regardless of work load.

Then nobody would ship on Nexus and everyone else would carry on as normal. Google doesn't move many devices, they aren't a major player here.

Also open source drivers is not going to happen, but that's not even what's being asked for. Qualcomm isn't allowing Google to redistribute the *binary blobs*

Nexus devices aren't sold on a carrier, and those that are (Verizon Galaxy Nexus) *do* go through carrier testing.

Who says iOS devices don't go through carrier testing? It's quite possible that iOS 7 is actually in carrier testing right now, hence the several month "betas" that Apple does. That could just be the carrier testing cycle right there.

Yes it is, because it sits on /system which is a fixed size partition. Actually deleting the APK would get you exactly 0 bytes more storage *and* would break the factory reset option *and* breaks incremental OTAs.

Yes, they do. That's the privacy policy that nobody reads. If you want security design documents, good luck with that, you'll never see them from anyone.

Then don't check the fucking box that says "Backup my stuff to Google" ?

Yes, they could. This is what Chrome does for saved passwords, for example, so Google's servers only ever get an ecrypted blob.

However, the question is why on earth is your *WIFI* password that sensitive that it needs that level of user friction, hassle, and increased support costs? Corporations can easily use their own app or a 3rd party app that injects the wireless credentials through Android's public API for that - there's no reason for Google's backup to handle that. Those that care about security have probably already secured every device on their network instead of blindly trusting anything that can reach it. So what, exactly, is so damn sensitive about a wifi password that this needs to be an option that Google should support? Are you that worried that Google will leach off of your bandwidth or something?

And if the NSA is already tapped into the fiber backbones as people suspect, what would they want with this info anyway? Why wardrive and catch snippets when you can just record literally everything?

60% of Android is *greater than* 90% of iOS, not less.

So at this point your claim is basically "Google is run entirely by the NSA"

Speaking of which, can I borrow some tinfoil? You clearly have a good stockpile, and I don't feel like running to the store right now.

lol wut? No, that's not an easy conclusion. Github and Bitbucket are only going to share your sourcecode with the NSA if they receive a FISA (or similar) request for them. In which case you've drawn the attention of the NSA somehow and self-hosting isn't going to save your ass because they're just going to show up on your doorstep with the FISA request instead of Github's. And if you say "no" they'll just throw you in jail.

And if you do take on the task of self-hosting, you now have to deal with security and monitoring and such. The sort of things the cloud companies are doing that you probably won't. Meaning self-hosting will make it *EASIER* for the NSA to hack in and get your source, not harder.

That would be damn near impossible. Do you really think Google has no security whatsoever on API access much less data access? I'm pretty sure if the new hire goes to the security team and says "hey, let me punch a hole in the network to the outside world for this API. Oh, and I need also need to approve this API to access all this data" they aren't just going to blindly say "sure thing, no problem!"

Google is using ECDHE for HTTPS. Unless NSA has been running an incredibly good MITM that nobody has detected and has never once had a single outage or issue, HTTPS to Google has been uncompromised since 2011.

Sadly more people aren't using ECDHE yet, though, so the same can't be said of most sites which could very well have compromised certs. Perhaps this can be used to help push ECDHE more broadly, although I kind of doubt anyone will really care, sadly.

That's because you *want* that to be true to justify your initial emotional reaction. Google has very clearly stated that nothing of the sort is happening. They are not playing words games in the slightest. There is no broad data dump - not directly, not "indirectly" (which is a stupid argument in the first place), nothing. The other companies have said similar things. Nobody is arguing semantics. PRISM as it was initially reported simply doesn't exist.

Seriously, the initial reports were just *wrong*, flat out. Anyone with half a brain could easily see that if they bothered to look. If the slides meant what they were initially reported on it would be the single greatest feat in the history of mankind as the budget was listed at $20M.

False. The x8 slots you'll find in any PC these days is PCI-e 3.0, which is 64Gb/s. The bandwidth in those 6 Thunderbolt connectors is less than a *single* x16 slot these days (128Gb/s).

And in case you think that's overkill, note that higher end video cards are bottlenecked by anything less than x8 (64Gb/s). Good luck combining 3 Thunderbolt connections together to drive a single video card.