Using Bodhi on My Chromebook: Network, Suspend

Introduction

In previous posts, I have discussed installing Bodhi on my Samsung (ARM) Chromebook and updating it to support Chromium and Flash, plus controlling the brightness via the brightness keys on the keyboard. In this post, I will discuss (wireless) network configuration/management and also suspend on lid close.

Network

From my investigation, I found 3 main candidates for network configuration and management for Bodhi. Most likely there are others, but these were the ones I saw being discussed and used (by different people).  The choices I found were:

1. EConnMan: This is the EFL (Enlightenment) user interface for ConnMan.
2. Network Manager: This uses GNOME and is the network configuration/management tool that comes by default with Ubuntu.
3. WICD: This is a lightweight python based wireless/wired network manager.

At first glance, given that EConnMan is EFL based and given my desire to use Enlightenment modules where feasible, this would appear to be my first choice. However, in reading the Bodhi forums, it seems that users were being dissuaded from using EConnMan, at least when they encountered problems. The alternative suggested was Network Manager.

For a while I tried using Network Manager. I have used Network Manager for years on my Ubuntu machines, and in fact still do.  It is probably the most functional and most widely used solution in Ubuntu, and supports things such as mobile broadband.  It is somewhat heavy in terms of resources and it uses GNOME. Considering I am running Bodhi on a Chromebook with limited memory and disk space, (and using Enlightenment, not GNOME) I want lightweight solutions where feasible.  Additionally, although I got Network Manager to work, I had quite a few issues configuring the wireless security.  The problem may not have been Network Manager itself (and its accompanying nm-applet) but an issue using the keyring for storing passwords. 

Basically, the problem I encountered was that when I was queried (by nm-applet) to enter the password for my wireless router, it always prompted me again. When I invoked nm-applet from within a terminal window, I could see (based on messages printed out) that it could not find the password in the keyring and thus was prompting for it. Although the ~/.gnome2/keyrings directory existed, nothing was written there. I tried starting various keyring programs at start-up, but still did not resolve the issue. Note that I had already configured the policy kit for Network Manager as described here (which did result in the appearance of the dialog box where I was asked to enter the password). I should point out that I have not had keyring issues on Ubuntu in the recent past and it may well be that had I been using Bodhi on an x86 or x86_64 machine, I would not have had an issue. It is important to remember that while Bodhi is based on Ubuntu for x86 and x86_64, for ARM it is based solely on debian.  This may (or may not) be partially responsible for the issues I had with the keyring.

The only way I was able to enter the password for wireless access points in Network Manager was to use the network connections editor application, nm-connection-editor. Using this I was able to store the password in Network Manager configuration files, which does not use the keyring.  While this worked, it was not ideal and for this reason, plus the fact that Network Manager is more resource intensive (and is GNOME based), I decided to try WICD.

To try WICD, I needed to turn off Network Manager. I did not want to uninstall it initially (although I may later). To turn off the Network Manager daemon I executed:

sudo insserv -r network-manager

That way if I wanted it started in the future I could use

sudo insserv network-manager

to have it automatically started at start-up.

I also had to turn off Network in the list of Enlightenment start-up apps.  The start-up apps are reached via  the main Bodhi menu at Settings->All->Apps->Startup Applications.

Since I had previously installed and then disabled WICD, I needed to have its daemon started automatically at start-up. I did this with:

sudo insserv wicd

I also went into the Bodhi menu to Startup Applications and turned on "Wicd Network Manager Tray".  Based on some documentation I read, I also added my user ID to the "users" group. I had previously added it to the "netdev" group.  I don't know which group membership, if either, is required. Update 11/28/2013: Looking at /etc/dbus-1/system.d/wicd.conf I see on my machine that the group you need to be in is "netdev".

After restarting, the WICD gadget appeared in the tray and I was able to click on it and configure wireless networks. I should also point out that I prefer the look of the WICD tray gadget versus the one from Network Manager (nm-applet). The one from Network Manager seems too big. Clearly this is a personal preference.

One other thing to note is that both Network Manager and WICD install pm-utils scripts for handling suspend/resume via pm-utils.  This will be relevant in the next section.

Lid Close and Suspend

