For the last several months I’ve been using a Chromebook Pixel as my primary computing device. I’d like to talk about some of the down sides of this machine. For clarity (thanks Simon), I’m running Ubuntu 15.10 instead of ChromeOS as my daily driver.

Let’s start with the couldn’t-be-better so I don’t sound like a negative nancy:

  • Wonderful battery life
  • An enourmous wonderful screen
  • A fantastic touchpad and screen digitizer
  • Comfortable keyboard
  • Sturdy case and screen hinge
  • etc.

People around the net have spent time detailing out how marvelous a machine it is, and I could go on for paragraphs about how much I like it. But being a full-time software developer and effectively my team’s substitute dev-ops puts me right in the path of one of the biggest pitfalls of this device:

#Storage

I purchased the higher-end model. It’s got an i7-5500U dual core (hyperthreaded), 16 GiB of system memory, and a 64 GiB pcie-bus SSD for storage. I thought I could get away with just the 64 GiB, but work required I expand it due to my customer’s environment needs. It also has an SDXC-compatible SD card slot with which I have a 256 GiB U-II SD card.

In general usage, even compiling, it performs adequately. I expected slow read/write times with the SD card since it is an SD card afterall. What I didn’t expect was my current project customer to introduce Docker into my life. As of January, my development environment has switched from a series of VMWare VMs to a series of ever-growing Docker images.

This wouldn’t be so bad, except of course that WebSphere is a several-thousand-file behemoth of software, with a great many of its configuration files being in the dozen-kilobyte range. This simply plays havoc with my storage hardware. I commonly see a startup time of roughly 10 minutes just for my REST service to begin initialization in the WebSphere container.

I’m currently trying to build a docker container for another piece of software (who’s name I’m not sure I am at liberty to mention) who’s file count is easily in the thousands, each also roughly in the dozen-kilobyte range. I’m letting the docker build command run over night. It will probably take 3-4 hours to complete.

#Other issues

There are a few other things I (wouldn’t say) struggle with from time to time, but these issues are for all practicalities, solved. Mostly.

##Drivers

Thanks to the efforts of tsowell and raphael, the Chromebook Pixel 2015 edition works flawlessly, mostly.

There’s an issue with the touchpad and touchscreen (it doesn’t work ootb) which is solved by a custom kernel driver and systemd service script to reset it on boot and wakeup. There’s an issue with sound (it doesn’t work) without a custom alsa driver and config script. Sound also doesn’t “just work” in the sense that with these drivers, the devices aren’t enumerated by alsa and pulse properly. This is mostly just a trivial annoyance, but it is an existing issue. There’s an issue with the ACPI charging signal that doesn’t quite play right with Ubuntu’s defition of charging and discharging. There’s a weird issue with USB-C connectors that are not actually reversible. There’s an issue where the integrated webcam doesn’t play quite right with some v4l consumers.

But all these issues boil down to minor annoyances, easier to ignore than most people’s browser’s “advanced search bar” plugins. Still, at the end of the day, it isn’t perfect, and that’s a shame.

##Backlight

The Pixel sports a backlit display and keyboard. Both require a custom command to drive. Raphael from above provides scripts to manage the hardware, but it requires a custom service script to make the device nodes global writable and a manual keybind to (for me) ctrl+f6 and ctrl+f7 for the display and ctrl+shift+f6 and ctrl+shift+f7 for the keyboard. Because these are custom-bound, it doesn’t interface with standard screen-dimming techniques in Ubuntu.

I would really like to make a service utility that detects system idle time and automatically dims the keyboard appropriately. I’ll probably get halfway done and stop working on it…

##Suspend

Sometimes suspend just doesn’t work, either due to disk activity or the ACPI charching signal mentioned before, or because it’s Linux and something fucked up yet again. Usually the affect of this is that WiFi won’t turn back on for some reason or another, or the SSD will remount with errors (Ubuntu defaults to making read-only). The only solution is a reboot, usually hard. I still reboot my computer less than any of my coworkers on employer-maintained Windows 7 laptops. But once every 13 days is still to often /s!

#Still Good

All told, this is by far the best machine I have ever owned. I’ve got the battery of a MacBook Air and the power of a decent desktop, for a remarkably low price relative to competitors. The only thing I would ask Google to change is to just nut-up and put a damn decently sized SSD in it. I won’t run ChromeOS until I can completely manage my work life with it. This includes Exchange, Lync, RDP, Synergy, Java, C#, C++, Angular, Docker, Webex, Cisco Anyconnect, Firefox, and a host of other software that I’d have to still use Crouton to run anyway. So stop pretending “the cloud” is going to happen and just give us some storage already.