Please create an account to participate in the Slashdot moderation system


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Well (Score 1) 71

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.

Comment FUD bullshit (Score 1) 210

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.

Comment Re:Google can fix it with a hammer. (Score 1) 221

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*

Comment Re:Android 4.3? (Score 1) 120

I don't understand.
If Nexus and iOS devices can be updated without carrier interference, why can't everything else be similarly updated.

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.

Comment Re:Not close to essentially (Score 2) 120

Not on a device without expandable storage its not.

And really not even then.

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.

Comment Re:more info (Score 1) 242

- google is not disclosing how they protect our data

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.

- google has full access to data that at least I consider is none of their business, so I'd like to be able to supply my own encryption key.

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

Comment Re:This is why I turned off backup (Score 1) 242

Well, they could offer the option of letting the user set a backup password that is known only to the user (warning the user that if they lose the password, they lose their backups).

Most home users probably won't use it, but those that care about security (like every corporation that uses Android devices) probably will.

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?

Comment Re:Misses the point (Score 2) 419

Facts - 3.2 is the only 3.x line considered in the Android dashboard. The "UI Shift" of Honeycomb was an outlier, with some components of pre 3.x and 3.x making it into 4.x. 4.x is Jelly Bean. 0.1% of the market is on 3.2 and almost 60% are on some variant of 4.x. 60% (rounded even) is much less than roughly 90% on iOS.

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

Comment Baseless (Score 1) 165

It's easy to draw the conclusion that git-hosting in the cloud, like Github or Bitbucket, will lead to sharing the sourcecode with the NSA.

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.

Comment Re:Facebook and Google and the NSA (Score 2) 323

You're way over-thinking this. The NSA just sends their DBA's over to google with fake credentials. They get hired based on their stellar work history. Then they create accounts with full access to Googles APIs and hand them over to the NSA. The NSA can run any query they want against googles data. They can even CHANGE it. It would be a trivial thing to do and would only be noticed if the traffic was excessive. I doubt there's any query that Google would even bat an eyelash at given their size.

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!"

Comment Re:https (Score 2, Informative) 323

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.

Comment Re:Facebook and Google and the NSA (Score 1) 323

I've been feeling that they are liking arguing semantics. Sure the government doesn't have direct access but a 3rd party does and via perhaps their data the government gets what it wants or something a long those lines.

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.

Comment Re:The TB bus does not have a lot of bandwidth (Score 1) 607

The bandwidth here is basically faster than 6 x8 slots.

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.

Slashdot Top Deals

"We Americans, we're a simple people... but piss us off, and we'll bomb your cities." -- Robin Williams, _Good Morning Vietnam_