Although I have been using Linux for well over 10 years, I have been hesitant to use suspend/resume.  First, Linux typically boots up somewhat quickly (typically 30 seconds or so) as opposed to some Windows machines which took minutes. Additionally, I am aware of people having issues with machines they continually suspended and resumed, that were cleared up after a reboot.  However, despite the fact that Bodhi on my Chromebook boots in about 10 seconds, I decided to play with suspend/resume anyway, as I don't expect to have numerous programs running simultaneously and will thus hopefully not run into many problems.

Most people seem to have their laptops suspend when they close the lid, so I decided to see if I could get that configured easily.  To support detecting and handling lid events, I needed to use something like ACPI.  Although I was told ACPI did not work well on ARM, I did find some information here  (see Advanced tab) about it being used on Samsung Chromebooks for handling suspend on lid close. I installed the acpid package, which is the ACPI daemon.  Note that I had previously tried to install acpi-support in addition to acpid, but was unsuccessful (for ARM architecture--others should be OK). The acpi-support package depends on acpi-fakeykey which was not available. At one point I even tried compiling acpi-fakekey and created a package for it (for ARM). However, the actual code (at run-time) depends on uinput (a kernel module), which is something that was not available in my ARM kernel.

Despite not being able to install acpi-support, which provides many helpful scripts for use with ACPI, I was able to create the event handler and script I needed.  I found useful information on ACPI events here. First I went into /etc/acpi/events and added (as root) a file named lid with the following contents:

event=button/lid
action=/etc/acpi/lid.sh %e

The first line tells it the action type, and the second gives the path to an executable (script in this case) to execute, passing the event string. I added /etc/acpi/lid.sh with the following contents:

#!/bin/bash
case $3 in
  close)
     pm-suspend
     ;;
  *)
     ;;
esac

After making these changes and rebooting, I was able to suspend on lid close.

Note that the event string passed into the script for lid close is:

button/lid LID close

and for lid open is:

button/lid LID open

This is why the script is looking at the third argument.

One thing I mentioned previously was that both Network Manager and WICD provide scripts for handling suspend and resume events. You can find these scripts in /usr/lib/pm-utils/sleep.d.  The scripts are 55NetworkManager and 55wicd respectively.  Upon resume from suspend, WICD did start up again and connect fairly quickly.

Usability on My Samsung Chromebook: Chromium/Flash and Brightness

Introduction

In a previous post, I described how I was able to get Bodhi Linux installed on my Samsung Chromebook (armhf architecture). It is set up for a dual boot environment (with ChromeOS), although at this point I don't have plans to boot in ChromeOS.  Although the install process I used included a filesystem image specifically for the Chromebook, there were still additions and tweaks I needed to make to make it more usable.

Chromium Browser Plus Flash

One of the things that could make or break the usability of environment would be the ability to play Adobe Flash content.  Although YouTube has moved away from Flash, there are still many web sites that use Flash content.  Being unable to view Flash content within a web browser would be a pretty major limitation.  Fortunately, there is a solution at least for one browser. While there does not appear to be a version of the Adobe Flash player for armhf, there is a version of the Google Pepper Flash player plug-in (see discussion here) which works with the Chromium browser.

So the first issue would be installing the Chromium browser. When I previously ran Ubuntu in crouton on my Samsung Chromebook I simply installed chromium from the Ubuntu repositories. Unfortunately, for armhf architecture Bodhi is based on Debian, not Ubuntu. I tried grabbing the Chromium browser packages from Ubuntu 12.04 and installing them on Bodhi. Unfortunately, I ran into a lot of dependency issues.  Fortunately, there is a version of the Chromium browser built for the Raspberry Pi computer, which is also uses the armhf architecture. I found the packages in the raspian repository here.  I downloaded all the deb packages (except the ones with "-dbg" in the name) onto my system.  To install them, I used GDebi, which does dependency resolution when installing packages. After getting the Chromium browser installed, I ran into some error messages about nss when running it. To resolve these, I executed the command

sudo ln -s /usr/lib/arm-linux-gnueabihf/nss /usr/lib/nss

With chromium running properly, I needed to use the libpepflashplayer.so 

To get the library file I had previously within ChromeOS opened a terminal (Ctrl+alt+t) and executed the command:

cp /opt/google/chrome/pepper/libpepflashplayer.so ~/Downloads/

