Why consider another distribution? I have been happy with Redhat/Fedora for the last 15 years. I have upgraded my systems around 30 times with new versions. In office, I use Ubuntu and find that perfectly acceptable as well. I keep abreast of Suse and Mandriva. However, they all have one feature in common. These distributions keep getting updated twice a year. A lot of excitement and curiosity is created around each new version. However, for the last few years, I want the new capabilities but find the process of upgrading too disruptive.

I was very comfortable with the OS which came with the EEPC 701. It booted very fast and had all the functionality I needed once I had installed VLC and could play x.264 video. After over two years, I finally had to change and replace it with Ubuntu Netbook Remix as I wanted to explore new browsers, particularly, Mozilla Fennec. Switching distribution was easier than making the new browsers run with the old libraries.

This triggered a train of thought – what if I wanted to create my own distribution. Should I base it on Debian, Ubuntu, Fedora or should it be something else. If something else, why? It is easy to create a custom spin with Fedora. I use it for creating a live-usb version which I use on an old system without a hard disk. Switching versions is not hard. The repository details need to be changed. But it is not transparent. It also needs all the virtually identical packages to be downloaded again.

If I create my distribution using the stable version, by the time I am ready to release it, the base has changed. Xandros had a new version out by the time I bought EEPC, which continued to use the older version.

The concept of a rolling distribution started to appeal to me. I was not looking to create an installation just for me. I was looking at the possibility of a system given to me with a pre-installed OS, which I continue to use till the system dies. Hence, ease of installation is not an issue. Ease of updating packages is important.

New releases of the major distributions provided a perfect excuse for me to experiment. A new version of Xorg appeared with a new version of Intel graphics driver. A very nice improvement unless one is working with old hardware, in which case the display often froze. The option now was to reinstall older distribution or look for an option which would allow selective downgrading of packages. At some point, support for old hardware has to go. However, I should not have to sacrifice the benefits of all new packages.

Arch Linux – First Steps

My father would painstakingly write an email taking half an hour and the display would freeze after I had upgraded my parents' machine to Fedora 12. This was the perfect opportunity for me to explore Arch Linux. I followed the instructions on the Arch wiki. Installation is pretty straightforward though not trivial. It needs some knowledge of Linux packaging. Using the package manager, pacman, was similar to using yum on Fedora. Installation of the applications my parents needed was not difficult since I knew the package names.

Arch Linux also uses the current versions of Xorg and Intel drivers. The display issues on my parents system were even worse with Arch Linux. One can easily downgrade a package by installing a lower version from /var/cache/pacman/pkg. However, since this was the initial installation, this was not an option. As expected, forums provided an answer. One post had given links to 5 packages which needed to be replaced to use of older version of xorg and intel driver on the old hardware. The problem with the intel legacy driver is that one can't switch from the graphical environment to the console environment. That is ctrl-alt-f1 etc. will not display a usable console. While it is irritating for me, my parents will never need it.

Arch Linux wiki prominently mentions the option to specify the list of packages to exclude from an update. I added these packages to the pacman.conf file, as follows

IgnorePkg = xorg-server xf86-video-intel-legacy xf86-input-evdev xf86-input-synaptics intel-dri

I subsequently had to add a sixth package to the list 'libgl'. Subsequently, I found that yum configuration file also has a similar option.

My parents' system has been current since then and has not had a problem with video freezing. Among the major changes so far - the system had thunderbird 2 when I installed Arch Linux. Now it has thunderbird 3. The system is now using the 2.6.32 kernel.

The only misstep I faced was that I installed the go-openoffice which had problems with templates. Forum posts led me to the openoffice-base as the alternate option. I then needed help to get the spell-check to work. The dictionaries are included in the distribution in /usr/lib/openoffice/share/extension/install/. But the desired ones have to be installed using the Openoffice 'Extension Manager' in tools.

I had problems gettting pulseaudio sound to work for normal users. Finally, I made them a part of the audio group till I sort out the persmissions issue.

I copied a couple of directories from the Fedora distribution - /usr/share/icons/Fedora and /usr/share/themes/Fedora. This resulted in the desktop looking about the same in Arch Linux as it did on Fedora and minimised the impact of the change on my parents.

Replicating Arch Linux

In case the systems are identical, we can create a dump of a disk image and restore it on other systems. However, I wanted to try to replicate the environment on another old system which was similar but not identical.

I took a tar backup of the root partition of my parents computer, with the plan to restore it and see the minimum changes needed to make the new system functional.

The experience turned out to be harder than I expected. I restored the tar backup on an empty partition. Changes needed to be made in fstab to use the correct partitions for root and home. Grub configuration needed changes to use the correct uuid of the root disk. After some effort, the system started to boot, but the kernel would crash. I re-installed the kernel to make sure that a fresh kernel image is built but the kernel panic would not go away.

Next step was to install the minimum Arch Linux and then restore the backup. I made the necessary changes to the fstab and grub configuration files. I had saved the installed kernel and kernel image and restored them. This time, the system booted and worked fine. It was perfect until I tried to install network manager to use the usb Reliance Netconnect. Package manager, pacman, complained. I forced it to ignore the problems and, soon, had an unusable system.

Arch Linux uses files for maintaining the state of installed and available packages in local and sync directories in /var/lib/pacman. Since I restored the tar backup, the directories now had the original files and the updated files. The result was a very confused package manager.

So, my third attempt was to install core Arch Linux. Now, I removed the local and the sync directories before restoring the backup. As before, I had saved copies of the installed kernel and image files and restored them. Although some extra files probably remained on the system, it did not create any problems. The system has been working fine.

In retrospect, it would be much easier to create a script which will install the desired packages after the core installation – much like having a kickstart file on Fedora.

Arch Linux for Organisations?

I hope to return to this topic after another six months, when new versions of Fedora and Ubuntu are out and I have played around with Arch Linux updates over the major changes as well.

Organisations crave for continuity. The cradle to grave time frame for an organisation is longer than the lifespan of any workstation. Solutions like RHEL work well for servers in an organisation. The same model is not suitable for desktops, where requirements are much more of a moving target.

If an organisation has internal skills, Arch Linux may very well be an ideal distribution to use. The admin staff can maintain a single repository. They can have a script for installing the desired applications on a fresh machine. Even though the command 'pacman -Syu' to update the system is not hard, an organisation could offer a gui to do so. Or the admin staff can make it a cron task.

If the organisation is a software development house, all the better. Developers could use virtual machines with whatever distribution and version they need for meeting the client needs. Each time a new one is needed, an image could be created and stored on a central repository. A developer can get started with the desired image immediately with negligible down time.

One downside I have already mentioned. The use of files for keeping track of the packages – installed and available is flaky. The second issue is the boot up process which does not use the init levels. It uses a rc.conf file – it is simple but different. I miss the integrations like pulseaudio and the desktop on the major distributions and the friendly admin tools. I also miss the delta packages of Fedora.

Overall though, I am enthusiastic about the possibilities Arch Linux offers and plan to continue experimenting with it. This article has been completed using the beta version of OpenOffice 3.2 available through the Arch Linux repository. Both the stable and the beta version can be installed. It is an immensely valuable option for users to very easily try the new packages for features important for them and provide feedback.