Rolling-release testing



As I stated last week, I recently began an experiment where I would install, run and evaluate five rolling-release operating systems to see which ones were the most reliable. I usually shy away from life on the cutting edge, preferring to stick with fixed releases with long support cycles. These days I want most of my computers to be predictable and reliable and the cutting edge does not appeal to me. However, the idea of an evolving operating system -- one that does not need to be re-installed, one that does not have a fixed end of life -- does hold an appeal. I do like playing with new features and new applications when I'm not working and so rolling-release distributions are interesting to me.



Whenever the subject of rolling-release distributions comes up, some people report having poor experiences where their systems broke after a short time. Others report running the same installation for years without serious setbacks. I decided to try running several rolling-release operating systems to see how they performed for me.



When it came to setting up this experiment, the tricky part was going through all the choices that had to be made before I even began downloading installation media. First I had to choose which projects to cover. There are many rolling-release distributions out there and I wanted to balance having a wide variety against my limited free time. Arch Linux was an obvious choice, it is a true rolling-release and the foundation for many of today's rolling-release distributions. Though Arch carries a lengthy installation process and requires a lot of manual configuration, its position in the Linux community as an important rolling-release project cannot be denied. PCLinuxOS was another easy choice. The distribution maintains a rolling-release style, but while Arch is very cutting edge, PCLinuxOS has a conservative style to it. The distribution has a reputation for being stable for long periods of time and I felt it to be an obvious addition to the list.



The openSUSE project recently announced their Factory branch would become a rolling-release distribution and I have a great deal of respect for openSUSE's stable releases. I decided to add openSUSE's Factory distribution to my list. My decision was further helped by the fact openSUSE is one of the few Linux distributions to support automated file system snapshots to aid in recovery (or rollback) of the operating system if an update goes wrong. In an effort to represent the BSDs, I added PC-BSD to the list. This operating system features an easy method for switching between stable (Production) and rolling (Edge) repositories and also features a handy rollback feature in case things go wrong. I felt PC-BSD made for a good addition to the list and it provided a way for me to explore a desktop-oriented BSD project.



Debian GNU/Linux also made my list, largely because Debian provides a base for so many distributions. Debian's many branches are used by dozens of projects and it is hard to talk about Linux without giving a nod to the Debian project. I wasn't sure right away if I wanted to run plain Debian or a distribution which used Debian as a base. However, I decided that since I was using vanilla Arch Linux (as opposed to a spin-off of Arch) that it was only fair to run plain Debian rather than an off-shoot.



I also had to choose how to set up each distribution. It was my intention to use similar desktop environments and applications as much as possible to keep the trial fair. Since PCLinuxOS defaults to using the KDE desktop and PC-BSD will run KDE by default unless we specify otherwise at install time, I decided that I would have each operating system run KDE as the graphical user interface. I also chose to run the Firefox web browser and LibreOffice as test applications. These applications are common and complex, making them good packages to use in a test environment. I decided I would update each operating system on a weekly basis and then make sure each system would boot, login to the desktop and run these applications. If something went wrong, I would see what steps could be performed to recover the system.



Finally, I wondered about installation procedures. I was dealing with five operating systems with different approaches and philosophies. Should I attempt to install each of them in a similar manner, treating each the same, or install each according to best practices as described by the distribution's documentation? I came to the conclusion that it would be best to follow each project's documentation as closely as possible, giving each project equal treatment rather than expecting them to conform to a specific approach.



* * * * * PCLinuxOS 2014.08



The first distribution I installed was PCLinuxOS (version 2014.08). The ISO for PCLinuxOS is 1.6 GB in size. The project's main edition ships with the KDE desktop, a large collection of software and is automatically set up to be a rolling-release distribution. These features, along with the distribution's friendly graphical system installer, made PCLinuxOS the easiest of the operating systems to set up. The only potential stumbling block I ran into was the large amount of disk space PCLinuxOS requires. The project's website recommends at least 10GB of free drive space, but I soon found that I would need more space if I wanted to install applications and software updates. Once I had installed PCLinuxOS and made sure I could run LibreOffice and Firefox I followed the project's documentation and launched the Synaptic package manager in order to check for software updates. The initial update contained 159 packages and all these updates downloaded and installed without any problems.







PCLinuxOS 2014.08 - the Synaptic package manager

(full image size: 374kB, screen resolution 1280x1024 pixels)