I then copied the file to a flash drive for use after installing Bodhi. Alternatively, you could upload it somewhere (for example Google Drive) and then download it after installing Bodhi. Once on the machine, I decided to copy it to /usr/lib.  To do so, you need to use sudo. For example, assuming you have a terminal open to the directory where you downloaded or copied libpepflashplayer.so, you would execute the command:

sudo cp libpepflashplayer.so /usr/lib

Then to test it, I executed the command:

/usr/bin/chromium --ppapi-flash-path=/usr/lib/libpepflashplayer.so --ppapi-flash-args=enable_hw_video_decode=0,enable_stagevideo_auto=0,enable_trace_to_console=0 --disable-flash-3d

You can put libpepflashplayer.so where you want, but I discovered that simply placing it in the plugins directory for the Chromium browser was not sufficient. I had to put it somewhere and specify its path when invoking /usr/bin/chromium.

Once I tested flash content within the Chromium Browser and saw it was working, I edited /usr/share/applications/chromium.desktop and changed the Exec line to:

Exec=/usr/bin/chromium --ppapi-flash-path=/usr/lib/libpepflashplayer.so --ppapi-flash-args=enable_hw_video_decode=0,enable_stagevideo_auto=0,enable_trace_to_console=0 --disable-flash-3d %U

Note, to edit the file you will need sudo. I use gedit to edit, but there are other options available. Once I updated the (launcher) file as described above, I was able invoke the Chromium Browser normally (via application menu for example) and have it process Flash content.

Adjusting Screen Brightness

The Samsung Chromebook has keys labelled for decreasing and increasing screen brightness. These are in the F6 and F7 positions on the keyboard.  Bodhi has a Backlight module providing a widget for controlling brightness, but this did not work for me. What I decided to do was use a simple script and invoke it from the aforementioned keys to control brightness.

I based my script on work done by hkoster1 on the Debian User Forums. First I had to find the brightness device file to send adjustments to.  By searching, I found it at /sys/devices/platform/s3c24xx-pwm.0/pwm-backlight.0/backlight/pwm-backlight.0/brightness.

The script, based on getting an argument of "u" (for up) or "d" (for down) increases or decreases the brightness respectively. It does this by first getting the value from the brightness file (should be an integer between 0 and 2800) and adjusting it up or down by 200.  The script will only set a value between 200 and 2800. If you want to allow a value down to zero, you could modify the script.

You can download my script (into a directory to which you have write access) via the command:

wget --no-check-certificate https://googledrive.com/host/0Bx4fuKmDTtwmZWJMeEtpRWZxY1E

Then execute the command:

mv 0Bx4fuKmDTtwmZWJMeEtpRWZxY1E brightness

followed by:

chmod +x brightness

and then:

sudo cp brightness /usr/local/bin

You can test it by executing:

/usr/local/bin/brightness u

to increase brightness

/usr/local/bin/brightness d

to decrease brightness

Next I needed to assign commands to the two brightness keys. First I had to get to the keybindings menu via "Settings->All->Input->Key Bindings". Since the key, F6, for brightness down was not defined, I had to add it by pressing the "Add" button and then hitting the key. Then on the right I scrolled down to Launch and selected "Command" and then entered into the "Action Params" textbox:

/usr/local/bin/brightness d

You can see a screenshot of this key binding here:

I hit the "Apply" button to make the setting stick. Next, I did the same for brightness up by hitting the "Add" button for F7 and entering the command:

/usr/local/bin/brightness u

and hit "Apply" again.

After this, I could control the screen brightness up and down with the 2 keys.

Installing Bodhi Linux on My Samsung Chromebook

Introduction

In previous posts I described my experience with my Samsung Chromebook and why I decided to install Bodhi linux instead of using ChromeOS in conjunction with crouton.  Installing Bodhi, like most Linux distributions, on most Intel or AMD based computers is pretty straightforward (at least on most models).  Part of the reason the ARM-based Chromebooks, like the Samsung Chromebooks, are different is because they have secure boot.  From what I have read, the Chromebooks use UEFI or a subset thereof. The upshot of this on the Samsung Chromebook is:

1. Installing a different OS is different, and more complicated, than on an Intel or AMD x86 or x86_64 architecture machine.
2. You have to do things to bypass/disable the secure boot feature that comes with the Chromebook for ChromeOS.

