I'm no expert; but my off-the-cuff assumption would be that it could be made quite fast:

At least with Debian and derivatives, you have a locally stored cache of package data(not the packages themselves, but their metadata). Searching that is pretty fast unless you have a lot of repositories or a brutally slow storage system.

The obvious(and probably flawed in some less obvious way that I'm not thinking through) extension would be to add the VID/PID combinations (or device classes, for class drivers) to which a driver package applies to the existing metadata about the package. You might also have a 'driver package vs. 'non-driver package' distinction to reduce the search space). During the hotplug process, if nothing suitable is already available, apt-cache search for the VID/PID pair would be run, and a match downloaded, if available(the amount of security prompting would obviously be a matter of configuration: sometimes it would be desireable that admin authorization always be required, sometimes it would be better if downloads from already-blessed repositories are acceptable, depends on the use case).

The local search would be reasonably fast, barring very slow storage, the download and install obviously depending on the size of the driver and the speed of the connection. In the not-terribly-valuable opinion of a layman, it seems like it could be reasonably quick.

This wouldn't be the kernel's problem; but it might be kind of neat to make the package manager aware of the hotplug process; in order to allow largely automated hunting of the repositories for the appropriate modules for a newly inserted device; but the amount of space saved may just not be enough to be worth the trouble. It'd arguably be more elegant than preloading more or less everything, or having the user grovel around with VID/PID combinations looking for helpful advice on Google; but storage tends to be cheaper than any human labor you'd want touching important software...

In addition to being cool stuff, mercury also has a very long history of use in gold extraction. I don't know about the people who built this particular structure; but mercury-amalgamation gold extraction is known to have been in use in South America well before the Spanish showed up. Given the human enthusiasm for gold, that's another point in mercury's favor as a funerary good, along with being weird and cool looking.

(Large scale extraction is now usually done by cyanide leaching, since that's somewhat less nasty than mercury amalgamation; but small scale miners often still use mercury. As one might imagine, the 'now heat the amalgam with a blowtorch to drive off the mercury and recover the gold' step is about as good for you as it sounds, possibly worse.)

They've been trying(in part by developing, in part by buying, they ate Softlayer and Cloudant fairly recently); but they've been finding it a bit tricky.

IBM wants to sell you some sort of unique, value-added, hardware and/or software feature that makes going with them worth it over going with the commodity product(presumably, this is why they sold of PCs and low-end servers). Some customers do want this; but it's a very, very, different offering from the more commodified cloud providers(Amazon, Google, and Microsoft all differ a bit in where they are on the spectrum from 'what you do with them is your problem; but our VMs are cheaper than you can believe' to 'we can provide automagic email accounts and SQL server instances abstracted from the host OS'; but all of them are very much on the 'we aren't going to hold your hand; but look at how cheap this stuff is' side, an area where IBM has no obvious advantages.)

The one other element in the cycle you identify is arguably 'management/administration'.

This can work both for and against both local and remote/cloud options: Back when anything that touched the mainframe needed 6 signatures and a blessing; but you could classify an IBM-compatible as an 'office supply' and just have it on your desk and doing stuff, part of the virtue was in cutting through red tape, not in enjoying DOS on a slow machine with virtually no RAM. These days, especially for individuals or small outfits, without technical expertise available, 'the cloud' wins not so much because local computers are expensive(since they aren't, they've never been cheaper, either absolutely or per unit power); but because 'the cloud' is something you can use just by plugging in a URL and following directions. IT geeks are correct to point out that 'the cloud' is neither impregnable nor as well-backed-up as it likes to pretend to be; but for a non-techie user who will lose all their data as soon as their HDD dies or they lose their phone, it's still a step up.

For larger outfits, who have technical expertise available(and whose needs are complex enough that they will need IT and/or developers whether they go 'cloud', local, or some combination of the two), it is much more a straight battle on cost, security, and reliability; but ease of use and ease(or nonexistence) of management is huge for the consumer side.

Amazon is a bit tepid when they try anything too novel(their phone went from flagship pricing to free-after-contract how fast?); but they have three basic virtues that make them a terrifying force to be reckoned with:

1. Cultural disinhibition: They started selling books; but never seemed to have fossilized into the 'We are a bookstore. I can see maybe expanding into selling some bookmarks, or paperweights; but hand tools? How absurd!' model. 'Books' was merely a special case of more or less rectangular objects that are legal to send through the mail. They've since expanded into an ever larger collection of more or less rectangular objects that are legal to send through the mail, without much concern about what they are.

