raspberry pi, weekend edition

This is a screen shot of my Raspberry Pi (one of two) running Arch Linux Arm for Raspberry Pi with the twm desktop environment. I’ve gone back to the twm X desktop because, as I discovered since my last report, it’s the only truly lightweight desktop with any kind of decent performance on the hardware.

Testing Raspberry Pi Distributions

Since my first post on the subject, I’ve tried both Raspbian and Pidora, and found both lacking for my uses, especially Pidora. Their poor performance out-of-the-box on the RPi pushed me to try out Arch Linux for Raspberry Pi.

Arch Linux Arm for Raspberry Pi comes as a minimal installation image with no graphical desktop environment. What I at first though was a liability (no DE) turned out to be a asset as I learned more about the RPi and its hardware. The very first thing I noticed was how well Arch Linux performed and the minimum resource footprint it took among all the distributions I tried. Once I had Arch Linux up and running, I started to use pacman and the Arch repositories to add packages up to the windowing environment xfce. And that’s when I ran out of file system space on the SDHC (secure digital high capacity) card I was using.

All the distributions seem to limit themselves to a total of 2GB space. After my encounter with Arch’s 2GB limit, I re-flashed my 8GB card with the baseline image and then used gparted on my Ubuntu notebook to resize the root (/) partition to fill nearly the entire card. I used gparted to created an additional 512MB swap space, which I enabled under Arch the next time it was booted.

Working with Arch Linux for ARM

Once I had Arch’s file system properly configured I installed a set of base-line Arch packages that would suit my needs. I created a new account, called pi, and worked from within a lower privilege account using sudo. I enabled the function keys on my Apple keyboard so I could switch between virtual desktops. I installed gcc, python, and nodejs from the Arch ARM repositories. I tweaked the environment a bit until it was to my liking, then shut it down and made a backup image of the entire 8GB card, again using dd on my Ubuntu notebook. I then tested the backup by copying the backup image onto a second 8GB SDHC card, and booted from the second card.

Adding a Desktop Environment

The first graphical desktop environments I tried were xfce and lxde, in that order. The xfce DE was a complete non-starter for me so I copied my 8GB backup image to the SDHC card and started over. I installed lxde and found it was better than xfce, but not all that great. It was lethargic when I tried moving windows across the desktop.

Rather than wipe and reload, I decided to install twm and work from that. At first it looked like twm was very broken. I could bring up the desktop with the default values, but I had no menu system. The only way to exit twm was with pkill x, a command I eventually found was the only way to exit twm back to the command line.

In the end I constructed my own local .twmrc file. The screen shot at the start of the post is where I’ve essentially stopped for now. I have xterms for simultaneous editing and tasking, as well as nedit for a rather light editor. I also have vi and emacs installed for those times when I’m at the command line. As a very simple test of node.js, I created an extremely simple HTTP server, the source you see in nedit in the upper right of the screen, ran it, and then check it on my Ubuntu desktop using Firefox.

There wasn’t much to the Javascript server, but then it didn’t need much for this very simple end-to-end test. I have most, if not all, of the tools I need installed on the Raspberry Pi, and I’m comfortable with either the twm desktop or the command line. For the end state of this project it’ll be running headless anyway, so a desktop environment isn’t needed.

Lessons Learned

Use Arch for this kind of work. It’s highly granular and can be tailored to a specific environment. It seems to support the largest selection of ARM boards, and if my experience with the Raspberry Pi is any indication, then it’s the best choice for building ARM-based devices in the coming Internet of Things. My only concern about Arch is how secure is it, and can I harden it sufficiently. My only other alternative at this point is to try and follow Linux From Scratch and cross-compile my own distribution, and I really want to avoid that if possible.

An Offer to other Raspberry Pi Users

I have a Github account, but nothing in there right now. If there is any interest in my software configurations I could compress (zip) the base 8GB Arch Linux backup image I have and make that available for others to use. I could even create a second image of the card with twm and make that available as well. If there is an interest please leave me a comment.

Update 3 February 2014

I’ve re-opened my old Sourceforge account. I created that account back in 2000. That’s right, I’ve had a Sourceforge account for 14 years, with not much to show for it. I’ve compressed the two 8GB images I’ve been building using zip under Ubuntu 13.10, then uploaded them both to Sourceforge. The file sizes range from 600 to 700 MB, so be advised. The TWM graphical desktop manager version is the larger. When unzipped they’re a full 8GB (or 7.5 GiB to be totally truthful).

It’s called Project Rubus: https://sourceforge.net/projects/rubus/files/images/

raspberry pi

I finally found time this evening to pick up a few items and bring one of my two Raspberry Pi Model B boards to life. My wife and I went out for a simple supper. While we were out I stopped by a local Best Buy and picked up an inexpensive all-plastic 22″ Samsung 1920 x 1080 LCD display and an Apple USB keyboard. The Samsung comes with a convenient HDMI port, which the Raspberry Pi plugs into with the right cable. The Apple keyboard was surprisingly inexpensive as well, the cheapest on Best Buy’s shelves, yet it’s built around a nice machined aluminum frame.

I’d already set up the boot device, a SanDisk 8GB SDHC, with last year’s Raspbian release. When I booted up into the graphical desktop I was pleasantly surprised that the Logitech M305 wireless mouse worked with the system. Power was supplied by my Galaxy S4 charger. The whole time I was running the system the charger never got warm. I tried to bring up wireless networking with a USB WiFi Cisco Valet dongle that’s normally plugged into the back of my Wii, but that didn’t work. I need to dig around and see if I can find a way to inexpensively add WiFi to the Pi.

The graphical desktop for Raspian is Xfce, a simple environment that has been a refuge for many fleeing Gnome 3. Xfce proved to be absolutely no problem. If you’re used to Gnome 2 in any incarnation, then Xfce is dead simple to operate. Besides, give me a shell to work in and I don’t really care what the visual desktop looks like. A quick check of resources shows it has GCC 4.7.2, Python 2.7, and a late version of Ruby. Although I couldn’t start irb up because not all the Ruby Gems were installed.

Working with Raspian on the Raspberry Pi demands patience. It’s slow. Even my Linux VMs on my Windows 8.1 are faster and smoother than the Pi. And yet one must always remember that the Raspberry Pi is, after all, a $35 bare-bones computer running a mid-to-low-end ARM processor (ARM1176JZFS running at 700MHz) with 512MB of RAM. Although, come to think about it, my AMD 32-bit PC from 2003 was only a little bit faster, ran Microsoft Millennium (ME) on 512MB of DRAM. I suspect that if I were to install the current release of Raspian it might run a bit smoother than it does right now. Still, it’s a bit remarkable to see it running at all. I purchased this as an embedded system, not as some ground pounding workstation. For what I intend for the board it’ll be running in character mode to avoid consuming precious memory with a graphical desktop. For what I have in mind I think it’ll be just fine.