Although I discussed this in previous posts, it is important to note here that what we are talking about is installing a separate OS (in addition to ChromeOS) that will be booted into at machine start. Essentially it is a dual boot, even if you have no intention of using ChromeOS. ChromeOS is still available, although booting to it, although not complicated, is not trivial and not as simple as making a selection from a list of OS's like one might be used to seeing with linx on many Intel/AMD based machines. This dual-boot environment is also different from the crouton situation, in which you use a chroot to run a subset of another OS to which you can switch with a key sequence.

Bodhi Linux is of course not the only option for Linux on the Samsung Chromebook.  One of the earliest options available was Ubuntu, via ChrUbuntu. Other options include installing Arch Linux or Debian. One thing all of these installations require is that you first put your Chromebook into developer mode. Additionally, every time you reboot (or power on) your Chromebook, you will be faced with a warning screen, at which time you need to hit Ctrl+d or wait 30 seconds for it to boot into Linux.

There is one other thing I should point out.  Too often, in my opinion, people or organizations, take credit for some invention which is built on the work of others.  This is the especially the case (again in my opinion) with things like software patents, but that is a discussion for another day.  The information I am providing here is based (very) largely on the work of others.  As I will describe later, I started out with a description and script for installing bodhi on Samsung ARM Chromebook, and used information from other OS installation descriptions to solve issues as I encountered them.  I believe the installation descriptions I worked with were probably originally based on reference documentation, much of which comes from Google. Although what I am providing is partially a product of my own perseverance and frustration, there is very little invention here. I will try to link to information sources I used in coming up with an installation solution for my Chromebook.

Please also note that there have been changes in the Samsung ARM Chromebook that may mean what I did may not work for you, or work without some changes.  As will be pointed out later, the original installation instructions I followed did not work for me.  The existing ChromeOS installation was not set up as the script I initially used expected.  I suspect that this was due solely to a newer version of ChromeOS, but perhaps there have been hardware changes as well.

Finally, please note following these steps permanently deletes all local data and configurations of your Chrome OS, restoring it to a pristine factory state.

As with any case where you install a new OS on a machine, bypassing what the manufacturer provided, I take no responsibility for the results.  If you are not willing to take the chance of something going horribly wrong, don't take the chance. I am not aware of people bricking their device using similar steps, but there are no guarantees. Unless the unbelievable happens, even if things do go horribly wrong, you should be able to recover your machine to the factory defaults following the recovery instructions here. As always, caveat emptor.

The Original Installation Instructions

The main installation source I used for my work to get Bodhi installed on my Samsung Chromebook was this post by Jeff Hoogland, who is Bodhi's lead developer.  Needless to say, without his earlier work I would not have even had a place to start with installing Bodhi on my Chromebook.

I followed the instructions in Jeff's post and got most of the way through the steps.  In fact, if you have a Samsung Chromebook, it is possible his steps and script will work for you.  What I encountered was that after executing the script according to instructions, upon reboot, it booted back into ChromeOS.  As you can see in this forum topic, I was not the only (or first) person to encounter this. I later discovered that the cause was that where previously the ChromeOS had a copy of the kernel installed under /boot, that is no longer the case.  If you wish to see if Jeff's script will work for you, you could go to the end of step #2 in his instructions and then execute the command:

ls /boot

If it does not find the boot directory this means his script will not work for you (unless he has updated since the time I tried it).  If you do find /boot then you hopefully can successfully use his script. My version of the script (based on his) checks for this and hopefully handles either case, but I have not been able to test the case where there was an existing kernel to use, since that was not the case on my Chromebook. The modifications I made to Jeff's script were based on the information I got from debian installation instructions I found here. I am grateful to the author, as I was stuck until I found the description of repackaging the running kernel.

Please note that I not only modified Jeff's script, but I borrowed the description of many of the manual steps as well.

Instructions Using My Script

Just to be clear, the instructions here are pretty much the same as in Jeff's post, except that my script is a modified version of his.  And at the end of the script I have commented out the reboot command in case you want to look around first. So you will need to issue the reboot command manually at the end yourself. Many of my descriptions will parrot Jeff's.

Step 1: Return to Secure ChromeOS Environment

If your machine does not boot into developer mode (i.e. does not give you a message about Chrome OS verification being turned off), you can probably skip this step. Otherwise, I would suggest you do this step. If you have some other OS installed, either via dual boot or via chroot, you should back up any data you need first. Any data you had previously will be lost. Although ChromeOS is backed up automatically, you probably should back up anything on the disk in your Chrome OS environment as well.

