Skip navigation

Category Archives: chromebook

In a previous post, I discussed some of the issues I was having with running linux on a Chromebook (using crouton). The main issue was the small hard drive, 16 GB doesn’t give you a lot of room to work with. Accounting for the OS you are left with about 7 GB of usable disk space. For even light weight development, you will run out of space very quickly. Since I wrote that post I have had a few personal developments regarding the issue that I think are worth discussing.

One of the main advantages of the Chromebook is the price. While Mac’s are great, laptops are inherently meant to be a portable device, and are therefore subject to high levels of risk for both damage and theft. At a cost of ~$250, I could go through 4 Chromebooks before reaching the cost of the lowest priced Mac Book Air. And as luck would have it, I ended up destroying (sort of) my Chromebook. While brewing beer with some friends, a pint was knocked over and spilled all over the keyboard. Surprisingly, after drying the laptop out, it appeared to be alright, minus a few sticky keys and some weird behaviors from the track-pad. But about a week later, I spilled a cup of coffee on the thing (maybe it was sign?) and although the keyboard worked initially, it completely crapped out a few weeks later.

How not too brew beer!   I highly recommend keeping laptops in a safer location.

How not too brew beer! I highly recommend keeping laptops in a safer location.

The Chromebook still worked with a usb keyboard and mouse, but considering I move around a lot and like to work from coffee shops and libraries, it had lost a lot of it’s usefulness. A replacement keyboard would be around $50. While that isn’t too bad, there were no guarantees that that would fix the issue, and considering I would be doing the repair myself, I figured it would be best to move on. After all, one of the main reasons for using a Chromebook was their relative expendability[1]. There were a handful of new Chromebooks being released so I decided to ‘upgrade’. After some research, I chose to go with the Toshiba Chromebook 2 4GB model. The main reasons I went with the Toshiba were the 1080p screen, slightly larger size (13-inch), and the availability of the 4 GB model (a 2GB model is also available). The higher resolution and larger screen were a very nice upgrade, my Samsung’s 11-inch screen felt very cramped in comparison. I sprung for the extra RAM because the ChomeOS tends to resort to swap memory fairly often, and that slows things down. The Toshiba still only comes with 16GB of hard disk space, so I also sprung for a 64GB SD card. Including taxes, the laptop and card came in a little under $400. This puts it a little outside of the ‘expendable’ range, I felt that it was worth it.

My initial impressions were very positive. The 1080p screen is gorgeous. The 13-inch size was just right, still small enough to comfortable fit in my backpack, but big enough to have a terminal and editor open side-by-side. In order to get around the issues of disk space, I choose to follow the instructions on this blog in order to get a crouton Linux environment running smoothly off of the 64GB SD card. And now that I had 64GB’s to work with I went ahead and did a big install, downloading all of the standard Ubuntu desktop applications and features. I even set up a second environment that I could use to experiment with the anaconda python distribution. I was pretty stoked.

The Toshiba, look at that screen!

The Toshiba, look at that screen!

But alas, the honeymoon didn’t last much longer than a few days. Turns out the current version of crouton doesn’t play well with externally mounted environments. When the laptop goes to sleep, the external media gets unmounted and returns in read-only mode. Essentially it freezes the session and requires a reboot. All things considered, it’s not a huge deal, you just have to remember to shutdown your Linux session before closing the laptop. But it is annoying, especially considering the boot time is pretty long due to the fact that it is reading system files off of the SD card. One thing I might try, is keeping the chroot on the internal SSD and symlinking the user and application folders to the SD card. Not sure if this would work, but something to consider. Alternatively, I could do a bare bones command line install on the SSD and use that when I need quick access, and save the full Ubuntu desktop environments for when I am putting in some solid hours. Fortunately I now have two Chromebooks, so I can test it out on the old one first!

