My Arch Linux Raspberry Pi images were updated and uploaded to Sourceforge this weekend. The lead-in image is a screenshot of the TWM desktop running a colorized VM in an xterm and emacs. You’ll note that the colors and general look and feel are tweaked a bit.

This weekend I added additional functionality to my Raspberry Pi; the ability to manipulate the GPIO through RPi.GPIO. This meant updating the base image with more development tools as well as downloading and installing RPi.GPIO from its Sourceforge repository. I’ve had very little time to test it; the only test I’ve conducted so far is using test.py that’s part of the RPi.GPIO source bundle.

The base image started with the Groundhog Day base image had the following actions performed:

• removal of regular vi and its replacement with vim via softlink;
• update of system to Arch Linux for Raspberry Pi as of 8 Feb 2014;
• addition of git;
• addition of more development tools, especially for Python 3;
• addition of RPi.GPIO 0.5.4.

That running image was copied back and compressed (zipped) into ArchLinuxARM-2014.02.08-rpi-base08G.zip where it was uploaded to the Rubus Project on Sourceforge.

I then took the base image and duplicated it on another card where I installed Xorg and TWM. This installation was meant to be cleaner than the Groundhog Day image release, having learned a bit over the past week. In particular I did not install lxde.

The graphical system consisted of the base image plus:

• xorg
• xorg-xinit
• xorg-twm
• xterm
• xorg-oclock
• xorg-xlogo
• xorg-xeyes
• xorg-xload
• xv
• medit

The pi account also has proper local .twmrc, .xinitrc, and .Xresources files. The system X files under /etx/X11 are no longer being hacked. I finally remembered the proper syntax for just about everything that matters. The .vimrc has been edited to enable line numbering and syntax highlighting for vi/vim. There is a .emacs file to configure Emacs to my tastes. You should check this and modify to suit your tastes.

After testing the image was compressed (zipped) as rchLinuxARM-2014.02.09-rpi-twm08G.zip and moved up to Sourceforge.

The usual root and pi accounts are on both images. As always, change the root and pi passwords if you plan on using these images on networks you do not have absolute control of.

I’m now moving on to tying hardware into the RPi. I have a Parallax Propeller Professional Development Board that’s been sitting around in its anti-static bag for years now, purchased when Parallax had a sale on them for less than $100, waiting for me to pull that board out and put it to work. I’ll be using the Parallax board with the RPi to begin my hardware integration. It has a large breadboard, lots of switches, lots of single blue LEDs, and size blue 16 segment displays on the board. It’s for developing the 8 core Propeller Chip, and I have every intention of buying one and integrating that with the RPi. I got lots of crazy ideas…

Oh, two other little things.

1. I’ve joined the wayland-devel mailing list and I’m lurking at the moment. I want to get Wayland/Weston up and running on my RPi, either through packages, building from sources, or some combination of the two. I’m well aware of the fork of Wayland/Weston to Northfield/Norwood that occured last year, but when I went looking at the Northfield and Norwood git repositories I discovered that nothing has been done on either for nearly a year. I may just give up on Wayland and follow Canonical’s lead with Ubuntu and adopt Mir. Or maybe not. But somehow, some way, I want optimized native support of the RPi’s built-in on-chip graphics hardware.
2. I’ve switched to using Samsung 16GB micro SDHC I 1, class 10 cards. Why 16GB? Because that’s the smallest I can find locally that doesn’t cost an outrageous amount ($17 + tax). I’ve been using SanDisk and Toshiba 8GB regular cards. Of all the cards I have, I prefer the Samsung for their performance. I’m debating whether the next release will be a 16GB image compressed. I’m already pushing the 1GB upload limit as it is with my current compressed images.

How to Use Either Image

1. Download either image from Sourceforge (see links in this post or at the top of my blog)
2. Unzip on your OS of choice. They’re zipped up on Ubuntu.
3. Plug in an SDHC card of 8GB or larger capacity into your primary computer or notebook.
4. Copy the unzipped image directly to the flash card. For Linux, use dd.
5. When finished copying plug the SDHC into a Raspberry Pi. With the RPi connected to a monitor/TV, keyboard and mouse, turn it on. The RPi should boot. Note that a wireless mouse, such as the Logitech M305 or later, will work with the RPi.
6. At the console login, either login as pi (password pi) or root (password root). You should login as pi and use sudo to work rootly commands.
7. If you’ve flashed with the TWM image, start TWM by typing ‘startx’ at the command prompt.
8. Once in the desktop environment, a right mouse button on the desktop will bring up the long command menu (see screenshot above). A left mouse button will bring up a short menu of applications.
9. The xterms have menus bound to the <Ctrl>Left Mouse and <Ctrl>Right Mouse.
10. Remember that TWM was chosen for its relatively small footprint. There are absolutely no games or productivity applications. There is no browser. It’s purely a developer’s environment (i.e. editors + development tools and languages).
11. For further details read the README and wiki on the Rubus Project at Sourceforge.

Back in 2000 I was writing a Java-based portable environment I called Portable Java Environment, or PJE. Catchy name, right? My goal back then was to use Java to replace the regular Unix desktop, using only the lowest level X libraries for displaying the graphics portion. When it wasn’t running on Unix (Solaris) or Linux, it would be running on Windows as a regular application, but with all the same tooling. Thus you could switch back and forth, be reasonably productive, and not worry about differences between desktop environments. Such were the dreams back then…

The main component of that environment was the desktop which I called J-Desktop. I started to share it online, and the name morphed into Jesktop (see here and here). I tried to keep it going, but the job pressures mounted and then 9/11 came along and I drifted away from the project.

Flash forward to 2014, and I’m in need of a place to put the Arch Linux ARM images I’ve been slowly piecing together for others to download. So today I create Project Rubus and uploaded both the base and base+twm 8GB images (compressed via zip) up to Sourceforge.

The circumstances between 2000 and now are very different. My girls are now in their mid-20s and out on their own, and my job responsibilities have changed drastically. Although, ironically, I’m back at the same facility I was working at in 2000, on the same program. But the circumstances are radically different, and the program has long since shipped, and is in use.

I’ve added my Sourceforge project link to the top menu. So if you don’t want to read my rants you can go straight there and see what I’ve added to the project. Note that I’ll always blog about it here, so it might be useful to read what I have to say about the code or tools before you grab you copy.

The project has a wiki, and I usually put small announcements there. I did this time for the Groundhog Day Image Release.

As for that PJE/J-Desktop tooling, I wonder now if it would run sufficiently well on the ARM-specific java that’s available from Oracle. It’s been fourteen years since I started that project, and Java has changed drastically, especially its performance (it’s increased drastically). I’m not too crazy about any of the desktop environments that are available to run on the Raspberry Pi. Sorta makes me wonder…