Best Distribution of 2020: Arch Linux

Introduction

As usual the notion of "The Best Distribution" requires qualification because the idea of a best distribution depends on the user and their needs. For me the characteristics of a good distribution are:

Reliability

Ideally, there should not be any problem with the OS. Any problem that occurs should resolvable easily and quickly.

Current Software

Availability of current software should include desktop environments and the distribution shouldn't rely on Flatpaks or Snaps to provide current software. A rolling release is best but, regular release distributions with an adequately frequent releases can work.

Good Software Selection

Ideally, the distribution's default repository should have all of the software a user needs. If not in the default repository, a supplementary repository should be available for less popular software and one where third parties can contribute to the distribution.

Quality Packaging and Repository Infrastructure Resources

Packaging should be such that there are no errors in packaging recipes that result in blocking errors when users perform package transactions. Similarly for repository infrastructure resources (such as repository metadata).

Good Package Building System

In case, software is not available, the y should have a flexible package building systems that require minimal effort for users to learn.

Refinement in System Design

In case, software is not available, the distribution should have a flexible package building systems that require minimal effort for users to learn.

No Prioritization of Universal Packaging Systems for Providing Software

The distribution should provide all software in the systems native package format. Instead of "empowering" developers with universal packaging systems, and unburdening them from having to package their software for for multiple package formats, the distribution itself should package the software for them, and users, in the system's native package format.

Refinement in System Tools

and secondarily:

Refinement in Appearance

Good Online Infrastructure

Good Documentation

Innovation

I have installed the distributions that I regard highly, that come relatively close to meeting these requirements on my G5, and as a set provide multi-booting variety. The distributions are openSUSE Tumbleweed, Arch, Fedora KDE Spin, Kubuntu, Manjaro, and Solus. Of all these distributions the ones I think come closest to meeting my requirements are Arch and openSUSE. Because of this closeness that resulted in these two coming in at the top two spots in 2019, there will be lots of comparisons of these two in what follows.

Arch was only a close second last year and openSUSE the best because, not only did it meet my requirements, but has the one thing no other distribution has, a comprehensive system management tool in YaST. This, along with its other characteristics -- some intangible, in my view, makes openSUSE the spiritual successor to high end UNIX workstations of the late 90's and early 00's, like those from the defunct Silicon Graphics.

YaST includes a module to manage one of the unique features of openSUSE, the combination of the Btrfs filesystem and the openSUSE developed Snapper snapshot management tool that provides bootable system snapshots and system rollback capability. This YaST module -- or any of the others -- doesn't preclude using a command line interface to manage it. Arch, as a distribution that provides upstream components that users can assemble as they wish, also provides this capability -- excluding management by YaST -- as long as the user decides to set it up the Arch way during installation. Unlike Arch, however, openSUSE's installer, of course, automatically configures this feature for users during installation if the user indicates.

And this capability works well. It even worked very well the first time I used it in 2015 to restore an entire desktop environment and related applications that I had previously uninstalled. Unfortunately, the system requires a history of system snapshots and it must be enabled manually during installation by checking a box Enable Snapshots somewhere in the installer. It also worked very well this year (after doing the necessary intervention required when not enabling snapshots during installation) when I experimented with SUSEprime (see below) necessitating a system rollback to a point before my experimentation. Later, when an update broke Tex Live, restoring the system with Snapper did not fix the problem for a reason I did not investigate, but probably has something to do with configuration files in my home directory, which isn't included in snapshots. I just decided to reinstall Tumbleweed from the current installation media.

This was when I discovered the catastrophic reliability problem; openSUSE shipped a broken kernel in the installation medium that led to an unbootable OS after installation. The image below shows a Reddit post discussing the issue viewed on Firefox Developer Edition running on Arch with the same kernel version.

A Packaging and Repository Issue in openSUSE Tumbleweed

An issue of the type depicted in this image happens too frequently in openSUSE and never in Arch.

Besides, this particularly extreme reliability problem, which was only resolved after waiting some time before a new ISO was available, there were other problems. These problems led to my choice of Arch as the best distribution of 2020 instead of openSUSE Tumbleweed, the distribution I would actually prefer were it not for these problems.

My Arch Installation with the Plasma Desktop Environment

Installation

Despite all of its strengths, Arch, as a distribution that is assembled by the user during installation, is not for everyone. It is suited for users who have some prior knowledge of Linux and do not mind performing the completely manual installation from a console (the set of tty interfaces accessed by the Fn keys). It is also suited to users with less experience but who want to take the installation process as an opportunity to learn more about Linux.

