Arch Linux and desktop adventures with the Raspberry Pi

It turns out that the Raspberry Pi is capable of quite a lot. I have had mine for a couple of weeks now and have been exploring what it can do, as well as taking the opportunity to broaden my knowledge (after all it is a device intended for educational use). I have been exploring desktop, server and set top box uses (the latter two I will cover in future posts) for the hardware and it has been a very interesting experience. After using the Debian image for a few days I got frustrated with the old versions of software in the Debian repositories. Don't get me wrong I admire and respect Debian greatly but for cutting edge stuff it can be a challenge. I tried to use a technique known as Apt pinning to enable installation from different branches. This worked and enabled me to do quite a lot, but I felt that maybe it was time to try a different approach so I decided to try out the Arch Linux ARM image.

I have been a Linux user for years, first on Debian then I moved to Ubuntu. Despite that Arch Linux ARM was a bit of a shock at first! Admittedly Ubuntu is really easy to use. You just install it and everything is there, little effort is needed to use the actual operating system, the complications tend to be with getting hardware working. Arch is a different story though; when you first boot it up all you get is a shell and a flashing cursor. No graphical environment is installed by default, the distribution feels almost as raw as the Raspberry Pi itself when you first encounter it. Arch bills itself as "a simple, lightweight distribution". It might not seem that way initially, but after you put in the effort to get past the initial learning curve it starts to feel that way.

You can customise and set up everything in the way you want aided by the very useful Arch Linux wiki which comprehensively covers many topics that you may encounter. Arch has a package manager called pacman which offers similar functionality to apt on Debian. The way configuration files are organised seems a bit simpler though. Also the distribution is updated through a daily release cycle - you don't have to do huge upgrades every so often or work with "frozen" versions of packages. This makes Arch great for exploring the latest releases of software.

I found a post on the Raspberry Pi forums about installing the enlightenment desktop under Arch. This worked out well, although by the time I saw the post I had already installed the X Server component. A great advantage that Linux has is that several of these graphical environment are available. It is possible to just try them and see which one you like the most! I gave XFCE (which is designed to be lightweight and work on lower specification hardware) a go using the instructions on the Wiki. It works really well so I have stuck with that. Sadly up to date versions of Chrome and Firefox are not available under Arch Linux ARM, but an up to date version of Midori is available which scores a reasonable 355/500 on the HTML5 test. However web browsing can be very slow/unusable on the Raspberry PI. At first I thought this might just be due to the limited specification of the machine but it turns out to be solvable.

The Raspberry PI has 256MB of memory which is split between the operating system and the GPU. As it is a small amount of memory by modern standards the way it is split is done really matters. The Arch distribution for the Pi by default splits the memory 50/50 which works well for a lots of things but means that web browsing is pretty hopeless. In most machines you would change this split by changing a setting in the BIOS, but the Pi does not have a BIOS so the method is different.

On the boot partition there are several files that end in ".elf". The Broadcom system-on-a-chip on the device looks for a file named "start.elf" before loading the operating system. This file also decides how the split is done. Several other ".elf" files exist these start with "arm128", "arm192" and "arm224". The number in these files is how much memory will be given to the OS (the remaining memory goes to the video chip). The more memory you give to the video chip the more it can do, but less is available to the OS so it consequently can do less and so on. How you split depends on what you are doing, a set top box type use might go for a 50/50 split, a desktop might want more memory for the OS. I backed up the old "start.elf" file to "old_start.elf" and copied "arm192_start.elf" to "start.elf" and rebooted. The difference was dramatic, Midori was now able to browse web pages in a pretty respectable fashion. I even tried it with some Javascript heavy sites and it coped. It is not as fast as browsing the web on a laptop, but is usable.

The next challenge was getting a cheap Wifi dongleworking that came with TV I own. This turned out to be not as difficult as I thought. Drivers for the wifi chipset (RT5370) are built into the kernel, although they seem to have a serious issue with speed in this case. At some point I will try out the manufacturer's driver instead. Wicd turned out to be a great way to manage the Wifi connections. It gives you not just a graphical environment that can be used but also an interactive terminal application so if you don't want to launch XFCE or similar you do not have to. A problem I have encountered though is that the Wicd doesn't set up a network connection quickly enough on boot so that the time gets set by the NTP daemon, so I have to run the command manually. I understand there is a way round this, so will investigate further.

It has been great to try out Arch Linux ARM. It feels like a Linux distribution that is well matched with the Raspberry Pi and can help to get the most out of it. It has been well worth the effort to learn it and maybe knowing how everything is put together can make it simpler in the long term to fix problems. In my next post I use the Raspberry Pi as a server and get some cutting edge web technology up and running.