Garuda Gnome is rather slow with opening apps

Hello everyone!

First off, I’d like to start with a brief summary of how I ended up here. Now, I’m no Linux expert and certainly don’t need to use Linux (e.g. for work), but I do like messing with my computers and have used Linux in general quite a bit in the past. I hadn’t done so for quite a while, so while I’m not quite a newbie, I’ve forgotten a lot, so I’m gonna ask for your understanding if I say anything rather stupid. Now, the machine of concern today is my 2020 Asus Zephyrus G14. I was quite fed up with how Windows sucked for daily portable usage (it is atrociously slow if you wanna conserve battery and riddled with sleep issues, at least on my machine), so I decided to give Linux a shot on this thing. I started with Manjaro but I had trouble with the NVidia stuff (didn’t read properly, it was my bad) and ended up nuking the installation, so I decided to give Garuda a go and went with Gnome because I prefer it for a touchpad device and because, well, the normal KDE Dr460nized version refused to boot up after installation on my machine. I ended up running into quite a bit of trouble, mostly of my own making because I am rather a noob when it comes to Arch, but I’ve mostly solved my issues by scouring the web. Biggest issue I had was with battery life, but that is now resolved and it’s approximately 2-2.5x better than on Windows, no joke.

Sorry for this long introduction, now to the “issue” at hand. As I said, I’m running Gnome. I’ve configured it as I wanted it, with a few extensions (most notably Vitals, Dash to Dock, Blur my Shell, Burn my Windows, Caffeine, Gesture improvements, Just Perfection and a few others) and everything is nice and stable, but man do applications take their sweet time to launch. Not even heavy ones, like my Opera browser with a bazillion tabs open. I’m talking about the Settings app or Pamac or Nautilus/Dolphin etc. Same apps open almost instantly on my KDE Dr460nized VM on my desktop (yes, I know, it’s not supported and I break it a lot, but it works) and Manjaro was noticeably snappier on the same machine (although with KDE, which was a mistake usability wise for me). When I say they take long to launch, I’m talking anywhere from 1 to 5 seconds mostly, but it’s thing that I know could be working instantly.

Now, my first thought was the CPU was, well, saving too much power, but even with the performance governor and plugged into the wall I get mostly the same behavior, just a tad better. I’m running on the integrated GPU with the dGPU disabled, but even in hybrid mode the behavior is the same (and the idle power much higher). I’ve tried a few things that I can’t even remember, I’ve tried running a cleanup with Stacer, tried BTRFS balancing, tried a bunch of kernels, nothing changes this behavior. Checked with Htop/top/iotop, nothing seems to be hogging resources constantly, biggest “offender” was Gnome Shell with sometimes like 3% CPU usage. I also read up on some bug with xdg.desktop.portal and removed xdg.desktop.portal.gnome to no avail (removing the rest would break flatpak and some other stuff, so I didn’t bother because from what I gather it’s been fixed, all the reports were from May/June, and the symptoms others have described with 30s to open apps weren’t what I’m observing).

Also, another thing is that animations don’t seem to be as smooth as I expected (going into the overview, scrolling the app drawer, changing virtual desktops, going full screen with YouTube videos takes a while etc). Xorg or Wayland, power plans, iGPU or dGPU seem to have no effect on this behavior. This has been the case since I installed Garuda and persists when connected to external monitors. It’s not a huge issue as it’s fine for what I need out of this setup, just mentioning it in case it’s connected to the app slowness issue.