2. Adequately competent implementation: Remember 'Microsoft PlaysForSure', the killer ecosystem of hardware, software, and a competitive marketplace of music sellers(almost always cheaper than iTunes)? No? That's not very surprising, they don't really deserve to be remembered. How about 'Ultraviolet', the 'cloud-based digital rights library' that is somehow associated with blu-ray, some media players and streamers, and various retailers; but is so dysfunctional that I can't actually summarize exactly what the hell it is? No? I can't imagine why.

Amazon, though, while they don't lead the pack, knows how to get the job done well enough (their Kindle e-readers and 'FireOS' tablets all have at least adequate industrial design and build quality, and 'FireOS' is arguably nicer than some Google-blessed-but-vendor-skinned versions of Android, despite being a hostile fork; and their media-streamer hardware and software are both more or less painless). You don't necessarily go to them for the premium gear; but they are definitely good enough that they don't actively sabotage the appeal of the low prices.

3. Logistics. I don't know how they do it(if I did, I'd probably be a whole hell of a lot wealthier); but when they decide to sell something, they know how to make it impressively cheap compared to the competition, whether it be books or VM time.

On the very small plus side, perhaps this will make using Ireland as the tax dodge for your tech company slightly less convenient. Otherwise, isn't this the same country that decided that outlawing blasphemy would be a cool idea in 2009? There may be a screw or two loose.

What is damned annoying is that 'Gatekeeper' can be turned off; but as of 10.10, it will turn itself back on after a period of time. iOSX seems likely in the near future.

I can only comment on SRPs as they currently exist; but as of now the only real pain is vendors who don't sign anything. Self-signed or untrusted roots throw up scary warning by default; but you can add those to the trusted list if you wish. Legacy software is a giant pain in the ass, since most of it predates the custom of signing much of anything by default; but newer stuff generally isn't so bad. If necessary, you bless the vendor's cert and that takes care of it. You can also (again, with the present implementation of SRPs) bless binaries by hash, rather than by signature, which is frequently easier if you need to do once-offs.

TFA is a little vague; but if it is implemented the way that Software Restriction Policies currently are; I'd be all for it(and I say that as a smirking, linux using, tinfoil-hatted paranoiac.)

Cryptographic verification and whitelisting are enormously powerful techniques, and (aside from being able to take advantage of them), they are simply too useful to forbid successfully. What matters, and makes the difference between a fortress and a prison, is who gets to put something on the whitelist.

If you can whitelist something(either by signing it yourself, adding the cert of the person who signed it to the trusted list or both), it's a fortress. If the whitelist is what the vendor says it is, it's a prison. Same deal with 'secure boot'. If I can re-key it, it's a valuable tool. If I can't, it's a device that I'll never be more than a peon on.

Unfortunately, the general lack of DRM(wouldn't even have to be effective DRM, just going through the motions) is pretty much the only thing that keeps a DVD-like arrangment from enjoying force of law anywhere with a DMCA-style law on the books.

Copyright tends to be a little awkward around computers; because there is so much copying that has to occur internally just to display something; but the analogy between running adblock and taking scissors to a magazine is a pretty easy one, and the right of the end user to mangle up an article, even a copyrighted one, however it amuses them is pretty well established.

If, though, even the most pitiful DRM were on the table, you'd be right were DVDs are: you need an illegal circumvention device to watch them without an authorized CSS decryptor; but you can only get an authorized one by agreeing to certain conditions, which include enforcing the unskippable flags, region codes, etc.

Does this not count?

Doesn't google maps do stuff when you zoom in close enough to trigger 'street view' that was only ever implemented in Flash on the desktop, and would need either Flash or some fairly aggressive WebGL to do without fairly brutal strain on the limited resources of a mobile device(sure, in theory, a canvas element and javascript can manage any graphical task; but Not Very Fast, for 3d type tasks).

EXTERMINATE!!!

I'd be the first to agree that using javascript and canvas as the world's least efficient framebuffer is dumb as hell; and that there are viable use cases for 'apps'; but the pox of 'apps' that are little more than skins around websites must be put to the flame. Mobile browsers don't exactly clutter up the edges of the screen with a lot of cruft, so you have the same amount of screen space either way. You'd better have a very good reason for having a separate app for the purpose...

'Mobile' as in 'WAP' or whatever is as dead as dead can be; but there are definitely styles that look better on teeny little(but frequently high resolution) screens, and other styles that are effectively unreadable.

Oddly, wikipedia is dinged in TFS as not having a mobile-friendly version; but I've found theirs to be among the more tasteful entries in the genre....