The best distribution of 2019 is openSUSE Tumbleweed. This article describe some of the characteristics of openSUSE that make it so, at least for me.
The best distribution of 2019 is openSUSE Tumbleweed. This statement 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, primarily:
and secondarily:
Arch is a close second because it has all of these, but it is a special case as nearly every characteristic depends on the user except those characteristics having to do with software selection and packaging quality.
Some others that deserve honorable mention are Manjaro, Kubuntu, and Fedora. Of these Manjaro deserves special credit for its support of multiple kernel versions. It was also the only distribution that didn't require additional work to make the installation usable on the Dell G5 with respect to graphics without requiring any post installation fixes.
Reflecting my esteem for these distributions, they are all installed either on my Dell G5 or my Acer V15 Nitro as permanent installations.
But of any of these distributions or others openSUSE is the only one that has all of these characteristics to the largest extent, while some of the others have only some of these characteristics.
openSUSE Tumbleweed has always been reliable when using ext4. There was a time in 2015 when I had not allocated an adequate amount of space for the default btrfs file system and before openSUSE added automated cleanup of automatically generated snapshots, when the filesystem ran out of space requiring intervention to restore functionality. Since then I have started allocating enough space for the btrfs formatted root partition, and as a result I have never had a problem with using btrfs. And I have never had any other problem that I couldn't resolve in less than a minute.
The largest problem I have faced with openSUSE in the past few years has been a segfault during a zypper dup operation, requiring a rebuild of the RPM database with the command: rpm --rebuilddb and cleaning the package cache with zypper clean -a Other minor problems included oversights on the part of packagers that resulted in errors during transactions, described below.
To be fair to the other distributions I mentioned above, none of them has given me any reliability problems, with only Arch requiring me to enter a couple of commands for manual intervention due to packaging changes. These required the same amount of time as it took to fix openSUSE problems.
For a long time, before desktop environments provided similar capability, openSUSE has included launchers for a terminal and file browser with a root profile. When using these launchers, after an initial root password entry, users could execute commands or perform file operations as root. More recently, of the distributions that were installed in the Acer and Dell laptops, openSUSE was the first to implement an integration of the distribution's logo and progress spinner into an OEM's firmware splash screen. (Fedora 30 followed shortly thereafter.)
Over many months I had been considering Arch, Fedora, Manjaro, and a lately -- Kubuntu as a possible recipients of the Best Distribution of 2019 title. All of these distributions are worthy of such a title, but this small attention to the refinement by the distribution was what prompted me to select openSUSE as the best distribution of the year, over some of the others I considered including .
But the distribution's refinement goes far beyond this stylistic refinement to more substantial refinement in its system tools and system design. In my opinion, and for my sensibility, this is where openSUSE stands out among the other distributions considered, and even any distribution.
The package management is very advanced, powerful, and flexible. As evidence, consider the system package management configuration, set through a master configuration file -- /etc/zypp/zypp.conf -- applicable to package management generally and to all package management tools. Many aspects of package management can be configured just through this file. The CLI package manager -- zypper -- is configured through its own configuration file, /etc/zypp/zypper.conf. One feature of this configuration file I appreciate is the ability to configure the output. For anyone interested the configuration file names in this paragraphs are links to actual files.
In addition to these files the overall package management is simple (or, elegant) for the level of advanced features. For example, repository prioritization is included in the repository definition and the priority can be set in the command that adds the repository itself, without any need for the complex pinning process of Debian based systems, but not as simple as Arch. The zypper commands themselves are rational and simple with all functions accessed through a simple form of:
zypper --options command --command-options
without the need for plugins and related programs, as in Fedora and Debian based distributions.
Another unique feature of of zypper is the informative message when updates will require a system reboot (screenshot 9, above). Recently there has even been an improvement that even provides the packages that necessitate a reboot before the user confirms acceptance of the update (screenshots 4, 5, and 6, above). An additional command zypper ps -s that gives a detailed list of running programs and services that have been updated and would benefit from a reboot. These feature are ones that users of other distributions miss.
Besides this, the output of the package management is very rational in the information that is provided and how this information is presented in the terminal. The normal
zypper dup
output (screenshot 5, above), before the user accepts the proposed transaction, displays packages that will be upgraded, packages that will be installed, packages that will be downgraded, packages that will be uninstalled, packages that will change architecture (x86_64 to noarch, or vice-versa), highlighting the first letter of the package name (configurable in /etc/zypp/zypper.conf). If using
zypper dup --details
the pre transaction summary outputs this information (screenshots 3 and 4, above) and additionally the repository that each package comes from, in a tabular easy to read layout as opposed to the hard to read output of dnf and apt.
The package management is integrated into the best and only comprehensive suite of GUI system management tools -- YaST. This is more beneficial to Leap users than Tumbleweed users as YaST software management, unlike the package kit based applet, will not do a zypper dup -- which updates Tumbleweed to a new snapshot -- instead doing a zypper up. But it is useful package search with very informative views of specific packages. It is also very useful in switching system packages from the openSUSE repositories to the Pacaman repositories after this has been added with the appropriate priority. Switching system packages means reinstalling packages that were initially installed from the openSUSE repositories from the Packman repositories. Some of the YaST package management functions most useful to Tumbleweed users and the screens on which they appear are presented below.
For more on openSUSE package management see, Repository Management in openSUSE.
YaST doesn't replace system management through CLI tools even for Leap users; YaST modules can be used through a CLI interface and underlying system tools are available in more direct CLI forms.
One other example of openSUSE refinement and maturity in system design is the use of a /etc/sysconfig directory of files for storing variables used by the system and applications. These can be edited manually using a text editor, with the YaST Sysconfig Editor, or the CLI version of this module used with a command like, for example,
yast sysconfig set DISPLAYMANAGER=gdm
A similar functionality is the YaST Alternatives, also with an ncurses interface, and an underlying command line tool. Some screenshots of these tools are below.
Software selection in the default repositories is good in openSUSE, but it is not the best. There are a few programs that I regularly use that are not available in openSUSE. In the past, glances was not available in Tumbleweed and Filezilla was strangely not available in Leap 42. Currently, Kvantum is not available in the default Tumbleweed repositories.
New users will also find that proprietary codecs and drivers are not available in openSUSE's official repositories due to its strict adherence to licensing restrictions. Software that relies on these codecs that are installed from the official repositories are missing the functionality provided by these codecs.
Fortunately, there are solutions that resolve these issues. First, openSUSE has a very robust infrastructure for users to build packages and host repositories. I used one of these repositories to install Kvantum, one of the alternative theme engines available for the Plasma desktop. Second, the Packman repository is available for proprietary codecs and a large selection of software that relies on proprietary codecs and other components for functionality. Such software from the Packman repositories can replace those from the default repositories by clicking "switch system packages" in YaST. The priority of the Packaman repository can be set so software from Packaman always takes precedence. Without the third-party Packaman repository to provide proprietary codecs and to replace software from the default repositories that use these codecs with those from the Packaman repository, it would not be possible to use openSUSE as a general purpose OS.
Additionally, thanks to its maturity, many major third-party developers provide RPM packages and repositories that can be used by openSUSE natively. Examples are Nvidia repositories for its proprietary Linux drivers, a Google repository for Google Chrome and, a Microsoft repository for Microsoft's Visual Studio Code. Conveniently, many third-party software, such as Atom Text Editor and Google Chrome, have downloadable RPM packages that when installed will automatically add the respective repository to the system.
Quality of packaging is good. In my experience especially complex package sets, such as TeXlive, with many parts that are needed for the software they provide to work well and packages requiring configuration provided by scripts run during installation are well executed. However, there are occasional problems with packaging that seem to be caused minor oversights on the part of packagers in changing a dependency version or similar oversights that I don't encounter in other distributions. The following two excerpts from zypper transaction outputs illustrate the type of errors. In both cases I didn't need the software and could uninstall them.
17:44:30 θ63° [brook@G5-openSUSE:~/DataEXT4 … /MultipurposeServer/OrdBook] master ± sudo zypper dup --details [sudo] password for root: Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade... Problem: python3-notebook-6.0.2-1.1.noarch requires python3-tornado >= 5, but this requirement cannot be provided not installable providers: python3-tornado-6.0-12.1.noarch[repo-oss] python3-tornado5-5.1.1-2.1.i586[repo-oss] python3-tornado5-5.1.1-2.1.x86_64[repo-oss] python3-tornado6-6.0.3-2.1.i586[repo-oss] python3-tornado6-6.0.3-2.1.x86_64[repo-oss] Solution 1: Following actions will be done: deinstallation of python3-notebook-5.7.8-3.4.noarch deinstallation of jupyter-widgetsnbextension-3.5.1-1.1.noarch Solution 2: deinstallation of python3-tornado4-4.5.3-2.1.x86_64 Solution 3: keep obsolete python3-notebook-5.7.8-3.4.noarch Solution 4: break python3-notebook-6.0.2-1.1.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/4/c/d/?] (c):
Installation of exim-4.93-1.1.x86_64 failed: Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /usr/share/doc/packages/exim/doc/cve-2019-13917: cpio: File from package already exists as a directory in system error: exim-4.93-1.1.x86_64: install failed error: exim-4.92.2-1.1.x86_64: erase skipped
openSUSE's Plasma implementation is regarded as one of the best. One indication of its quality us the integration of the update applet into the system tray, which in the past did not perform the
zypper dup
distribution upgrade command required by Tumbleweed, performing a regular
zypper up
update, as in Leap. Now it is possible to upgrade to a new Tumbleweed snapshot directly from the applet. As an additional indication of a good Plasma distribution, openSUSE Tumbleweed implements Discover, Plasma's native GUI package manager as well as Kubuntu.
Not only is the integration good, openSUSE Tumbleweed always makes new versions of Plasma available shortly after release by KDE, sometimes before Arch, sometimes a few days after. In the case of Plasma 5.14 which was released around October/November of 2019, it was available in Tumbleweed a few days after Arch, while Manjaro and Fedora delayed its availability for weeks. Plasma's importance to openSUSE was evident even during the initial release of Plasma 5 in mid-2014, before it was really usable, when openSUSE provided it in one of its extra repositories.
openSUSE has the most mature online infrastructure of any distribution. It allows users to view all package build details, including build status and results, the .spec, the inputs to the .spec file including patches to the software being built, and even download the prebuilt package from this package information view.
One of the ways this package information can be accessed is through one of the best features of the infrastructure, the software portal, a link to which appears in the openSUSE custom Firefox home page. From the portal users can search for software from official, user, or third-party repositories and install a package using YaST's 1-Click-Install capability, or download the package.
The distribution even makes the Software Portal and the openSUSE Build Service available to packages of other distributions, see Good Package Building System, below.
Before openSUSE was split from SUSE, the distribution provided a set of printed books, through which users could learn all of the details of the distribution, providing a good overall knowledge in various areas of the system as opposed to a very specific topic based knowledge provided by an Arch wiki search. The books are still available, officially applicable to openSUSE leap -- but still relevant to Tumbleweed -- in many formats including downloadable PDFs and ebooks and an html version.
openSUSE also provides what it calls wiki. It is more than a wiki as it provides a hub for many types of content for a subject, such as in some pages a central location for developer documentation. The wiki is organized into Portals and Support Data Base (SDB) articles. The portal pages contain general information as well as links to various types of documentation such as SDB articles and tutorials.
While many of the pages have been modernized in terms of appearance, these pages are still disorganized in terms of structure and navigating these pages in a rational way was hard for me. The main page of the wiki has general information on the major components of the project itself. One level deeper in the Distribution category there are links to some useful information sources such as the official documentation and basic guides. This doesn't seem like a good way to organize the information. Also, while dividing the wiki into portals as a hub for different types of documentation is excellent, there was a lack of uniformity to the portals and some SDB articles were not part of a portal.
Despite these problems, there is some essential information on the wiki that supplements the excellent and thorough information provided by the books. For example, there are portals for YaST and Snapper and an SDB article on installing Nvidia proprietary drivers.
openSUSE uses the RPM format which uses the powerful and flexible rpmbuild along with the recipe for package building, the .spec file, in a command of the form:
rpmbuild -bb name-of-package.spec
For more on building packages locally see Build an RPM Package for Installation and Management by the System Package Manager
For advanced users, openSUSE also provides as part of infrastructure a client/server system to build packages on the openSUSE Build Service using the command line client.
OpenSUSE Tumbleweed and the regular release of variant of the openSUSE, Leap, also are the first adopters of new technologies. openSUSE was among the first distributions to include systemd and Secure Boot. More recently it also supports the Trusted Platform Module.
Another new technology, embraced by openSUSE, but eschewed by other distributions has been the btrfs file system. This file system along with the snapper snapshotting tool allows users to rollback an openSUSE installation to a previous state. This rollback feature is impressive in its effect. In 2015 the last time I used it, it was able to restore a system to a previous state that included a whole desktop environment that I had uninstalled. The impressiveness was due to the perception that many people would have that when software is uninstalled it is gone forever. btrfs and snapper bring it back magically.
Some believe that btrfs is unstable or unreliable, but I have been using an installation of openSUSE Tumbleweed with a separate /home formatted to the default XFS and / formatted to the default btrfs with the default subvolumes since May since I upgraded to an NVMe SSD on my Dell G5 without any problems. The only precaution I have taken is to give 75 GB to the root partition as opposed to my typical allotment of 25 - 35 GB to the root partition when using ext4.
Despite its excellence openSUSE is not perfect. In addition to the rare, minor, and easily recoverable repository metadata and packaging issues, some users may find that it is sometimes too bleeding edge, especially in the cadence of its kernel updates.
This sometimes is ahead of third-party software support for the latest kernels.[1] If openSUSE Tumbleweed as a distribution would support at least an additional LTS kernel, something even Arch does, let alone multiple kernel versions as do Manjaro and Sabayon without any problems, it would benefit users who need some options in available kernels.[2].
openSUSE Tumbleweed provides users with a refined, flexible, and rationally designed distribution with the latest software and a comprehensive one-of-a-kind system configuration utility -- YaST. It has historically incorporated the latest Linux technologies such as Dracut, Secure Boot, systemd, and lately it supports the Trusted Platform Module which is not supported by any other distribution.
It also features the unique innovation not found in any distribution the Btrfs/Snapper system snapshot and rollback utility developed specifically for Linux that allows something similar to Solaris boot environments.
When I suggested multiple kernel support in openSUSE in a past post to allow use of VMware in Tumbleweed, one die-hard openSUSE users suggested that I use different virtualization software and that the problem is with VMware and not openSUSE and that this was a case of the "tail wagging the dog." While it is true that VMware speeding up support of new kernels would resolve this issue, I thing that the case is the opposite, with the distribution forcing a certain workflow on the user instead of being responsive to user needs. This particular issue is not a problem in what is regarded as the most bleeding edge distribution, Arch.
↩The former openSUSE chairman indicated that the extra work in maintaining and testing additional versions of kernels prevents multiple kernel version support in openSUSE.
↩