Garudal Linux Review [KDE Dragonized (D460nized),231029
April 3, 2024, 9 p.m.
Garuda Linux is an Arch based distribution that provides an easy GUI installation of an Arch system with the widely used Calamares installer. But unlike the numerous other distributions that offer such an easy installation of an Arch system and some custom convenience tools, such as a welcome application, Garuda Linux is more ambitious. It provides installation on a Btrfs filesystem that incorporates Snapper to manage snapshot and rollback capability, as well as distribution developed GUI tools for system administration -- making it far more than the typical Arch based distribution. Its focus is to provide a high performance Linux distribution -- to that end using the Zen kernel and including other optimizations -- that is also beautiful.
This article reviews the 231029 ISO release of Garuda's Dragonized (stylized as Dr460nized) edition which features the Plasma desktop.
Introduction
In October 2021 I reviewed Garuda Linux, the same KDE Dragonized -- stylized as Dr460nized -- version that is the subject of this review. At that time I was impressed by the ambition of the distribution in that they included many atypical choices to achieve their vision of a highly performant and beautiful distribution. I did, however, find that some of the choices made to realize that ambition were not wise, such as the choice of making fish the login shell by default, instead of making it the interactive shell for the user, while keeping bash as the login shell.
Some time after the last review -- although I did not review it -- I also installed a version of Garuda Dr460nized on my third laptop, the Acer. This installation was disappointing because the rollback feature -- at that time with Btrfs snapshots managed by Timeshift -- did not work. This was a surprise because immediately after installing Garuda the first time, even before the installation for the 2021 review, I tested the rollback feature, which worked well.
Since then the distribution has had a major change in its Btrfs configuration by replacing Timeshift with Snapper to manage snapshots and rollbacks. It has also made many changes to its architecture, replacing some of the features that I found unwise with better alternatives. But it still differentiates itself from other Arch based distributions, and Linux distributions generally, with many of the same features as the past versions, some with improvements since the version last reviewed.
- its use of Btrfs as the default file system, utilizing the filesystem's snapshot and rollback capability in conjunction with the Snapper snapshot utility to allow bootable snapshots and system rollbacks, similar to openSUSE's Btrfs/Snapper.
- its use of fish as the default interactive shell incorporating a command prompt supplied by a customized Starship, instead of the almost universal choice of bash with a standard prompt in other distributions.
- its use of the performance optimized Zen (linux-zen) kernel, one of the officially supported, but not default, kernels of Arch Linux
- its use of Zram -- a system to create a compressed block device in RAM -- for swap space instead of the more traditional swap partition or swap file
- its inclusion of an extensive set of GUI convenience tools, collected in the Garuda Assistant suite of utilities, itself included in the Garuda Welcome application which also includes other GUI system configuration and maintenance tools. A third-party GUI to manage the Btrfs filesystem and Snapper, Btrfs Assistant, is also provided, and while not seamlessly intgrated in Garuda Assistant, it is launchable from Garuda Assistant.
- its other performance enhancements such as, among others, process priority modification daemons, which in the current version are all opt-in, whereas in the previous version they were enabled by default.
Changes since the last reviewed version include (some mentionedd earlier):
- addition of firewalld which is enabled by default, along with its own independent panel widget next to the system tray
- replacement of the default Arch initial ram disk generation facility, mkinitcpio with Dracut, the same tool used by openSUSE
- replacement of Timeshift with Snapper to manage snapshots and rollbacks. The subvolume layout has also been modified to be compatible with Snapper requirements, similar to openSUSE and the manual Arch installation on a Btrfs filesystem with Snapper that I discussed in An Arch Linux Installation on a Btrfs Filesystem with Snapper for System Snapshots and Rollbacks. The distribution has also incorporated a GUI interface to Snapper in its Btrfs Assistant application
- performance enhancing features, apart from the use of the Zen kernel, such as ananicy becoming opt-in now, whereas they were enabled by default in the past version
- replacement of the fish shell by Bash as the as the login shell as in most other distributions, while still maintaining fish as the default interactive shell
- removal of Latte Dock, which had previously generated both the bottom dock and the top panel containing the active window title, focused application menu, and system tray; these graphical shell features are now generated by PlasmaShell as PlasmaShell panels
The most noticeable characteristic of Garuda Dragonized and the one that makes the largest contribution to its identity -- at least superficially -- remains the same; that is the extensively customized Plasma desktop. The most radical of the customizations is the replacement of the typical Plasmashell configuration of a single bottom panel encapsulating a task switcher, system tray, and launcher widget with a configuration that uses a top panel -- rendered in the current version of Garuda by PlasmaShell -- that contains, on the left side, the Plasma default Application Launcher, as well as the Window Buttons, Window Title, and the Window AppMenu plasmoids; Better inline clock in the center, and the Plasma System Tray on the right side. Garuda's Plasmashell also includes a bottom dock, now also generated by Plasmashell as a panel configured to look like a dock. The top panel is reminiscent of Unity in its look and behavior, while the overall look of the configuration is very similar to macOS.
Other modifications to Plasmashell include additions to the screen edge gesture configurations such as a left edge gesture to switch from the first desktop named "Desktop" to the second of two preconfigured desktops named "Offscreen". The developers enable many animations (or Desktop Effects) provided by the Plasma window manager, Kwin, including for example, the Cover Switch ALT + TAB task switching animation, Zoom Desktop when logging in, Magic Lamp when minimizing windows, and Wobbly Windows among others, mimicking the macOS animations.
The appearance is defined by a modified Sweet global theme named Sweetified -- available in dark mode only, a matching Kvantuum application style theme, and BeautyLine icons, and a Sugar Candy based SDDM theme.
Garuda Linux Dragonized (Dr460nized) Theming
The customization of Garuda Linux extends to an excellent GRUB menu theme and splash screen.
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
The effort to enhance the beauty of the distribution extends to the pre-login look. The GRUB theme and GRUB splash screen, which was improved between the 210406 and 231029 ISO releases, are very impressive. The SDDM theme as well as the Plasma splash screen are also very impressive. The look of Garuda prior to user login is illustrated in the following set of screenshots.
Garuda Aesthetics Pre-Desktop Environment
Even before the desktop environment is started Garuda's aesthetics are impressive.
In fact, the aesthetic qualities are what prompted me to try Garuda Linux with the 210406 release, and now with the current release. In 2021, I had grown tired of the Plasma desktop on the Fedora, Manjaro, and Endeavour OS installed on my secondary laptop, so I tried to use Budgie and Cinnamon for a change, but I couldn't be away from the flexibility and power of Plasma for more than a few minutes, so I looked around on the Internet and discovered Garuda. I found the theming of the Plasma desktop to be fresh and very aesthetically appealing, so I installed it using the 210406 ISO release over Fedora. The installation was not without its problems, but after I resolved the issues, I was so immediately impressed by the distribution, I installed it on my primary laptop.
I later installed the more recent 210621 ISO on my primary laptop in order to have a more recent impression of installing and using the latest Garuda for the previous review. Since the first installation, I have used Garuda almost exclusively on my tertiary laptop. In that time I have found that the distribution does achieve its goals of producing a distribution that is fast -- see Garuda Linux Benchmark Comparison Versus Solus for objective measures of its speed -- and beautiful. And while earlier releases had some issues, as discussed in the previous review, by the current release it has matured a great deal and is now very reliable.
Review Summary
My experience with Garuda Linux, its features, and my impression of these features is described in the rather lengthy Review section below (which follows Recommendation), but for those who find the Review portion of the article too long, a summary is provided in this section. Also articles that supplement the review are available:
- Garuda Linux Benchmark Comparison Versus Solus
- Garuda Linux Review [KDE D460nized,231029] Supplement: Installation
And for those interested in installing a pure Arch system on a Btrfs filesystem and configuring system snapshot and rollback capability with Snapper, fully using all of its features, as does openSUSE, and with openSUSE's more elegant subvolume layout and rollback process which fully uses Snapper (i.e., Garuds's does not use Snapper's capability to set the default subvolume) see An Arch Linux Installation on a Btrfs Filesystem with Snapper for System Snapshots and Rollbacks.
The summary of the review:
- The largest accomplishment of the distribution, in my view, is in providing an easy installation of a fully configured Arch system with a Btrfs filesystem that takes full advantage of the filesystem's capabilities, such as the system snapshot and rollback capability. The snapshot creation process -- now managed by Snapper, whereas in previous versions it was managed by the Timeshift backup utility -- is well integrated in Pacman package operations which also produce a bootable snapshot in the GRUB menu, through the use of the snap-pac, snap-pac-btrfs, and grub-btrfs Arch packages (for the role of these packages, see An Arch Linux Installation on a Btrfs Filesystem with Snapper for System Snapshots and Rollbacks).
-
I only had two real issues with Garuda, the other minor and subjective issues notwithstanding.
- The distribution provides an SHA checksum to ensure the download integrity of the ISO. Verifying a checksum is only one of the two necessary components for ensuring a good ISO, and a mechanism also necessary for verifying the authenticity of the download. Reputable distributions typically provide a signed GPG signed ISO for this purpose, in addition to the checksum. Some even combine the the download integrity and authenticity verification by providing a signed file which contain the checksums of downloadable ISOs.
- In the current release, the display of man pages is corrupted by the improper inclusion of what seem like the formatting tags throughout all man pages. This is probably due to an incorrect configuration when compiling man related packages or a systematic error in all packages. This issue does not appear in my Arch Linux installation.
- Although Garuda's Btrfs/Snapper configuration worked as intended in my use for this review, and its GUI tools surpass even SUSE's in making rollbacks as simple possible, I don't believe the subvolume layout is as elegant as openSUSE's which mounts an actual snapshot as the root filesystem. In the openSUSE configuration, when a rollback is performed, Snapper makes a new snapshot copy of the rollback target and ensures that it is the one mounted at next boot. Garuda on the other hand does not mount a snapshot, but a higher level subvolume which contains all snapshots. Its in house developed tools use Btrfs tools directly to copy the previously mounted high-level subvolume, create a new subvolume, and give it a name that is the same as the previously mounted subvolume. In addition to Garuda not actually using Snapper to perform rollbacks, and because of this, it does not use Snapper's capability -- which relies on the Btrfs concept of default subvolume -- of ensuring the correct snapshot is mounted at /. Over time, after numerous rollbacks, this will lead to many copies of the high level subvolume, (see the first image in the set titled A Comparison of Garuda's Btrfs Subvolume Layout with openSUSE's, below) whereas in openSUSE's configuration, the layout does not change.
-
The Garuda Linux developers do indeed achieve their goal of creating a high performance distribution, as the Phoronix Test Suit benchmark comparison against Solus performed for the review of the 210621 release would seem to demonstrate. After that review, I was concerned that aside from the Zen Kernel and Zram, many of the responsiveness related inclusions in the distribution were from what seem to be obscure utilities and daemons sourced from the AUR, a problem because the practice of using packages from the AUR for software that affects the core system is generally regarded as undesirable, and the cause of breakage of an Arch system. I also found the benefit of these utilities to not be necessary for more powerful systems with the workload of a workstation.
While at least in the benchmark against Solus, Garuda performed better than another distribution, a recent Phoronix benchmark comparison of all kernels available for Arch indicate that the default Arch kernel actually had better overall performance than the desktop performance optimized Zen Kernel. For most laptop users the default Arch kernel may be a better choice because of its overall better performance and lower power consumption than the Zen Kerenl used by default in Garuda. - The performance enhancements that were previously enabled by default now require users to enable them through the Garuda Assistant application. This is a desireable change as some performance gains would be the result of default settings that realize the gains at the cost of power savings. That these particular performance enhancements are now up to the user will allow users to enable them, or not, as appropriate for their platform, i.e., whether the computer is a laptop, where in certain cases it is desirable to balance performance with power saving. Also, a desirable capability for laptop users -- hibernation -- is not available in a default Garuda system, due to the exclusive use of Zram as the swap device, without even allowing the provisioning of an additional swap device in the form of a swap partition during installation, or even using an existing swap partition.
- One of the most impressive features of Garuda Linux is the central hub for Garuda developed GUI system administration utilities, Garuda Welcome and one of its components, Garuda Assistant, itself a collection of GUI utilities. In previous versions, all of these GUI tools were not true GUI tools, but a collection of GUI controls powered by Bash scripts that either open a terminal and execute commands or activate small external third party GUI utilities sourced from the AUR. Now at least one of these utilities, Btrfs Assistant has been ported to the Qt framework and is more mature than the previous tool that provided similar functionality.As another sign of Garuda tools maturing is that only one of the GUI utilities does snot work as intended, whereas in past versions of Garuda, many utilities didn't work as intended and the commands were not aware of other commands that had been activated through the GUI and failed silently when there was a conflict. During my use of Garuda for this review the only Garuda utility that failed was the Garuda Boot Options component of the Garuda Welcome application, which failed to apply the specified GRUB menu settings to the final GRUB configuration.
- While Garuda allows installation of the proprietary Nvidia driver by selecting the appropriate option in the installation medium's GRUB menu, laptop user's will need to install Optimus Manager which will remove some of Garuda's very minimal, ineffective, and not universally appropriate Nvidia related configuration. The extent of Garuda's Nvidia configuration -- besides making the proprietary driver available, is to ensure that the most fine grained power management mode is enabled. By default the configuration uses the Hybrid or Offload mode of Optimus, which uses the discrete GPU on demand, but provides no way to switch to the full power Discrete mode, the reason for Optimus Manager being necessary. In past versions, Garuda installed this utility by default, but must have decided against this due to the complexity of configuring the utility such that configurations are appropriate for specific Nvidia GPSs with different capabilities. (See Nvidia Optimus on Linux.)
-
In addition to creating a high performance distribution, the goal of the developers is to create a beautiful distribution. As with the other goal, they have succeeded by choosing great Plasma theming components and an icon set that complements the theme. The additions to the terminal, such as the informative and interesting command prompt provided by Starship, the terminal theme, and robust command syntax highlighting that is built into the Fish shell also contribute to the beauty of the distribution. The pre-login appearance is also excellent with very appealing GRUB, Plymouth, and SDDM themes. The only improvement that can be made to the pre-login appearance is the supression of the GRUB messages "Loading kernel ...", "Loading initial ramdisk", and the systemd message, which interrupt the Plymouth animation.
Despite the great overall theme, some of the appearance choices detract from the usability of the distribution. For example, the dark theme is not usable in bright environments depending on the screen quality. Also, the themeing of applications which require authentication by root are not consistent with the overall theme. This is common on many distributions when user specific settings are not applied to the root user, but in Garuda's case, this is a regression from previous behavior. - The Plasma desktop is extensively customized, most notably by replacing the default configuration of a simple bottom panel, with a top bar and a bottom dock, in the current release generated by Plasmashell itself instead of by Latte in previous versions. Widgets in the top panels are also not the typical Plasma widgets, but those that seem to be created by Latte developers.
-
During testing for the previous review the distribution was evolving very rapidly, perhaps because it was an immature hobbyist distribution, and as suggested by one of the developer's comments in various Garuda forum posts, the distribution is created by Linux enthusiasts to suit their tastes and to learn by experimenting with their distribution. For example, a major change between the 210406 and 210621 ISO releases was the replacement of the default login shell from the Fish shell to Bash. Minor changes included going back and forth between Neofetch and Paleofetch and replacement of a Garuda patched os-prober package with one sourced from the AUR. The Garuda tools were also seeing major changes and new functionality; for example, Garuda Assistant gained two new tabs and the contents of one tab was split between two tabs. During that period, a Hotfix capability was also added to Garuda System Maintenance, which actually did not work as intended (see Garudal Linux Review [KDE Dragonized (D460nized),210621]).
As of release covered in this review, the distribution has stabilized greatly, with far fewer sudden changes to features. Garuda has also matured -- perhaps the reason that there are not as many new changes -- with far fewer issues in Garuda applications.
Recommendation
When selecting a distribution for installation on my primary laptop, the most important considerations are reliability and quality. These characteristics are usually found in distributions with a corporate backing, of which I prefer openSUSE. I also have a high opinion of Arch and Debian, which, while not having the corporate backing that provides resources that help in developing a distribution with high quality and reliability, they are large, meritocratic communities with mature distributions. I made an exception for Garuda for the previous review because I was intrigued by the look of the distribution and the possibility of an easily installed Arch system on a Btrfs filesystem with snapshot and rollback capability working out of the box. (I have since then installed Arch on a Btrfs filesystem with an openSUSE style subvolume layout with full Snapper integration).
Garuda greatly benefits from the design of its Arch base, from the simple and transparent configuration of Pacman which is used by Garuda to add its own mirrors and repositories, to the systemd unit file type syntax of Pacman hooks which allow integration of the Btrfs/Snapper snapshot management during package management transactions. In areas of the distribution which were added by Garuda, it is clear -- more so in its earlier releases -- that the distribution is an experimental, hobbyist distribution developed by Linux enthusiasts who make a distribution that suits their needs and sensibilities, while at the same time learning from the act of creating and experimenting with their distribution. The developers characterize themselves and the distribution as such in various Garuda form threads, such as the one titled 'zram-generator' incorrectly listed as hard dependency for 'garuda-common-settings'.
This nature of the distribution resulted in numerous significant changes to the distribution over the past few years, such as the fundamental change in the login shell from fish to Bash, presumably to avoid the difficulties described in the previous Garuda review of using fish as the login shell -- which would not have been necessary if the distribution had been more mature. At the same time the overall quality of the distribution has improved over its earlier state where some of the Garuda tools did not work as intended and were implemented with unsophisticated methods. It seems the quality improvement is not only due to better and more skilled implementation of its tools, but improved testing of the distribution, which may be the result of increasing numbers of dedicated community members.
The only thing I did not like about Garuda, which wouldn't have been an issue with a more mature distribution, is the lack of proper installation ISO integrity verification in the form of a GPG signature. The distribution only publishes the checksum values for the various installation media, which is only good for download integrity verification.
Another issue with the distribution is that proper configuration of Optimus and laptops in general is not performed by the distribution. As mentioned later in the article, in earlier versions of Garuda, the distribution installed Optimus Manager by default. However, the default configuration of the utility was not suitable for newer post-Turing generation NVIDIA GPUs. In the current release, the distribution solved the problem by simply not even installing Optimus Manager. It would be convenient for users if the distribution could automate a proper Optimus configuration in a way that is transparent to the user in the same way it does other aspects of the system, such as the simple system rollback.
Despite these areas that, in my opinion, the distribution needs to prioritize, the developers are very ambitious and passionate about their distribution and open source software generally, and have a grand vision for their distribution which they pursue with dedication. This is evidenced by their provisioning of a distribution with a Btrfs filesystem and configuring system snapshots and rollbacks to be managed -- although only to a limited extent, and in my opinion not as well as openSUSE (see below) -- by Snapper, an out-of-the box configuration that has thus far only been provided by the commercial SUSE Enterprise Linux and its community counterpart openSUSE and the Debian testing branch based Siduction. In the current release, the rollback process is even simpler than openSUSE's, with users only needing to confirm a rollback action in a dialog box after booting into a read-only snapshot. The implementation of a comprehensive system administration GUI is also a reflection of their vision.
The vision and dedication of the distribution's developers has been realized in the current release with a distribution that is reliable, easy to manage, performant, and visually appealing. I am glad I tried Garuda, as I have learned more than I would have with some more typical distributions. For example, in examining how the performance options set by performance-tweaks work, I learned about the systemd-tmpfiles system works. I have also been exposed to more Linux tools than I would have with typical distributions -- such as the Fish shell, Zram, Starship, and eza, among others -- inspiring me to configure my other Linux installations differently. I will continue to use Garuda on my secondary and tertiary laptop, but it will soon be replaced with CachOS on my primary laptop, where a pure Arch system installed using the process documented in An Arch Linux Installation on a Btrfs Filesystem with Snapper for System Snapshots and Rollbacks, an Ultramarine (Fedora based) installed on Btrfs with an openSUSE subvolume layout and full Snapper integration, and an openSUSE Tumbleweed installation also currently have a permanent home.
Review
Installation
The pre-installation experience and the actual installation are described in Garuda Linux Review [KDE Dragonized (D460nized),231029] Supplement: Pre-Installation and Garuda Linux Review [KDE Dragonized (D460nized),231029] Supplement: Installation, respectively. But some notable items from those supplementary articles:
- Garuda Linux does not provide any of the resources necessary for verifying the authenticity of the installation ISO, but only for verifying the download integrity in the form of checksums.
- The installer does not have the option of mounting any partitions other than those formatted in Btrfs to any mount point in the installed system, with the exception of the ESP partition.
- Upon first boot, users are guided in performing minor post installation configuration and installing additional software. Although the implementation requires many, many individual dialogs instead of a single tabbed window, I found it very helpful, including in discovering software I was not aware of.
The Plasma Desktop
Dragonized is the Garuda edition that uses a heavily themed Plasma desktop. Other editions that use the Plasma desktop are available.
Plasma Customization
Garuda Linux Dragonized Edition is the most customized Plasma desktop environment of any distribution I have seen since Plasma 5 was released in 2015. Its primary change from the typical Plasma desktop shipped by other distrubutions is the replacement of a single panel at the bottom of the screen to an application menu panel at the top of the screen and a dock at the bottom. In previous versions of Garuda, these GUI shell elements were provided by Latte Dock, but since Latte Dock develoment has ceased, the top bar and the dock are now provided by natively by Plasmashell panels. While this removes some capability provided by Latte is now missing, the overall look and basic functionality remains the same.
I find this change to native panels, whatever the reason, welcome because the choice of using a Latte rendered top panel instead of a native Plasmashell may not have been a good one, at least in terms of performance and stability, if not in control of the appearance. As I described more fully the previous review of Garuda Dr460nized, Latte had many performance and stability issues, including issues such as conflicts between Latte and Plasmashell, the latte-dock program sometimes not starting at boot, and performance issues such as slow startup. Its problems may have been exacerbated by Garuda using developemnt versions and not stable releases.
Despite the improvement in experience, there is one annoyance with the current configuration. That is that it is extremely difficult to find a place in the dock to right click the dock in order to activate panel editing mode. Right clicking anywhere in the dock activates context menu related to the only plasmoid in the dock, the Icon Only Taks Switcher, Kwin related items, and the iconified application related items if available. Users have to a very tiny area in the corner of the dock in order to activate panel related settings.
Other significant customizations by Garuda to the Plasma experience includes the effort to better integrate GTK applications to the Plasma configuration chosen by Garuda. This begins with providing a consistent look and feel between KDE applications (built with Qt) and GTK applications by providing the Sweet-Dark GTK theme that matches the Plasma adn Kvantum theme elements (see Image 2 in the following set of images).
Another example is that some important GTK applications' menus are redered in the top panel's Window AppMenu widget just as are native KDE applications. This is the case with Inkscape and GIMP application menus appear in the Window AppMenu widget of the top panel instead of the applications' windows. Unfortunately, this is not the case with any version of Firefox where menus are still not rendered in the top panel. Mpre unfortunate is that even the Firedragon browser -- forked from Librewolf, which itself is a fork Firefox -- has regressed in that its menus are not rendered in the top panel as it had in an early 2021 version of Garuda.
Also, Garuda has made the effort such that at least some GTK applications use the the native KDE Frameworks/Qt file dialog when saving files by appropriately setting the GTK_USE_PORTAL environment variable. This causes the KDE file dialog to be used when for example saving an image from a website. [1] Unfortunately, other GTK applications -- I tried Firefox, GIMP, Inkscape -- do not use the same native KDE Frameworks/Qt file dialogs. This may be understandable for GIMP and Inkscape which may offer options during save/open, but not on Firefox which should have the same requirements and limitations of Firedragon in terms of file operations.
Another effort in improved GTK application integration in Garuda's Plasma includes the enablement of GTK applications' menus in the top panel's Window AppMenu widget as well as those of KDE/Qt applications. Both Inkscape and GIMP application menus appear in the Window AppMenu widget of the top panel instead of the applications' windows. One of these GTK applications (I don't remember which) until a very recent update broke this feature also had its menu rendered in the Global Menu widget in my installation of openSUSE Tumbleweed. But in Garuda the menus of these applications continue to be rendered in the top panel.
GTK Integration
Inkscape and GIMP's application menus are rendered in the top panel. Firedragon initially had its
menu rendered in the top panel as well until an update broke this. Other GTK applications I've
tried, limited to browsers, do not have the menu rendered in the top panel.
However, this feature is still somewhat inconsistent. At some early point in my time with Garuda, Firedragon had its menu drawn in the top panel but does not anymore. Other important GTK applications also do not have their menus rendered in the top panel. Most notable of these is Firefox, which while not installed by default, does incorporate other Garuda customizations but not one that allows its menu in the top panel.
Plasma Theme
As mentioned before, the look of Garuda Linux Dragonized Edition is defined by the Sweetified theme, a matching Kvantuum application style, the default Beautyline icons, and the included Candy icons . A matching Konsole theme is also provided, but not a matching Yakuake skin. This combination looks very good but for users with not so great screens might find it is only usable in darker environments. On my previous primary laptop -- the Dell G5 -- which was used as the reference for the previous review, when working in a bright room, even with the screen brightness set at 100%, it was extremely difficult to read any text displayed on the screen. This situation is much improved on my newer primary laptop, the Lenovo Legion 5i Pro which has a much better screen.
The provided system icons are also not visible in some applications such as Inkscape and even in Qt (but not KDE Frameworks) based applications such as TeXStudio.
Unfortunately, when users request a light theme in the Garuda forum, the developers insist that it looks better, that it is actually easier on the eyes, and that alternative themes should be installed. Unlike me (with the previous laptop) and the users making the request, the developers must work (or game) in darkened rooms or have very bright screens. But the resistance to adding another theme is understandable, for some of the reasons stated by the developers, and when considering the amount of work that is required in maintaining a distribution, in my opinion the effort is better exerted on more substantive tasks.
One other problem with respect to themeing I found could be better is . Two such applications are the Garuda Network Assistant and BTRFS Assistant/Snapper Tools. Also notable is the theme of this GUI application doesn't match the standard Garuda theme. This is common in many other distributions, where themes are installed per user and not systemwide, and applications belonging to root have a different theme. While not true for Garuda Network Assistant, other Garuda system adminsitration GUIs that require root privileges to launch did match the overall theme of the distribution.
Wallpapers
The Default Garuda Dragonized Wallpaper and the Many Others Available
In this release Garuda Dragonized has chosen a default wallpaper that represents the edition.
Missing Elements
The Plasma Desktop experience is mostly excellent, both in regards to its interesting and cohesive visual aspects which is anchored by the Sweet theme in the desktop, and outside the desktop includes the stunning GRUB, Plymouth, and the SDDM themes, and the arrangement of the Plasma shell. However, in addition to the legibility issues of the theme due to transparency and light secondary text colors, there were issues in these areas and other elements I missed.
-
One of the missing elements to the otherwise cohesive look and feel is in the appearance of
- Also, until very recently -- weeks after I installed Garuda 231029, by no fault of the Garuda developers, Kate, KDE's excellent text editor does not have an editor color scheme that is consistent with the Sweet theme. This has been corrected by Kate itself by its inclusion of a new customization that "Follow(s} System Color Scheme".
-
Until also very recently, the Media Player plasmoid did not show artwork from the music app I use almost exclusively Tidal Hi-Fi, as shown in the following image. This has not been an issue in my Arch install, but it is also sometimes an issue in my openSUSE Tumbleweed installation. This issue has somehow resolved itself.
Tidal Hi-Fi Playing and Plasma's Media Player WidgetFor some time after installation, the Media Player widget did not show the artwork from Tidal HiFi. This expected behavior was restored recently without any intervention.
Btrfs
Garuda Linux has adopted what some view as the filesystem destined to be the default Linux filesystem, Btrfs -- as did the Btrfs pioneer, openSUSE, prior to 2016 and Fedora very recently -- as its default file system. Among the benefits of Btrfs compared to the file system that is generally considered as the current de facto standard file system, ext4, is the ability to create snapshots of the system, i.e. duplicate certain configured branches of the filesystem hierarchy to preserve its state. The snapshots enable the capability of booting into an earlier version of the system and rolling back the system to a previous state.
Potential users concerned about the reliability of the Btrfs filesystem should not be; the only area of concern is when using the filesystem's built in capability of RAID in RAID 5 or RAID 6 configurations. I have been using Btrfs on openSUSE Tumbleweed for five years without a problem. I also used it for a time earlier in its history as openSUSE's default filesystem, when -- although it impressively was able to roll back the system, even after large changes -- it did have issues such that my installation became unusable because the area reserved for metadata in the filesystem was filled, or the snapshots used all available space. Since then openSUSE has added utility services that maintain the filesystem and also made changes to limit the number of snapshots that are kept, eliminating the early issues. It seems other distributions like Garuda have benefited from openSUSE's work as these issues are not present.
Garuda Uses openSUSE Created Btrfs Patches in Its os-prober Package
It should be noted that, as the filesystem does require more space than traditional filesystems, more storage space should be allocated to Btrfs partitions. I typically allocate twice as much storage space for Btrfs partitions as I do for ext4 partitions, possibly the reason that my more recent, but longer duration, use of Btrfs in openSUE has been more reliable than my earlier initial experience. It is also important to properly configure Snapper's configuration of automatic snapshot cleanup and monitor the filesystem's allocation of storage to its data, metadata, and system components and perform the Btrfs balance operation as necessary or through automation. (See Not Enough Space on Btrfs Filesystem Due to Exhausted Metadata Block Group Allocation
Although the Btrfs filesystem has its own set of tools that include the capabilities of creating and managing snapshots (see man btrfs.8, snapshot creation and rollbacks are typically managed by an external program such as Timeshift or Snapper. One of the major differentiators of Garuda Linux is that, not only does it make an Arch installation easy, it installs it on a Btrfs filesystem. Further it installs it with a Btrfs subvolume layout that allows the use of Snapper to manage snapshots and rollbacks. This greatly improves upon the Arch recommended Btrfs configuration and makes the rollback process much simpler, even trivial, for the user. The Arch recommended Btrfs subvolume layout requires uses to access the system via a chroot from a live ISO or another installation on the same system and manipulate snapshots using Btrfs tools to perform the rollback. Garuda, however, at least since the 210406 version, has allowed users simply to boot into a read only snapshot and easily initiate a rollback the system. In earlier versions this process was managed by TimeShift, but in more recent versions, Garuda has switched to using Snapper, the same utility used by openSUSE, Snapper, to manage the Btrfs snapshots and rollbacks. However, it seems that based on my limited knowledge of Btrfs and Snapper, Garuda only uses parts of the Snapper functionality; it uses it to create snapshots manually and through integration with pacman, but not to perform the rollbacks, instead automating methods similar to the Arch recommendation to rollback by using Btrfs built-in tools for e.g., copying subvolumes. Neither does it use Snapper capability to facilitate mounting the appropriate snapshot after a rollback. In my opinion the openSUSE methods are much more elegant and have been proven to be reliable over many years.
Most user's will not be aware of the internals of Garuda's Btrfs/Snapper configuration, but will see the GUI tools that are used to manage it. This begins with the GRUB menu that integrates the available read-only snapshots into which the system can be booted to begin the rollback process. The images in the following set show the GRUB menu of the current Garuda Dragonized release and the Btrfs snapshot related items. The first image shows the main GRUB menu which has as one of its items, "Garuda Linux snapshots", which when selected lists the available snapshots (Image 2). When one of the available snapshots is selected, another menu is shown, which allows selection of the kernel to load, if more than one is available (Image 3).
Btrfs Snapshot Selection in GRUB Menu
Subvolume Layout
Although Garuda configures Btrfs to be used with Snapper its subvolume layout is different from that used by openSUSE for many years, and that of the Arch installation on a Btrfs filesystem with Snapper I described in An Arch Linux Installation on a Btrfs Filesystem with Snapper for System Snapshots and Rollbacks. The following listings show the output of btrfs-list on the Garuda installation before any rollbacks have been performed. From this output we can see the initial hierarchy of subvolumes on the Garuda installation, in which a subvolume named @ with a subvolume ID of 256 is created within the main subvolume (ID 5). A subvolume named .snapshots and assigned a subvolume ID 262, to contain subvolumes for individual snapshots is created inside subvolume @ (subvolume ID 256); the existence of such a subvolume named thus is a requirement of Snapper operation. All other subvolumes, those that contain filesystem hierarchy paths excluded from snapshots are in their own subvolumes (subvolume IDs 257 - 261) under the main subvolume (subvolume ID 5).
╭─brook@garuda in repo: ordinatechnic_content/distribution-reviews/garuda-linux on exp [x!?⇡1] as 🧙 took 4s
╰─λ sudo btrfs-list --show-id --show-parent --show-toplevel
WARNING: to get refer/excl size information, please enable qgroups (btrfs quota enable /home)
WARNING: to get refer/excl size information, please enable qgroups (btrfs quota enable /)
NAME ID PARENT TOPLVL TYPE REFER EXCL MOUNTPOINT
GARUDA_HOME - - - fs - 2.64G (single/dup, 16.80G/20.00G free, 83.98%)
[main] 5 - - mainvol - - /home
GARUDA_ROOT - - - fs - 26.50G (single/dup, 54.44G/85.00G free, 64.04%)
[main] 5 - - mainvol - - /
@ 256 5 5 subvol - - /
@/.snapshots/47/snapshot 309 262 262 rosnap - -
@/.snapshots/48/snapshot 310 262 262 rosnap - -
@/.snapshots/49/snapshot 311 262 262 rosnap - -
@/.snapshots/50/snapshot 312 262 262 rosnap - -
@/.snapshots/51/snapshot 313 262 262 rosnap - -
@/.snapshots/52/snapshot 314 262 262 rosnap - -
@/.snapshots/53/snapshot 315 262 262 rosnap - -
@/.snapshots/54/snapshot 316 262 262 rosnap - -
@/.snapshots/55/snapshot 317 262 262 rosnap - -
@/.snapshots/56/snapshot 318 262 262 rosnap - -
@root 257 5 5 subvol - - /root
@srv 258 5 5 subvol - - /srv
@cache 259 5 5 subvol - - /var/cache
@log 260 5 5 subvol - - /var/log
@tmp 261 5 5 subvol - - /var/tmp
@/.snapshots 262 256 256 subvol - -
╭─brook@garuda in repo: ordinatechnic_content/distribution-reviews/garuda-linux on exp [x!?⇡1] as 🧙 took 259ms
╰─λ
The next listing shows the subvolume hierarchy after a rollback has been performed. From a comparison with the previous listing, it would seem that the Garuda Btrfs/Snapper configuration, while maintaining compatibility with Snapper by making a subvolume named .snapshots does not use Snapper as intended -- as will become clearer later, especially if familiar with the discussion in An Arch Linux Installation on a Btrfs Filesystem with Snapper for System Snapshots and Rollbacks -- instead using the Btrfs tools directly. It would seem to follow a process similar to the Arch Wiki recommendation, where during a rollback, the subvolume previously used as the current system, named @ (the root of the filesystem hierarchy) is renamed to reflect the date and time of the rollback, in this case @_backup_20241101190348897, a new subvolume created by copying the snapshot to which to rollback, and named @. This new subvolume is then used as the current system in subsequent boots.
╭─brook@garuda in ~ as 🧙 took 25ms
╰─λ sudo btrfs-list --show-id --show-parent --show-toplevel
WARNING: to get refer/excl size information, please enable qgroups (btrfs quota enable /home)
WARNING: to get refer/excl size information, please enable qgroups (btrfs quota enable /)
NAME ID PARENT TOPLVL TYPE REFER EXCL MOUNTPOINT
GARUDA_HOME - - - fs - 2.76G (single/dup, 16.68G/20.00G free, 83.40%)
[main] 5 - - mainvol - - /home
GARUDA_ROOT - - - fs - 26.26G (single/dup, 54.68G/85.00G free, 64.33%)
[main] 5 - - mainvol - - /
@_backup_20241101190348897 256 5 5 subvol - -
@/.snapshots/61/snapshot 323 262 262 rosnap - -
@/.snapshots/62/snapshot 324 262 262 rosnap - -
@/.snapshots/63/snapshot 325 262 262 rosnap - -
@/.snapshots/64/snapshot 326 262 262 rosnap - -
@/.snapshots/65/snapshot 327 262 262 rosnap - -
@ 330 5 5 snap - - /
@/.snapshots/68/snapshot 331 262 262 rosnap - -
@/.snapshots/69/snapshot 332 262 262 rosnap - -
@/.snapshots/70/snapshot 333 262 262 rosnap - -
@/.snapshots/71/snapshot 334 262 262 rosnap - -
@/.snapshots/66/snapshot 328 262 262 rosnap - -
@/.snapshots/67/snapshot 329 262 262 rosnap - -
@root 257 5 5 subvol - - /root
@srv 258 5 5 subvol - - /srv
@cache 259 5 5 subvol - - /var/cache
@log 260 5 5 subvol - - /var/log
@tmp 261 5 5 subvol - - /var/tmp
@/.snapshots 262 330 330 subvol - -
╭─brook@garuda in ~ as 🧙 took 263ms
╰─λ
In the second listing above, we can see that after a rollback, the parent of the .snapshots subvolume is now the new @ subvolume, i.e., the parent of .snapshots is now subvolume ID 330 whereas before it was subvolume ID 256. This is in contrast to the openSUSE subvolume layout hierarchy, shown in the following listing from a two year old openSUSE Tumblweed installation with at least one rollback. The listing shows that even after a rollback the parent subvolume of the .snapshots subvolume remains the original subvolume containing the .snapshots, (in this case ID 256).
73% 17:26:48 USER: brook HOST: 16ITH6-openSUSE
~ ❯$ sudo perl /usr/local/bin/btrfs-list --show-id --show-parent --show-toplevel
NAME ID PARENT TOPLVL TYPE REFER EXCL MOUNTPOINT
OPENSUSE_ROOT - - - fs - 66.51G (single/dup, 10.36G/85.00G free, 12.19%)
[main] 5 - - mainvol 16.00k 16.00k /
@ 256 5 5 subvol 16.00k 16.00k
@/var 257 256 256 subvol 10.96G 10.96G /var
@/usr/local 258 256 256 subvol 7.03G 7.03G /usr/local
@/srv 259 256 256 subvol 16.00k 16.00k /srv
@/root 260 256 256 subvol 10.54M 10.54M /root
@/opt 261 256 256 subvol 1.34G 1.34G /opt
@/home 262 256 256 subvol 23.91G 23.91G /home
@/boot/grub2/x86_64-efi 263 256 256 subvol 4.20M 4.20M /boot/grub2/x86_64-efi
@/boot/grub2/i386-pc 264 256 256 subvol 16.00k 16.00k /boot/grub2/i386-pc
@/.snapshots 265 256 256 subvol 592.00k 592.00k /.snapshots
@/.snapshots/113/snapshot 378 265 265 snap 17.93G 54.00M /
@/.snapshots/446/snapshot 713 265 265 rosnap 17.92G 6.38G
@/.snapshots/447/snapshot 714 265 265 rosnap 18.23G 18.59M
@/.snapshots/448/snapshot 715 265 265 rosnap 18.23G 8.27M
@/.snapshots/449/snapshot 716 265 265 rosnap 17.93G 22.48M
73% 17:26:50 USER: brook HOST: 16ITH6-openSUSE
~ ❯$
More importantly, the difference is that in openSUSE the current system (the subvolume mounted at / at startup) is always a snapshot, the initial snapshot when the system is installed, and a new snapshot created from a prior snapshot when the system is rolled back. In Garuda, the current system is not a snapshot but always the \@ subvolume. During rollback, as mentioned above, the @ subvolume is recreated from a snapshot. This difference might be so that in Garuda there is better compatibility with the way GRUB works to find the kernel path by default without patching, at the cost of Snapper's inherent functionality. The following set of images better illustrates Garuda's subvolume layout and how it is used. We can see, as was evident in the above listings by noting the subvolume IDs and the parent subvolume IDs that each of the subvolumes containing the excluded filesystem hierarchy paths are in the same subvolume as the one that contains the snapshots subvolume, instead of directly in the main subvolume. And that unlike openSUSE's layout, as mentioned above, Garuda places the .snapshots subvolume directly in the @ subvolume.
A Comparison of Garuda's Btrfs Subvolume Layout with openSUSE's
In openSUSE a snapshot is always mounted at /. The snapshot that is mounted changes during a rollback through Snapper functionality. In Garuda the top subvolume under the main subvolume is always mounted at @. This is recreated from a snapshot during rollbacks.
common features of the subvolume layouts of these two distributions and In addition to the excluded filesystem paths subvolumes being placed directly in the top level subvolume, unlike in openSUSE, Garuda includes /usr/local and /boot in the snapshots, whereas openSUSE excludes /usr/local and /boot/grub2 by creating subvolumes for them. Also, Garuda places /var/cache, /var/log, and /var/tmp in separate subvolumes whereas openSUSE has everything under /var in a single subvolume. Garuda's choice seems to only make sense if these subvolumes are mounted with different mounting options in /etc/fstab but they are not. It should be noted that although the openSUSE subvolume layout described above is the default, its YaST installer allows complete configuration of the what subvolumes are created and their options (in addition to many other advanced storage configuration possibilities), so a user could specify a different subvolume layout including whether the snapshots subvolume should be created.
Default subvolume
An important concept of the Btrfs filesystem is that of the default subvolume. When specifying a Btrfs partition for mounting, if a subvolume is not explicitly specified as that to be mounted using identifiers such as the subvolume ID or subvolume path in fstab options, the default subvolume is mounted. At filesystem creation the default subvolume is the top level subvolume with a subvolume ID of 5. If other subvolumes are created at any level below the top level, any one can be set as the default subvolume. Garuda keeps the default subvolume as the top level subvolume, whereas openSUSE makes a specific snapshot the default subvolume. As we see below, the significance of this is related to Snapper operation.
Snapper
In standard use of Snapper with Btrfs, at least in the way openSUSE uses it, and what I emulated in An Arch Linux Installation on a Btrfs Filesystem with Snapper for System Snapshots and Rollbacks and A Fedora Installation with an openSUSE Style Btrfs Subvolume Layout and Snapper Intergration for System Snapshots and Rollbacks, at installation the image is copied to a subvolume created for an initial snapshot. This subvolume is set as the default subvolume, meaning without explicitly setting the subvolume to be at / in /etc/fstab, the default subvolume is mounted. Each time Snapper is used to perform a system rollback, it creates two new snapshots, one a read-only duplicate of the current system and another that is a read-write copy of the snapshot to which to roll back that is to be used as the new system. The new read-write snapshot is then set as the default subvolume, ensuring the correct snapshot is mounted at /. Garuda does not use the ability of Snapper to set the default subvolume; it always remains the top level subvolume. Nor are the two subvolumes created by Snapper at rollback, which leads me to suspect that Snapper is only used to create snapshots during package management by integration with pacman with snap-pac, and as mentioned before the rollback is performed by automating the Arch recommended process using Btrfs provided commands to manipulate subvolumes. The following line in the source of Garuds's snapper-tools also seems to indicates as much.
proc->start("btrfs", QStringList() << "subvolume"
<< "snapshot" << rootDir.filePath(to_restore.path) << rootDir.filePath(target));
The following image showing the output of snapper list in openSUSE in the top half, and Garuda in the bottom half, lists the available snapshots in each. In openSUSE's case, Snapshot 113 is set as the currently mounted snapshot and the snapshot to be mounted at next boot, as indicated by the asterisk after "113". This indicator is (the asterisk) is placed on the Btrfs. default subvolume. (Other indicators are a "+" indicating the default subvolume and the one to be mounted to / during the next boot, and "-" indicating the currently mounted snapshot.) In Garuda's case, none of the markers indicating the currently mounted snapshot, or the snapshot to be mounted at next boot are indicated.
The Output of snapper list In Garuda and openSUSE
The Garuda output does not indicate the currently mounted snapshot or the one to be mounted at the next boot.
Mounting Filesystem Hierarchy Root in /etc/fstab
As mentioned previously, mounting the correct subvolume in /etc/fstab at / is different in Garuda's Btrfs/Snapper system compared to openSUSE's. In Garuda, the subvolume currently named @ is always mounted, so the subvolume identifier can be hard coded in the mount options of the /etc/fstab entry for /, as shown in the following image. The Btrfs default subvolume does not need to be set by Snapper.
The Garuda /etc/fstab File
Unlike in openSUSE, which fully integrates Snapper, the subvolume identifier is hardcoded in the mount options of the entry for /.
In the openSUSE implementation, an actual snapshot is mounted as the root of the filesystem hierarchy. Initially the Snapshot #1 is set as the Btrfs default subvolume. Because of the way mount works with the Btrfs filesystem, if mount options are not specified, the default subvolume is always mounted. This makes the subvolume identifier unnecessary in the /etc/fstab mount options for the / entry. Upon rollbacks Snapper automatically sets the new snapshot to be used for the root of the filesystem hierarchy as the Btrfs default subvolume, always ensuring that the correct snapshot is mounted.
The openSUSE way seems more elegant to me, and would seem to result in a less cluttered layout over time (see the set of images titled A Comparison of Garuda's Btrfs Subvolume Layout with openSUSE's, below). It also provides flexibility in adding other subvolumes outside of the second-level subvolume that contains all other subvolumes while still keeping the overall subvolume layout organized.
The Kernel Path in GRUB Kernel Command Line
Related to the difference in the specification of the mount options in /etc/fstab -- or the lack thereof -- between Garuda and openSUSE is the specification of the kernel path in the GRUB configuration file generated by grub-mkconfig, /boot/grub/grub.cfg. As shown in the following image of the Garuda GRUB configuration file, the path to the kernel always begins with same subvolume path /@/... in contrast with the openSUSE way of configuring Btrfs subvolume layouts and Snapper.
The Garuda GRUB Configuration File
The path to the kernel in /boot/grub/grub.cfg always begins with same subvolume path /@/boot/... in contrast with the openSUSE way of configuring Btrfs subvolume layouts and Snapper.
In the following image of the GRUB configuration of an Arch installation on a Btrfs filesystem with subvolume layouts and Snapper configured in the openSUSE way, the path to the kernel image is different. The path is to the specific snapshot that is used as the current root filesystem. In the image -- of the sytem which has been in continuous use forfor almost three years and undergone several rollbacks -- the root image is Snapshot # 833, which for reasons and by methods described above has been set as the default subvolume. The kernel path reflects this and begins with /@/.snapshots/833/snapshot/boot/....
The GRUB Configuration File of an Arch Btrfs Installation Configured the openSUSE Way
In the openSUSE way of configuring Btrfs subvolumes and integrating Snapper, the root filesystem is a snapshot located in the snapshots subvolume. Thus the kernel path includes the subvolume path.
As described in, A Fedora Installation with an openSUSE Style Btrfs Subvolume Layout and Snapper Intergration for System Snapshots and Rollbacks, if the parameter SUSE_BTRFS_SNAPSHOT_BOOTING="true" is set in /etc/default/grub, the logic of the GRUB scripts sourced in /etc/grub.d would generate a relative kernel image path that does not begin with the subvolume path to the snapshot and would simply begin with /boot, withoug any subvolume path. This is how the GRUB configuration would appear in openSUSE; in the Arch installation illustrated above, this parameter was omitted and as a rersult the full absolute path is used.
Testing Rollbacks
In the review of the 210621 release of Garuda, I didn't test the rollback capability, at that time using Timeshft, because in my previous use of the 210406 release that version had worked reliably. But at some point after the review of 210621, when I tried to use the rollback capability, it did not work. So for this review I tested the rollback capability. Although, as mentioned above, the subvolume layout is not as elegant as openSUSE's and Snapper capability is not used to perform the rollback -- let alone the fact that Snapper capability to set the default subvolume and its attendant advantages -- in favor of direct use of Btrfs tools by Garuda's Btrfs Assistant and its snapper-tools, Garuda's current rollback capability does work reliably. As illustrated in the following set of screenshots, I first made a manual snapshot before making any changes. I then installed Freecad and observed that it launched as expected and noted the files created by the installation at, among other paths, /usr/lib/freecad (see Image 4, below). I performed the rollback by booting into the manually created test snapshot, the one to which to rollback. Garuda's snapper-tools detected that I had booted into a snapshot and displayed a dialog asking to confirm a rollback. Confirming the rollback performed the action successfully. I then rebooted at which point I observed that Freecad would not launch and that the files created by the installation were not found on the system.
Using Garuda's Btrfs Assistant to test rollbacks.
In this test restoring to a manually created snapshot using Garuda's GUI works as it should. It even provides a dialog box when booting into the chosen snapshot to which to rollback, so all the user has to do is confirm the rollback. It is not necessary to run a Snapper command.
The internal details of how the rollback is effected notwithstanding, i.e., I prefer openSUSE's methods, Garuda's system performed well. It well surpasses Arch's recommended way of managing snapshots and rollbacks. It even surpasses openSUSE's in that it does not require the user to issue a Snapper rollback command after booting into the read only snapshot, only confirming the message in the dialog that appears. Whether the subvolume layout and the rollback process that does not really use Snapper for rollbacks will continue to work reliably is a question for regular long term Garuda users.
Nvidia Optimus
For users with relatively recent Nvidia GPUs who want to get the best performance from their computers, Garuda offers easy installation of proprietary Nvidia drivers (from the Arch repositories). Users simply need to select the non-free option in the GRUB menu when booting the installation medium to ensure that these drivers are installed and available to the system. For desktop users, selecting the boot option is the most effort they will have to exert for usable Nvidia graphics. The situation is different for laptop users with Nvidia's Optimus graphics switching system, because although the default installation will make the Nvidia driver available and enable it, the necessary tools to manage Optimus are not included by default. Also, in the default installation, although some effort is made to reduce power consumption, as we will see, it does not make a difference when compared to other distributions with Optimus management utilities.
The default state of Nvidia graphics
On my Lenovo Legion 5i Pro with an Nvidia GeForce RTX 3050 Mobile discrete GPU, the installation, by default, uses the discrete GPU in Hybrid or Offload mode. The following listing of the output of nvidia-smi confirms that it is in this mode that the Nvidia GPU is active. If it had been in Discrete or Dedicated mode, all of the applications running with a graphical output would be listed under "Processes" instead of just the main Xorg process. (See Nvidia Optimus on Linux for a discussion of the meaningfulness of this output and other Nvidia Optimus concepts.)
╭─brook@garuda in ~ as 🧙 took 34ms ╰─λ nvidia-smi Mon Jan 1 22:46:41 2024 +---------------------------------------------------------------------------------------+ | NVIDIA-SMI 545.29.06 Driver Version: 545.29.06 CUDA Version: 12.3 | |-----------------------------------------+----------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+======================+======================| | 0 NVIDIA GeForce RTX 3050 ... On | 00000000:01:00.0 Off | N/A | | N/A 31C P3 8W / 40W | 9MiB / 4096MiB | 0% Default | | | | N/A | +-----------------------------------------+----------------------+----------------------+ +---------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=======================================================================================| | 0 N/A N/A 1065 G /usr/lib/Xorg 4MiB | +---------------------------------------------------------------------------------------+ ╭─brook@garuda in ~ took 810ms ╰─λ
The default installation also ensures that the Nvidia Runtime D3 Power Management capability is enabled in "fine-grained" mode. The listing below, showing the output of
cat /proc/driver/nvidia/gpus/0000:01:00.0/power
confirms this:
╭─brook@garuda in ~ ╰─λ cat /proc/driver/nvidia/gpus/0000:01:00.0/power File: /proc/driver/nvidia/gpus/0000:01:00.0/power Runtime D3 status: Enabled (fine-grained) Video Memory: Active GPU Hardware Support: Video Memory Self Refresh: Supported Video Memory Off: Supported ╭─brook@garuda in ~ took 48ms ╰─λ
The fine-grained mode of the Nvidia Runtime D3 Power Management is enabled by ensuring the Nvidia kernel module option NVreg_DynamicPowerManagement2 is set to 0x02 in /usr/lib/modprobe.d/garuda-nvidia-prime-powersaving.conf.
options nvidia "NVreg_DynamicPowerManagement=0x02"
This modprobe config file is part of the garuda-nvidia-prime-config package, which also provides udev rules in /usr/lib/udev/rules.d/90-nvidia-prime-powermanagement.rules that ensure that Nvidia Runtime D3 Power Management is enabled when the driver is loaded and turned off when the driver is unloaded, as shown in the following listing.
╭─brook@garuda in ~ took 31ms
╰─λ cat /usr/lib/udev/rules.d/90-nvidia-prime-powermanagement.rules
File: /usr/lib/udev/rules.d/90-nvidia-prime-powermanagement.rules
# Enable runtime PM for NVIDIA VGA/3D controller devices on driver bind or device add
ACTION=="bind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030000", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="bind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030200", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030000", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030200", TEST=="power/control", ATTR{power/control}="auto"
# Disable runtime PM for NVIDIA VGA/3D controller devices on driver unbind
ACTION=="unbind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030000", TEST=="power/control", ATTR{power/control}="on"
ACTION=="unbind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030200", TEST=="power/control", ATTR{power/control}="on"
╭─brook@garuda in ~ took 30ms
╰─λ
Other options are set in /usr/lib/modprobe.d/garuda-nvidia.conf, a file belonging to the Garuda package garuda-nvidia-config
options nvidia-drm modeset=1 options nvidia-drm fbdev=1
Other interesting settings are in the /sys filesystem controlled by the Nvidia driver, namely, /sys/class/pci_bus/0000:01/device/power/control and /sys/class/pci_bus/0000:01/device/power/runtime_status, the values of which, as they existed in my initial use of Garuda 231029, are shown in the following listing. The most important of these is the value of /sys/class/pci_bus/0000:01/device/power/control which ensures that the Runtime D3 Power Management is enabled.
╭─brook@garuda in ~ took 18ms [🔴] × cat /sys/class/pci_bus/0000:01/device/power/* ... excised ... File: /sys/class/pci_bus/0000:01/device/power/control auto ... excised ... File: /sys/class/pci_bus/0000:01/device/power/runtime_status suspended ... excised ... File: /sys/class/pci_bus/0000:01/device/power/wakeup enabled ... truncated ... ╭─brook@garuda in ~ took 28ms ╰─λ
The default installation also ensures that all of the necessary systemd services required for its power management capability are enabled, as illustrated in the following listing.
╭─brook@garuda in ~ took 43ms ╰─λ sudo systemctl list-unit-files --type=service | grep nvidia [sudo] password for brook: nvidia-hibernate.service enabled disabled nvidia-persistenced.service enabled disabled nvidia-powerd.service enabled disabled nvidia-resume.service enabled disabled nvidia-suspend.service enabled disabled ╭─brook@garuda in ~ as 🧙 took 8s
The following listing shows the status of each of the above services when using Garuda in its default state.
╭─brook@garuda in ~ as 🧙 took 8s ╰─λ sudo systemctl status nvidia-hibernate.service ○ nvidia-hibernate.service - NVIDIA system hibernate actions Loaded: loaded (/usr/lib/systemd/system/nvidia-hibernate.service; enabled; preset: disabled) Active: inactive (dead) ╭─brook@garuda in ~ as 🧙 took 174ms [🔴] × sudo systemctl status nvidia-persistenced.service ● nvidia-persistenced.service - NVIDIA Persistence Daemon Loaded: loaded (/usr/lib/systemd/system/nvidia-persistenced.service; enabled; preset: disabled) Active: active (running) since Mon 2024-01-01 17:13:33 EST; 2h 31min ago Process: 883 ExecStart=/usr/bin/nvidia-persistenced --user nvidia-persistenced (code=exited, status=0/SUCCESS) Main PID: 889 (nvidia-persiste) Tasks: 1 (limit: 28428) Memory: 912.0K (peak: 2.0M) CPU: 6ms CGroup: /system.slice/nvidia-persistenced.service └─889 /usr/bin/nvidia-persistenced --user nvidia-persistenced Jan 01 17:13:33 garuda-16ith6 systemd[1]: Starting NVIDIA Persistence Daemon... Jan 01 17:13:33 garuda-16ith6 nvidia-persistenced[889]: Started (889) Jan 01 17:13:33 garuda-16ith6 systemd[1]: Started NVIDIA Persistence Daemon. ╭─brook@garuda in ~ as 🧙 took 75ms ╰─λ sudo systemctl status nvidia-powerd.service ● nvidia-powerd.service - nvidia-powerd service Loaded: loaded (/usr/lib/systemd/system/nvidia-powerd.service; enabled; preset: disabled) Active: active (running) since Mon 2024-01-01 17:13:33 EST; 2h 31min ago Main PID: 884 (nvidia-powerd) Tasks: 3 (limit: 28428) Memory: 904.0K (peak: 1.7M) CPU: 20.649s CGroup: /system.slice/nvidia-powerd.service └─884 /usr/bin/nvidia-powerd Jan 01 17:13:33 garuda-16ith6 systemd[1]: Started nvidia-powerd service. Jan 01 17:13:33 garuda-16ith6 /usr/bin/nvidia-powerd[884]: nvidia-powerd version:1.0(build 1) Jan 01 17:13:33 garuda-16ith6 /usr/bin/nvidia-powerd[884]: Dbus Connection is established ╭─brook@garuda in ~ as 🧙 took 76ms ╰─λ sudo systemctl status nvidia-resume.service ○ nvidia-resume.service - NVIDIA system resume actions Loaded: loaded (/usr/lib/systemd/system/nvidia-resume.service; enabled; preset: disabled) Active: inactive (dead) ╭─brook@garuda in ~ as 🧙 took 52ms [🔴] × sudo systemctl status nvidia-suspend.service ○ nvidia-suspend.service - NVIDIA system suspend actions Loaded: loaded (/usr/lib/systemd/system/nvidia-suspend.service; enabled; preset: disabled) Active: inactive (dead) ╭─brook@garuda in ~ as 🧙 took 66ms [🔴] ×
The Problem with Garuda for Nvidia Optimus Users
When I first got the Lenovo Legion 5i Pro, the first distribution I attempted to install was Garuda Linux because, at that time, my perception of the distribution was that everything would work correctly out of the box. As I discuss in the Lenovo review and Nvidia Optimus on Linux, this was not the case. The problem then was that Garuda installed the Nvidia drivers and Optimus Manager, but configured Optimus Manager to use the bbswitch kernel module to externally manage the power state of of the Nvidia GPU. For reasons explained in Nvidia Optimus on Linux, this GPU power state management method is not compatible with Nvidia GPUs of the Turing architecture or later generations which, with recent versions of the proprietary Nvidia driver, provide an internal power state management mechanism -- Runtime D3 Power Management.
In this releases (and maybe in the intermediate releases since the one available when I attempted the install on the Legion), Garuda solved this problem by not installing Optimus Manager, and letting users configure Optimus Manager themselves. Even the Optimus Manager developer takes the same approach to configuration, stating in the guide to configuring Optimus Manager power management functionality:
The whole point of the Optimus technology in laptops is that your Nvidia GPU can be turned off when you are not using it, resulting in significant power savings. optimus-manager supports several ways to control the power state of the Nvidia GPU, however since v1.2 they are all disabled by default. The reason for this choice is that pretty much every laptop model model requires a specific method, and using the wrong one can lead to complete system lockups, weird driver issues, or unexpected reboots
As a consequence, to use the Nvidia hardware to its fullest capability, and to enable the most appropriate of its features for a particular session, Garuda users must not only install Optimus Manager but be knowledgeable about their Nvidia hardware and set its options appropriately. This is complicated by the fact that even though all post-Turing Nvidia GPUs have the Runtime D3 Power Management capability and those before do not, different generations of post-Turing Nvidia GPUs apply power management options differently.
Garuda provides a pre-built binary package of Optimus Manager from the AUR in its Chaotic-AUR repository. This is included in the Garuda package garuda-optimus-manager-config. However, this package requires as one of its dependencies, bbswitch-dkms, which should not be used with Turing-generation or later Nvidia GPUs.
I installed Optimus Manager from the Chaotic-AUR repository and set the switching method in its configuration file appropriately for the Nvidia GPU. This not only gave me the ability to easily choose Discrete mode for the GPU instead of using the only available mode in the default Garuda installation, but somehow this also improved battery life at the same time, but I don't think this contributed to the improvement. (I did also install acpid at the same time, but I don't think this contributed to the improvement).
The situation presents an opportunity for Garuda. If the distribution developed an automated tool that applied the appropriate value for the Optimus Manager option that sets the method for controlling the power state of the Nvidia GPU, "switching", depending on the specific generation of the user's GPU it would be a distinguishing achievement that would greatly benefit users.
Fish Shell
One of the interesting choices made by the Garuda developers is to use the fish shell. In the installations of Garuda using using ISO versions prior to 231029, the login shell and the interactive shell was set to fish. In later versions including the current release, the login shell was changed to Bash. This change was a good decision because fish, by design, and as its name -- an acronym for Friendly Interactive SHell -- suggests, is meant to be an interactive shell. It is not POSIX compliant, has very different syntax from Bourne-like shells, such as Bash, and many applications components in a GNU/Linux system rely on the way Bourne-like shells operate and source configuration files to set environment variables. It is also not the shell the majority of Linux users are accustomed to using.
I assume the change was necessitated by problems arising from these characteristics, and possibly because it alienated users. In briefly investigating how fish works as a login shell, I myself did not appreciate its use as a login shell because of the disadvantages mentioned above.
But when the distribution changed the default login shell, it wisely kept fish as the default interactive shell benefitting users with its powerful features. In the releases immediately following the switch to bash, fish was activated as the user's interactive shell through the user's ~/.bashrc file, which is one of the files sourced when bash is the login shell. This method of integrating fish allowed it to be used in any terminal accessed by the user, even when using a virtual console terminal (started by CTL+ALT+Fn or when a GUI is not started automatically during system startup).
In later versions of Garuda, including the 231029 ISO release, fish is activated as the user's interactive shell directly through the terminal emulator. This is the case at least in the Dragonized edition where fish is activated when Konsole -- KDE's terminal emulator -- is launched. This method retains Bash as the interactive shell when using a virtual console terminal.
fish Activated As User Interactive Shell by Konsole
This image shows fish as a subprocess of Konsole in System Monitor, the Konsole profile settings dialog that specifies the command to activate fish when Konsole is started, and the text file that represents the profile settings.
The choice to keep fish as the default interactive non-login shell in the later version of Garuda may be a benefit for some users who value its convenience features when used on the command line. Convenience features include:
- excellent command syntax highlighting, which renders various types of tokens in different colors, distinguishing between command names, options, arguments, and strings, and even indicating an error in the command
- a very robust autocompletion feature that automatically suggests the most likely entry the user desires, and a very simple and effective method of displaying other alternative completions and accepting the desired choice
- wildcards
For an essential introduction to Fish use and features, see the Fish Tutorial. And for its differences to bash with respect to login shell functionality, see Fish
Because the features listed above make fish an excellent interactive shell, I started using it as my interactive shell -- while retaining bash as my login shell -- in all of my Linux installations -- thanks to my introduction to it by my Garuda experience. Two of fish's convenience features, especially, have caused me to consider using fish as my default interactive shell in other distributions. These are the impressive autosuggestion feature which automatically renders and continuously updates-- in grayed out text -- the most likely completion of the user's entry as the user types a command, requiring only hitting Right Arrow for the suggestion to be rendered as if the user had typed it; and the tab completion feature, with which a user can start entering a command and then press Tab to cause a list of possible completions to be displayed under the command entry line, pressing Tab cycles through the possible completions, and when the desired completion is displayed in the command, the Enter key can be pressed to execute the command, as normal.
Despite its excellence as an interactive shell, fish will occasionally become inconvenient for users accustomed to Bash due to the differences between it and Bash in, for example, how environment variables are set and special characters used in pattern matching are expaded. In my case, I am avoiding the learning curve associated with the differences because the convenience features mentioned above are sufficient, and when necessary, I temporarily switch to Bash shell by executing bash, entering commands to be interpreted by Bash and then return to fish by entering exit. Alternatively, a single command can be interpreted by Bash without switching to Bash in the terminal emulator session, by using bash -c 'command-to-be-interpreted-by-bash'. One of the situations this is necessary is when activating a Python virtual environment with the command source path-to-venv/bin/activate. Attempting to run this command directly in the fish shell results in an error because the syntax used in assigning environment variables in the activate script is not compatible with fish.
Garuda Fish Configuration
Garuda adds to the friendliness of the fish shell itself by defining in its per-user configuration file, ~/.config/fish/config.fish, many command aliases intended to make users' interactions with the terminal more convenient and the output more interesting, informative, or beautiful. Unfortunately, some of the aliases cause options to the original command to be used, and in certain cases completely replace the command with another, a behavior that may not always be desirable to some users. For example, as shown in the following listing displaying a portion of the per-user fish configuration file, the ls command is completely replaced by eza, an alternative directory listing command. (eza replaces the exa, the ls alternative previously used by Garuda) The listing also illustrates the syntax difference between Bash and fish in conditional execution.
## Useful aliases
# Replace ls with eza
alias ls 'eza -al --color=always --group-directories-first --icons' # preferred listing
alias la 'eza -a --color=always --group-directories-first --icons' # all files and dirs
alias ll 'eza -l --color=always --group-directories-first --icons' # long format
alias lt 'eza -aT --color=always --group-directories-first --icons' # tree listing
alias l. 'eza -ald --color=always --group-directories-first --icons .*' # show only dotfiles
# Replace some more things with better alternatives
alias cat 'bat --style header --style snip --style changes --style header'
if not test -x /usr/bin/yay; and test -x /usr/bin/paru
alias yay 'paru'
end
The replacement of ls with eza helps Garuda to realize the goal of making a beautiful distribution as the program's output is visually appealing. One of eza's features is its ability to display a glyph representing the file type next to the file name in the directory listing, as shown in the following image. It is also practically useful by providing options that add functionality that is not possible with ls and would require extermal programs to replicate the same functionality, such as tree when ls is used to provide directory listings. eza itself is an improvement to exa in both performance and functionality. In my previous review of Garuda, the performance of exa's -T option to produce tree output was not good in certain cases and it lacked the capability to allow specification of the levels of recursion. Both of these flaws are fixed in eza.
Directory Listing by eza
ls is aliased to eza with options including that to enable rendering of filetype icons. eza has built-in capability to output the directory listing in a tree format.
For the most part, the aliases do not lead to any kind of negative experience. In fact, in the case of eza, this leads to an improvement without unexpected behavior. But another replacement, the basic core utility cat by bat which adds syntax highlighting and Git integration to the output of file contents, does. I found myself entering the full path of the cat command in order to avoid the alias being used.
In addition to this and other numerous aliases, which may not be desireable or are not useful, and may not even be known to users, other useful capability is added to fish through functions defined in .fish files in /usr/share/fish/functions/, called as appropriate during interactions in the shell. One such function, fish_command_not_found, produces useful output indicating the pacman package that contains a command that is not found by using pkgfile on the back end. In past versions of Garuda, as illustrated in the previous review, produced a simple list of suggested packages to install, whereas now the visual presentation is much improved, also displaying package descriptions that are apparently extracted from the packages' PKGBUILD files.
Fish Shell Suggests Packages to Install When a Command Is Not Found
The visual presentation is much improved over previous versions of Garuda, in which a command that was not found produced a simple list of packages that could be installed.
Starship
Besides providing excellent interactive shell and additions to the default shell configuration, Garuda, in keeping with one of the goals of the distribution, adds elements to make the shell interface beautiful. This is not only through the Konsole color scheme that looks good and is consistent with the overall Plasma appearance (but only readable at night and when the window below the terminal window has a dark background due to the transparency setting), but by using, a Neofetch like tool called fastfetch to display system information during launch of a terminal emulator. fastfetch supports displaying the distribution logo as an actual image and not just ASCII art, and Garuda takes advantage of this capability by supplying an impressive logo (see image below). In the earlier releases of Garuda, Paleofetch -- a rewrite of Neofetch in C, and then Neofetch itself were used.
fastfetch Displays System information
Garuda currently uses fastfetch, replacing Paleofetch and Neofetch in earlieer releases to produce system information on terminal launch.
fish provides its own command prompt that is different from the typical one provided by Bash but it is simple. Garuda improves the command prompt by using Starship, a utility that provides an interesting, colorful, and informative shell prompt, similar to Powerline and Liquid Prompt, but without the Vim integration of Powerline.
Starship is activated in the per-user fish configuration file, ~/.config/fish/config.fish by the lines
## Starship prompt
if status --is-interactive
source ("/usr/bin/starship" init fish --print-full-init | psub)
end
The prompt, with the default configuration provided by Garuda displays information in two lines. As seen in the various images depicting Konsole in this article, the first line of the prompt indicats the typical user and host information and the present working directory, and the time the previous command took to execute. If the present working directory is located in a Git repository, it will display the name of the repository, or if the present working directory is at some depth below the repository root, a relative path to the root of the repository, and the name of the branch, if any, as well as a symbolic representation of the state of the repository. The second line begins with a symbolic representation of the exit status of the previous command.
Starship is extremely configurable and all aspects of the default configuration provided by Garuda can be modified, and additional components not enabled by default in the configuration can be added to the prompt. (To see my configuration of Starship on my new Arch Btrfs/Snapper installation, visit An Arch Linux Installation on a Btrfs Filesystem with Snapper for System Snapshots and Rollbacks.) The configuration, specified in the file ~/.config/starship.toml, is much less complex than Powerline but more complex than Liquid Prompt, due to Starship offering more functionality.
Both Starship and the aliasing of the ls command to the eza command rely on another component, Nerd Fonts, which are sets of fonts suitable for terminals and text editors, patched to include glyphs from the Font Awesome, Devicons, and Opticons font sets, among others. The distribution includes the Fantasque Sans Mono Nerd Font, and is set as the default fixed width font in Plasma's System Settings. It would have been useful for the distribution to package more of these fonts and include them in the Chaotic-AUR repository for users who might want a different Nerd Font.
Garuda's shell, terminal, and related customizations have improved since the previous review of Garuda Dragonized. All of the minor issues I described in that article related to the shell and terminal emulator have been fixed. The only issue that remains -- a subjective one, so some users, like the developers, may not find it an issue -- which is that, although the color scheme is visually appealing and has a unified look and feal with the other visual elements of the Plasma desktop and other applications, the usability of the Sweet color scheme used in the Garuda default Konsole profile. Like other aspects of the Sweet theme if the terminal window is on top of another window with a light background, some text is not as readable as it should be.
Another minor issue related to the terminal customizations is the lack of a better selection of Nerd Fonts on the system by default. Many popular fonts used in terminals and text editors have patched Nerd Font versions, all of them available in the AUR, but Garuda doesn't make these fonts available by default, nor do include any of the other Nerd Fonts besides Fantasque Sans Mono available in their AUR derived Chaotic-AUR repository.
Zen Kernel
One of the goals of Garuda Linux is to produce a high performance Linux distribution, a goal that has been accomplished as evidenced by the Phoronix Test Suite benchmark comparison against Solus, performed as part of the previous review (see Garuda Linux Benchmark Comparison Versus Solus). One of the enhancements that the distribution makes to increase performance is using the Zen Kernel (linux-zen), one of the kernels officially supported by Arch, instead of the default Arch kernel. The Phoronix Test Suite benchmark test against Solus did show better performance compared to the Solus kernel, but a benchmark comparison of kernels available on Arch by the Phoronix web site shows that the default Arch kernel actually offers the best overall performance over all Arch kernels, including the Zen kernel.
According to Liquorix, packagers of the Zen kernel for Debian, the Zen kernel provides "the best configuration ... for desktop, multimedia, and gaming workloads". Also accordint to Liquorix, the kernel provides enhanced performance by implementing the following features.
- Zen Interactive Tuning
- Tunes the kernel for responsiveness at the cost of throughput and power usage.
- PDS Process Scheduler:
- Fair process scheduler for gaming, multimedia, and real-time loads.
- Preemptible tree-based hierarchical RCU
- RCU implementation for real-time systems.
- Hard Kernel Preemption:
- Most aggressive kernel preemption before requiring real-time patches. Guarantees responsive system under high intensity mixed workload scenarios.
- Budget Fair Queue
- Proper disk scheduler optimized for desktop usage, high throughput / low latency.
- TCP BBR2 Congestion Control
- Fast congestion control, maximizes throughput, guaranteeing higher speeds than Cubic.
- Compressed Swap
- Swap storage is compressed with LZ4 using zswap.
- Multigenerational LRU
- Alternative LRU algorithm that performs better under high memory pressure and uptimes
- Mainline LRU patched with le9
- When using mainline LRU, cache is protected under high memory pressure at 256mb and less.
- Minimal Debugging
- Minimum number of debug options enabled to increase kernel throughput.
Previously the same source as the above list indicated that the process scheduler used was MuQSS and not PDS. The Detailed Feature List, zen-kernel GitHub Wiki states that the MuQSS is not enabled by default, but can be enabled with a certain configuration setting during kernel compilation. Which one is enabled at this time is difficult to ascertain without kernel development skills, which I do not have, but mention this feature of Garuda's default kernel for completeness of the review.
In reporting the beenchmark comparison results between Garuda using the Zen kernel and Solus, I concluded that Garuda's superior performance was due to the Zen kernel. But Phoronix's own benchmark results against other Arch kernels suggests that even the default Arch kernel would have been competitive against the Solus kernel because its results show that it has better overall performance compared to the Zen kernel. Having seen this Phoronix result, if I were to keep Garuda installed on my primary laptop, I would use the Arch kernel instead of the Zen kernel, with the added benefit of power savings on the occasions I use it on battery power.
The following image displays one of the results of from the benchmark comparison. For the complete set of results, see Garuda Linux Benchmark Comparison Versus Solus.
Garuda Linux with the Zen Kernel vs. Solus Benchmark Comparison
Garuda Linux with the Zen kernel performed better than Solus in many of the Phoronix benchmark tests performed in 2021.
zram
Another major modification to a typical Arch system, and a difference compared to every other distribution I have used, is Garuda's use of zram (also used by Fedora by default beginning with Fedora 35) which creates a compressed block device in RAM for use as swap space. This is used, as discussed in the Arch Wiki page, Improving Performance, to increase the speed of swap transactions, which has the effect of improving performance if a system often swaps due to memory constraints. As a secondary benefit zram reduces read/write cycles, increasing the longevity of an SSD if swap is on an SSD.
The compressed block device is created and managed by the zram kernel module, which reads the value in /sys/block/zramX/comp_algorithm to set the compression algorithm used to compress the block device, and the value in /sys/block/zramX/disksize to set the size of the block device. Any number of zram block devices can be created, each with their own compression type and size setting, so the X in the above paths identifies a particular zram block, where it can be 0, 1, 2 ... N. /sys/block/zramX/ contains other files used internally by the module. On the current Garuda installation, as in 231029 installation for the previous review, only one zram device was created equal in size to the amount of physical RAM on the system. The values in the two relevant paths are shown in the listing that follows.
╭─brook@garuda in ~ took 9ms ╰─λ cat /sys/block/zram0/comp_algorithm File: /sys/block/zram0/comp_algorithm lzo lzo-rle lz4 lz4hc 842 [zstd] ╭─brook@garuda in ~ took 26ms ╰─λ cat /sys/block/zram0/disksize File: /sys/block/zram0/disksize 24976031744 ╭─brook@garuda in ~ took 29ms ╰─λ
Garuda installs the package zram-generator which provides the systemd unit generator of the same name that creates the systemd-zram-setup@zramX.service service, the status of which for the single zram device is shown in the next listing. The service reads its distribution or administrator created configuration -- if they exist, they don't in Garuda (see man zram-generator.conf.5), makes the zram block device available at the appropriate systemd target using the systemd infrastructure, writes values to the paths used by the kernel, and loads the zram kernel module creating the devices.
╭─brook@garuda in ~ as 🧙 took 13ms ╰─λ sudo systemctl status systemd-zram-setup@zram0.service ● systemd-zram-setup@zram0.service - Create swap on /dev/zram0 Loaded: loaded (/usr/lib/systemd/system/systemd-zram-setup@.service; static) Drop-In: /run/systemd/generator/systemd-zram-setup@zram0.service.d └─bindings.conf Active: active (exited) since Sat 2024-01-27 14:25:41 EST; 1h 14min ago Docs: man:zram-generator(8) man:zram-generator.conf(5) Process: 683 ExecStart=/usr/lib/systemd/system-generators/zram-generator --setup-device zram0 (code=exited, status=0/SUCCESS) Main PID: 683 (code=exited, status=0/SUCCESS) CPU: 19ms Jan 27 14:25:41 garuda-16ith6 systemd[1]: Starting Create swap on /dev/zram0... Jan 27 14:25:41 garuda-16ith6 systemd[1]: Finished Create swap on /dev/zram0. ╭─brook@garuda in ~ as 🧙 took 49ms ╰─λ
Swap is activated by the associated systemd unit dev-zramX.swap. The status of this unit for Garuda with the single zram device, after it is activated as swap, is shown below.
╭─brook@garuda in ~ as 🧙 took 49ms ╰─λ sudo systemctl status dev-zram0.swap ● dev-zram0.swap - Compressed Swap on /dev/zram0 Loaded: loaded (/run/systemd/generator/dev-zram0.swap; generated) Active: active since Sat 2024-01-27 14:25:41 EST; 1h 15min ago What: /dev/zram0 Docs: man:zram-generator(8) man:zram-generator.conf(5) Tasks: 0 (limit: 28534) Memory: 8.0K (peak: 540.0K) CPU: 116ms CGroup: /system.slice/dev-zram0.swap Jan 27 14:25:41 garuda-16ith6 systemd[1]: Activating swap Compressed Swap on /dev/zram0... Jan 27 14:25:41 garuda-16ith6 systemd[1]: Activated swap Compressed Swap on /dev/zram0. ╭─brook@garuda in ~ as 🧙 took 45ms ╰─λ
Although the zram system may be beneficial for certain low memory systems which may swap frequently, it is unnecessary in systems with a large amount of RAM for the workload. In my Lenovo Legion 5i Pro, with 24 GB of RAM, I rarely have less than 12 GB of RAM available, even taking into account many gigabytes occupied as buffer/cache. This doesn't really matter; the real issue for me was that zram is not able to be used as a resume device for hibernating the system, and the Garuda installer doesn't allow specifying a traditional swap partition to be mounted in addition to the zram device, so that the swap partition can be used for hibernation for users that want this capability. In one of the supplements to this review, Garuda Linux Review [KDE Dragonized (D460nized),231029] Supplement: Fixes and Enhancements, I describe the process I used to add a swap partition to and enable hibernation in Garuda.
Performance Enhancements
All of the performance enhancements included in Garuda Linux, including the Zen Kernel and zram are those suggested in, or referenced by, the Arch Wiki article Improving performance, which covers a broad range of options for improving all aspects of system performance. In the 210621 release of Garuda, performance enhancements, such as those provided by the performance-tweaks package were enabled by default. In the current version, Garuda has made these enhancements opt-in, a good decision in my opinion, as some of the enhancements may not be necessary for all users' systems. The following image shows the Garuda Assistant Settings component that allows users to select the performance tweaks they wish to enable.
Garuda Assistant's Settings Component
Performance and power saving enhancements can be enabled here.
Energy Related Performance Settings
One of the performance enhancements made by Garuda is the favoring of, by default, performance at all times in a certain set of configuration items which represent the trade-off between less power use and increased performance of the CPU, the currently active graphics card, and a rotational disk, if present. This is done by activating the "Performance tweaks" checkbox in the Settings tab of Garuda Assistant. This will install the performance-tweaks package and dependencies.
Enabling Performance tweaks Installs Needed Packages
Enabling Performance tweaks installs an eponymous package, which consists of udev rules and tmpfiles which modify power/performance policies. It also installs Ananicy, Irqbalance, and Preload and related packages.
Installing performance-tweaks writes the configuration files shown in the following listing to the system.
╭─brook@garuda in ~ ╰─λ sudo pacman -Ql performance-tweaks [sudo] password for brook: performance-tweaks /usr/ performance-tweaks /usr/lib/ performance-tweaks /usr/lib/modprobe.d/ performance-tweaks /usr/lib/modprobe.d/amdgpu.conf performance-tweaks /usr/lib/tmpfiles.d/ performance-tweaks /usr/lib/tmpfiles.d/cpu-governor.conf performance-tweaks /usr/lib/tmpfiles.d/energy_performance_preference.conf performance-tweaks /usr/lib/tmpfiles.d/pcie_aspm_performance.conf performance-tweaks /usr/lib/tmpfiles.d/power_dpm_force_performance_level.conf performance-tweaks /usr/lib/tmpfiles.d/power_dpm_state.conf performance-tweaks /usr/lib/udev/ performance-tweaks /usr/lib/udev/rules.d/ performance-tweaks /usr/lib/udev/rules.d/30-amdgpu-pm.rules performance-tweaks /usr/lib/udev/rules.d/30-radeon-pm.rules performance-tweaks /usr/lib/udev/rules.d/50-sata.rules performance-tweaks /usr/lib/udev/rules.d/60-ioschedulers.rules performance-tweaks /usr/lib/udev/rules.d/69-hdparm.rules ╭─brook@garuda in ~ as 🧙 took 3s ╰─λ
The systemd services systemd-tmpfiles-setup.service and systemd-tmpfiles-setup-dev.service, and the associated command systemd-tmpfiles cause the actions specified in the configuration files, according to the format described in man tmpfiles.d to be performed.
The following listing shows that the files in /usr/lib/tmpfiles.d/ cause the setting of policies that favor performance for each relevant system component at boot.
╭─brook@garuda in ~ as 🧙 took 3s ╰─λ cat /usr/lib/tmpfiles.d/cpu-governor.conf File: /usr/lib/tmpfiles.d/cpu-governor.conf w /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor - - - - performance ╭─brook@garuda in ~ as 🧙 took 9ms ╰─λ cat /usr/lib/tmpfiles.d/energy_performance_preference.conf File: /usr/lib/tmpfiles.d/energy_performance_preference.conf w /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference - - - - performance ╭─brook@garuda in ~ as 🧙 took 13ms ╰─λ cat /usr/lib/tmpfiles.d/pcie_aspm_performance.conf File: /usr/lib/tmpfiles.d/pcie_aspm_performance.conf w /sys/module/pcie_aspm/parameters/policy - - - - performance ╭─brook@garuda in ~ as 🧙 took 9ms ╰─λ cat /usr/lib/tmpfiles.d/power_dpm_force_performance_level.conf File: /usr/lib/tmpfiles.d/power_dpm_force_performance_level.conf # w /sys/class/drm/card0/device/power_dpm_force_performance_level - - - - high ╭─brook@garuda in ~ as 🧙 took 9ms ╰─λ cat /usr/lib/tmpfiles.d/power_dpm_state.conf File: /usr/lib/tmpfiles.d/power_dpm_state.conf w /sys/class/drm/card0/device/power_dpm_state - - - - performance ╭─brook@garuda in ~ as 🧙 took 12ms ╰─λ
For example, the file /usr/lib/tmpfiles.d/cpu-governor.conf contains the single line
w /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor - - - - performance
where the w specifies the action "write to a file, replacing existing contents", the path following the w specifies the file to which to write, the four "-" each represent an item not used in this case, but could be octal permissions of a created file, user, user group, and a time duration after which systemd-tmpfiles-clean.service and its associated program systemd-tmpfiles remove the file.
In the case of this particular tmpfile, it should cause the systemd components mentioned above to ensure that the contents of /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor through /sys/devices/system/cpu/cpu15/cpufreq/scaling_governor (on a computer with 8 cores and 16 threads) to be "performance". The other tmpfiles will similarly ensure the text that will ensure performance settings in the /sys files to which they apply. The effect of of enabling performance tweaks with respect to the tmpfiles was surprising in that it was different on the two laptops on which I installed Garuda.
On the 2019 Dell G5, the effect of enabling Performance Tweaks was as it should be. The contents of all files referenced in the above tmpfiles were immediately changed from settings that favored power savings to those that favored performance, as shown in the first image of the following set, which displays the contents of the files that should be modified. Even the Power Profiles Daemon setting was overridden and could not be changed to "Powersave in the Plasma desktop Battery and Brightmess plasmoid.
However, on the 2021 Lenovo Legion 5i Pro, unfortunately, none of these tmpfile configuration settings had any effect, as shown in the second image of the following set. In all cases, except /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference, all settings continued to favor power savings instead of performance. And the only reason energy_performance_settings showed power save is because, unlike in the Dell G5, it always conforms to the Power Profiles Daemon setting, which was set to "Performance when the screenshot was taken. The above lack of effect of the Performance Tweaks settings did not change despite some reboots and despite the fact that the Lenovo's thermal/performance hardware switch was set to performance. If I had to guess the reason for the discrepency between the Dell and the Lenovo I would suspect it is related to the OEM platform firmware S4 handler mentioned in the section ACPI Power States of Nvidia Optimus on Linux, which interfered with hibernation as mentioned in Lenovo LEGION 5i PRO 16ITH6 Review [82JF002RUS].
Also, the files related to dpm_power do not exist, causing the error shown in the third image of the set.
Performance tweaks tmpfiles Have No Effect on the Lenovo Legion 5i Pro
Surprisingly, none of the /sys files that should be affected by the /usr/lib/tmpfile.d settings are in fact affected on the Legion 5i Pro, but they had the intended effect on the Dell G5.
Other Performance Settings
In addition to the above performance settings managed by the tmpfiles described above, enabling Performance tweaks in Garuda Settings also enables other performance enhancements that do not directly affect energy consumption, although they have separate checkboxes, so presumably they can be individually disabled at a later time. These are Ananicy, Irqbalance, and Preload, described below. In the version of Garuda previously reviewed, 231029, a few additional performance enhancements were also enabled by default, discussed in the previous review; these are memavaild, prelockd, and nohang. All of these memory optimization daemons may have been removed because of the switch to systemd-oomd, which is enabled by default (see image of Garuda Assistant, Settings tab, above).
ananicy
According to this program's GitHub page
Ananicy (ANother Auto NICe daemon) — is a shell daemon created to manage processes' IO and CPU priorities, with community-driven set of rules for popular applications (anyone may add his own rule via github's pull request mechanism). It's mainly for desktop usage.
Process priority is related to management of CPU resource allocation to processes, known as process scheduling. As processes are started, the kernel assigns a time slice of CPU use to each process in the order the processes are started. If a process runs past its allotted time slice, it is placed in a wait queue based on its priority.
Each processes has, as one of its attributes, a nice value which is a measure of its priority relative to other processes. Possible nice values for a process are between -20 and +19, where the lowest nice value has the highest priority. The default nice value for a process is 0. Generally only privileged processes can assume a negative nice value or assign a negative nice value to other processes. Unprivileged processes can increase their own nice value, i.e, lower their priority, relative to other processes.
Users can also modify the nice value of a process by invoking its program with the the nice command. Ananicy automates the setting of non-default nice values according to user contributed rules stored in files with the extension .rules in /etc/ananicy.d/ and in its configuration file, /etc/ananicy.d/ananicy.conf. Generally, rules identify a process and specify the change in the nice value from the default. Because IO priority, in addition to CPU time priority, depends on the nice value, the rules can also specify IO priority as one of the IO scheduling priority classes mentioned in man ionice: idle, best-effort, or realtime. The rules mechanism allows the grouping of processes by type, where the members of a type can be defined in any of the .rules such that nice values can be assigned to a group of processes. For example, in previous versions of Garuda, the processes named mkinitcpio, makepkg, and pacman were assigned to the group "BG_CPUIO", in the file /etc/ananicy.d/00-default/archlinux.rules, as shown below.
# Some rules for Arch Linux specific tools
{ "name": "mkinitcpio", "type": "BG_CPUIO" }
{ "name": "makepkg", "type": "BG_CPUIO" }
{ "name": "pacman", "type": "BG_CPUIO" }
This file and these rules don't exist in the current version of Garuda, but it demonstrates the basic operation of Ananicy.
The nice value can also be modified for multiple processes that can be grouped as belonging to a certain type of program. The following listing of /etc/ananicy.d/00-types.types shows some rules that affect the nice values of groups of processes.
╭─brook@garuda in ~ took 22s
╰─λ /usr/bin/cat /etc/ananicy.d/00-types.types
# Type: Game
# Use more CPU time if possible
# Games do not always need more IO, but in most cases can be hungry for CPU
{ "type": "Game", "nice": -7, "ioclass": "best-effort", "latency_nice": -7 }
# Type: Player Audio/Video
# Try to add more CPU power to decrease latency/lags
# Try to add real time io for avoiding lags
{ "type": "Player-Audio", "nice": -4, "latency_nice": -4 }
{ "type": "Player-Video", "nice": -4, "latency_nice": -4 }
# Must have more CPU/IO time, but not so much as other apps
{ "type": "Image-View", "nice": -4, "latency_nice": -4 }
{ "type": "Doc-View", "nice": -4, "latency_nice": -4 }
# Type: Low Latency Realtime Apps
# In general case not so heavy, but must not lag
{ "type": "LowLatency_RT", "nice": -9, "ioclass": "best-effort", "latency_nice": -9 }
# Type: BackGround CPU/IO Load
# Background CPU/IO it's needed, but it must be as silent as possible
{ "type": "BG_CPUIO", "nice": 16, "ioclass": "idle", "sched": "idle", "latency_nice": 11 }
# Type: Heavy CPU Load
# It must work fast enough but must not create so much noise
{ "type": "Heavy_CPU", "nice": 9, "ioclass": "best-effort", "ionice": 7, "latency_nice": 9 }
# Type: Chat
{ "type": "Chat", "nice": -3, "ioclass": "best-effort", "ionice": 7 , "latency_nice": -3 }
# Type: Compiler
{ "type":"compiler", "nice": 9, "latency_nice": 9 }
# Type: Service
{ "type": "Service", "nice": 10, "ioclass": "best-effort", "ionice": 6 , "latency_nice": 10 }
# Type: Indifference
{ "type": "IN_DIFF", "nice": 0, "ioclass": "best-effort", "ionice": 7 , "latency_nice": 0 }
# Type: Adj OOM Score
{ "type": "OOM_KILL", "oom_score_adj": 1000 }
{ "type": "OOM_NO_KILL", "oom_score_adj": -1000 }
╭─brook@garuda in ~ took 1ms
╰─λ
In the file, the group "BG_CPUIO", thus the processes assigned to the group, is assigned a nice value of 16. The listing above also shows that the Garuda rules prioritize processes defined in the groups "Player-Audio", "Game", and some others by decreasing their nice values, and adjusting their IO priority. The rules in this version of Garuda have been modified to be more conservative in their modification of nive values and IO priorities. Also, another performance enhancement daemon, previously available in Garuda Assistant is not listed in Settings component, whereas in the previous version it was.
irqbalance
irqbalance, installed as a dependency to performance-tweaksif the "Peformance Tweaks" option is enabled in Garuda Assistant,
is a daemon to help balance the cpu load generated by interrupts across all of a systems cpus. irqbalance identifies the highest volume interrupt sources, and isolates each of them to a single unique cpu, so that load is spread as much as possible over an entire processor set, while minimizing cache miss rates for irq handlers.
Its package provides a systemd service, irqbalance.service, to manage the service. A file containing environment variables passed to the service is written to /etc/irqbalance.env.
preload
preload is also installed as a dependency of performance-tweaks if the "Peformance Tweaks" option is enabled in Garuda Assistant. It is
an adaptive readahead daemon. It monitors applications that users run, and by analyzing this data, predicts what applications users might run, and fetches those binaries and their dependencies into memory for faster startup times.
The package provides a systemd service, preload.service, to manage the daemon. A configuration file is installed at /etc/preload.conf, with various settings which can be used to modify the daemon's operating parameters. Another configuration file used to pass options to the daemon's command is also provided at /etc/conf.d/preload.
Powersave Tweaks
Garuda also offers a "Powersave Tweaks" enhancement which can be enabled from the Settings tab of Garuda Assistant. This enables, among other components, all of which can be enabled independently, Power Profiles Daemon, Auto-cpufreq, and Thermald. Before eneabling Performance Tweaks, I had enabled Powersave Tweaks but found it did not seem to make a difference in saving battery life.
What actually made a significant difference in reducing power consumption as evidenced by the following image, was installing Optimus Manager, which required removing Garuda's packages conainging configuration files affecting Nvidia, as well as installing acpid, the latter because I noticed in the Xorg log that Nvidia ACPI events were not being responded to (see Nvidia, below).
Garuda Power Consumption
After installing Optimus Manager and acpid, and removing conflicting Garuda packages, power consumption was significantly reduced.
Garuda Welcome
Garuda Welcome provides a central hub for accessing various Garuda developed system administration and configuration utilities, third party utilities, and links to various support resources, contact channels, and the online services provided by Garuda. This is a vary nice looking tool, and if all the administration components worked as intended, a very useful tool. The individual components are not full-fledged GUI applications, but when activated by the GUI controls actually open a visible Alacritty terminal emulator window to execute a command in the terminal (as shown in the sixth image of the following set of screenshots), executing a single CLI command, even if the particular configuration task should perform some follow-up actions. Compared to YaST, and even a less comprehensive tool such as Mageia's Control Center, it lacks maturity and sophistication, below the surface.
More importantly, some of its components, as discussed below, do not work correctly. The worst example of this is the Garuda Boot Options component, which resulted in a misconfigured GRUB when making the simplest modification of specifying a different default boot menu item. Despite its current flaws, it, as a whole, and the Garuda Assistant has great potential for typical users who do not need the advanced enterprise capabilities of a tool like YaST.
Garuda Welcome
Garuda Welcome is a GUI that provides a central location for accessing Garuda's own GUI utilities and executing commands that run in a terminal opened in the background. Its component applications can be launched independently of the hub.
Garuda Assistant
Garuda Assistant is one of the components of Garuda Welcome, which like the other components can also be launched independently outside of Garuda Welcome.
Its intent is to allow users to easily maintain and configure their systems without a terminal, by running the appropriate CLI commands, based on the GUI's elements, in a background terminal, or in the case of one of its components, BTRFS Assistant, by opening a separate Qt based GUI application. It organizes its capabilities in a series of six tabs, one for launching BTRFS Assistant, and each of the other five containing related controls, as shown in the following set of screenshots, and described below.
This application has seen major design changes since the last reviewed version, most notably, the removal of the components related to Btrfs snapshot management to a stand-alone application. In recent past versions, this particular tool seems to have been under very heavy active development. Even during the period I was testing the 210621 version for the previous review, two new tabs were added, one of the tabs was split into two separate tabs, and additional items were added to each tab. With the latest change, active development seems to have stabilized.
Garuda Assistant
Garuda Assistant organizes its commands in seven tabs, after an update. Previously, it only had four tabs, the change indicating the rapid evolution of the distribution.
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
- Maintenance
-
The Maintenance tab (Image 1, above) contains tools to perform certain package manager tasks and modify certain aspects of the package management system, such as, refreshing repository mirrors, reinstalling all packages, clearing the package cache, removing the package database lock, etc. It also allows users to select configuration items to reset, which will copy configuration items from /etc/skel.
- BTRFS/SNAPPER
- This tab (Image 2, above) simply contains a button to to launch the separate BTRFS Assistant GUI application. This is a new development since the last reviewed version of Garuda which incorporated controls to activate commands included with Btrfs as a collection, and some stand-alone tools (main btrfs) in this tab of Garuda Assistant.
- System Components
- This tab (Image 3, above) contains controls to enable certain capabilities and system services by activating a checkbox for a particular item and selecting "Apply". The checkboxes are organized by scope, for example, "Vritualization", "Bluetooth", "Firewall", etc. I only used two of the items in this tab, the first being the "Firewalld enabled" checkbox to enable the firewalld.service. The second item I used from this tab was the "User in vboxusers group" item. I did also try the "Virtualbox" item, after having already installed the program earlier, to see what Garuda Assistant would do: it attempted to install VirtualBox from the Oracle specific package from chaotic-aur instead of recognizing the Arch default repository version of the package was already installed.
- Settings
- The Settings tab of Garuda Assistant (Image 4, above) allows user to modify one of the most fundamental system configuration items, the default login shell, set by default to bash . It aslo allows setting some less important settings which don't all seem to logically belong together, and enabling some other components, by specifying the components to install (or uninstall, if they are intalled by default). One of these components is Garuda's "Performance Tweaks" (discussed below in the section Performance Enhancements), "Powersave Tweaks" (discussed below in the section Powersave Enhancements). Two of the interesting items in this tab are networking related items that may be better placed in Garuda Network Assistant, an item that allows specifying the DNS resolving service, which places the IP address of the chosen service in /etc/resolv.conf and another item that installs (or uninstalls) the Hblock utility which blocks malicious and adserving IP addresses by rewriting /etc/hosts.
- System Specs
- This tab displays detailed system information (Image 5, above).
- Other Diagnostics
-
The Other Diagnostics tab displays information from two sources, the journal maintained by systemd, which is usually viewed with the journalctl command, and the output of two subcommands of systemd-ananlyze, each activated with a corresponding button. The information from journalctl is limited to errors and only from the current boot. Information from the other source, systemd-analyze is produced from the output of
systemd-analyze blame
which lists units in descending order of the time it took them to start, andsystemd-analyze critical-chain
which lists the hierarchy of the critical chain of units and the time each unit in the chain became active and how long it took to start.
Garuda System Maintenance, based on the name of the tools' notification and window titles, is a hotfix capability and an announcement capability, both shown in the set of images below. The hotfix tool displays a pop-up dialog informing the user that a hotfix is available and asking wheather it should be applied (Image 3, below). The tool doesn't actually work; when the user clicks "No", the tool doesn't accept the response, seemingly proceeding to apply the hotfix as indicated by the notification pop-ups shown in Image 4, although it doesn't really apply the hotfix. When the user clicks "Yes" the same notifications appear, but again, nothing is applied.
More impressive is the announcement notification, shown in the first image below. It provides useful warnings and notices to users when an intervention is necessary. The notification includes a button to open a Garuda forum post elaborating on the subject of the announcement.
Garuda System Maintenance Integration in Plasma
Garuda System Maintenance provides actionable notifications when maintenance actions are recommended.
BTRFS Assistant
As we saw above in the section Testing Rollbacks, Garuda not only implements a Btrfs and Snapper configuration that avoids complexity for the user in the Arch recommended configuration (although I thing the openSUSE's is better for reasons mentioned in the Sections Btrfs and Snapper) it also provides a GUI application, Btrfs Assistant that makes managing the capabilities provided by the Btrfs filesystem and the Snapper utility. The application, written using Qt divides its functionality in separate tabs: Overview, Subvolumes Snapper, Snapper Settings, and Btrfs Maintenance, described below.
- Overview
- This tab provides general information about the Btrfs such as the allocated and free space, including the storage space used by data blockgroups, and the Btrfs internal metadata and system blockgroups. It also allows enabling the Btrfs quota feature, scrubbung the filesystem, and performing a balancing operation on the filesystem storage (see Not Enough Space on Btrfs Filesystem Due to Exhausted Metadata Block Group Allocation for the significance of some of these concepts).
BTRFS Assistant
Click on any of the thumbnails to view a slideshow of the images.
This utility is very user friendly and includes controls not only for the basic snapshot management and configuration, but also the most important maintenance function, balancing the filesystem. It does however not include some capabilities included in openSUSE's YaST module for managing snapshots, the ability to see a diff between different snapshots at a file-level granularity, as well as the ability to restore individual files from snapshots. For comparison, the following set of images shows the screens in openSUSE's tool relevant for this functionality.
openSUSE's Btrfs Management
While the GUI provided by Garuda is easy to use it lacks the power of openSUSE's Btrfs related YaST modules.
Click on any of the thumbnails to view a slideshow of the images.
Click on any of the thumbnails to view a slideshow of the images.
Garuda Settings Manager
The Garuda Settings Manager component seems to be derived from the Manjaro Settings Manager. It includes components to manage system configuration items such as installation of hardware drivers, installation of additional kernels (Manjaro is capable of installing multiple versions of the same kernel, and not just additional variants), adding user accounts, etc, as shown in the first image of the following set. This tool makes sense in Manjaro as most configuration items are incorporated into a desktop environment's control center, and this Manjaro Settings Manager is used for other configuration items that can't be incorporated in the DE's control center. In Garuda's case, it would make more sense to incorporate the functionality of Garuda Settings Manager into Garuda Assistant.
Garuda Settings Manager
This GUI application seems to be a derivative of Manjaro's settings manager.
Garuda Gamer
The Garuda Gamer component is impressive in terms on the number of tools in its three tabs. It seems to have a comprehensive set of tools that will meet the needs of those who want to game on Linux, the most important target user of Garuda Linux.
Garuda Gamer
Garuda Gamer seems to have a comprehensive set of tools for those who want to game on Linux.
Garuda Network Assistant
The Garuda Network Assistant component of Garuda Welcome has tools related to networking organized in two tabs: "Status", "Linux drivers". (In the last reviewed version, there was an additional tab named "Windows Drivers") The "Linux drivers" tab (shown in the second image, below) is intended to show the network hardware on the system and the driver kernel modules associated with each hardware item, as well as managing the driver kernel module. While the tool accurately display the network hardware, it was not able to list the associated drivers, and as listing the modules is necessary to use the management tools, was not able to perform any of the management tasks.
Garuda Network Assistant
Garuda Netword Assistant contains some interesting tools, although some do not seem to work. One of the interesting tools is the ability to create a WiFi hotspot.
I found the "Status" page interesting because among its many tools is one to create a WiFi hotspot (shown in the third image, below). When I tried this tool, which is actually Linux WiFi Hotspot embedded into Garuda Network Assistant, it seemed to successfully create a hotspot on the 2.4Ghz WiFi radio while there was a WiFi internet connection on the 5 Ghz WiFi radio. The Plasma network system tray applet also has a similar capability and very simply creates a hotspot, but does not have the capability to create a hotspot on one band while another band is providing an internet connection to the hotspot host, as the Garuda tools seems to have. Unfortunalely, it didn't work in this way, as I couldn't see the SSID from a different device, nor could I connect by manually entering the SSID I chose in the tool.
Garuda Boot Options
The Garuda Boot Options component tool was one I was happy to see because Garuda GRUB configuration automatically sets the default selection in the GRUB boot menu, "Garuda", to load the Zen Kernel, but I prefer to almost always load the default Arch kernel, which I installed at some point to save battery life. I specified my preferred selection in the tool by changing the "Boot to" dropdown menu selection from "Garuda on linux-zen" to "Garuda on linux" (see the second image in the following set of screenshots). The result was not as expected and not as it should have been; it did not make my specified choice the default, keeping the previous default, and worse it added a duplicate set of GRUB menu items for the Garuda installation (see the fourth image in the following set of screenshots, compare to the image of the GRUB boot menu shown in one of the screenshots in the Introduction section, above).
Garuda Boot Options
Garuda Boot Options is intended to perform such actions as setting the default selection in the GRUB menu, modifying the displayed information during boot, and adding kernel parameters. Unfortunately attempting to use this tool to modify the default GRUB selection did not work just as in the previous reviewed relase of Garuda.
Software
One of the most interesting aspects of Garuda in terms of default applications intended for the end-user -- not system related software -- is that the set of software installed on the system is essentially customizable during installation. Upon first boot Garuda Welcome's Setup Assistant, after various prompts regarding whether to update and upgrade to an ultimate version, prompts the user whether to install additional packages. This tool not only allows users to relatively quickly add software, but aids in discovery of programs of which users may not be aware, displaying available choices by category.
The workflow of using this tool has been greatly improved since the last reviewed version of Garuda. Previously, it required going through many steps. For each category of software it was necessary to first answer a prompt asking whether to install software from a particular category, then checking boxes in a dialog boxes for the category. In the current version, there is only one dialog box with tabs for each category. (See Garuda Linux Review [KDE Dragonized (D460nized),231029] Supplement: Installation to see a set of screenshots from the first boot Setup Assistant process.)
More interesting is the additional repository, named Chaotic-AUR, that Garuda provides to supplement the Arch repository from which Garuda's own utilities are installed. It also includes many of the packages from the AUR as pre-built binary packages, saving users the time that would normally be spent compiling or converting non-Arch-native packages to Arch's format when installing packages from the AUR.
Unfortunately, the number of packages installed from this repository when there are versions in the normal Arch repositories is concerning as they may not be as high quality. Also, many packages that affect how the core system behaves are installed from this repository, with the ultimate source of the packages being the AUR. This is particularly concerning because, in my experience, and as in the experience of long-time Arch users on the internet, when a package affecting the core system is installed from the AUR the system may break, sometimes because the AUR packages are unmaintained or generally not of sufficient quality.
Another issue I have related to this repository and how it is used is that, besides serving the utilities developed by Garuda, it contains many meta packages that are used to install other packages as dependencies. The meta packages may be a convenience that allows installation of all packages related to a certain other package in order to ensure a particular capability is enabled in the installed system, but sometimes the meta packages cause the installation of not strictly necessary for functionality as desired by the user.
An example of these meta packages is networkmanager-support, which causes many Network Manager plugins to be installed as well as neard, a package for supporting NFC devices -- unnecessary on both of my laptops because they don't have NFC hardware. Another example bluetooth-support, which as a meta package causes the installation of necessary packages for Bluetooth functionality, but also causes a packages from the AUR (as pre-built packages from chaotic-aur) -- a possible source of instability, as mentioned above -- bluetooth-autoconnect, that is not actually necessary for Bluetooth capability.
The unnecessary packages installed by the meta packages is representative of some of the compromises between installing an Arch system the Arch way, resulting in a system that the user knows well with only the components that they want, contributing to a simple and light system, and the ease of installing an Arch based system where everything is pre-configured by the distribution.
Package Management
GUI package management in the 210406 release was provided by Pamac, installed by default. It wasn't installed by default in the 231029 release. But when going through the Finalize Installation phase of installation of that release (seeGaruda Linux Review [KDE Dragonized (D460nized),231029] Supplement: Installation), among the categories of software for the installation of additional software was package managers and software stores. This particular selection dialog allows users to choose any number of GUI package managers for inclusion in the system.
The Garuda Setup Assistant GUI Software Manager Selection Dialog
CLI package management is of course through pacman. But the Garuda developers enable certain options not found in the default pacman configuration, among them the ability to perform parallel downloads of packages. They also add the packages which provide the necessary hooks for managing the creation of new Btrfs snapshots which are then added to the GRUB menu, as mentioned above. CLI package management can also be performed by Paru, a , the Pacman wrapper that also supports the AUR. This great convenience for installing packages from the AUR, is a rewrite of Yay the previously dominant AUR helper.
Garuda also includes many aliases in the fish user configuration to make CLI package management more convenient for users who take the time to study the many configured aliases. The commands that alias package management commands are shown in the following listing.
╭─brook@g5 in ~ took 7s ╰─λ cat ~/.config/fish/config.fish | grep pamac alias aup="pamac upgrade --aur" ╭─brook@g5 in ~ took 45ms ╰─λ cat ~/.config/fish/config.fish | grep pacman alias fixpacman="sudo rm /var/lib/pacman/db.lck" alias rmpkg="sudo pacman -Rdd" alias upd='sudo reflector --latest 5 --age 2 --fastest 5 --protocol https --sort rate --save /etc/pacman.d/mirrorlist && cat /etc/pacman.d/mirrorlist && sudo pacman -Syu && fish_update_completions && sudo updatedb' alias gitpkg='pacman -Q | grep -i "\-git" | wc -l' # List amount of -git packages alias mirror="sudo reflector -f 30 -l 30 --number 10 --verbose --save /etc/pacman.d/mirrorlist" alias mirrord="sudo reflector --latest 50 --number 20 --sort delay --save /etc/pacman.d/mirrorlist" alias mirrors="sudo reflector --latest 50 --number 20 --sort score --save /etc/pacman.d/mirrorlist" alias mirrora="sudo reflector --latest 50 --number 20 --sort age --save /etc/pacman.d/mirrorlist" alias apt='man pacman' alias apt-get='man pacman' alias cleanup='sudo pacman -Rns (pacman -Qtdq)' ╭─brook@g5 in ~ took 44ms ╰─λ
Garuda Update
Most notable with regard to package management on Garuda is the garuda-update CLI tool.
Privacy
Gruda provides some applications and tools to enhance users' privacy, as evidenced by the default browser provided by the distribution, as well as some of the extensions and settings.
Firedragon Browser
The distribution's default browser is Firedragon, forked from Librewolf, itself a fork of Firefox by dr460nized, one of the developers of Garuda -- and ostensibly, based on the name of the istribution dedition, the primary developer of Garuds's Plasma edition. Librewolf removes telemetry, adds privacy conscious search engines, and includes uBlock Origin by default, among other features.
Among the privacy enhancing and other related feature differences between Firedragon andLibrewilf, as listed on its GitHub page, are:
- Searx & Whoogle search engines added, with the possibility to run locally with fitting optdepends installed
- The default search engine is Garudas searX instance
- DNS-over-HTTPS using Quad9 servers to unblock censorship by internet providers
Other differences from Librewolf, also as stated on its GitHub page are:
- Enhanced KDE integration due to OpenSUSE patches (also using kfiredragonhelper)
- Canvasblocker, Dark Reader, ClearURLs & Tabliss addons added
- Sweet theme added
- Custom, dr460nized branding dragon
- Presets for both profile-sync-daemon (which Garuda Linux ships by default) & Firejail available
Whoogle
Whoogle is a self hosted Google search proxy that can be installed locally or on a remote server. Its privacy related features, which are available whether it is installed locally or on a remote server, as stated on the project's announcement on Reddit and on its GitHub page, include:
- No ads or sponsored content
- No javascript
- No cookies
- No AMP links
- No URL tracking tags (i.e. utm=%s)
- No referrer header
- Tor and HTTP/SOCKS proxy support
- Autocomplete/search suggestions
- POST request search and suggestion queries (when possible)
- Randomly generated User Agent
- Optional NoJS mode to disable all Javascript in results
When installed on a remote server that processes the search requests as a proxy, the IP address of the computer where the search request originated is not tracked. If installed on the local computer, in which case only the privacy features listed above would be available, IP tracking would still occur -- unless the browser sends requests through a VPN, Tor, or a similar network configuration.
The Garuda distribution operates a Whoogle instance on their own servers. The default browser in Garuda Firedragon is configured to use it as the default search provider.
searX
Garuda also hosts an instance of searx along with Whoogle and is one of the available search engine options in Firedragon. Like Whoogle, searx is a metasearch engine that relays search requests to search engines. Also like Whoogle it respects its users' privacy by NOT:
- tracking users
- profiling users
- using cookies
- using connections that are not encrypted
But unlike Whooge it can relay requests to as many as seventy search engines and not to just Google. Also, like Whoogle it is installed on a remote server to get the most privacy benefits but can also be installed on a local computer. I installed it on my first installation of Garuda 210406 on my secondary laptop, following the Step by step installation instructions on the project's home page (except using the package from the Arch repositores and not by cloning the Git repository). It was an impressive tool, not only in the privacy aspects but the available search results. Unfortunately, the configuration is somewhat complicated and I didn't redeploy it after having to reinstall Garuda 210406 or after installing Garuda 231029 on my primary laptop.
Garuda Services
In addition to the privacy related tools mentioned above, Garuda provides several services, listed below, for user convenience made from self hosted cloud applications.
Links to Garuda Services on the Librewolf Start Page and the Start Pages Three of the Services
Garuda Cloud
Garuda Cloud is a a NextCloud instance hosted by the distribution that provides a small amount of cloud storage to users. One of the developers explains its purpose in the Garuda Forum post:
It is a self-hosted instance of NextCloud which can be used for a lot of things actually, I'm using it for syncing contacts, calendar and dotfiles for example. You get 250mb of storage which should be sufficient for these things.. It's meant as a test for us to find out how many people actually want to use this kind of service to maybe expand it in the future if there is demand - but its also serving as an example for you to find out how open source alternatives to proprietary ones work for you. E.g, one possible setup is connecting davx5 on android with the NextCloud to serve as alternative to Google contacts/cal sync.
Bitwarden
Bitwarden is a multi-platform password manager that allows many additional cloud powered features, such as information sharing, among different Bitwarden clients. Nitwarden Inc. can provide hosting for the services for a fee, but allows organization to self host. Garuda hosts an instance to provide the program's services to its users.
Documentation
Garuda specific documentation is provided in the form of a wiki accessible from a link in Garuda Welcome and also from an obscure menu item on the main Garuda web page. Currently, the documentation is very minimal, only providing information on the most essential of topics, one of which is on performing a system rollback. Perhaps, as the distribution becomes more mature, the documentation will become more comprehensive, covering Garuda's own tools at a level that even includes background on its underlying operations.
Garuda Wiki
Garuda has a Wiki site, currently very minimal, but covering the most important and unique aspects of the distribution such as the Btrfs/Snapper rollback capability.
Support
Support to the users on the forum is very good. Technical issues presented by users seem to be addressed quickly, with solutions provided. Less importantly, non-technical issues, such as the request for a light theme are also addressed, but some users will not be satisfied with the answers.
",
The Garuda Forum Site
The distribution provides support mainly through its forum site, but also provides numerous chat platforms for instant communication with Garuda developers and maintainers, and the Garuda community of users.
Fixes and Enhancements
The current Garuda Linux, as in the release reviewed in the earlier article still doesn't enable hibernation out-of-the-box. This is probably because of the choice of using a compressed RAM space for swap with Zram. It is however possible to add a swap space as a traditional swap partition with a lower priority such that it is not used in the running system for swap but only for storing the system state for hibernation.
Hibernation
The current Garuda Linux, as in the release reviewed in the earlier article still doesn't enable hibernation out-of-the-box. This is probably because of the choice of using a compressed RAM space for swap with Zram. It is however possible to add a swap space as a traditional swap partition with a lower priority such that it is not used in the running system for swap but only for storing the system state for hibernation.
The steps for enabling hibernation was described in the supplementary article for the earlier review, pGaruda Linux Review [KDE Dragonized (D460nized),231029] Supplement: Fixes and Enhancements. One modification to the process described there is that adding the resume mkinitcpio and regenerating the initrd is not necessary. This is because, as mentioned elsewhere in this article, the distribution now uses Dracut instead of mkinitcpio, and the installed Dracut includes typical modules, including a resume module.
Also necessary -- not mentioned in the previous article which was written by referenceing an installaiton on the Dell G5, a laptop with a pre-Turing NVIDIA GPU (see for why this matters)-- was to enable systemd related to power management of post-Turing generation NVIDIA GPUs. Garuda, although it provides easy installation of the NVIDIA drivers, because it does not bother with hibernation, does not enable them by default.
NVIDIA Power Management systemd Services Not Enabled by Garuda
As mentioned in , it was also necessary to make a modification to the systemd sleep configuration by modifying /etc/systemd/sleep.conf or in a new file in /etc/systemd/sleep.conf.d which will override the values in the former, by replacing or adding it is necessary to change the order of preference for the allowed hibernation modes from "platform shutdown" to "shutdown platform", or to only shutdown. A similar modification to HybridSleepMode may also be necessary in certain scenarios. I created a new file in and added the lines:
[Sleep] HibernateMode=shutdown HybridSleepMode=suspend shutdown
This modification is necessary not only for Garuda Linux, but all distributions installed on the Lenovo Legion 5i Pro. Without this modification, as mentioned in the Lenovo review, when initiating hibernation, the system would seem like it was hibernating but actually sleeping. Strangely powering off and powering off imediately after the rEFInd boot manager started would hibernate the system.
References
Notes:
- [1]
↩