ChromeOS Flex: The Flexibility and Complexity of Linux Apps

Once you’re up and running with ChromeOS Flex–or just straight-up ChromeOS, of course–it’s time to take the next steps. That means discovering where this system meets your needs and where it falls short. Basically, it’s all about apps and services.

I’ve used ChromeOS enough to know that it can meet my needs for the most part. Indeed, I use ChromeOS, more often than you may believe, usually via a terrific year-old HP Dragonfly Pro Chromebook that’s been upgraded to Chromebook Plus status with the release of that platform upgrade. But most recently with the PC-installable ChromeOS Flex I’m now experimenting with. With the right hardware–again, a ChromeOS Flex-certified laptop is key here–the experiences are very similar.

That said, there is one important difference from an app compatibility perspective, as noted previously. ChromeOS Flex doesn’t support Android apps and the Google Play ecosystem. This doesn’t impact me that much, as I use only a few Android apps on ChromeOS, and none are critical, so I don’t miss them here.

What ChromeOS Flex does support, of course, is Chrome and web apps, and Linux apps via the ChromeOS Linux development environment. Like Android app support, this is a double-edged sword in that it adds functionality that’s so crucial that it may put ChromeOS/ChromeOS Flex over the top for you, while also adding complexity that can somewhat undermine the simplicity that makes this platform so appealing.

And that’s a big discussion. So big, in fact, that I pulled it out of this article and will publish something separately about simplicity and power users, and how truly elegant platforms offer both and are more desirable for it. For now, I will instead examine how Linux impacts the ChromeOS Flex (and normal ChromeOS) user experience, and why I need it to even consider using this platform.

From a platform perspective, my switch to Google Drive in late 2023 removed one of my previous major blockers to using ChromeOS (or Flex). Google Drive is as integrated with the ChromeOS Files app as OneDrive is with File Explorer in Windows. And it offers roughly identical functionality: I can browse all of my cloud-based file system from this app, selectively sync folders and files so that they’re available offline, and seamlessly access it all from apps for file open/save. That’s a happy coincidence, but it makes a big difference.

From a web app perspective, ChromeOS Flex gives me a good chunk of the functionality I rely on every day, from basic web browsing (in this case using Google Chrome, of course, but combined with key extensions to protect my privacy), to email and calendar (I use Gmail and Google Calendar on the web everywhere), social media (Twitter, Threads, Mastodon, etc.), and a growing selection of web apps.

For example, I use what seem like native versions of Notion, Clipchamp, and some other apps. But these apps are really web apps, even on Windows, and they work just fine in ChromeOS. I’ve pinned both to the ChromeOS Shelf–its Taskbar–as apps, just as I do in Windows.

But there are apps I rely on that are not available in web app form, of course. And here I need to be a bit more flexible. Even moving between Mac and Windows, I make certain adjustments because some apps are better on one platform than the other–for example, I write with iA Writer on the Mac, but prefer LibreOffice Writer, a Microsoft Word clone, on Windows because iA Writer is lacking on Windows–but ChromeOS introduces an additional consideration. I can use a web app alternative–Photopea or Pixlr Suite instead of Affinity Photo or Adobe Photoshop Elements, perhaps. Or I can turn to Linux if an app I want can be found there.

I do a bit of both.

On the Linux end, the first step is to install the ChromeOS Linux development environment in Settings. This is a quick and easy process in which you specify a username and the disk size for its underlying virtual machine (VM), and then let it do its thing.

When it’s done–it only takes a few minutes–you’re dumped into a Terminal command line window and left to your own devices.

I use Linux for three apps, two of which are related to writing and two of which are related specifically to my book work: Typora (a user-friendly Markdown editor). Visual Studio Code, and Git. My goal is to eliminate each if possible with web app equivalents. This isn’t far-fetched: There are plenty of decent web-based Markdown editors, and a Visual Studio Code web app already exists. As for Git, that I’m not sure of. But for now, these things work well in Linux app form in ChromeOS and meet my needs. Albeit with a bit of complexity.