Starting with PCLinuxOS got my experiment off to a smooth start. The distribution is very easy to install, the documentation is clear on requirements and recommended update procedures. The distribution automatically uses rolling software repositories so there is no additional configuration involved. My one concern with PCLinuxOS at this point is, by default, the distribution does not appear to offer any method for taking snapshots of the operating system. We are using standard partitions and I suspect if any low-level packages break during an upgrade it will be necessary to attempt to recover the operating system using live media.



* * * * * PC-BSD 10.0.3



The second project I installed was PC-BSD. This FreeBSD-based operating system is offered as a large download, approximately 3.3GB in size. The installation process is quite simple and PC-BSD's graphical system installer is easy to navigate. During the install process I decided to install the lightweight Lumina desktop environment with the plan of adding KDE post-install.



I installed a bare PC-BSD system and, once the initial setup was complete, I opened the project's AppCafe software manager and, using the graphical utility, switched PC-BSD's software repository from the default (Production) to the rolling repository (Edge). When this change was completed AppCafe automatically updated its package information and offered to download the latest packages. Whenever updates are performed on PC-BSD via the update manager the operating system takes file system snapshots and updates the boot loader so we can easily load older snapshots of the operating system. This makes recovery from a broken operating system quite easy. If an upgrade breaks PC-BSD we can load an old file system snapshot and switch back to the Production repository prior to attempting another upgrade.



Once I had switched over to the Edge repository and downloaded all available updates I rebooted. At this time I found I could login to my account, but the Lumina panel containing the application menu was missing. I was able to right-click on the desktop and bring up Lumina's settings to re-add the application menu. From there I opened AppCafe with the intention of adding the KDE desktop to my system, but I found AppCafe had changed a great deal and no longer appeared to be working properly. I switched to the command line and used the pkg package manager to download KDE. I found I was able to login to KDE without any problems and, later that day, I found an update to AppCafe was available in the Edge repository which restored some of the graphical package manager's functionality.



At this point I have mixed feelings about using PC-BSD as a rolling-release operating system. The project appears to change rapidly with near-daily updates to components and AppCafe has changed a lot in just a few days. The system and most key applications are still functioning properly though. Plus, PC-BSD makes recovery very easy and I can rollback any malfunctioning updates simply by rebooting the operating system. I suspect with PC-BSD I will be in for a rough ride, but be able to recover quickly from any problems.







PC-BSD 10.0.3 - switching to Edge repository

(full image size: 370kB, screen resolution 1024x768 pixels)

* * * * * openSUSE "Factory"



The next distribution on my list was openSUSE. The hardest part in getting openSUSE up and running was finding the installation media for the Factory branch which is linked to from this page in the project's wiki. The Factory branch is available in a few different editions (Full DVD, KDE, GNOME and net-install). I took the KDE edition to maintain consistency and found this installation media to be 905 MB in size. The openSUSE distribution has a very friendly graphical system installer that requires almost no effort from the user. The distribution defaults to installing with the Btr file system. Using Btrfs we can manually create file system snapshots which can aid us if we need to rollback changes to the operating system. Some configuration tools that ship with openSUSE, such as YaST, can automatically create file system snapshots and this further safeguards us against broken upgrades or user error.



Once openSUSE was installed and I had all the applications I desired in place, I went into the YaST control panel and found file system snapshots were not enabled. The YaST module which handles snapshots (yast2-snapper) informed me I first had to configure snapper from the command line. This surprised me a little as openSUSE 13.1 had automatically done this work during the initial installation. After reading the openSUSE project's documentation on basic snapper usage and the snapper FAQ, I found the information I needed. From there I was able to set up snapper and make use of file system snapshots.



The first day I was running openSUSE I opened the distribution's update manager and was told no updates were available. This struck me as unusual, given the installation media I had used was a week old. A little checking showed the PackageKit service was blocking package management, preventing the update tool from seeing available updates. I switched to the command line and ran the zypper command line package manager. The command line utility detected PackageKit and helpfully offered to stop the daemon. The zypper package manager then reported one update was available and, upon receiving my permission to upgrade, downloaded and installed the new package.



From what I have read of openSUSE's documentation it seems that Btrfs will take file system snapshots, but there isn't any snapshot integration with the boot loader. This means if an update breaks my openSUSE installation I will probably need live media to access Btrfs snapshots and restore an older copy of the file system. This not as straight forward as PC-BSD makes the process, but openSUSE appears to offer the next best approach. I like that openSUSE is very easy to install and automatically provides Btrfs as the default file system. Using the Factory ISO images means that the user does not need to manually switch package repositories after the installation.