Anyways, overall, I am still pretty happy with the Chromebook. It’s light, has super long battery life (I only bring my charger if I am going to be gone for more than a day, pretty awesome!), and most importantly, it runs Linux! As a word of advice, if you are looking at Chromebooks for the purpose of running a Linux distro, I would consider looking into a model with a 32GB SSD. With a 32GB, you could easily fit a large Ubuntu chroot on the SSD, and use a SD for external storage. If I find a good workaround for the sleep/unmount issue, I’ll be sure to post it here.

[1] I am in no way endorsing excessive levels of consumption. As stewards of our planet and our environment, I think it is important that we consider the implications of our consumption and our waste. My previous experiences with Mac’s have lead me to believe that despite their seemingly better build quality, the machines don’t have that much better longevity. The fact is, most of the internals for the electronics we buy are manufactured and supplied by many of the same companies, and the only real differentiation is premium materials/features and branding. And you will be happy to know that the Samsung Chromebook is still in service. I have it set up as a desktop, and am playing around with some more experimental linux distros on it. At some point down the road, it would be fun to attempt to repair/replace the keyboard, once I get some other projects off my plate perhaps.

So I have been a fan of the thin client model of computing for a few years now.  I was turned on to the idea (without even realizing it) at my old consulting job, where we would remote desktop into a hefty SAS server to run our programs.  There were a number of benefits to this setup.  For programs with long run times, we could run the code on the server, and not have to worry about shutting down our laptops for the duration of the run.  The server had much larger memory and disk space than our laptops, so running code on large data sets was a lot easier on the server because of the larger resources.  Having all of the code and data in one location allowed for easier collaboration between team members.  And not having to run the code locally meant that our computers were still functional for other tasks while running a large job (nothing worse than trying to answer a few e-mails while a large SAS job is churning away in the background, tying up all of your computers CPU and memory).

Since leaving the consulting job, I have been running a thin client setup of my own for a while now, but my opinion on the matter has cooled somewhat.  I purchased a Samsung Chromebook and installed Ubuntu on it using crouton.  There are some noticeable bugs, but overall, I love the setup.  The laptop is light weight, small but large enough to be functional without a second monitor, and cheap.  It is essentially a 90% of a MacBook Air for 20% the price.  The two major sacrifices that you make with this laptop are RAM (2 GB) and disk space (16 GB SSD).  After a few months of use however, I am down to 4 GB [1] of disk space left which doesn’t leave much room to do work locally.  While I still think the thin client setup is the way of the future, I may have gone too thin, so to speak.

Part of the problem I am having is that I like to do work locally from time to time.  The laptop is small and light, and therefore easy to take with me anywhere.  I often find myself in locations without any wireless connection, and therefore, no access to AWS, my current choice of server provider.

Another complaint that I have is the set up time required to get AWS instances running.  I normally keep one micro tier instance of EC2 running at all times, in case I need to offload a small programming task to a server.  However, the micro instance, while free, can’t handle some of the larger jobs that I want to run.  This means that I need to fire up a larger EC2 instance, load all the data up, make sure I have all of the proper libraries installed, and then run the job.  Finally, after the job has run, I need to get the results, and kill the instance.  If I had a larger budget, I could afford to leave a larger instance running 24/7 (or just buy my own server), but the larger instances aren’t free, so in order to keep things cheap, I need to go through these hoops.

I am probably going to be spending some time exploring ways to make the remote server process a little less painless.  I am fairly certain that what I am doing is less than optimal.  Things like imaging my micro instance and transferring that image to a larger instance can make things a little less painful (at least when it comes to installing libraries and utilities), and hopefully I can dig up some other shortcuts and best practices for the other issues I have run into.  This should make some good fodder for my next few blog posts.  Stay tuned.

[1] It’s more like 2 GB of disk space, as ChromeOS relies on zRAM to supplement RAM, and it will automatically start deleting data if you get below 2 GB (From what I can tell, ChromeOS only deletes recoverable data like Google account information).  For the most part, all of the data is being used by Chrome OS and Ubuntu as well as the various utilities and tools that I have installed on Ubuntu (as far as I can tell), so clearing up space isn’t going to be easy.  I will probably start using a SD card to add some extra storage though.