The Linux development environment in ChromeOS is based on Debian. It’s important to know that because the Linux versions of apps, when they exist, will come in at least a few different versions, ChromeOS users will need to download the Debian version.

Anyway, with Linux up and running, I used Chrome to download the two standalone apps, Typora and Visual Studio Code, from their respective websites. As with Windows, downloads go to your user account’s Downloads folder by default and, as with Windows, you can just double-click the installer executables (which in this case are .deb files) to install them. ChromeOS puts up an “Install app with Linux” window when you do this, so it’s as user-friendly as it can be.

In Windows 11, I install Git and then configure and use it using from the (PowerShell) command line in that platform’s Terminal app. But this step is unnecessary here: Because the Linux environment in ChromeOS is designed for developers, Git is built-in. So all I had to do was authenticate against my GitHub account, as I do in Windows. And then clone one of repositories locally. There’s some humor to this because the repositories I need to clone are for my books. So they are, ahem, book repositories. (As opposed to book depositories. Moving on.)

And this is where the complexity side of using Linux in ChromeOS raises its head.

When you install Linux on ChromeOS, Google creates a “Linux files” entry in the Files app’s sidebar (under My files and alongside the local Downloads folder). Google Drive gets an entry, too, of course, but it’s outside My files (and at the same hierarchy level as My files, if that makes sense). The Linux files view is not the entire file system inside the VM, as you might expect. Instead, it’s a graphical view into your Linux user account’s home directory (which in my case is, /home/paul). This is fine: I don’t need to graphically access the entire Linux file system directory structure from Files, and you can imagine someone screwing it up by mistake by deleting, moving, or changing certain files. I’m on board with this design.

(You can also right-click folders in Files and choose “Share with Linux” to make them available in that environment. That’s a nice touch, and good to know about.)

But when you open a Linux app–I’ll use Typora as an example–it of course runs in the Linux environment even though it’s visible on-screen with Chrome and the various web apps, all of which run in the ChromeOS environment. And that means that file operations–File Open as the obvious starting point–occur in Linux too. That is, Typora can “see” the Linux file system, and its File Open dialog displays your home folder by default. But it can’t see the local ChromeOS file system, which includes Google Drive. And that’s where I store all my documents.

Technically, that sentence isn’t correct. As it turns out, Linux and the apps that run in it can, in fact, “see” the ChromeOS file system. It’s just that this file system is mapped into the Linux file system in a way that will be non-obvious to many people. And so you need to take a couple of extra steps to simplify this interaction. Or, just change the way you do things.

To access the ChromeOS file system directly in Linux, you just need to know the correct path, and anyone with Unix (if you’re my age) or Linux experience will likely find this at least somewhat familiar: You can find it within the /mnt (for “mount”) root folder structure. So the Google Drive folder in ChromeOS is  /mnt/chromeos/GoogleDrive.

That’s not too difficult to remember, but in Windows, I pin certain Google Drive folders–Book, To-do, and 2024-05 (or whatever my current month archive folder is)–to Quick access in File Explorer so that I can easily access them from the navigation bar. (I did this with Favorites in the macOS Finder as well.) The Linux environment in ChromeOS doesn’t ship with a graphical file manager, though you can install one. But the File Open dialog in Linux apps lets you similarly pin file system folders for easy access. So that’s workable.

It’s workable but inelegant. The issue is basic file management. For Thurrott.com articles, I often create a document, save it to my desktop, and the archive it (by moving it into 2024-05 when done) when I post it online. If it’s a longer article that I will write over some days or weeks, I’ll move it into To-do. And for the books, I have an entirely different workflow in which I create a local copy of each book repository in the Book folder and then sync that between my PCs (because Book is in Google Drive) so that I can access that content offline.

Were I going to move to ChromeOS, I might investigate compatible Linux file manager apps and work as I do in Windows and the Mac. But it occurred to that this isn’t necessary. I can use my Linux home folder as scratch space, as I do with the desktop in Windows (and the Mac). If I complete an article I saved there, I can then use Files in ChromeOS to move the finished documents into 2024-05 in Google Drive. And if I don’t finish an article, I will just move it into To-do where I can access it from anywhere later. This works fine.

