Celebrating Linux Diversity

Some time ago I wrote about excessive forking, how it dilutes out human efforts and leads to duplication of results. Embarrassing as it is, I have to admit that my judgment was clouded and procured far too hastily. In my musings I have neglected the positive aspects of forking and producing re-spins of popular distributions. This was brought to my attention by a recent article on DistroWatch.com, as part of the Distro Watch Weekly series.

One of the key features of Linux-verse and the open-source community in general is freedom. Programmers, developers and the like are not limited by ‘egoistic’ corporate agreements and copyright claims. Naturally, too much freedom may lead to waste of resources, but this is greatly overshadowed by the real consequence – evolution.

In the animal kingdom various species developed different mechanisms of adaptation, connected tightly with the size of their progeny. On the one hand, we have us, humans. The offspring we ‘generate’ is small in number, but we try to compensate for that with the care the children are given. As a result, children learn from the experience of their ancestors and from their own. That is how we handle evolution. On the other hand, we have insects. They are fragile and much more susceptible to environmental hazards than us. Hence, the progeny has to be sizable enough to warrant survival of a species.

What I personally find very interesting is that the Linux-verse is a combination of both of those models. We, humans, produce distributions based on past experience, but those distributions are like insects. Many have to be produced and many have to ‘die in vain’ for only a handful to ‘adopt’ and become truly successful. This is sometimes a curse, but mostly our salvation.

Let us then enjoy the diversity of the Linux-verse and allow things to sort themselves out naturally. Through natural selection.



The Source of Them All…

For quite a while now I have been considering source-based Linux distributions. I believe they pose the highest level of difficulty in terms of installation and maintenance. Since I strive to understand Linux fully, they were the logical next step on my path. I had already tried Gentoo and Sabayon some months ago, albeit without much success. However, with newly gained knowledge I felt much more confident and skilled. I knew that this time I would succeed…

The source-based model is not so popular anymore, because it entails time-consuming compilation of most or all software packages, followed by extensive manual configuration. Currently, there is Gentoo, Sabayon, Lunar Linux, Calculate Linux and some other less known distros. Since I read some complaints regarding Lunar Linux installation, I decided to give Gentoo a second (or maybe third?) go.

This time around I decided to follow the official Gentoo Handbook to the letter, though with some improvements on my part. The default method is to use one of many Gentoo’s liveCDs and start from there. Alas, the interface offered is entirely console-based and some things are rather inconvenient (copy-pasting, web-browsing, etc.). Hence, I decided to start from an ArchBang liveCD (sorry, Archie!). The installation procedure was essentially the same (mounting hard drive partitions to local folders on the liveCD medium, downloading and unpacking the Gentoo environment, etc.). The only point when it differed was when I had to configure Portage mirrors manually, because ArchBang’s liveCD lacked the required software. To be fair though, there was a single bottleneck during installation – setting up GRUB2 on an EFI partition. For reasons unknown to me, this was improperly documented in the Handbook. Two vastly different procedures were suggested and the Handbook itself promoted setting up GRUB2 on the Master Boot Record (MBR) of the drive. Unfortunately, UEFI in its default mode forces the user to rely on an EFI partition for bootloader installation, though using MBR is possible.

Compiling the kernel was a particularly interesting experience. I had to spend roughly 3-4 hours going through all of the options to understand what Linux does and doesn’t support. Though time-consuming and mundane, I prefer building my own kernels with selective hardware support, rather than using a possibly bloated distribution kernel. This is especially convenient for laptops, which can hardly be customized. Surprisingly, it was not the most time-consuming step during Gentoo maintenance. Software installation was…

Looking at compilation times across package versions, I immediately noticed that the statistics are quite discouraging. For instance, Firefox, being one of the major offenders, takes approximately 1-2 hours to compile. On my setup (core i3, 4GB RAM) it took 4 hours, even though I disabled many options (USE flags) prior to compilation. The KDE desktop or Libre Office are even more problematic. Many Gentoo users leave such updates overnight.

Then it struck me. In its stable repositories, Gentoo does not offer packages equally ‘bleeding edge’ as Arch Linux. The software versions available were exactly the same as in Debian Sid. Perhaps the kernel, among few others, was more recent. Furthermore, as many users before me observed, the boost in speed and responsiveness was marginal. Thence, I found it amusing that each of us Gentoo users would have to pay with their time and their computers’ processing power to reach the same result as Debian developers, when building software packages for the Linux populace.

All in all, I believe it was worth it. Gentoo Linux is like a boot camp for aspiring Linux developers. It teaches Linux, but teaches hard. The lessons I learned from setting it up will become useful in the future, no doubt. However, since the dawn of x86_64 computers, compiling software locally for better performance is no longer advantageous. Rather, it presents a viable alternative to those paranoid about unnecessary features in an operating system, such as me.

Next destination – Debian!