Desktop of Ubuntu 12.04, with its default wallpaper
Figure 1: Desktop of Ubuntu 12.04, with its default wallpaper

My journey through the world of Linux began in mid 2012, when I first tried Ubuntu 12.04 as a dual-boot with Windows 7 on my Dell laptop. At first, I must admit I was not impressed, as it was like I had landed on an alien planet, as I had never had any need to use a terminal emulator (or command prompt as it is called under Microsoft Windows) before. Fortunately, I persevered (although, I did return to Windows on-and-off) and after a while I became almost addicted to Linux. A couple of years later I decided to delete the Windows 7 partition on my Dell laptop and make the laptop 100% pure Linux. Since then, I have never regretted making the transition to Linux. Although, I eventually outgrew Ubuntu as it was essentially preschool with so much hand-holding that I was left out of many of the important decisions about my own system.

When I outgrew Ubuntu in mid 2015, I started to search for a new free operating systems to call “home”, using Oracle VM VirtualBox, KVM/QEMU and live USB I tried a variety of free (of monetary cost) operating systems, including:

Linux From Scratch

I have also repeatedly tried to build a Linux From Scratch system but it failed almost every time. The second last time it failed (on 28 May 2017) with Manjaro Linux 17.0 live session as the host (or bootstrap) OS and I was building LFS 8.0 and the failure was due to glibc 2.25 issues. Namely its test suite failed during this stage (chapter 6.9) giving this log. After this running:

echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

per chapter 6.10 of the manual failed as the compiler was malfunctioning. Also tried using ALFS with jhalfs-2.4 and that still failed due to kernel issues. The #lfs IRC channel was not really helpful people just said to try the manual way over and over (doing a clean start from the beginning the LFS guide) again until it magically works. I did manage to install Linux From Scratch with this effort starting on 6 October 2017 and ending 7 October 2017 and it finally booted fine, except one minor networking issue.

Distribution difficulty

I have ranked the distributions I have tried by how challenging they are to set up and use on a scale from 0 to 5. 0 are beginner-friendly distributions no more challenging to set up and use than Windows. I am unaware of any distribution that is exactly 0 on this scale. 1 are beginner-friendly distributions that are usually as easy as Windows to install, but may be a little more challenging to use post-install for beginners. Ubuntu is an example of a distribution with a difficulty score of 1. 2 have automated installers and may be as easy to set up as Windows, but post-installation they are significantly more challenging to use than Windows. Usually due to things like bugs, small repositories, poor out-of-the-box support for devices with proprietary drivers and/or difficult package management. 3 have no automated installers, but have a simple installation process, are usually installed from the command-line. Initial system configuration post-install is done from the command-line. Package management is not too easy for beginners, but it also is not too complex. Alternatively some distributions may fit this category that have an installer but with very complicated package management. 4 have no automated installer and a complicated installation process and are installed from the command-line. The package manager is complicated and builds from source by default. 5 is Linux From Scratch (LFS).

1 includes: Ubuntu and most of its derivatives like Linux Mint. Along with Chapeau, deepin, Korora, Manjaro Linux, Q4OS and Sabayon Linux. 2 includes: CentOS, Debian, Fedora, Mageia, OpenMandriva, openSUSE and TrueOS. 3 includes: Arch Linux, NixOS, Parabola GNU/Linux and Slackware Linux. It has an installer but its package management is complicated as it has no high-level package manager, by default, that is one that resolves dependencies, manages repositories and downloads packages automatically for you. Package managers that do this for you (e.g. slapt-get) is available, but it is not installed, by default, on Slackware. 4 includes: Exherbo Linux, Funtoo Linux and Gentoo Linux. 5 is mostly just LFS.

Operating systems installed on my actual hard disk

Of the operating systems listed before I have also installed the following nine on my PC, outside a VM and live session:

  • Arch Linux
  • Fedora 22/25/26/27
  • Funtoo Linux
  • Gecko Linux
  • Gentoo Linux
  • Linux Mint 18.2
  • Manjaro Linux
  • NixOS 17.09
  • openSUSE Tumbleweed
  • Sabayon Linux
  • Ubuntu 12.04-15.04 / 16.04 / 17.10
  • Void Linux (musl)