You will be reinstalling the Chrome OS image.  While in ChromeOS, you can create the image by entering:

chrome://imageburner

in the browser's address bar and following the instructions. Other options to create the image, on a different computer (Linux, Mac, Windows) are found at the link I will give in this paragraph. What you need to do here is reboot but when you encounter the "Chrome OS verification is turned off" message, do not hit Ctrl+d. Instead hit the space bar and follow the instructions here.  If you did not previously create an image, you can create one on another computer.  I created one on another Linux machine. Note that my Samsung Chromebook has a Snow... ChromeOS image.  You can check the type at the bottom of the recovery screen. Note that if you want to force the screen which says "Chrome OS is missing or damaged" you can boot in recovery mode by turning off your machine and then holding ESC (escape) and Refresh (F3) and hitting the power button. At this point you can plug in your recovery USB drive created earlier. On the Samsung Chromebook you cannot use the blue USB port, but the other one. After plugging in the USB drive (into the correct USB port), if it says the image is not valid, it probably means you selected the wrong one (I did this once) when creating the restore image.

Step 2: Boot in Recovery Mode

Assuming you did not do step #1, you should back up any data you need first. Any data you had previously will be lost. I assume at this point that you have a ChromeOS verified boot environment, either because you never changed to developer mode or you executed step #1 above. You now need to boot into recovery mode. You boot into recovery mode by turning off your machine and then holding ESC (escape) and Refresh (F3) and hitting the power button. You then should hit Ctrl+d and then on the next screen press enter. At this point the system should reboot into recovery mode. Once it reboots into recovery mode it takes a few minutes to configure everything, so please be patient.

Step 3: Get into a Virtual Terminal with Internet Access

After the system has started up, select a wireless access point to connect. to. It might take a few seconds after starting up for the list of access points to get populated into the pull-down list.  After selecting the wireless access point, go to the next screen (the google login screen) but do not log in. Hit Ctrl+alt+-> (where -> is where F2 would be on many keyboards).  This will open up a shell window.  For the username enter chronos and just press enter for the password (there is no password).

Step 4: Download and Run the Installation Script

From the command prompt run:

wget --no-check-certificate http://goo.gl/2OOuG0

followed by

sudo bash 2OOuG0

The commands are case sensitive. Note that "2OOuG0" has two capital letter O's (not zeros) following the digit 2, and the last character is a zero.

After entering the second command (which runs the script), you will be provided some information about your Chromebook. To continue, press enter.

Step 5: Choose How Much Space to Give to Bodhi Linux