* * * * Debian GNU/Linux "Sid"



Next up is Debian and going into this installation I had a few debates with myself. Assuming I wanted to run Debian's GNU/Linux operating system (as opposed to the Hurd or FreeBSD options), did I wish to run Debian Testing or Debian Unstable? While Debian's Testing branch would probably offer a better, more stable experience, Testing is about to enter a feature freeze and transition into Debian's next Stable release, called "Jessie". Going with Unstable would provide a more pure style of rolling-release, one that would not freeze, but Debian does not supply ISO images for Unstable. If I wanted to run Debian Unstable (often referred to as Sid) then I would first need to install Debian Stable or Debian Testing and switch to the Unstable branch. I eventually decided to install a Testing snapshot of Debian and then transition it over to Unstable.



My next issue was which ISO to download. Debian is the "universal operating system" and there are lots of download options. There is a minimal net-install disc, a few desktop editions and various sized ISO images. I also had to decide whether to install a desktop environment up front and then update it, or I could perform a minimal install of Testing, then switch over to the Unstable repository and then install a desktop environment. Debian offers, if nothing else, a lot of choice.



In the end I decided to perform a bare bones installation using Debian's net-install option. This gave me a command line environment and an installation of Debian Testing. I then manually edited APT's configuration to switch over to Debian Unstable and grabbed all available software updates. This went smoothly with just 98 MB of new packages being downloaded. I then installed the KDE desktop, the Iceweasel web browser (in place of Firefox) and the LibreOffice productivity suite.



The whole process went smoothly and I encountered no problems. I ended up with a responsive KDE desktop and a fully up to date system. I let Debian's system installer set up my partitions which gave me a root file system running on ext4. This meant I had no file system snapshots or rollback options. Debian's package manager has a well deserved reputation for being reliable and I'm counting on it to not trash my copy of Sid.



* * * * * Arch Linux 2014.09.03



The last distribution on my list was Arch Linux. Arch is well known for its philosophy of getting the user to do everything manually. This includes installing the operating system. Arch doesn't have an installer so much as a series of instructions on how to get from an ISO image of about 600 MB to a local copy of the operating system. Once we get the base layer of the operating system installed we then get to manually configure networking, install the X display server, add in such items as a display manager and add a desktop environment. This is all done from the command line, making occasional use of the nano text editor. I will admit it has been a few years since I last installed Arch and I made it a point to read through the installation guide prior to setting up the distribution.



Performing the base install of Arch involved downloading about 185 MB of packages, double checking some procedures in the project's wiki and then rebooting. Upon rebooting I found I did not have a network connection any longer and had to tinker with systemd to get back on-line. After that I downloaded about another 800 MB to enable the X display server, acquire the proper video driver and install the KDE desktop. The next time I rebooted I was brought to a graphical login screen where I was informed I could not login as the administrator, a slight problem as I had not yet created a regular user account for myself. I switched back to a command line long enough to create a new user account and then jumped back to the graphical environment in order to login. Arch provides a fairly bare bones implementation of KDE and so I went about adding a web browser and LibreOffice.



I think it is interesting to note that, technically, Arch does not really have any default settings and so whether we have an advanced file system (such as Btrfs) is largely up to the person installing Arch. The project's wiki notes Btrfs is supported in Arch's copy of the Linux kernel. However, I was not clear, having read through the documentation, if the project's boot loader would support booting from Btrfs. Further, the documentation appears to assume users will install Arch on the ext4 file system and I did so in order to keep the installation as simple as possible. This meant it was relatively straight forward for me to follow the installation instructions and achieve a running system. However, the trade-off is I will not benefit from file system snapshots and I will be somewhat at the mercy of the Arch software repositories. For the purposes of this experiment, no extra work had to be done to make Arch Linux into a rolling-release as that is the project's default configuration.



* * * * * At the time of writing each operating system in my trial has been up and running for a few days. About once a week I will update each system and take note of what does or does not work. At the moment I plan to focus on whether each system is still able to boot after an update, whether I will be able to login to a graphical desktop and browse the web using Firefox and edit documents using LibreOffice. I am open to suggestions as to other tests readers may want me to perform. During this trial I will be posting observations on events as they happen on my Twitter feed as regular updates seem appropriate for a trial involving rolling-release distributions. I will also post updates on the experience here on weeks when something of significance happens.