The complexity of the Arch installation can be reduced greatly by preparing partitions beforehand and installing from an existing Linux installation on the same computer -- as I described in Installing Arch from an Existing Linux Installation -- but it is still not as simple as the graphical installation systems used by most distributions, especially the Calamares installer. Arch derivatives are also an alternative method of installing an Arch system that removes the manual process by providing a graphical installer. While some of these are a great convenience for users, they do make a lot of decisions for the user that may not be desirable. A distribution like Manjaro is an extreme example of this, and by using its utilities, a user may end up with a system that is not exactly what they wanted.

Although it offers a graphical installer, like Arch, openSUSE is also suited to an experienced user. The YaST installer allows complete configuration of the installed system (one example of the refinement of its system tools). This power of openSUSE's installer is such that it requires a user with some Linux experience to use it to its full potential and makes the interface much more complex than the installer used by most distributions.

An openSUSE user also has more configuration related to perform after installation due to openSUSE's policy of only distributing FOSS software. This includes adding the PackMan repository, prioritizing it properly with zypper or YaST, and if using proprietary graphics, optionally configuring the proprietary driver (see SDB:NVIDIA drivers and SDB:NVIDIA SUSE Prime).

In short, although there is a graphical tool in openSUSE, setting up an openSUSE system may be considered non-trivial, although not to the same extent as Arch.

Characteristics

Of the characteristics of an ideal distribution, at least for me, some are worth discussing in this article. These are reliability, touched upon above, software selection, the quality of packaging and repository infrastructure resources, and online infrastructure.

Reliability

Arch Linux has the reputation, in some circles, of being unreliable and that it breaks upon update. In my experience, this is far from the truth. I installed Arch on my G5 in July 2019 when I wrote a review of it. It has been reliably since then. The installation of Arch on my Acer ran for even longer without any problems until I decided to install over it.

Also, in addition to offering the same restore capability as openSUSE, and one unique infrastructure based one, mentioned later in this article, Arch Linux provides another method of kernel reliability. This is the possibility of installing a long term supported kernel on the system. At the time of this writing the default kernel version is 5.11.7 and the LTS kernel is 5.10.24. The purpose of this LTS kernel should not be confused with the purpose of other officially supported kernels available in Arch such as the hardened, and zen kernels which are at the same version as the default kernel but offer additional features, while the LTS is just a slightly older version. Having both the default and LTS kernels installed provides a backup if the default kernel version is broken.