The installer will prompt you for how much space you want to give to Bodhi. You should enter an integer amount for how many GB you would like to give Bodhi. On the 16 GB Chromebook the most Jeff (and others) recommended giving to Bodhi is 9 GB (with the maximum being 10).  For information, the initial base Bodhi install occupies around 1.6 GB. Once you select an amount of space to give Bodhi the drive will be re-partitioned automatically and then the system will restart. After restarting,  you will need to go through the ChromeOS setup process once more (see the beginning of step #3). Again, when you get to the google login screen do not log in.

Step 6: Getting the Linux Filesystem Set Up

Get into the virtual terminal again as described at the end of step #3. Then run the same two commands given in step #4, which will download and execute the script a second time.  This time the installation script will see that your drive has already been partitioned and it will begin downloading the Bodhi Chromebook image which it will then install onto the system. Note that this will take some time depending on your internet connection speed since a 300MB tarball needs to be downloaded and extracted. A couple of things to note here. First, my script will write the identification of the target kernel and target disk into a file called bodhiboot.info. This may be useful for debugging purposes.  Secondly, I commented out the line at the bottom of the script which reboots, in case you wish to look around before rebooting.

One other thing to point out is that near the end of the script, the following statement is executed:

cgpt add -i 6 -P 5 -T 1 -S 1 ${target_disk}

where you can find the value for ${target_disk} in the bodhiboot.info file mentioned above. This statement sets the Bodhi Linux partition as the top priority so after reboot it will boot Bodhi and not ChromeOS.  The "-S 1" arguments indicate there has already been a successful boot.  If this is not included (it was not needed in Jeff's script), the first reboot will take you into Bodhi, but subsequent boots will take you back to ChromeOS (you can still follow step #3 to get back to the same chronos virtual terminal if that happens).  The reason I believe the "-S 1" is needed is because if there is no indication that there was a successful boot of the alternative OS, it will boot ChromeOS instead.  Otherwise, if you have a bad boot image, it would continually just boot you into that image. If you wish to boot Bodhi just once and then have it boot back to ChromeOS subsequently (until you are confident you are ready to make Bodhi the permanent choice on every boot), you can remove the "-S 1" from the script (assuming you know how to use the vi editor), or after executing the script but before rebooting, enter the command:

sudo cgpt add -i 6 -P 5 -T 1 ${target_disk}

remembering to replace the "${target_disk}" with the value of the target disk given in bodhiboot.info. Note also that if you reboot into ChromeOS and then get back to the chronos virtual terminal (without logging in) and rexecute the script, it will still recognize that the partitioning has already been done and only execute the second pass of the script. Note also, that your previous files and the 2OOuG0 script should still be there.

If you left off the "-S 1" arguments to the cgpt command but are confident that Bodhi will boot up safely, you can manually execute

sudo cgpt add -i 6 -P 5 -T 1 -S 1 ${target_disk}

again replacing "${target_disk}" with the target disk value from bodhiboot.info.

When you are ready to reboot, enter the command

sudo reboot

and hopefully you will boot into the Enlightenment desktop. Note that the default installed user is armhf and the password is bodhilinux. That user has sudo rights. With the given installation image, there is no login screen and you will be logged in as the default user automatically.

Please also note that based on information I found in the debian install instructions, I found that to get the audio speakers working on the Samsung (ARM) Chromebook, I had to open a terminal and enter the following command (just once):

 alsaucm -c DAISY-I2S set _verb HiFi

To customize the installation to work with special keys like the increase/decrease brightness, increase/decrease audio, and mute audio, I made some additional changes after installing. I will discuss those changes in a future post.

Choosing a Linux Distro for my Chromebook

Background

I have been using Linux at home for over 10 years, and I used it at work for over 5 years.  At various times, either at home or at work, I have used Ubuntu, SUSE (or OpenSUSE), Red Hat, Fedora, Scientific Linux, Mandrake/Mandriva as well as a few others.  For desktops, I have used GNOME, KDE, Unity, as well as experimented with things like Xfce and LXDE.  More recently, in my crouton environment on my Samsung Chromebook, I tried enlightenment.

Prior to my experience with crouton, I had for quite a few years used Ubuntu on my home computers.  At times I used the KDE-based variant, KUbuntu and then switched back to regular Ubuntu. When Ubuntu moved away from using GNOME to using Unity, I decided to give it a try.  Those familiar with Ubuntu during that time know that there was a lot of controversy within the Ubuntu (and Linux) community about the switch.  Clearly there was politics (or control) involved.  Although it took time to get used to, over time it got better and better and I found it quite usable.  I currently still have Ubuntu with Unity on my older laptop.  I am somewhat ambivalent about it. I did try GNOME 3 Shell for a while, but found it buggy and went back to Unity.  My previous experience with KDE 4 was pretty positive. If I had a more powerful laptop I might be trying KDE again.  It continues to improve and has really nice eye candy.  

As I explained in previous posts, I liked the Samsung Chromebook because it was light, fan-less, and had a long battery life.  What it is not though, is a powerhouse.  Because of this, while looking at desktop environments for the Ubuntu running under crouton, I came across e17 (enlightenment) as one of the options.  It is very lightweight, compared to things like GNOME, KDE, and Unity.  After using so many desktop environments, it looked, well, different.  It is very configurable.  Unity has its taskbar on the left. With e17, you can put one anywhere. You can even have more than one. You can make them hidden (appearing when you scroll over the edge a la Mac) or not.  You can put various gadgets in them.  I liked the fact that if you clicked on the desktop, it brought up a main menu through which you could navigate to just about everything.  Maybe I was just in the mood for something different, but I liked what I saw. And as I used it for a while, I still liked it.

Bodhi Linux

Using e17 led me to the distribution that showcases it, bodhi. Bodhi builds on top of Ubuntu (except for ARM which I will get to later).  It is a minimalist distribution (at the start), and can run on old and/or low-power hardware.  While Ubuntu (or one of its variants) consistently ranks near the top of distrowatch, bodhi is barely in the top 20 (still not all that bad I guess).

As an experiment, I installed bodhi on an old Acer Aspire One netbook. This was one of the earliest netbooks and is clearly not powerful.  Although I didn't do a lot with it, it installed easily and seemed to work fine. Years ago I took this netbook on a vacation to Europe and it make take an event similar to that in the future for me to use it extensively.  However, based on my use of e17 and this netbook experiment, I decided I wanted to give bodhi more of a try. Oh, there was one other thing. Based on this, it seemed bodhi could be installed on the Samsung (ARM) Chromebook.

Limitations of Linux on ARM

In case I haven't made it clear previously, the Samsung Chromebook is ARM-based, not Intel-based. That is, it does not use the Intel architecture used by Intel (and AMD).  As I found out, this is quite significant.  Over the years, thousands of Linux packages (applications) have been written for Intel 32 bit and 64 bit architectures. For a long time though, there were issues with running a 64-bit version of Linux.  Recently, I probably should have realized that, given issues I had in earlier years on 64-bit linux, I would have similar (actually more) issues on ARM.  As I worked with crouton, I ran into certain packages I wanted (or needed) that were not available for ARM. Previous posts on this blog outline many of these issues.  Although they were not available at the time, based on my experiences, I would recommend someone wanting an inexpensive Chromebook with long battery life for Linux use should choose one of the new Chromebooks employing the (Intel) Haswell chip instead of an ARM based one.

Given, however, that I already had a Samsung (ARM) Chromebook, I decided to go ahead and install bodhi linux following the guide I mentioned earlier.  I will discuss this more in another post. I should point out that the very week I installed bodhi on my Chromebook (after quite a few trials and tribulations), it was announced on the bodhi forums that official support for ARM was being dropped.  Had I known this when I started I might not have gone down the path I did, but now that I have and have been pretty much successful, I am glad I did.

One other thing I alluded to earlier is the fact that unlike the x86 and x86_64 versions of bodhi, the ARM (armhf architecture) version is actually based on Debian, not Ubuntu.  As I will point out in a future post, this brought a few surprises, although to this point no real issues.  One needs to keep in mind that Ubuntu itself is largely based on debian as well.

My Decision to Leave ChromeOS for Linux

5 Months In, Why I Went Back to Linux

After about 5 months of using ChromeOS (on a Samsung Chromebook) along with crouton, I decided to switch back to a full-blown Linux distribution rather than running crouton alongside ChromeOS (in a chroot).  I detailed my earlier decisions and experiences in earlier posts in this blog.

My Experiences with ChromeOS and Crouton

In earlier posts I discussed using ChromeOS on my Samsung Chromebook. Using ChromeOS, especially on Chromebooks, is about working in the cloud. In this case, it is pretty much the cloud as defined by google.  There are many advantages to using a Chromebook in this way, which is how it is intended to be used:

• Your data is automatically backed up to the cloud
• Your Chromebook receives updates automatically. Unlike what one might experience with Windows updates, this works pretty seamlessly.
• Your environment is protected against viruses

My general experience with working this way was quite positive.  The machine booted quickly, usually in about 10 seconds.  The chrome browser started. It remembered previously open tabs (from when I last closed the browser or shut down the machine), and restarted them. Depending on the number of tabs, this processing could take a while. Still, from shut down state, I was up and running quite quickly.

Essentially, the chrome browser is your desktop and is pretty much your environment.  Although there are some exceptions like the file manager and media player,  almost all your applications run inside the browser. With the advances made with HTML5 you can do amazing things within the chrome browser.  Essentially, many of things you run within the chrome browser are web apps.  That is, they are written to work solely in a browser environment, irrespective of the underlying OS.  ChromeOS also supports Chrome Apps, an enhancement of what were previously called packaged apps. Unlike web apps, these apps can use Chrome APIs to access functions of the underlying ChromeOS.  Unlike web apps, the packaged apps can be written to allow offline access to data.

As I mentioned above, my experience with working in ChromeOS was quite positive. Many of the things I use are web oriented. I use twitter, mainly to follow what others write rather than comment myself.  I use Google+ in a similar vein.  I also read several blogs, do searches, and do much of my shopping on-line. For those activities, ChromeOS and the chromebook are ideal.  As I mentioned in previous posts however, there were things which I could not do in ChromeOS, including:

• Use GNUCash for budgeting and tracking expenses
• Get data from my Garmin GPS watch via the ANT+ USB stick
• Use a non web-based e-mail client
• Use GIMP for doing graphical editing
• Use my scanner and load the results into GIMP

For some of these, there are on-line alternatives. Obviously, I could use web-based mail. There are also some on-line financial apps and graphical editors.  Other than accessing my scanner and using the ANT+ USB stick, in theory I could use ChromeOS and web-based applications for everything I probably need to do. However, I chose not to because:

• I am uncomfortable with having all my data, like financial data, in the cloud under the control of some third party.
• I have been using Linux for over 10 years, and prefer certain open source software (OSS) like GNUCash and GIMP.

My discomfort with having using web-based applications for everything stems from concerns about both security and privacy.  The recent revelations about the NSA and their hooks into numerous firms, including Google, means that my data is neither private nor secure.  Allowing hooks into Google for access by government agencies, makes their system more susceptible to hacks by more nefarious entities.  Since the data is now accessible (at minimum) by both the company whose app I am using and the government, it is clearly less private, despite assurances to the contrary.

Using Crouton for Non-Web Access

As I explained in previous posts, I was able to set up crouton to allow access to things like my scanner and to run applications like GIMP and GNUCash. Crouton sets up a separate (via a chroot) Ubuntu environment which can be accessed via a key sequence.   When I wanted to use my email client, I switched to the crouton environment and accessed it there. Similarly, I used this environment for access to my ANT+ stick and scanner, and to use GIMP and GNUCash.  I also was able to set up software to copy/paste the clipboard between the ChromeOS and crouton environments.

I worked in this environment for months and was able to do pretty much everything I need to do. After a while, I rarely needed to boot up my old Linux laptop to do something.

Why I Decided to Change

First let me say that for many audiences, a Chromebook may be ideal.  They are catching on at schools, and this makes total sense. One feature I failed to mention earlier is the fact that multiple users can share the same physical Chromebook. Since all the data is kept in the cloud (at least if you use only ChromeOS), it is trivial to have multiple accounts associated with the machine. In fact, a student can log into a different physical Chromebook every day and not know the difference.  Administrators can set up the Chromebooks similarly with various extensions, etc..  Also, quite a few Chromebooks cost under $250 at retail prices. It was stated recently that 1 in 5 school districts is using Chromebooks now.

For consumers who are able and willing to work in a web environment, a Chromebook may be the perfect option.  For printing, if they have a cloud enabled printer, they can easily print from their chrome browser. At this point it appears that sales of Chromebooks are increasing, while sales of other types of laptop and desktop computers are decreasing.  If you are willing to buy into the idea of having all your data in the cloud, Chromebooks may be ideal for many consumers.

That last point is the major rub for me however. As I used the Chromebook more and more, and as more reports of the NSA and cooperation of Google and other companies regarding access to user data came to light, I became more and more uncomfortable with the entire premise of using so many web-based apps.  Just what are they doing with my data? How secure is it? We have all seen stories of various merchant sites being hacked and thefts of personal and/or credit card data.  Can you trust their privacy policy? Even if it seems OK today, will they change it tomorrow and if they do, will you be so wedded by that time to their application that you feel you have no choice but to go along with a changed policy that (potentially) gives you less control of your data.

With native applications, at least those that don't send data to the web, I have control of my data, as long as I have adequate security controls in place.  When I use the browser and web apps, I may not know whether I am giving up privacy and/or security.  With native applications I am familiar with, at least I should (hopefully) know.

Given this concern, one might ask, wasn't I already using a solution to this dilemma? After all, I already was using crouton which gave me native (and controlled) access to data.  I could use this environment for things where I wanted to guarantee better control of my data, while using ChromeOS for everything else.  Although this is true, I guess I consider the ChromeOS environment somewhat insidious. You get used to it and use more and more of its apps and after a while you are tempted to use it for almost everything. At that point, you have lost control of most if not all of your data.   Additionally, I got tired of constantly switching back and forth between the crouton and ChromeOS environments.

In the end, while the Chromebook might be ideal for lots of people, I decided it wasn't for me.