The books are simpler. I write those in Visual Studio Code and I update the main GitHub repositories with any changes from time-to-time using Git from the command line. So that can all happen in Linux. And when I update the repository, I can then use Chrome to publish a full or subset preview, download it, and then view it in PDF form. And that all happens in ChromeOS. There’s no need to worry about cross-environment copies, moves, or whatever else. Some of the workflow happens on each side.

Let me more explicitly explain how I set this up. (And then why this ended up being a mistake.)

After authenticating with Git, I cloned by Windows 11 Field Guide repository to a new windows11fieldguide folder in my home folder in Linux using the command line. Then, I pulled (downloaded) the contents–about 200 Markdown files and 2600+ images and other files–of my book repository into it, creating a local copy. In less than a minute, I was able to view the contents of the directory in Terminal (using ls).

Then, I opened this folder in Visual Studio Code (having previously signed in with my GitHub account, and thus syncing my custom settings, which include extensions specific to writing). This works identically to how Visual Studio Code works in Windows and the Mac, of course. (Excuse the superfluous extra stuff on-screen; Visual Studio Code doesn’t let you take screenshots in Linux, apparently, and I didn’t yet figure that out.)

I made a single change to a single Markdown file (at the time, I was working on the Edge Collections chapter I just posted), saved it, and then switched back to Terminal. As on Windows (and the Mac), I updated the master copy of the repository in GitHub using the changes I made locally using three command lines:

git add *
git commit -am “Some text describing these updates”
git push

And then I switched over to Chrome, navigated to the correct page on Leanpub, and published a subset preview, which I had previously configured to be just the new Edge Collections chapter. And when that completed, I downloaded and opened the PDF, which included the change: Those five bullet points at the top.

Not exciting, per se. Just a proof point.

Sadly, also a proof point that I don’t understand Git all that well. What I briefly forgot was that I sync a local copy of my book repositories through Google Drive on other platforms. And that if I updated the book here, in Linux, those other copies would be out-of-date. This is why I use Google Drive: There’s only one version across all my devices, and it’s always up-to-date.

There are at least two fixes to this problem. Git obviously supports syncing from the cloud to a local instance (using pull, for instance), and I could just do that on my other devices. But because I just use Google Drive sync, and it just works, the second fix I considered makes more sense: I can just open the book repository folder that’s already in Google Drive on this PC (in ChromeOS Flex). A folder that I can sync locally, just as I do in Windows and the Mac.

So I switched to that tried and true system.

The first step was to open Files and navigate to the repository’s location, right-click it, and select “Make available offline.” And then, after the initial sync completed–it took a few minutes–I right-clicked its parent folder, Book, and chose “Share with Linux” (because I might want to access the other book repositories too). This was key: Otherwise, this folder wouldn’t show up in the Linux command line or the File Open dialogs in Linux apps.

Then I fired up Visual Studio Code, chose “Open Folder” and opened my Windows 11 Field Guide folder into the editor. It worked perfectly (minus that screenshot issue I will now research).

And what the heck. In the course of finishing this post, I decided to try Visual Studio Code on the web and see how well that worked for my book writing needs. It has some limitations compared to the “native” app versions, most notably around extension support. But I can live with that, and this web app opened and worked with my normal Google Drive-based book repository normally. Very nice. (And no screenshot issues.)

Everyone’s needs are different, and I’m sure many will run into blockers that make ChromeOS Flex–or normal ChromeOS–a non-starter or at least less viable than Windows or the Mac. But as I’ve noticed over the past year especially, the blockers that caused me the most grief historically are less problematic now. Some of it is my own change–like that switch to Google Drive–but a lot of it is just continued improvements to web apps. And that terrific “last mile” Linux capability that lets me use a handful of critical apps. (You could also run other web browsers in Linux, of course, though I’ve not done much of that recently.)

The issue here, of course, is the complexity. Linux isn’t for everyone, and it’s not a mainstream solution. But for those technical users who dismiss ChromeOS out of hand, Linux compatibility could help overcome their biases. And help make ChromeOS more useful to them, as it has for me.

More soon.