The release of Solus 4.1 Fortitude adds an official Plasma based variant of the distribution, the existing Mate, GNOME, and flagship Budgie editions. As the release announcement states:
We’re proud to announce a new addition to the Solus family: Solus Plasma Edition. Solus Plasma Edition has been a long sought after experience by current and prospective users alike, melding our ability to create a curated out-of-the-box experience with the sophistication of the Plasma Desktop experience.
Having used Plasma in Solus in the past -- by installation from the repositories, when it initially became available, and from the Plasma Edition testing ISO -- and generally having a favorable impression of the experience, I decided to install it again from the newly available official Plasma Edition ISO.
This article reviews Solus 4.1 Fortitude Plasma Edition released on January 25, 2020.
In my review of Solus 3.9999 Budgie Edition, I presented a generally favorable impression of the distribution. At that time Plasma had just became available in the Solus repositories, and as one who appreciates this desktop environment, I installed it from the newly available packages in the repositories. When a Plasma Edition testing ISO was released, I installed it on my Acer, and later when I got the Dell G5, I attempted to install it on the new laptop. Unfortunately -- for reasons I discovered in installing Solus 4.1 Fortitude Plasma Edition this time -- it was not usable. Because of this and also because of the undesirable default behavior of Solus's chosen boot-loader, gummiboot -- a fork of systemd-boot, now replaced with systemd-boot itself -- which is not conducive to multi-booting when there is another distribution installed that uses one of the systemd-boot variants (in my case KaOS), I gave up on Solus.
Now that an official Plasma Edition ISO is available, and having heard some positive comments about its performance, I decided to try it again. This time, however, I have worked through the issues that made it unusable on the Dell and learned how to alter the default behavior of systemd-boot to avoid frustration when mult-booting with other distributions that use systemd-boot.
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.
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. 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.
In the third image, above, depicting the /usr/bin/eopkg-cli the license header indicates a copyright by "TUBUTAK/UEKAE", the Turkish institutions that originally developed PiSi for Pardus Linux.
Read more on the relationship between PiSi and eopkg below in the Package Management section.
Like Sabayon, Solus is appealing to me as a novelty for its uniqueness. I could envision using it on my secondary or tertiary laptops where I don't engage in serious tasks such as editing a complex LaTeX document or a web development project with certain requirements. I actually used Solus for a long time on the Acer, and based on that experience it was one of the first I attempted to install on the newer Dell. However since then my needs have changed in a productivity laptop and my opinion of Solus has evolved at least in terms of productivity use, Nvidia hybrid support notwithstanding. Now I find it lacking in two areas for serious use, even discounting the quality oversight with respect to the touchpad issue and the package inclusion policy and practices -- that indicate that the developer and contributor base is too small -- possibly deterring potential users
First, it is obviously a work in progress that does not have the suitable maturity of something like openSUSE for example. Consider:
The one thing that impressed me during this recent time with Solus is the package build system. It is innovative and automates and simplifies the package building process. Unfortunately it focuses on the experience of contributors to the distribution and either does not seem to consider the experience of users who simply want to package for installation from a local repository or is not flexible enough for this use case without having to work around its focus. Other build systems are more flexible to more easily allow for this.
So, I would recommend Solus 4.1 Fortitude Plasma Edition for casual use and for multi-booters who want to try something new, but only for those who don't have relatively new NVIDIA based systems, as the developers don't detect and make the necessary configuration adjustments for this hardware.
As far as for certain types of productivity use cases, I would not recommended it. I came to this conclusion after having worked around the initial disappointment of the lack of my preferred LaTeX editor by building Kile and deciding to use the Solus installation to write the this review in one Plasma activity and work on a web development project in one of the data partitions of the Dell G5 that was started with nodejs version 10. As Solus only provides the latest version of nodejs and not the last three releases as many other distributions do, I gave up this notion in frustration and rebooted into openSUSE to continue working on these two task. Even Sabayon, which seems to have evolved into a distribution that is developed for the developers themselves, offers multiple versions of this important software. That distribution will remain on the Dell G5 -- along with openSUSE Tumbleweed, Arch, Fedora, and Manjaro -- to satisfy my occasional desire to use a unique distribution and Solus will be replaced with Kubuntu when 20.04 is released.
So I can't recommend Solus for the more productivity centered use cases that are similar to mine.
|Installation Types||Live ISOs with included installer|
|Desktop Environments||Budgie, Plasma, Gnome, Mate|
|ISO Environments||Budgie, Plasma, Gnome, Mate|
|Package Manager||eopkg CLI or Software Center GUI|
|Package Build System||solbuild|
I am not discussing package management in this section of the article as I discussed it elsewhere in the article and in my prior review of Solus in the Package Management section of Solus 3.9999 Review.
But I will describe other notable aspects of package management in Solus not mentioned elsewhere in this article such as my opinion that, while less relevant PiSi tools are still useful. The eopkg build command that comes straight from pisi can be used to build packages locally and is also used to populate the "3rd-party" section of the Solus Software Center. I demonstrated this function in the the Package Management section of Solus 3.9999 Review by building and installing the the Microsoft Core Fonts (not included in the GUI). Sadly the distribution is deprecating the "3rd-party" repository, instead integrating Flatpaks and Snaps into the Software Center.
In the last review I showed screenshots of the Solus Software Center on Budgie. For users interested in how this application looks with Solus's default theme on Plasma, screenshots are presented below.
The distribution states that needed software is installed by default so users can get going quickly without a lot of "setup fuss". (Apparently, as discussed above, the distribution doesn't seem to think making hybrid NVIDIA devices work to a suitable level as "setup fuss".) As in many distributions LibreOffice and Firefox are installed, as well as the atypical, on most distributions Elisa music player and Sm Player video player.
The Help Center serves as a documentation portal. It allows searching for articles, although the search box, doesn't seem to work on any page other than the main page. It is also divided into browseable categories.
Generally, the documentation is adequate only for the simplest and most essential topics, such as how to add kernel command line options. Help Center articles for more complex topics, such as configuring hybrid graphics switching, are non-existent. The most relevant article for this topic -- which happened to not be useful in my case -- is the article on installing proprietary NVIDIA drivers using Doflkicky which without further configuration -- on which there is no documentation -- on laptops such as mine will result in a black screen.
The project operates a forum unfortunately for the issues I couldn't resolve myself or with the Help Center articles, the forum was not helpful.
My experience with Solus 4.1 Fortitude Plasma Edition was not trouble free and required some fuss. The fixes needed for my hardware are described in Solus 4.1 Fortitude Review [Plasma Edition] Supplement: Fixes and Enhancements.
systemd-boot is only used on EFI systems, so this discussion is not relevant to BIOS systems.↩