At this point I’m rambling aimlessly and could go on further, so I’ll stop here and answer any questions as/if they pop up. Complete system specs are as follows : AMD Ryzen 4900HS, RTX 2060 Max-Q, 16GB RAM, 1TB SSD, Garuda is in dual boot with Windows. Here is also the output of garuda-inxi.

  Kernel: 6.5.3-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
    clocksource: hpet available: acpi_pm
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=8174d900-03e1-4c54-859f-3276705fc84f rw rootflags=subvol=@
    quiet quiet rd.udev.log_priority=3 vt.global_cursor_default=0 loglevel=3
    nvidia-drm.modeset=1 amd_pstate=active ibt=off
  Desktop: GNOME v: 44.4 tk: GTK v: 3.24.38 wm: gnome-shell dm: GDM v: 44.1
    Distro: Garuda Linux base: Arch Linux
  Type: Laptop System: ASUSTeK product: ROG Zephyrus G14 GA401IV_GA401IV
    v: 1.0 serial: <superuser required>
  Mobo: ASUSTeK model: GA401IV v: 1.0 serial: <superuser required>
    UEFI: American Megatrends v: GA401IV.221 date: 07/14/2023
  ID-1: BAT0 charge: 35.1 Wh (57.1%) condition: 61.5/76.0 Wh (80.9%)
    power: 12.9 W volts: 15.8 min: 15.8 model: ASUSTeK ASUS Battery type: Li-ion
    serial: N/A status: discharging
  Info: model: AMD Ryzen 9 4900HS with Radeon Graphics bits: 64 type: MT MCP
    arch: Zen 2 gen: 3 level: v3 note: check built: 2020-22
    process: TSMC n7 (7nm) family: 0x17 (23) model-id: 0x60 (96) stepping: 1
    microcode: 0x8600104
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache:
    L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 4 MiB desc: 8x512 KiB L3: 8 MiB
    desc: 2x4 MiB
  Speed (MHz): avg: 1399 high: 1400 min/max: 1400/3000 boost: enabled
    scaling: driver: acpi-cpufreq governor: powersave cores: 1: 1400 2: 1400
    3: 1400 4: 1400 5: 1400 6: 1400 7: 1400 8: 1400 9: 1397 10: 1400 11: 1397
    12: 1400 13: 1400 14: 1400 15: 1400 16: 1400 bogomips: 95816
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Vulnerabilities: <filter>
  Device-1: AMD Renoir vendor: ASUSTeK driver: amdgpu v: kernel arch: GCN-5
    code: Vega process: GF 14nm built: 2017-20 pcie: gen: 4 speed: 16 GT/s
    lanes: 16 ports: active: eDP-1 empty: HDMI-A-1 bus-ID: 04:00.0
    chip-ID: 1002:1636 class-ID: 0300 temp: 36.0 C
  Display: wayland server: v: with: Xwayland v: 23.2.0
    compositor: gnome-shell driver: X: loaded: amdgpu
    unloaded: modesetting,radeon alternate: fbdev,vesa dri: radeonsi
    gpu: amdgpu display-ID: 0
  Monitor-1: eDP-1 model: Najing CEC Panda 0x0050 built: 2019 res: 1920x1080
    dpi: 158 gamma: 1.2 size: 309x174mm (12.17x6.85") diag: 355mm (14")
    ratio: 16:9 modes: max: 1920x1080 min: 640x480
  API: OpenGL v: 4.6 Mesa 23.1.7-arch1.1 renderer: AMD Radeon Graphics
    (renoir LLVM 16.0.6 DRM 3.54 6.5.3-zen1-1-zen) direct-render: Yes
  Device-1: AMD Renoir Radeon High Definition Audio driver: snd_hda_intel
    v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16 bus-ID: 04:00.1
    chip-ID: 1002:1637 class-ID: 0403
  Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor driver: N/A
    alternate: snd_pci_acp3x, snd_rn_pci_acp3x, snd_pci_acp5x, snd_pci_acp6x,
    snd_acp_pci, snd_rpl_pci_acp6x, snd_pci_ps, snd_sof_amd_renoir,
    snd_sof_amd_rembrandt pcie: gen: 4 speed: 16 GT/s lanes: 16
    bus-ID: 04:00.5 chip-ID: 1022:15e2 class-ID: 0480
  Device-3: AMD Family 17h/19h HD Audio vendor: ASUSTeK
    driver: snd_hda_intel v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16
    bus-ID: 04:00.6 chip-ID: 1022:15e3 class-ID: 0403
  API: ALSA v: k6.5.3-zen1-1-zen status: kernel-api tools: N/A
  Server-1: PipeWire v: 0.3.80 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
  Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel pcie: gen: 2
    speed: 5 GT/s lanes: 1 bus-ID: 02:00.0 chip-ID: 8086:2723 class-ID: 0280
  IF: wlp2s0 state: up mac: <filter>
  Device-1: Intel AX200 Bluetooth driver: btusb v: 0.8 type: USB rev: 2.0
    speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 5-4:3 chip-ID: 8087:0029
    class-ID: e001
  Report: btmgmt ID: hci0 rfk-id: 0 state: down bt-service: enabled,running
    rfk-block: hardware: no software: yes address: <filter> bt-v: 5.2 lmp-v: 11
    status: discoverable: no pairing: no
  Local Storage: total: 953.87 GiB used: 42.45 GiB (4.4%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Western Digital model: PC SN530
    SDBPNPZ-1T00-1002 size: 953.87 GiB block-size: physical: 512 B
    logical: 512 B speed: 31.6 Gb/s lanes: 4 tech: SSD serial: <filter>
    fw-rev: 21106000 temp: 40.9 C scheme: GPT
  ID-1: / raw-size: 64 GiB size: 64 GiB (100.00%) used: 42.42 GiB (66.3%)
    fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-2: /boot/efi raw-size: 260 MiB size: 256 MiB (98.46%)
    used: 30.1 MiB (11.8%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
  ID-3: /home raw-size: 64 GiB size: 64 GiB (100.00%)
    used: 42.42 GiB (66.3%) fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-4: /var/log raw-size: 64 GiB size: 64 GiB (100.00%)
    used: 42.42 GiB (66.3%) fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-5: /var/tmp raw-size: 64 GiB size: 64 GiB (100.00%)
    used: 42.42 GiB (66.3%) fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) zswap: no
  ID-1: swap-1 type: zram size: 15.04 GiB used: 0 KiB (0.0%) priority: 100
    comp: zstd avail: lzo,lzo-rle,lz4,lz4hc,842 max-streams: 16 dev: /dev/zram0
  System Temperatures: cpu: N/A mobo: N/A gpu: amdgpu temp: 36.0 C
  Fan Speeds (rpm): cpu: 2500
  Processes: 479 Uptime: 28m wakeups: 2 Memory: total: 16 GiB note: est.
  available: 15.05 GiB used: 5.26 GiB (35.0%) Init: systemd v: 254
  default: graphical tool: systemctl Compilers: gcc: 13.2.1 clang: 16.0.6
  Packages: 1645 pm: pacman pkgs: 1610 libs: 507
  tools: gnome-software,octopi,pamac,paru pm: flatpak pkgs: 35 Shell: fish
  v: 3.6.1 default: Bash v: 5.1.16 running-in: gnome-terminal inxi: 3.3.29
Garuda (2.6.16-1):
  System install date:     2023-09-12
  Last full system update: 2023-09-16 ↻
  Is partially upgraded:   No
  Relevant software:       snapper NetworkManager dracut nvidia-dkms
  Windows dual boot:       Probably (Run as root to verify)
  Failed units:            snapper-cleanup.service 

Any suggestions, opinions, criticisms are welcome. Thanks a lot in advance and sorry for the dumb problem. Catastrophic failures are more interesting and it’s the Arch way, but I’ve managed to avoid/fix those myself so far.


1 Like

Hi there, welcome to the forum!

I’m not a GNOME user, but I’ve often read that extensions tend to break over time / updates and are a common source of troubles.
You could try removing them all and, if the situation improves, add them one by one until you try the offending one.
Apart from that, you tried a lot of things, but you could hopefully find other ideas in this tutorial:


The swirly thing means a reboot is in order. Please do so and see if it has (or hasn’t) any impact on the perceived opening. It probably won’t but it’s kind of a “tie your shoelaces” thing. :smiley:


As I said, I didn’t state all the troubleshooting steps I’ve taken in the OP. I have already tried disabling all extensions to see if it makes any difference, and sure enough, it doesn’t. Also, the same behavior was present since before I knew extensions existed (last time I used Gnome was with Gnome 2). Scrubbing through the thread you posted, the only thing that stood out to me was disabling BTRFS quotas, but that seems to be disabled on my system. I never disabled it, so it must have come that way. I have also ran a scrub and balance from the BTRFS assistant app quite a few times to no avail. System also runs cool and quiet (unlike with Windows, with which the laptop would be hot to the touch after an hour of browsing the web) and RAM is barely utilized at <1.5GB full.

I’m telling you, it’s weird AF. Manjaro with KDE didn’t have any such issues, so I’m guessing the issue lies somewhere in the software, I just can’t seem to find it. I can’t blame Garuda either. Ok, it’s heavier than a barebones distro, sure, but it’s not THAT heavy and the machine it’s running on is not slow. Only thing that’s “slow” about this laptop is its SSD, but even that is “slow” by PCIe 3.0 NVMe drives and is still capable of like 1.5GB/s reads/writes. I’m gonna upgrade that in the near future to a 2TB faster drive, but I fail to see how that could be the issue as it’s still plenty fast for just the OS.

Whatever the case may be, thanks for your answer! I’ll make sure to better read the thread you pointed me to later when I have more free time! Cheers!

Yeah, I saw that. I had just completed a round of updates just before I started writing my post here. Wasn’t the issue, obviously, but still it’s nice to have a second pair of eyes checking things out. Had I missed that and had it been the issue, I would’ve been banging my head against the wall now. But alas, I’m used to Windows, so I reboot a lot more than I really have to on Linux, so these issues don’t really affect me. Question is, what is affecting my system? Hmmmm… The mystery remains.

Also, going a bit off topic here, but before I posted anything I was scouring the Garuda forums for possible answers and I stumbled upon a thread about suggestions for customizing Gnome. That’s irrelevant to this discussion, but I saw your posts in there and if I remember correctly, you said you’re something like 71 years old? If so, damn, respect. How you have the patience to not only deal with Arch at 71, but you also actively participate in an online forum about it, helping people and being snarky about it, it’s beyond me. Hats off to you sir.


Yes, this is a retiree forum, the minimum age is 70.


Holy moly, that’s insane. Well, if that’s the case I’m gonna leave and won’t come back for the next 40-ish years. At 29 I don’t even meet the basic “looks forward to retirement” and “is in a senior position” criteria. I’m sorry that I brought shame and youthful ignorance to your forum dear sir, it won’t happen again. :joy:

Seriously though, I wish you all the best. Seeing some relatives of mine being defeated old people at barely 70 years old is disheartening, so it’s good to see there’s another side to this. Maybe I need to get my father hooked with Linux so that he stays young at 61.



Try masking xdg-desktop-portal-gnome and see if it makes any difference.

systemctl --user mask --now xdg-desktop-portal-gnome

You can unmask with the same command except with “unmask” instead of "mask" if it doesn’t help.

Hey, thanks for the input. Now, there wasn’t much point masking the package since I had uninstalled it, so I reinstalled it, which made no difference whatsoever, and then masked it which again, made no difference whatsoever. I rebooted just in case it did catch, but still no dice. Was worth a shot in any case, but I think my “issue” has nothing to do with that bug. As I said, from what I gather (a) it’s been fixed and (b) it never affected Gnome users. Still, I had to try it just in case, but it didn’t pan out.

Honestly, I’m at a loss. At this point I’m insisting on fixing it just because I want to see what is wrong. At any other point in my life, I would’ve just called it quits and installed something else (I hear good things about Fedora on this laptop, but I never grew to love Fedora). But, well, it’s my first time going Arch, even though it’s not vanilla Arch or even EndeavourOS, and giving up is not the Arch way. I may not be able to fix it in the end, but I’m learning stuff by trying so I guess it’s worth it even if I end up nuking the whole thing and starting from scratch.

Regarding distros, I honestly think I may give Fedora a shot on this laptop because, well, it’s a laptop, and maybe Fedora’s simplicity will be better suited to that use case. However, I’ve grown to love Garuda and I’m contemplating grabbing another SSD for my desktop PC and installing it there. Now, said desktop is no joke, it’s got a 5900X and a 6900XT and I’ve overclocked the snot out of everything (even my 16GB of 3600MHz C16 RAM is running at 3800MHz C14 with tight subs at 1.5V because reasons), so any “heft” that Garuda may present will be a non-issue there. I’m not saying it’s an issue on a modern powerful laptop like my G14, but on a laptop I’d much rather get +30 minutes of battery rather than extra bells and whistles. That said, even if Garuda wasn’t the optimal choice for the machine, I’m still getting (after tweaking a bit) 6-7W idle power consumption and ~10-12W doing casual browsing and light work/watching movies etc. Writing this I’m consuming 8.5W with screen brightness at 50%, so I’m more than happy with the results. If I can get it to be as snappy as it should be, then there’s no way I’m switching unless I get distro hopping compulsions again. I was clean from Linux for close to 10 years and now I’ve relapsed big time…

1 Like

Honesty, I think installing Fedora would be a good idea if you are considering it. Not to run indefinitely of course (:wink:), but it would be good to test if you have the same latency opening apps on their Gnome offering.

1 Like

Meh. Part of me wants to, really. But my curiosity is getting the best of me and I want to explore Arch. I’ve dabbled in Fedoraland in the past, but it never grew on me and I would default back to plain old Ubuntu and its derivatives. Also, with Fedora as well as with Ubuntu I never ran into solvable issues. It was either smooth sailing, or all hell broke loose. These small issues that pop up on Arch are all learning opportunities that I don’t want to miss out on. I know it may sound stupid, chasing problems and then complaining, but I intend to fully replace Windows with some form of Linux on my laptop eventually and I don’t want to nuke and reinstall every time something goes wrong. I’ve been away from the game far too long to be confident, so I need some conditioning again, and my current Garuda setup has provided me with ample opportunities to do that. I don’t even know if I’m making sense at this point, but I think I do considering where we are.

Also, I’m now on the 6.5.3 Linux kernel, and my Fedora VM is just on 6.4.something. Like, EWWW! DISGUSTING! :rofl:

Beware!!! I warn you !!! :wink:


I never found Garuda scary.
I found it easier than Debian or Fedora based distros.
I only had 3-4 significant issues ever since I installed Garuda(2.5 years now), and I was able to fix all of them with the community’s help.
You have all the software in the repositories, other obscure & some cool community projects in the AUR, and you also have chaotic-aur with Garuda.
You don’t have to go through all the hassle of managing additional repos for some packages you won’t find in the official repos and the potential of breaking your system.
You always have the latest and greatest software, and you don’t have to worry about point releases every 6 months, which also has the potential to break your system.

Garuda also has BTRFS system snapshotting, which is really a boon; it just makes you carefree of all the instabilities that might come with a rolling-based distro.


This would be way more accurate if my friends weren’t filthy casuals. Almost all of them think that using Linux in general requires some kind of black magic knowledge. I only have one friend that’s using Linux because he’s a developer, and even so, he’s using Ubuntu’s LTS versions. So I, alone, am a curious fool delving into Arch’s depths. :smile:

I don’t know about it being easier, but it sure hasn’t been nearly as hard as I expected. The only “problem” I’ve encountered that is 100% Arch’s “fault” is pacman’s syntax. I was used to apt’s and dnf’s syntax and they make more sense, honestly. Why “pacman -S” couldn’t be “pacman install” is beyond me, but that’s it, I learned the basics and I’m moving on nicely. Other than that, I love the experience so far. Yes I’ve had issues, but they weren’t big ones and apart from this sluggishness that doesn’t seem to go away I’ve been able to solve everything by reading online. Being on the cutting edge is also something I appreciate, for no other reason at this point than “bigger number better”. My machine isn’t so new anymore, so any ol’ distro will probably work fine as long as Linux 6.1 or higher is used, but I always appreciated running the latest stuff when I can.

As for BTRFS, at first I was concerned as I had read some stuff online how it’s not ready for prime time and how its development is practically abandoned from what I gather. I thought “why would they use it?”. But yeah, it’s been a-okay so far. Got my stupid butt out of trouble twice and gives me the peace of mind I need to explore. I know that I can install whatever and if it breaks the system big deal, just load a snapshot and call it a day. Honestly it’s amazing. I don’t really know the downsides, but the benefits are pretty clear.

As for Garuda by itself, I love it man. I might be complaining here, but if I didn’t love it I wouldn’t be getting into the trouble of doing so. From the fact that there’s a GUI for practically everything (heresy, I know, but if there’s a way to do something from a GUI that’s as good as doing it in the terminal, I’ll choose GUI every time - unless people are watching, then I’m using terminal to look cool :joy: ), to the fact that any package I’ve looked for is available, to the vast knowledge database that exists because of the Arch base and finally to how it’s a complete package and not a barebones install that you have to set up from scratch.

EDIT : Just notices something. In the garuda-inxi output in the display section I see that it says “Display : Wayland” and “server :”. Shouldn’t both be Wayland? I’m confused. That said, I doubt it’s causing my issues, as the issue also persists in X11 sessions.

1 Like

Lol, I didn’t meant scary :rofl:
I mean it’s addictive :grin:

No!!! see my profile (summary) in the forum :wink:
You will find another stupid fool :crazy_face:
Not everyone meets +70 yrs criteria :sweat_smile:

Complaints are welcome if they are polite :slightly_smiling_face: , polite complaints(feedbacks) help us to decide what to do next .

This is a sign of good linux user :wink: , keep it up :grin:
In fact this is a norm to show other window users how chad linux users in general are :sunglasses:


As far as I know, BTRFS is being actively developed and is pretty stable now. Garuda has been using it for the past 3 years ever since it was created (I suppose). Even the Enterprise Linux OS Suse, Fedora use it.


Good that you are have a positive learning experience. I too always thought it that way.

Did you try lts? like 6.1. Maybe the new amd-pstate CPU governor might be causing the issue.

Install the linux-lts & linux-lts-headers pacakages.

  Info: model: AMD Ryzen 9 4900HS with Radeon Graphics bits: 64 type: MT MCP
    arch: Zen 2 gen: 3 level: v3 note: check built: 2020-22
    process: TSMC n7 (7nm) family: 0x17 (23) model-id: 0x60 (96) stepping: 1
    microcode: 0x8600104
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache:
    L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 4 MiB desc: 8x512 KiB L3: 8 MiB
    desc: 2x4 MiB
  Speed (MHz): avg: 1399 high: 1400 min/max: 1400/3000 boost: enabled
    scaling: driver: acpi-cpufreq governor: powersave cores: 1: 1400 2: 1400
    3: 1400 4: 1400 5: 1400 6: 1400 7: 1400 8: 1400 9: 1397 10: 1400 11: 1397
    12: 1400 13: 1400 14: 1400 15: 1400 16: 1400 bogomips: 95816
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Vulnerabilities: <filter>

This seems somewhat strange to me, dunno. Avg speed at 1399 Mhz doesn’t seem right, but maybe I’m just reading it wrong. Try installing

sudo pacman -S zenmonitor3-git

And check, if the CPU actually starts clocking higher when you start programs etc.


The meme is real!

Once you go down that rabbit hole there’s no clawing your way back. I fumbled around in Linux for a while–this distribution, that package manager–but just never found one that scratched a particular itch, though many came close. Then I stumbled upon Arch, tripped, and “I’ve fallen and I can’t get up.” And I’ve been stuck in those depths for over a decade now. Not that I mind.

Me neither, just the people that use it. :wink:

GNOME, basically a minion of Red Hat’s, has always been in the forefront of Linux (sub)systems development. It’s probably best expressed with the (also Red Hat’s) Fedora distribution.

Personally, I like GNOME very much and have used it extensively. But it does not always play well in Arch. The trick for me, in Arch, anyway, is to substantially use it in the manner Red Hat intends it to be used. I seem to have fewer hassles with it that way. In Arch.

YMMV. :smiley:


“Snarky” may be a combination of age, pain levels, lack of sleep and a low tolerance for people that won’t read/search. And tl:drs like this. :wink:


Well, I try to keep my criticism constructive when I can. And if not, I’ll make sure to throw in a backhanded indirect insult somewhere. :sweat_smile:

Yeah, I don’t know what exactly I was reading tbh. I usually stuck with ext4 because that’s what I knew worked. But I have to say the most positive thing possible about BTRFS, I never know I have it. If I know what filesystem I have, it’s for a bad reason 99% of the time. As long as it does its thing and is out of my way, it’s perfect.

Battery life difference is quite massive. Basically, as I said in the OP, comparing minimums I’ll get 6-7W on Garuda and just shy of 12W on Windows. Thing is, Garuda as I have it set up doesn’t constantly spike power consumption the same as Windows, which will cause the power draw to spike for something as mundane as moving the mouse. So realistically the difference is even bigger than the minimums suggest and my laptop is actually usable as a portable computer again. Go figure!

As for kernels, I’ve tried the prepackaged Zen kernel, the znver2 kernel, LTS and mainline Arch 6.5 kernel. None of them exhibited noticeably different behaviors. I’ve set a flag in grub.cfg to force enable the amd-pstate driver at boot when I was trying to improve battery life (when in fact the only reason I had high idle power draw was NVidia’s bs). I’ll make sure to try without that and report back.

I’ll install that utility and report back on what I find.

That CPU speed isn’t strange, I was out and about and needed my battery to last as long as possible, so I forced it to use the powersave governor which basically forces the clockspeeds as low as possible. Normally it uses the schedutil governor from the amd-pstate driver (or ondemand) when on battery and the same or performance when plugged in. When using anything but the powersave governor, CPU speed ramps up and down according to load, so that’s not an issue. Even boost seems to work fine, which I assumed wouldn’t.

When you say “in the manner Red Hat intends”, do you mean vanilla Gnome? If so, I refuse to do that. It’s too limited, to the point that even MacOS feels more functional to me (and I hate MacOS). The interface is very nice and with extensions it’s honestly amazing, I appreciate the simplicity compared to KDE (which I still prefer), but it needs more functionality than it has in its vanilla form. Anyway, it’s not like it’s breaking or not working as intended, it’s just slower than it should be. Things could be worse.