...that also implements these up-coming standards

That means FireFox (which can already run several Chrome web-apps/browser games) and probably Opera.
But probably not Internet Explorer, at least not until they realise they've been left out and need to quickly add support for what everyone else is doing, even if it means more portability and less vendor lock-in.

For a given query:

- the technology which brings the most relevant web page, from the whole web
and
- the technology which brings the most relevant ad from all advertisers

are basically the same.

They *ARE* a search company. They just apply the search technology on web pages to attract users and on ads to get the money.
Same technology, applied on 2 different targets, for 2 different steps in the process of getting money.

And some Dell Lattitude even had a separate low power CPU for that task.

Power up the ARM and boot into the in-BIOS Linux for basic web etc.
Power up the Intel and boot into the full installed OS (windows or whatever) for a full environment (but power hungry)

Yeah if it's a part of one single product you've bought.

The trouble in this case is that it's 2 separate products (a laptop and an operating system) done by 2 separate companies (lenovo and microsoft) and which are bundled together, with a complex EULA and other legal paper binding the whole together.

openSUSE is also featuring KDE as their preferred desktop (although Gnome and others are supported too). And is a little bit easier to use and less prone to breakage than Debian Sid.

Not to minimize the intern's work, but it also shows that some of the iDevice work was also leveraged and recycled.

The GUI might be completely separate between iOS and OS X, but from what I've heard, some code is shared between the lower components of the OSes.
(The kernel is supposed to be the same, for example). So work for some of the component of Mac OS X has already been partly done.

Maybe in the ultra-low end market, like smartphones and tablet. The PowerVR deffered tiled rendering architecture has been king on the ultra-low spec for ages.

But Nvidia might be targeting something bigger. Like light-wieght laptops. Device which might require a little bit more graphical power than what can be delivered by a PowerVR or a Tegra, while still benefiting from the massively reduced power consomation that an ARM can provide. (when couple with an SSD and other such low-power components).
(Some DELL Latitude did feature a hybrid ARM/x86 architecture. Same screen, same keyboard. You could either boot into x86 and run a full scale Windows. Or boot into the ARM and run an embed Linux. The ARM/Linux had an impressively better battery life. Okay that came also because the ARM mode didn't power up the harddrive nor the discrete graphic card nor the USB ports).

One could easily imagine a dual-GPU solution, with a Denver containing the next gen Tegra, for when an absolutely low power is needed, and a discrete low-end/low-power GeForce for when the netbook is plugged and needs more graphical omph.
(Somewhat like the current OPTIMUS switching mode between the embed intel graphics and the discrete GPU depending on demand. Excet that a Denver project could bring much longer battery life while in low-power mode, while the discrete GPU could give better performance than a PowerVR, smartphone oriented SoC).

There's a completely separate project which tries to bring support for video acceleration and video APIs on the Gallium3D.

Now, these efforts are using the Gallium3D stack. That means that the video is getting decoded by the 3D hardware (by code running on the shader/kernel processors) and not by the separate video hardware that some chip feature.

(In AMD's case that means that the decoding is done by the same units which does OpenGL/OpenCL and not by the UVD).

Well, of course. AMD does publish documentation and put ressources behind the opensource development. NVidia doesn't.

For Nvidia cards, reverse-engineering is needed. So support will depend mostly on what the developper community has under their hand and can experiment the most with.
Too old cards aren't used so much any more, and thus there isn't as much experimentaiton going on them.
Too new cards haven't been around enough for enough reverse engineering to happen, so you won't see much support for them before a couple of year.

Putting OpenCL in there doesn't divert that much ressources from Nouveau. Gallium3D is very modular (that's the main reason it's popular in the open source).
You just have back-end exporting hardware functionnality on one hand, and front-end supporting various API on the other hand.
You could in theory just freely slap any front-end on any back-end (and it's mostly that way in reality, hence the popularity of Gallium3D).

So bringing OpenCL to Nouveau boils down to :
- efforts in impoving the OpenCL state tracker until it can support enough of the OpenCL API. These are efforts done be people external to the Nouveau project. (Mostly the initial Clover project, then Google Summer of Code, etc.) And these are efforts done (mostly) independently of the back-end used (a lot is done on the CPU backends like LLVMpipe, but could also be used on Nouveau, AMD's R600g or the Gallium drivers for Intel developped by Google).
- efforts to bring enough of the hardware functionnality into the Nouveau back-end. These are efforts done by the Nouveau team. But some of these effort benefit also the 3D API or any other front-end running on Gallium3D (in theory, even the Gallium3D powered DirectX 10/11 front-end could partly benefit of these efforts).

That's also why OpenCL has been so quickly added to Nouveau: because it's cheap. OpenCL is mostly done (unlike OpenGL which is only currently achieving OpenGL 3.0 support in Mesa 8.0, whereas the current OpenGL implementation is 4.2 - so several versions behind). And GPGPU is mostly only uploading code to run on the chip (lots of functionnality which is used for 3D is not used for GPGPU), so as long as the the few OpenCL specific hardwaare functionnality is supported, OpenCL is ready to go.

For an up-to-date 3D support, there's still a lot of work to go into the Gallium OpenGL state tracker so it supports all the API and functionnality necessary for OpenGL 4.2. And there's still lot of hardware functionnality that needs to be done in Nouveau. Which is, again done entirely by reverse engineering and without an help from NVidia.
So, still a lot to go before having good 3D support.

At least, AMD is giving out documentation and paying a few developpers, and overall trying to guarantee some opensource support in parallel to their closed source catalyst.
And Intel and Google are actively developping opensource drivers as their main hardware support for Intel chipsets (with Intel developping classic Mesa and Google making Gallium3D drivers).

Base won't be a problem, no more than today, when computer count in base 2, most people count in base 10, ans some people count using weird combination (mixed base 20 celtic influence, mixed base 5 with roman, base 12, base 60 in summeria, etc...)

A prime number is a prime number, no matter what crazy writing system you use to write it down. Base systems are just that, encoding ways used to write down abstract number.

To go back to the parent exemple:
base will only start to play a role when we send graphical representation of equation, as in written down in picture form.
once we send "5 + 7 = 12", not as a bip sequence, but as a nice bip-encoded picture. In addition to learning the strange symbols we use to write number, the alien will notice that for some crazy reason, we start to use 2 symbols for anything bigger than a number of 9.
If they count in base 20, they'll probably reply something along the line of "5 + 7 = B", with "5", "7", "B", "+" and "=" replaced with their own local way to represent the concepts, ordered in their preferred way to order their symbols (prefix notation? opposite endianness? etc).

That's why math is regularily proposed as a "first common language", a numbre is always the same numbre, no matter what crazy writting system you use to write it down.

Some civilisations have used 20, because that's the total number of fingers+toes.
Some civilisations have used 5, because that's the number of finger on 1 hand.
Some civilisations have used 12, because that's the number of phallanx (finger bones) on the 4 long fingers, and because it is nicely divided by 3 and 4.
Some civilisations have used 60, because it's pretty much easy to divide by quite an impressive number of divisor.
Our civilisations use 2 for computers, because a simple representation between "signal" and "no signal" is the easiest to implement. ...
But you just need to convert value from one system to the other. The maths behind remain the same.