my favourite were, in ascending order:

Linux Mint

It started fine, thanks to its Ubuntu base it was easy to set up Broadcom wireless in the live session, even without inserting an ethernet cable as the required packages were already in the package cache. I disliked the outdated software though and I hear distribution upgrades between major releases (e.g. 16.x, 17.x, 18.x, etc.) often causes major breaks. I also experienced some weird bugs with the Cinnamon applet installer. I only used it for a few hours though before I gave up.


Ubuntu was my first distro so I feel very comfortable with it, despite the fact that package development under it is difficult and tedious compared to how it is on other distributions I have used. I do not presently use it but it is fairly stable.


NixOS is a fascinating distribution, in principle, but in practice it is a pain in the rear to set up for the first time, especially if you have a Broadcom WiFi chip. One pain with is the bootloader. On 17 November 2017 I set it up to use OS prober via the option:

boot.loader.grub.useOSProber = true;

and it caused GRUB2 to be only set up to boot Gentoo and NixOS properly, Arch Linux’s entry in the GRUB2 menu actually booted NixOS, not Arch. Likewise if I use Arch to manage the bootloader it did not recognize NixOS and omitted a NixOS entry in the GRUB2 configuration file. I asked for help on this on Unix & Linux StackExchange here.

Sabayon Linux

It is the distribution that I have decided to keep on my /dev/sda1 partition permanently, because it is a good fallback distribution in case the distro on my /dev/sda3 partition fails to boot or otherwise has serious issues. It is a Gentoo derivative that has a beginner-friendly binary package manager, Entropy, alongside the complicated yet powerful package manager (oriented towards experienced Linux users) of Gentoo, Portage. Its software is usually fairly up-to-date (e.g., its website claims that its software is “bleeding-edge”), although sometimes you will see a lag, sometimes due to upstream issues (see most packages in its repositories come from the Portage Tree of Gentoo. e.g., GNOME 3.18 was released 23 September 2015, yet it was not until 15 November 2015 that the GNOME Shell 3.18 was finally added to the Portage Tree) and sometimes because only two people directly maintain the Entropy Store and as there are over 13,100 software packages in the Entropy Store it is sometimes impossible for them, from a practical standpoint, to keep all of them up-to-date.


openSUSE uses RPM packages like Fedora, but unlike Fedora its system software and desktop environments are usually nowhere near as bleeding edge. This is likely because openSUSE is designed to be compatible with both servers and desktops/laptops, with the former usually valuing stability over being up-to-date, while Fedora is mostly geared towards desktops/laptops. I tend to find that installing programs on openSUSE is similar to installing them on Fedora, in terms of difficulty. Its chief advantage over Fedora is that it has a Tumbleweed edition that is essentially like a simpler (less compiling software not in the repositories from source code) version of Arch Linux, thanks to the Open Build Service (OBS). The OBS is a system whereby users can freely build and distribute packages of their choosing for any one of a variety of different distributions (including Arch Linux, Fedora, openSUSE, etc.), the main problem with it is that it cannot build packages that require Internet access during the build (like the Atom text editor, for example). I initially thought OT had fewer bugs than Arch Linux, but, regrettably, I found OT definitely has its fair share of bugs, as does its derivative Gecko Linux (Rolling edition).

For example, when I booted Gecko Linux (Rolling) for the first time, after installing it, I typed in my credentials to access the WiFi (which did not require any extra packages installed as Gecko comes with Broadcom firmware pre-installed from the unofficial Packman repository of openSUSE), from the network section of the KDE Plasma 5 system tray, and while it seemed to connect to the WiFi (i.e., no errors were mentioned) the WiFi was not available to any of my applications, including my web browser (Google Chrome, which I installed manually as it does not come with Gecko, by default) and command-line programs like ping and zypper.


Fedora is interesting to me, in that installing software packages in its software repositories is usually at least as easy as it is on Ubuntu, but installing software manually from source code or setting up web applications (e.g., MediaWiki or WordPress) tends to be substantially more difficult than on other more user-friendly distributions.

