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.