Brian's Brain

I'm still chewing on and otherwise digesting the information Google provided on Chrome O/S during last week's briefing, so stay tuned for the analysis I promised on Thursday. For now, I thought I'd share some initial impressions on the operating system's Vmware virtual machine image (which reportedly also runs on open-source VirtualBox) that I downloaded from Gdgt last weekend. Long-time readers already know that I've long been using Vmware Fusion to run Microsoft's Windows XP Professional on top of Apple's Mac OS X (initially 10.4, now 10.5). This experiment would not only give me the chance to try out a second virtualized operating system environment with Fusion but also to concurrently run dual virtualization environments and assess the resultant performance.

As you can see from the above screenshot, I succeeded, at least from a functional basis. If you'd like to follow in my footsteps, here are a few suggestions that'll get you past the speed bumps that I and others encountered:

• Make sure that your virtual machine's network adapter is set to 'bridged' mode, not 'NAT'
• You won't be able to open the VMDK file, either directly within Fusion or via the Finder, apparently because of the way it's formatted. Instead, create a new virtual machine (I specified an 'other' Linux 2.6.x operating system, which seemed to work fine) within Fusion, specifying that Fusion should use an existing virtual disk image file and subsequently selecting the VMDK that Gdgt compiled. I put the VMDK in the 'Documents/Virtual Machines' folder of my user account, where the existing Windows XP virtual machine was located. Note that even after Fusion converts the VMDK to its preferred format, you'll still need to keep the VMDK available for Fusion to access (i.e. don't delete the VMDK)
• As you can see above, the virtual machine is restricted to a 16-bit color, 640x480 pixel resolution graphics setting. This is reflective of the bigger-picture fact that Gdgt's VMDK isn't compatible with VMware's Tools, which also means there's also no robust mouse functionality, support for folder sharing between the guest and host operating system, etc. Not a big deal, at least at this limited stage in Chrome O/S's development.

Here are a few more snapshots obtained after I entered my Google account details at the above login screen:

From a user experience standpoint, Chrome O/S is for all intents and purposes a multi-tabbed Chrome browser, augmented with a few additional features such as a battery life meter and a time-and-date display. This is because the whole point is for Chrome O/S-fueled devices to access applications and data stored on Google's 'cloud' of servers, with only nominal offline capabilities by virtue of Google Gears (and consequently requiring scant solid-state storage and working memory within the device itself). Interestingly, Google didn't seem to even include the capability to shut down the operating system within this particular public build; instead, you need to manually shut down the guest within Fusion.

And how fast does it run? Not very, frankly, even though you can see from the smcFanControl display at the top of each screenshot that the CPU was working pretty hard (the usual measured temperature is 72 degrees C or less, combined with a ~2000 RPM system fan speed...6200 RPM is the maximum fan speed supported by the MacBook Air). Then again, though, my expectations were modest. Keep in mind that I'm:

• Running Chrome O/S virtualized...
• In conjunction with another virtualized operating system (not to mention a resource-hungry host operating system)...
• On hardware with modest CPU and DRAM resources]s...
• Which only allocates a single CPU core and 256 MBytes of RAM to the Chrome O/S virtual machine (along with a single CPU core and 1 GByte of RAM to the Windows XP Pro VM)
• And after all, it's an early release. Google isn't shy about pointing out that 'there is still a lot of work to do'.

'Bare metal' benchmarks of Chrome O/S against other Linux distros are underwhelming, too, but again you should consider such exercises intellectual curiosity-satisfiers at best. Google isn't promising Chrome O/S-based hardware from its partners until at least a year from now; the company's got a lot of time between now and then for both feature expansion and performance optimization.

Gdgt also offers for download a USB flash drive-bootable version of the Chrome O/S image it compiled, if you'd prefer to go that route. But I frankly don't recommend you try out the VMware image that showed up on Bittorrent a few hours before Gdgt's version was released. After all, as I described above, you need to enter your Google account details in order to log into the O/S. And call me cynical if you wish, but I don't have much trust in code that might come to me via the Pirate Bay, even if I (think I) know its source.

Please share your experiences with Google Chrome O/S, either virtualized or hardware-native, in the comments!