http://xkcd.com/908/
XKCD is always the best ;-)

They probably could have bought these patents but obviously they are not worth that much to them. So their competitors paid for these patents more than Google was ready to pay for it, hence, as far as Google was concerned their competitors paid more than the patents are worth.
Bidding round numbers is a bad idea, you will learn it quickly on eBay (or maybe not since 99% items now are BuyItNow stuff that is cheaper on DealExtreme anyway).

Since there is quite a bit of iron the the blood and it has magnetic properties.
Similar effects are used in Corvette's active suspension http://en.wikipedia.org/wiki/Active_suspension

I they are using soft token apps in addition to hardware keys they are trivial to duplicate if you can get ahold of the key string and password from an employee.

All they whine about in this article is that WebGL can use images from other domain as textures. That has nothing to do with GPU security, it is a feature and/or flaw in HTML5/WebGL which allows to use this image as a texture in the first place.

Yes I can. For instance in ATI r6xx it can only go to a surface defined by SX_MEMORY_EXPORT_BASE/SX_MEMORY_EXPORT_SIZE described on page 127 here http://www.x.org/docs/AMD/R6xx_3D_Registers.pdf
In addition to that system memory is mapped to GPU via GPU VM page table, so only pages that were allocated by the process and that the kernel driver mapped into VM graphic context. See /usr/src/linux/drivers/gpu/drm/radeon and grep for VM_
So there are two layers of hardware enforced protection in addition to software command buffer parser that checks the addresses. Safe enough for you?

First, WebGL sends shader source code to the browser and the code is compiled and executed in OpenGL. This is no different from running any other OpenGL program on your machine. The remote attacker cannot make the GPU execute arbitrary hardware instructions, only whatever source he sends.
The shaders pretty much execute in a sandbox (shader on GPU can only access buffers bound textures, vertex buffers, constant buffers, render targets etc etc). The access outside these buffers is not possible because the hardware enforces it (there is no way to even address outside texture or render target). It is little more complicated with compute shaders which have little more flexible addressing but they still cannot access anything outside global buffer (or OpenCL address space). It is like segment based protection in CPUs.

Latest GPUs have actual page table and VM, so on top of security protection from "segment" based addressing, there is also VM/page table based protection which only allows particular GPU context to access pages that have been allocated and mapped into it's VM.

The only real problem is a possibility of DOS attack caused by the fact that GPUs are not preemptable. Therefore if you send some complicated geometry or you write a shader that takes a very long time to execute (multiple nested loops+many pixels/vertices or compute threads) the draw can execute for a very long time. On Vista and later this will cause TDR and kill the trouble process. It happens all the time if you develop games or GPU compute apps. The only way to disable the watchdog is with a registry setting. On XP the watchdogs are implemented in the kernel part of graphic driver (ATI VPU Recover, and whatever nVidia has).
This DOS is a little more problem in Linux since it doesn't have good watchdogs, the DOS should not crash X, but it will definitely lock the UI. Also, if you will bother to take look at the shader docs for AMD http://www.x.org/docs/AMD/r600isa.pdf you will see that the instruction set does not allow for truly infinite shaders, there are no arbitrary jumps, the loops cannot run forever (max loop count is 2^31), the flow control is only structured and easily verifiable. It is different for nVidia ISA which looks more like regular CPU and I think can do infinite loops.

On the upside Linux DRM drivers in kernel have pretty good command buffer parsers and validators, so it is hard for user-space driver to access memory that doesn't belong to it. On Vista and later the user-space driver doesn't even know GPU side addresses of its allocations and sends every render buffer with an allocation and patch list which is resolved and patched by VidMM and kernel mode driver, see D3DKMTRender function etc http://msdn.microsoft.com/en-us/library/ff547145%28v=vs.85%29.aspx

but then they wouldn't know where you are.
I bet this "electronic device" will also report your location in realtime to the government for "bookkeeping".

Desire HD maybe, but Inspire 4G (same thing for ATT, little different radio) is locked shut. The process of unlocking it is long as well (downgrade to Desire HD ROM, and then exploting DHD radio).

everyone selling the bulbs as heaters or for "industrial use".

I have bought collector's edition when it came out only because they promised a Linux port.
So fuck you Sweeney.
BTW, it sucked big time, UT3 is a lagfest.

Why does Goofle need two operating systems?
I just don't see the appeal.
Android makes some sense (save for Java, which fortunately came to bite Goofle in the ass, so maybe it will teach them something). It works, it runs on mobile devices and can scale to bigger machines and runs crap integrated with Goofle cloud.
At least Goofle is not afraid to kill products (see Wave). So maybe they will get rid of it.

I think cloud gaming sucks so if there will be only one company doing it for next 17 years, it's for the better.

are texting like crazy and their thumbs are getting red and bleeding in the vain attempt to have 3x more chance to have sex. They all forget that 3 * 0 = 0.

return their 16M IPv4 addresses, just look at the map
http://xkcd.com/195/
HP, DEC, Ford, Xerox, Bell Labs, Apple, MIT, USPS, DuPont, IBM, General Electric, Boeing, Prudential, Eli Lily, Halliburton.
Why does plane, car, drug or chemical manufacturer or an insurance company need 16M publicly routable IP addresses?
I guess HP has now all the DEC IPs, so they have 32M, WTF!