I'm getting ready to start another 30-day "The OS is Dead" trial in honor of the first look at ChromeOS (of course I'll do it with Chromium), and that means that I need to get Chromium in shape for the trip, which it's not by default. For my purposes, that means installing the following extensions:
Adblock+: You'll need to make sure that Chromium is fully updated for this one to work.
Facebook Enhancer: This extension pins the FB menu bar and side panel during scrolling.
Gmail Checker: This does the same for GMail instead of FB.
Google Bookmarks: This gives access to Google Bookmarks via a button.
Google Tasks: This creates a (hidden) task window on every page visited.
Jamendo Radio: This extension puts Jamendo at your fingertips. Unfortunately, it didn't work as installed and the links needed tweaking in the options.
Since I used the ZemantaFirefox plug-in for blogging, I needed to find something similar for Chrome. Zemanta's not the greatest, but it works with a feature set comparable to off-line clients. Luckily, Zemanta has a bookmarklet which causes the controls to load on supported pages. The system isn't automatic, but in my case, that's actually better since I can compose the whole post and load the components at the end, saving refreshing.
That's all I've done so far. I still need to find a video plug-in, I guess
First, you need to download a VMWare disk image (.vdmk). Here's a torrent file. Unpack the bz2 file to somewhere convenient. Next, open up Virtualbox (install), go to File > Virtual Media Manager and add the VDMK.
Either create a new appliance or add a second controller to an existing device. You'll need to change the network adapter to Intel Pro 1000 MT Desktop in order for the network to work.
Boot to the new hard drive and try ChromeOS out. There's not much to see, but it does launch fast, even in a VM.
Since ChromeOS requires Ubuntu to build the new operating system (and is based on it), I can't ignore it, can I? I may get fancy-schmancy and build it if an image doesn't come on-line in an hour or two.
About ChromeOS
Security
Open Development
Boot Speed
ChromeOS in Summary
The OS is Chrome, basically
All apps are web-based
There's no permanent local storage and everything is stored on the Internet
But thumb drives are supported
Local config and cache are encrypted
File browsing is done from within Chrome
Music and videos, too
There's no printing
The OS is self-repairing at boot, probably limiting the customization
But it's largely open source so you can customize and compile your own
"They want, wherever feasible, to build on existing components and tools from the open source community without unnecessary re-invention. This clear focus should benefit a wide variety of existing projects and we welcome it."[1]
D-Bus: The browser uses D-Bus to interact with the rest of the system. Examples of this include the battery meter and network picker.
Connection Manager: Provides a common API for interacting with the network devices, provides a DNS proxy, and manages network services for 3G, wireless, and ethernet.
WPA Supplicant: Used to connect to wireless networks.
Autoupdate: Our autoupdate daemon silently installs new system images.
Power Management: (ACPI on Intel) Handles power management events like closing the lid or pushing the power button.
xscreensaver: Handles screen locking when the machine is idle.
Standard Linux services: NTP, syslog, and cron.
Security Model
Process sandboxing
Mandatory access control implementation that limits resource, process, and kernel interactions
Control group device filtering and resource abuse constraint
Chrooting and process namespacing for reducing resource and cross-process attack surfaces
Media device interposition to reduce direct kernel interface access from Chromium browser and plugin processes
Toolchain hardening to limit exploit reliability and success
NX, ASLR, stack cookies, etc
Kernel hardening and configuration paring
Additional file system restrictions
Read-only root partition
tmpfs-based /tmp
User home directories that can't have executables, privileged executables, or device nodes
Longer term, additional system enhancements will be pursued, like driver sandboxing
How encryption works
In a nutshell, each user gets an encrypted image file in a hidden directory that is created at her first login. Thereafter, each time she logs in, the encrypted image is unlocked and made available for use. On logout or reboot, the user's data is locked away again. On some logouts, the encrypted image may be compacted. This step minimizes data loss due to file system fragmentation inside the image.