Solus 4.1 Fortitude Review [Plasma Edition]

Review

A good distribution, in addition to the actual experience of using the OS, requires a good experience with regard to its online resources. Using the Solus website to find download links, SHA checksums and GPG signatures, and verification instructions was good; everything was easy to find and instructions were clear and direct.

Unfortunately, moving on past the pre-installation activities to the actual installation was very problematic on the laptop on which I wanted to install Solus 4.1, the Dell G5 with an Intel Core i7-8750H processor, an integrated Intel UHD Graphics 630 integrated graphics processor, and a discrete NVIDIA GTX-1050 Ti mobile graphics processor. The live environment (as well as the installed system) loads the Free and Open Source Nouveau driver kernel module by default, which is not usable on this laptop's hardware. The use of this driver resulted in an erratic system in terms of window and pointer behavior. After several frustrating attempts I realized the way to avoid this problem when starting the live environment was to prevent the Nouveau driver kernel module from being loaded by modifying the kernel command line options from the systemd-boot boot menu. (This procedure for preventing Nouveau being loaded in the live environment and the permanent modification required in the installed system are described in Solus 4.1 Fortitude Review [Plasma Edition] Supplement: Fixes and Enhancements.)

To provide a good experience for users of NVIDIA hybrid laptops, the developers could have added an alternative boot option to the systemd-boot menu for NVIDIA users that does not load Nouveau. For users that choose this option -- if it were available -- on the boot menu, the settings could be carried to the installed system instead of requiring users to do this after installation. They could even go further and do what Manjaro does and preconfigure everything based on the choice at the boot menu.

Installation is not problem free even for users without NVIDIA graphics hardware. The installer, while simple and easy to use, does have a tendency to hang on the disk setup step with the message "examining local storage devices". I had to restart the installer numerous times before the installation would get past this step.

After finally managing to install the distribution, I noticed that this release, at least the Plasma Edition, is somewhat unstable. Specifically, whenever a package management operation is performed the ability to "tap to click" is lost despite the setting being activated in the touchpad settings. I've observed variations of this problem numerous times, and in at least one instance after rebooting, the relevant settings were unavailable, but strangely the touchpad tap to click was working.

The Touchpad Configuration in the Input Devices Component of Plasma System Settings

Tap to click would stop working after package management transactions and in at least one case after reboot the relevant settings were also unavailable.

• First after installing tlp the system lost touchpad capability entirely and the touchpad settings disappeared from Plasma System Settings.
• Later after rebooting and installing VirtualBox "tap to click" would not work although, this time, the relevant settings were displayed in Plasma System Settings and the "tap to click" was enabled in the settings. Disabling and re-enabling "tap to click" in the settings, resolved the issue.
• Until later after about two weeks of not using Solus I updated the system and again "tap to click" would not function despite the setting being enabled in Plasma System Settings. Again disabling the feature and re-enabling it resolved the issue.

This issue doesn't exist in the other distributions I use regularly.

The touchpad problem is probably a transient issue that will probably be fixed in upcoming updates and future releases, but for existing installations I have a feeling that resolving this issue may require editing some per user configuration files or copying updated configuration files from /usr/share/plasma or somewhere similar to the user's directory.

Another problem involved the default systemd-boot configuration. As configured by the Solus project, unlike in the live environment, there is no boot menu in the installed system.^[1] The documentation states that pressing the spacebar during boot will display a boot menu, however, it acknowledges that it is difficult to press the spacebar at the precise timing. In any case, for users of laptops with similar NVIDIA hardware it is critical to be able to access the boot menu in order to be able to disable the loading of the Nouveau driver, at least for the initial post-installation boot before the module can be permanently disabled from the installed system. The procedure to add kernel command line options, based on the Solus documentation, and the kernel options to include, based on the documentation of other distributions, is described in Solus 4.1 Fortitude Review [Plasma Edition] Supplement: Fixes and Enhancements.

The Solus project, despite its stated goal of providing "a multitude of experiences that enable you to get the most out of your hardware" and aiming "to provide the best experience for your device" completely ignores the needs of users with devices that have recent hybrid Intel/NVIDIA graphics. As I mentioned above, neither the live environment nor the installed system is usable without intervention by the user, contrary to another project claim: "get going without a lot of setup fuss" (although technically this refers to not having to install software and not to configuration). I came to this conclusion, after doing the necessary blocking of the Nouveau driver, when attempting to find a way to ensure that the NVIDIA graphics processor is switched off in order to increase the sub standard -- subjectively -- battery life on Solus.

Solus not only does not save users "a lot of setup fuss" by configuring one of the available switching mechanisms, as does Manjaro with a fully configured Bumblebee solution, as do various Ubuntu flavors and Linux Mint which provide a new tool that supports NVIDIA PRIME, but does not even provide any documentation of how one would go about enabling such functionality. An example of such documentation that succinctly and completely guides users on this is the KaOS documentation page entitled Hybrid Graphics Systems. Even openSUSE Tumbleweed which does not provide proprietary drivers by default has documented methods of configuring Bumblebee, providing the necessary software components from optional repositories. It now seems to have a more modern solution similar to Ubuntu's.

