Encryption isn't everything and all privacy.
But encryption is part of the solution, as much as Tor, etc.

Perfect privacy will require several component. Encryption is one of the them. Connection obfuscation like Tor is another. Relying on pseudonymous identities (Do Not Track Me single-use email addresses, for example) is yet another.

the 256 bits encryption is safe. the actual maths behind it have been repeatedly proven to be sound and secure.
getting the password stolen (keylogger, side channel, implementation bugs, etc.), on the other hand is likely to be what will happen. (and as both software and hardware is shown to be backdoored, they won't even need the effort of puting an new keylogger, just use the backdoors).

In the mean time, you can also make the surveillance job as difficult and expensive as possible.
Thus: encrypt and obfuscate as much as possible, even for trivial everyday activities.

Yet, SSL handle only the encryption between a server, and the client application. (and can be made totally transparent to the user).
Whereas the anti-surveillance discussed here are end-to-end (from one user to the other) and will always require some minimal end-user intervention (key handling, although the interaction can be minimized and user interface efforts can make the experient as easy as possible).

Note that OTR (Off-the-Record) is standard, and is capable to be used above any of those, just like OpenPGP works over email.
But again, this requires either using full blown clients (pidgin, adium, jitsi, messagebird, or any other OTR compliant client) or using extensions (like cryptocat) to be able to use it from within a webapp.

Also, for obvious reason, OTR disturbs the "search" fonction on chat web-apps (as the webserver only sees encrypted text and can't search).

As currently done by several other banks.
(I'm in europe)

Then tell them to go fuck themselves and switch to another bank.

Mine (europe) not only support that, but its directly accessible from the e-banking web interface, so you can do it at any time conveniently and quickly.

As a way to do fast person-to-person transaction, bitcoin protocole (and other crypto-coins) is a good idea (it's like cash transaction, but over the internet, although a bit slower. Or for EUropeans: it's like SEPA, direct payment without an intermediate, except that it's a bit faster).

But please, unless you're a gambler DO NOT store money as BTC (nor any other crypto-currency): its value fluctuate too much (1 BTC is 500$, perhaps 10$ tomorrow or 1000$ the day after tomorrow) , also if you rely on an on-line service ("web wallet") rather than your own bitcoin-protocol client ("wallet" software) there are risks out of your control (think about MtGox and similar scandals).

Otherwise cryptocoin protocols are really interesting, by making an intermediate un-necessary. (There's no "bitcoin company" handling the actual transaction, unlike Visa/Mastercard), and complete freedom of choice for each end-point of the transaction (both the merchant and the client can use any wallet software, exchange platform, payment processor, etc. as long as both end-point follow the bitcoin protocol. Just like any of them could be using any european bank for an online payment as long as both banks support SEPA)

Are incoming messages expensive too?
In EU, incoming SMS are free wherever you are (home network or roaming).
Us european tend to keep an older phone around. Swap your *home* SIM card into the old phone and put whatever you use when abroad (SIM with plan in target country, prepaid SIM for target country, or just some random sim that is cheap while roaming like XX-Sim).
We're still reachable on the usual number (can get message for free, can also acept calls but that has roaming charges), and have the travelling option on the main phone.

The Banks I've seen simply contact you instead of relying on complex tracking (you receive an SMS: "your credit card has been used in an usual place. Please contact us"). Just call the bank back and either authorise the payment or announce a stolen card/number.
Other banks alternatively use a side-channel confirmation (3DSecure, for example) while shopping online.
It has the advantage of being less invasive and not require an active collaboration of Phone provider. (you only confirm when a flag is raised, you don't need the bank and the phone provider continuously monitoring you).

The interesting part, is that the guy is building a test-farm infrastructure.

The kernel benchmarking/bissecting stuff could be automated and could become part of the normal development project.
(Having the test farm continuously benchmark key linux project (llike kernel, mesa, etc.) while they are developed).

That is going to be:
- a very valuable ressource for linux development
- a service that can be sold or that can be sponsored by big player (Valve co-financing the mesa/gallium continuous benchmarking ?)

And one day, once Mesa and DRI/Gallium etc. mature enough you'll probably going to have a similar landscape in Linux.
For now, it's "work in progress" zone.

And that's AMD official stance:
- once the opensource drivers get good enough, support for older cards gets removed from catalyst, and radeon is pointed as the official go-to solution for older cards.
- so catalyst = drivers for the current generation of cards (unless you want to beta test the bleeding-edge development) and radeon = drivers for all the previous generation (unless you want specifically a card that still isn't phased out yet, probably because the current openCL support is better in catalyst).
- that's also part of the reason why AMD has opensource driver developers on their payroll.

Interestingly Valve doesn't merly influence the market by their game being a reason.
They actually do directly help progress with actual code.

See reports on the same Phoronix website of various OpenGL 4.x extension being added to Mesa by Valve.

One day, when the Mesa finally achieves full opengl 4x compliance, you'll know it's partly due to developer on Valve's payroll (in addition to those on Intel's and AMD's payrolls, and the independent volunteers in Nouveau project, and the thousands of other contributors - some corporate other independent).

On the other hand, I think it would be highly unadviseable to do business with bank that bases its decision simply on a search result page, without even investigating *when* did the event referenced happen? To me, this sounds like very lazy practice and poor judgement and is going to bring problems down the line.
Better to ask for money loan from a bank that does proper investigations.

Now combine this with the other announcement: "UK Seeks To Hold Terrorism Trial In Secret" so such "threat the national security" rule also means that the trial get to be secret.

Yup. To me it sounds like "You do something we don't like with a computer? We get the right to disappear you! For Life! Cause, you see, it's a matter of national security. Thus the trial is secret, and the sentence is life"

and copyright trolls will join the **AAs to make such car not-street legal (even if it has nothing to do with the driving on street)
and will sue presumed-fraudulent drivers automatic al. ...so just after the Nth scandal of **AA making fools of themselves after issuing a C&D letter for reason of torrenting against the IP address of a networked laser printer, prepare yourself to read about a warning issued for reason of unlicensed washer fluid against the VIN... of a lawnmower.

AMD's perspective is that Mantle is less problematic:
- Mantle's spec are open.
- Also it's just a very thin layer above the bare hardware. Actual problems will mostly be confined in the actual game engine.
- Game engine code is still completely at the hand of the developer and any bug or short coming is fixable.
Whereas, regarding GameWorks:
- It's a closed-source blackbox
- It's a huge midleware, i.e.: part of the engine itself.
- The part of the engine that is GameWorks is closed and if there are any problems (like not following standard and stalling the pipeline) no way that a developer will notice and be able to fix, even as AMD are willing to help. Whereas Nivida could be fixing this by patching around the problem in the driver (as usual), because they control the stack.

So from their point of view and given their philosophies, GameWorks is really destructive, both to them and to the whole market in general (gameworks is as much problematic to ATI, as it is to Intel [even if it is a smaller player] and to the huge diverse ecosystem of 3D chips in smartphone and tablets).

Now, shift the perspective to Nvidia.
First they are the dominant player (AMD is much smaller, even if they are the only other one worth considering).
So most of the people are going to heavily optimise game to their hardware, and then maybe provide an alternate "also ran" back-end for mantle. (Just like in the old days of Glide / OpenGL / DX backends).
What does Mantle bring to the table? Better driver performance? Well... Nvidia has been into the driver optimisation business *FOR AGES*, and they are already very good at it. What is the more likely, that in case of performance problems developers are going to jump on mass to a newer API that is only available from one non-dominant PC player, and a few consoles, and completely missing on any other platform? Or that Nidia will patch around the per problem by hacking their own platform, and dev will continue to use the ?
In Nvidia's perspective and way to work, Mantle is completely irrelevant, barely registering a "blip" on the marketing-radar.

that's why there's some outcry against GameWorks, whereas the most Mantle has managed to attract is a "meh". (and will mostly be considered as yet another wanabe-API that's going to die in the mid- to long-term)

to me it sounds like again like the beginning of Internet Explorer vs. Firefox compliance to HTML standards.

Down to the detail of how it pans out:
- one company being the popular one (Microsoft, Nvidia), so everybody code to their platform (IE, drivers) and end up unknowingly produce bad that code that happen to rely on the peculiarities of this platform (the non standard assumption of Nvidia's drivers, the weird re-interpretation of HTML done by IE's engine). When there are problem, they tend to hack their own code.
- the other company being the underdog (Mozilla, AMD) making a platform (Firefox, Catalyst) that tries to follow the open standard to the letter (HTML5, OpenGL), but in the end other person's code (websites, code) behaves poorly, because it breaks standard and relies on quirks that aren't present in that platform. The users complain of problem (broken HTML rendering worse under Firefox than IE, non-compliant openGL code's performance being more degraded on AMD then Nvidia hardware).

Funnily, if past history is any indicator, on the long run AMD's approach is better and either them or one of their successor is bound to manage to bring opengl-compliance more important than driver tricks.
(the fact that AMD is dominating the current iteration of consoles, might help bring more power to them)
Interestingly the embed world might one also end up helping just like it did the browser wars (Internet Explorer was far less prevalent in embed machine like PDA/Smartphone/Tablet than on desktop and the problems with broken HTML became much more apparent, and compliance with HTML5 [sure to run on as much platforms as possible] was determinant. Also the embed eco-system mostly centered around compliant engine (like Webkit)) due to the same factors (extremely heterogeneous ecosystem hardware-wise, where Nvidia is just one player among tons of others with their Tegra platform. compliance with OpenGL ES is what is going to be determinant as the embed platforms are going to need a lingua franca to insure that porting an engine is as smooth as possible and works easily on all smartphones/tablets, no matter if they boast PowerVRs, Vivante, Lima, Adreno, etc.)

Maybe we might need something along Acid test and w3c conformancy test to exercise drivers and test game code for standard non-compliance.
(That partly exist as "piglit" - the test suite that freedesktop.org uses to test opensource mesa and gallium drivers).