Does Chrome OS's Linux virtual machine support help its apps close the gap on macOS or Windows equivalents? Let's find out.
As part of my ongoing quest to assess the feasibility of alternative (i.e. non-Windows or –macOS-based) computing platforms, regular readers may remember that I’ve so far published two posts on my experiences using a Chrome OS-based Google Pixelbook (its predecessor, a Toshiba Chromebook 2 2014 edition, still doesn’t have long-promised Android support, by the way … and if you’d like to follow in my footsteps, Pixelbook refurbs are on sale at Best Buy). In my most recent writeup, I discussed how the ability to run Android apps on top of Chrome OS significantly enhanced its viability as a mainstream operating system alternative. However, I also commented “these are [Android] apps originally intended for use on comparatively resource-poor smartphones and tablets.” While they may have “light memory and CPU horsepower demands (versus, say, a full-blown macOS or Windows app equivalent),” this means that they also tend to be feature-deficient compared to a full-blown macOS or Windows app equivalent.
As a result, I’ve expanded my testing to include the Linux virtual machine (referred to by Google as the Crostini project) that was added to Chrome OS’s stable channel beginning with version 69. Of particular help here was an article published on Android Police written by Corbin Davenport; I more broadly commend the entire series to your attention. Note that this is a Linux virtual machine running on top of Chrome OS (also based on Linux … but I digress), not a native Linux boot, therefore with requisite performance impacts, incomplete and otherwise imperfect hardware support, and other shortcomings. A previous open-source approach to running Linux on Chrome OS, called Crouton, leverages the chroot command and is still available, but for perhaps obvious reasons the “official” Google-developed Linux support in Chrome OS 69 and beyond gets my nod.
Step one is to “turn on” Linux support in the Chrome OS settings:
And here’s how to subsequently uninstall the Linux VM (in the process removing all Linux applications that you’ve subsequently also installed):
As you see, the primary user interface to the foundation Linux virtual machine is command line (terminal)-based, although GUI-based Linux applications are supported.
Speaking of which, and following Corbin Davenport’s instructions, here’s what it looks like to install the powerful image editor GIMP (the GNU Image Manipulation Program) via Flatpak:
Microsoft Office suite competitor LibreOffice:
And BitTorrent client Transmission:
Here they all are in Chrome OS’s app launcher, post-installation and prior to me doing icon re-ordering and grouping into folders (you’ll have to take my word that they all ran fine; I didn’t snag even more screenshots to prove the point):
The current Linux virtual machine implementation is imperfect in several notable respects, all of which Google is working on improving:
For one thing, since Linux and its apps are “sandboxed,” all associated data and other files reside in a unique “Linux files” area:
Linux can’t “see” the remainder of the Chrome OS directory structure; in order for it to be able to access a particular file, you must move it to “Linux files” using Chrome OS’s file manager. Also, Linux apps only support elementary audio playback (through Chrome OS), not fuller-featured audio capture and manipulation … which is why for now I’ve not bothered installing Audacity. And finally, GPU acceleration support is currently not available, which is an obvious bummer for computer gamers but also likely puts a serious damper on performance when doing still and video image editing, for example.
I had one more application that I wanted to install, this one Windows-based, actually. And believe me, I’m more than a bit embarrassed to tell you about it. I’m … umm … still doing my personal finances on an ancient copy of Quicken 2003 Basic. Right now, I run it on macOS using Wine as an intermediary compatibility layer. Wine also runs on Linux, but Corbin Davenport (along with others, per my research) warned me away from installing it on Chrome OS’s Linux virtual machine for now. Instead, I tried out CrossOver Chrome OS, a commercial (i.e. paid) version of Wine developed by CodeWeavers and available in the Google Play store. Yes, you’ve got that right … a Windows app on top of an Android virtualization layer on top of Chrome OS. Does your brain hurt yet?
I’d previously copied the Quicken install CD to a USB flash drive, whose contents I then copied to the Pixelbook SSD:
Installation of the initial Release R1 of Quicken 2003 Basic went smoothly:
It was at this point that I ran into a glitch. Given its geriatric nature, Quicken 2003 Basic doesn’t update itself over the Internet (to Release R3 in this particular case); instead, you run a separate executable to patch and otherwise upgrade it. When I did so, CrossOver Chrome OS threw a weird “not enough free space” error message, leaving me stuck at Release R1.
Conversely, this screenshot shows that I was able to update Quicken 2003 Basic to Release R3 just fine on Wine running on macOS:
I’m therefore guessing that, given CrossOver Chrome OS’s Wine foundation, this glitch will be easily solved once I make CodeWeavers aware of it.
As previously mentioned, Google has already publicly committed to making the experience of running both Android and Linux applications on Chrome OS ever more seamless and otherwise robust; evidence of ongoing progress is already evident in the developer and beta Chrome OS channel builds. Equally intriguing to me is Google’s ongoing progress in making the Pixelbook and other Chrome OS-tailored hardware dual boot-capable via an “alt OS mode” code-named “Campfire.” Such a mode would, for example, allow for full native (versus today’s virtualized) support for Linux running on Chrome OS hardware. But far more importantly for widespread impact, “Campfire” also opens the door to natively running Windows 10 on the Pixelbook and its hardware siblings.
Going forward, I’ll continue my Chrome OS testing, of course, and I’ll periodically report back here at the blog as I come across notable developments (my Pixelbook is sitting next to me, updating from Chrome OS 70 to 71 on the release channel as I type this, in fact). Until my next post in this series, I as-always welcome your thoughts in the comments.
—Brian Dipert is Editor-in-Chief of the Embedded Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.