The Chrome OS Answer to Native Apps: Remote Control

The Register has an exclusive story based on a public email from Google engineer, Gary Kačmarčík, and some follow up correspondence. The capability will be called “Chromoting” (which right there has my inner skeptic squinting his eyes at that name) and there are few details beyond that. Kačmarčík did compare the feature to something like RDP or VNC but executed from within the Chrome browser. The requirement of an additional machine running a traditional OS seems kind of a steep cost for someone in the market for a netbook, the intended target device of Chrome OS.

I suppose Google’s view is that netbooks are accessories not entirely independent computers. It isn’t too far different from the dependency inherent in the non-“legacy” applications Chrome OS will support, that is to say web applications that will require either a persistent connection or savvy developers to make use of newer web APIs for offline applications.

I suspect that the remote application feature will function something like the transparent mode most desktop virtualization tools provide. That is, rather than getting a typical RDP or VNC session which is a single window with the entire remote desktop, this capability will make it appear that only a single application is being remoted. That wouldn’t be too far of with can be done with a pair of X servers which you can run on Windows and Mac OSX as well as Linux and Unix systems. I suspect the first hackers to get their hands on a build with this feature will be able to sniff out the remote communications and tell us if it is indeed a frame buffer type tool, like VNC or RDP, or something more akin to XDMCP.

9 Replies to “The Chrome OS Answer to Native Apps: Remote Control”

  1. It seems to me that the ship has sailed and Google should fold the Chrome OS resources into Android. When they first announced Chrome OS I thought it was redundant to Android. I finally “got it”, and could accept the differences as making sense but I still think it’s unnecessary — especially now that the global mind-share is shifting away from netbooks and is squarely on tablets thanks to Apple.

    1. I don’t disagree but would add one qualification. Android should replace Chrome OS once an officially supported native API/SDK is released. (Apologies if such a thing already exists, I do not yet posses an Android based pretty.)

    2. I don’t get this objection that I often read that Google should not be working on two OSes, one for desktop one for mobile. Apple has two OSes, one for desktop one for mobile. They’re distinctly different and despite sharing an underlying architecture they are incompatible with each other at a user level. Microsoft does exactly the same thing.

      How can this ‘one OS for all’ advice approach anything resembling wisdom when it appears to only apply to Google?

      Desktop and mobile OSes have very different requirements and it makes a lot of engineering sense to develop them along separate tracks, as every company that has ever tackled both have shown before. Google’s a behemoth but the logistical requirements of software architecture don’t explode in its vicinity, they affect and distort development tracks with the same force as for every other human beings, thus severing development teams for substantially different goals remains the most prudent approach.

      The fact that Chrome OS is not getting a lot of cheers or adoption is an entirely separate issue unrelated to whether it is integrated with Android. If they were doing enough things right the separation wouldn’t matter, in fact it would be a plus.

      1. Ah, but Google hasn’t said Chrome OS is targeted at desktops or even laptops. They are specifically saying netbooks. That is where I agree with critics, specifically, I think Android should be enough for a netbook, as a mobile device. I think that follows the division you lay out amongst Apple’s and Microsoft’s different classes of OSes.

        The heart of my own view is not that Android should be Google’s one OS to rule them all. As you imply, my concerns are more around the notion of an OS that is little more than a browser, no matter how capable or blazingly fast, strapped to a kernel and precious little else.

        If they start suggesting Chrome OS for more capable laptops and desktops, then, yes, my criticism shifts to it being a waste of horsepower.

        1. Isn’t it actually quite likely that it will shift to laptops and then desktops (for whatever the latter are still worth in the market, at the time)? Good point on the netbooks. Something tells me though that they are only the beginning, and in that case I prefer a netbook interface more closely allied with its bigger brothers than with cel phones. Granted that puts me technically on the wrong side of the mobile line I drew myself, but I just drew that line wrong, is all. Really it’s the more handheld interface and the carrier/music industry business relationsihips that seem to be key indicators of different OS architectures.

      2. I agree with what you are saying and want to echo Thomas’ thoughts: my issue is that Chrome OS and Android OS are both “mobile” OSes. They are taking different approaches which can yield interesting results, but I think it’s counter-productive. It seems that Chrome OS was banking on the explosion of netbooks to continue, but iPad stopped them cold.

        I could see Chrome OS being used portably on a USB stick — boot it up on my work machine or at an Internet cafe to continue work I was doing at home — but I think there is a limited demand for that. And the people that DO demand that are already using Puppy or DSL.

        For a desktop — or a netbook — I’ve been impressed with Chrome browser on Ubuntu. The netbook remix has phenomenal performance. It boots to desktop in under 20 seconds and when I log into my Google accounts via SSL, I don’t see what a Chrome OS would do for me that I’m not already getting.

    1. Not that SDK and API. That’s for Java-ish code running on the Dalvik VM. However, I spotted what I was after in the sidebar of those links–the NDK, the Native Development Kit.

      http://developer.android.com/sdk/ndk/index.html

      So that answers my question, performance critical code can today be written in native code rather than having to run on top of Dalvik. I do believe Dalvik just got JIT, though, so the performance should be perkier than before its addition.

      1. Ah, gotcha –

        and yes, Android 2.2 includes Dalvik JIT and people are reporting real world 4x to 5x increases in performance. Sadly, I don’t think 2.2. will ever come to my now “ancient” G1 device. But my contract with T-Mobile is up in October and I have my eye on the Droid Incredible.

Leave a Reply

Your email address will not be published. Required fields are marked *