The lack of hardware support without "a lot of setup fuss" was a real problem for me. But the real problem -- one that may be insurmountable for potential Solus users -- many of whom may not have the complicated hardware support needs -- is the unavailability of certain packages on which they rely. Before providing a specific example of software that I think should be included, but is not, based on my current experience with Solus, I should note that when using Solus 3.9999, I requested the missing KColorChooser to be packaged. The developers accepted my justification for its inclusion and made it available in the next update cycle. This time however I made no request for the particular software I needed because a request for the same software from another user was denied.

The software in question is Kile, a very advanced LaTeX editor with features I find superior to the next best LaTeX editor available on Solus -- TeXStudio, Also, as a KDE application, it uses the modular components of other KDE applications such as Kate, Konsole, and Okular. Additionally, it integrates with the Plasma desktop visually as it can easily use available Plasma color schemes for the application and syntax highlighting as well as the widgets provided by KDE Frameworks.

The reason for denying the request to include Kile was, initially, the lack of a stable release of Kile with KDE Frameworks 5 (KF5) support. The lack of KF5 support in Kile clearly is not an issue now since I was able to build Kile using the KF5 components currently available in Solus as dependencies of the build. Later the reason became, in addition to the lack of KF5 support, that there had not been more development commits since the last release, which may not be an issue anymore either.

The lack of Kile in Solus repositories, now that it supports KF5, could be an issue with the latest version of Kile available from upstream in that it is tagged as 3.0 beta 3, while the source tarball is indicates version 2.9.93, but this is not something that can prevent packaging the software; it certainly has not been an issue for other distributions as I have been using it regularly in Arch, openSUSE, Fedora, and even Sabayon.

Some reviewers feel that the unavailability of some packages is due to the Solus Package Inclusion Policy, but I think it is due to other factors. I think primarily it is a lack of an automated -- or more automated -- process that tracks upstream releases and builds packages automatically. As a result, more hands on activity is required for packaging taking up developer time, something that is mentioned in the packaging policy. There is also no automated way to track expired requests, again requiring Solus developers to manually review expired packaging requests, the impracticality of which is also mentioned in the packaging policy.

I mentioned in passing, above, that I built Kile myself using the Solus package build system for installation from a custom local repository using the Solus command line package manager, eopkg. (Read about this in Building a Package on Solus for Installation by eopkg from a Local Repository.) Although the developers encourage users to contribute missing packages they build using the Solus build system for the benefit other users -- and even provide a good video and written tutorial series, I don't think most potential users will want to go to the trouble of packaging software that is not available in the repositories. But for the few who commit to Solus and are willing to use it, the package build system is good and easy to use, and seems to have conveniences not found in other systems such as Arch's PKGBUILD and makepkg combination or rpmbuild. Unfortunately, its focus is on building packages for Solus's unstable branch for contribution to the distribution and does not provide as many conveniences for the additional use case of building packages locally for installation by eopkg from a local repository. To learn what I mean by this read the article linked above.

Solus also has a problem that may prevent some users from adopting it for long term daily use in that the there is a general lack of maturity that is necessary for certain types of productivity. In my I case, in addition to the lack of certain software that I think should be available -- even taking into account the goals of the package inclusion standards -- is the lack of multiple versions of nodejs. Distributions such as openSUSE, Fedora, and Arch make different versions of this software available, a sign of their maturity and suitability for more than casual use. Fedora even goes farther with the modular streams concept that allows multiple versions of various developer-centric software available.

All of the issues I discuss above are actual problems in the usability of Solus, either the distribution as a whole, or in one case, just the Plasma Edition. But one other thing I was surprised and somewhat troubled by with was how much the developers and some members of the community emphasize that Solus is independently "built from scratch". Although the distribution does have its own infrastructure -- part of which is Phabricator, developed by Phacility, compiles its own kernels and packages, developed its own GUI software center, and most importantly developed its own desktop environment, Budgie, to claim that it is entirely built from scratch is not completely accurate. The core of Solus, the eopkg command line package manager relies greatly on the PiSi package manager developed by Pardus Linux before it abandoned the project in favor of Debian's advanced Packaging Tool (APT). Also, the package metadata generated by Ypkg ultimately ends up in a PiSi xml resource for use in repository indexing. Most tellingly, eopkg installation errors produce a traceback from the PiSi Python 2.7 package.

• 
• 
• 

Solus Relies on PiSi In Its Package Management

Image 1: The repository index of the custom local repository I created for locally built packages. Image 2: The eopkg python executable imports pisi modules exclusively apart from system related modules. Image 3: pisi modules imported by eopkg come from Python 2.7 system site-packages. Note that the license header indicates a copyright by "TUBUTAK/UEKAE", the Turkish institutions that originally developed PiSi for Pardus Linux.
Click on any of the thumbnails to view a slideshow of the images.