Manjaro and Sabayon also provide the capability of installing additional kernel versions to a larger extent than Arch by making available more than just one additional kernel version. (By multiple kernel versions I don't mean the old kernels left on the system after a regular update that includes new kernel versions, but additional kernels that are installed independently.) openSUSE, in yet another example of its superior system design supports the installation of multiple kernel versions but, as I discussed in a previous article, does not make additional versions available in its repositories.

Arch is so reliable, in my experience, that the one problem I had on Arch which required me to find a solution was not attributable to Arch and was also shared by openSUSE, which was that TeX Live provided from the distribution's repository broke to the point of not being usable. But this happened in openSUSE earlier, presumably because openSUSE adopted updated TeX Live components earlier than Arch. Also, of all the distributions in which I installed TeX Live, until the time it finally broke -- after openSUSE, the one on Arch had none of the bugs I encountered in other distributions, and described in my review of Fedora 32 KDE Spin.

Apart from this problem with TeX Live, which I believe is a result of Arch, like Tumbleweed, providing the latest TeX Live components which are not as thoroughly tested as TeX Live yearly stable releases, I had no other problems. openSUSE, however, had the usual numerous annoyances, which its strengths far outweighed. Minor examples included a problem in openSUSE where the LiquidPrompt shell prompt intermittently display the system temperature, an issue I think has something to do with power management. And more major problems included openSUSE's kernel 5.8 causing VirtualBox to break, and MySQL Workbench not being installable because a particular library dependency wasn't available in the repositories. Both of these problems caused me to stop what I was doing on openSUSE and boot into Arch.

Arch had no issues.

Good Software Selection

openSUSE has a good selection of packages in its default repositories. With the addition of the PackMan third-party repository -- a necessity for making proprietary codecs available and providing alternative versions of software found in openSUSE repositories that enable these codecs -- openSUSE the software selection of available to users is extensive. Additionally many popular software titles that are not necessarily open source are available to openSUSE users in native RPM packages made available by their developers. Examples include Google Chrome, Visual Studio Code, and Sublime Text Editor. More notably, some engineering software from Dassault Systems, such as Catia Dymola are only distributed as RPM packages.

However, my personal experience in software availability has been less than ideal with openSUSE. This was with respect to installing software for my WorkForce Pro WF-4740. On Arch all software for the printer was available through the AUR; this included the necessary components for network scanning. When I tried to install the Epson software from openSUSE, necessary Qt4 libraries were not available, preventing the installation of the scanning software.

Another highlight of Arch software availability is due to an active user community in the form of the excellent optimus-manager. This software is well designed and not only performs switching of graphics cards also gives users a configurable choice of Nvidia power management options, one of which allows, as I discovered after posting The Best Distributions for Problematic Nvidia Optimus Hybrid Graphics, laptops where the integrated Intel graphics card is not connected to the HDMI port to display to an external monitor without switching to the Nvidia card. The similar solution provided by openSUSE, SUSEprime, only partially worked for my hardware.

Quality Packaging and Repository Infrastructure Resources

By "quality packaging" I mean that there are no problems in the definition of package dependencies or package dependency versions in the recipes that define the package -- PKGBUILDs in the case of Arch and .spec files in openSUSE. Problems of in these files ultimately result in errors during package management transactions that prevent the installation or update of packages. Other issues related to a lack of quality in repository resources can also result in preventing the installation and of update of packages. One such repository resource issue I occasionally encounter in openSUSE Tumbleweed is a problem with the repository metadata, one example of a repository resource, that prevents updates until it is fixed by the distribution.

One such issue related to packaging or repository resource that I experienced in the past year was a dependency resolution problem that prevented me from installing spotify-easyrpm. One of the solutions presented by zypper in order to proceed with the installation was the uninstallation of busybox-patch, a package that replaces GNU's patch command with a version provided by busybox. It turns out uninstalling busybox-patch didn't matter.

A more serious issue of this type in 2020 was dependency resolution problem due to a missing library required by MySQL Workbench. Installation of this software available from the default openSUSE Tumbleweed repositories was months after I first saw this issue it still hasn't been resolved by openSUSE.

A Packaging and Repository Issue in openSUSE Tumbleweed

An issue of the type depicted in this image happens too frequently in openSUSE and never in Arch.

The only problems in this area that I have experienced in Arch are an occasional file conflict during a package transaction. But these are always known and the resolution is posted in the front page of the Arch Linux site. Performing the posted fix which just involves running pacman with options that allow the replacement of the file in conflict will allow the package management transaction to proceed. There have never been issues in Arch packaging or repositories that have prevented the installation or update of a package.

Good Online Infrastructure

openSUSE has the most mature and most comprehensive online infrastructure of any distribution. Some examples of its strength in this area include the YaST one-click installation mechanism, the software portal which is a gateway to viewing package build details, and OBS user repositories. openSUSE even provides its OBS infrastructure to build packages for other distributions. Arch online infrastructure is not as extensive, but it provides a good set of resources such as the ability to download PKGBUIDs, mirror information, and access to the Arch Build System which among other use cases will allow users to rebuild the entire system customizing the compilation of all software, in a similar fashion to FreeBSD Ports.

One aspect of Arch online infrastructure, which I only discovered this year, was especially impressive to me -- the Arch Linux Archive. The ALA "stores official repositories snapshots, ISO images, and bootstrap tarballs across time", allowing users to install a previous version of a package, and even restore all packages on the system to a versions available in the official repositories at a specific time in the past. No other distribution has such a capability.

The rollback system on openSUSE serves a similar purpose, but it is not independent of the system, and on Arch a user who has set up a Snapper/Btrfs capability can have the same rollback capability, albeit without the option of managing it with YaST, and still use the ALA if necessary.

One other element of the Arch Linux online infrastructure also impressed me this year when I realized how much its existence improves the user experience. This is the previously mentioned Latest News section on the front page of the Arch Linux website. Not only does it provide occasional distribution news and announcements, but it provides notice of problems users may experience and provides the resolution with a description of the problem. Although I look at this news listing before I update Arch, I was struck by how useful it is after experiencing the kernel and MySQL Workbench issues on openSUSE and finding the most relevant reference to these issues being on Reddit.

Conclusion

I mentioned earlier in this article that in my opinion openSUSE/SUSE Linux is the spiritual successor to the UNIX variants at their prime found on high end workstations of the late nineties. This is due to not only YaST, something that could conceivably be found on a commercial UNIX product of that time, but to the overall refinement in its system design and system tools. zypper is one example of this refinement, with its flexibility and robust capability.

The refinement of openSUSE under the hood surpasses that of Arch (although Arch's simplicity allows for a transparency of the system to the user, a characteristic that may be as equally appreciated as openSUSE's superiority in system design). Unfortunately, while the refinement of openSUSE system tools and design can be appreciated, it does not matter if quality issues prevent its use for a particular. Many times in 2020 when I had a problem with openSUSE, some of which I discussed in this article, or with another distribution installed on my primary computer, I could always expect to reboot into Arch and that everything would work as it should. And when I did reboot into Arch everything worked as it should. For this reason Arch Linux was the best distribution of 2020.