Reply to post: Re: Absolute tosh!

Re: Absolute tosh!

@Charles,

IOW, caching is basically a case of "Ye cannae fight physics," hitting a hard limit with the Speed of Electricity.

I think we can do a little better than the DRAM that's currently used. HP's memristor is (apparently) faster than DRAM. As well as being non-volatile and with no wear life problems and huge capacities. So a SIMM based on that would be quicker. But still not quick enough to eliminate the need for a cache.

As things are today it's kinda nuts; the signalling rate down those PCB traces is so fast that they're RF transmission lines, and there's more than 1 bit on the trace at any one time! It was the Cell processor in the PS3 that first used that style of RAM connection. Sigh - I miss the Cell; 100GByte/sec main memory interface. It was one helluva chip.

Unless, of course, latency comes into play. Why do you think network computing has such limited use outside the controlled environment of LANs? Because the Internet is itself an untrusted, unreliable environment. You're simply trading one set of disadvantages for another.

Not really. We already have an elaborate certification system to establish that the website I'm getting data from is in fact the website it says it is. All I'm talking about is changing the data that's recevied. At present it's a blend of html, javascript, css, etc. That's not a problem if it comes from a website we trust, but the javascript is potentially disasterous if it comes from a malicious website. However, if what my "browser" received were simply a remote display protocol then I don't care what the website is showing me, it cannot (assuming the protocol implementation is good) run arbitrary code on my machine. There would be no such thing as a malicious site, because there would be no mechanism by which any site could launch arbitrary code on a client's machine.

I suppose I have to trust the site to run the code they've said they will. But I do that anyway today; for example I trust Google to send me the correct Javascript for what is to be done.

As for reliability - services like Google Docs are all about the Internet and Google's computers being reliable (or at least they're supposed to be).

And for many, the reason the code MUST run client-side is because you need the speed you cannot get other than from a locally-run machine. Ask any gamer.

That's true enough; a game that runs in a browser is better off running client side instead of server side. I suppose I'd counter that line of argument by asking what's wrong with a proper piece of installable software instead (I know, I know; web, write once run anywhere, etc etc).

But for the majority of what most of us do with the web I dare say that we'd not notice the difference. Furthermore the monstrous size of the pages some websites dish up these days is ridiculous (www.telegraph.co.uk is appallingly bloaty). We really would be better off getting a remote display data stream instead; it'd be less data to download.

As far as I can tell there is no real disadvantage for the client in having server side execution viewed with some sort of remote display protocol (unless it's a game), and only positive benefits. The server's worse off though; instead of just dishing out a megabyte or so of html/javascript/css/images, it'd have to actually run the darn stuff itself. That would take considerably more electrical power than the likes of Google, Amazon, consume today. The economic model of a lot of today's "free" services would be ruined.

I think that it's unfortunate that the companies that would lose a lot by such a massive change (Google, Facebook, etc) are also those with a lot of influence over the web technologies themselves (especially Chrome from Google). Instead of getting web technologies that are better for clients, they're in a position to ensure that we keep using technologies that are better for themselves. That's not so good in my view.

Interestingly I've been taking a close look at PCoIP a lot recently. One of the directions Teradici seem to be headed is that you use that protocol to view a desktop hosted on AWS. That's not so far away from the model I've outlined above...