It is also interesting to me in that its system software and desktop environment-related software is usually the most up-to-date of any distribution following a fixed-release cycle, yet the rest of its software tends to lag behind the latest available release, in my experience, anyway.

It has its own equivalent to the OBS, Copr (although unlike the OBS it can only build packages for Fedora), which does afford packages Internet access during their build, if the packager grants them this. Copr also like the OBS, has strong licensing restrictions (namely, that they have to be FOSS) on any packages built and distributed through it.

Fedora is also a very touchy distribution. Not sure why but I have my suspicions it is due to safety measures related to SELinux. By touchy I mean if you chroot into a Fedora distribution (after mounting up all the necessary parts of your system like /proc, /dev and /sys) and run dnf update or any other package management command (e.g. dnf install vim) you will find that if you boot Fedora several systemd services will fail and the system will often not reach its graphical interface target (that is, GNOME will not start). I have also found that moving folders around in a Fedora root partition, even in the home folder, from another system (e.g. mounting the Fedora root partition to say /mnt) will also cause major problems when you try to start Fedora. Likewise I have also found that manually compiling software and installing it to /usr/local also tends to cause major problems.

Void Linux (musl)

I had serious runit issues and many of the more important daemons would not start including:

  • cgmanager
  • DBus
  • LightDM
  • NetworkManager even though I set up the symlinks properly, even the ##voidlinux Freenode group seemed to agree I did everything right, it is just for some reason some supervise files in /run/runit did not exist. I did like the fast boot times, though, and fast package management times.

I also had to install it from the minimal ISO (musl) as the Cinnamon ISO (musl) had the Cinnamon DE crash repeatedly on me. A dialog box kept asking me whether I wanted to restart it and I did so about four times before I said, “To … with this!”

I gave it another go though and everything went fine and dandy. I met the consequences of using the musl C standard library, namely that several characters are not rendered properly due to poor locale support. I think the problem the first time I installed it was that I was doing some package management stuff like installing NetworkManager and LightDM from a chroot so some of the symlinks were set up improperly. In retrospect I should have looked at this article on the Void Wiki.

Funtoo Linux

Funtoo Linux was the first source-based distribution I had successfully set up on my computer, outside a VM. It, for the most part, was quite an enlightening experience and it gave me the confidence to re-try installing Gentoo Linux on my PC outside a VM, after my first attempt failed quite miserably.

Gentoo Linux

I successfully installed Gentoo Linux around early April 2017 and with what I learnt from installing Funtoo Linux I found it fairly easy. I ended up switching my init system from OpenRC to systemd and using git to control my local Portage tree copy (as opposed to the default of rsync). Around late April 2017 my hard disk on which Gentoo was installed crashed and I had to re-install it. Took about two days to set up a basic, usable system with a GUI (namely KDE Plasma). I learnt that a Gentoo (testing) is quite buggy, mostly with respect to building packages. I found myself filing at least one bug report per day, until my system was fully set up (which took roughly a fortnight), with all the packages I wanted.

Arch Linux / Manjaro Linux

Manjaro Linux is a beginner-friendly derivative of Arch Linux, a Linux distribution based on the “Keep It Simple, Stupid” (KISS) principle, that is geared towards more experienced Linux users. The way it interprets the KISS principle, is that a fresh Arch install should be the barebones and that automation (e.g., there is no automated installer for Arch, by default) should be kept to a minimum. For this reason, Arch Linux was previously out of my reach, until I found some scripts for automating its installation process. Unfortunately, installing Arch on my removable drive did not go well at first (I forgot to install and configure a boot loader for it, I think), so I then opted to use Manjaro Linux in its place on this drive.

Later I managed to install Arch Linux on this removable drive and successfully boot it and then I successfully installed it on my internal hard drive (namely on my /dev/sda3 partition, with /dev/sda1 being my Sabayon partition and /dev/sda2 being my swap partition). Graphics issues caused me to delete this internal drive installation and install OT in its place. Later I deleted this installation and installed Arch in its place. Manjaro Linux uses its own repositories, which are updated approximately once a week, this is apparently to ensure the system’s stability.