Terminals are cool, tiling is amazing, electron sucks, DEs suck and KDE is for psychopaths.

“Want to come check out my neofetch? Where are you going?”

It’s been 3 years since I switched to running Linux full-time on both my desktop and laptop. Of course, the first year or so was marred by a sub-optimal experience with an uncooperative set of laptops, trying to get them to do things they just weren’t designed to do.

After that, I settled on separating duties into a desktop and a laptop again. In this post, I’ll be rapid-firing interesting things about each build that I ran into - whether it’s a problem, solution, neat tool, or workflow change that stuck with me. Sorry if it gets rambly - this is really half blog post, half link dump for my personal reference - if you want, you can jump to the part where I talk about gaming or the conclusion.

The Laptop Experience

The laptop that I finally settled on (for regular laptop things) after trying… uh… four laptops from major manufacturers was the Dell XPS 13 2-in-1 7390. To recap:

• Razer Blade Stealth 2019: Display issues that somehow only occurred on Linux. My best theory is that this is somehow related to panel self-refresh, but why it occurred through reboots, only after running Linux, and in the BIOS is unfathomable to me.

• Lenovo Thinkpad T480s: A power hungry WQHD display and underpowered cooling canned this contender firmly in the bad battery life and poor performance zone.

• Dell XPS 13 9380: Inadequate cooling and throttling issues, again.

• Razer Blade Stealth (Late 2019): I never wrote about this, but I did try the late 2019 model. Unfortunately, I was so burned by Razer at this point that when I ran into an issue with xf86-video-intel where electron apps were “frozen” (an issue that I can’t find documented anywhere except my current laptop’s arch wiki page, oddly) thanks to the Gen 11 Iris GPU inside having immature support and a bad combo of drivers, I blamed Razer and returned it immediately.

To be completely fair to these machines, I didn’t really use them as laptops a whole lot, aside from the Blade. So the Thinkpad and XPS could be perfectly great laptops, but I wouldn’t really be in a position to say. They weren’t great for performance, is what I can conclude.

Anyway, it usually comes with me on non-work trips or couch stints and streams/plays light games, does web browsing, remotes into servers, and watches lots of video with mpv.

Bad Hardware Decisions

Right off the bat, here’s a list of what doesn’t work on the 7390:

• The webcam (seriously)

I’m really not sure how Intel dropped the ball this badly.

Intel Icelake integrated the IPU 4th Generation Gen IPU with on-die MIPI interface, which is not supported by Linux.

Yikes.

Supporting IPU4 is an exercise that will likely take many months of effort. It is not being worked on, that I’m aware of, and has no sponsorship to do so.

So Intel decided to leave Linux out in the cold for their next gen image processing. Great.

• The fingerprint reader

  • So, apparently a lot of laptops use “Goodix” brand fingerprint readers, which are extremely difficult to support and are closed-source. Dell earned a small bit of my good will when they promised their 2020 XPS 13 Developer Edition would have support for the fingerprint reader in Linux.
  • What this actually meant in practice was that they distributed a proprietary blob for that one model of fingerprint reader which contributed nothing to the disjointed support that these readers see in Linux and libfprint. I am upset and scream into the void. Nothing happens.

• The touchpad & keyboard (sometimes)

  • This issue was as arcane as they come and I’m still not fully sure what’s going on. At times, the touchpad will just stop responding. Clicks will work, scrolling will work, but moving the mouse will not. dmesg spits weird errors that seem like they’re to do with hardware. The touchpad is configured to reject input if you’re typing, which makes sense, but it seems like the laptop will present a false-positive sometimes and pretend like the keyboard is active when it’s not.
  • This all came to a head when my laptop keyboard completely stopped responding for a few reboots, taking the touchpad with it. Flexing the frame can cause it to resolve itself, further cementing a hardware issue in my mind. Not a great experience, and I run into it about once a month.

Wayland is almost there

When I wrote about Wayland earlier, it was regarding video hardware acceleration in Firefox, something that was just closed 2 years later only to be continued in this bug with yet more issues. At this point, I shouldn’t be surprised when I see outstanding bugs for Firefox lasting this long.

It works great until it doesn’t, and when it doesn’t work, you can either wait, or go back to X. To be completely honest, I have mostly resolved my issues with Wayland because I haven’t really touched the laptop’s configuration. You set environment variables and forget them, and they mostly work okay. If I search for “wayland” in my dotfiles, I get:

/etc/environment:

MOZ_ENABLE_WAYLAND=1

mpv.conf:

gpu-context=wayland

.config/sway/config:

# load dpi via xrdb for XWayland
exec xrdb -load ~/.Xresources
# modified redshift for wayland
exec redshift -m wayland > /dev/null 2>&1 &

While we’re on the topic of env vars, one interesting thing to note is that if a game/application was made with SDL2, launching it with SDL_VIDEODRIVER=wayland and a recent version of SDL will actully make it Wayland native!

I think if I had Wayland on my desktop, I’d have more to rant about here, but I don’t at the moment.

---

There are GOOD THINGS about Wayland, don’t get me wrong. It’s just that, for the most part, you won’t notice them. But when I plug in a USB-C dock and connect it to HDMI and - oh - the display is detected and sway has already output to it, hey, that’s neat, you know what - I shouldn’t have to go muck around with xrandr. Nice.

http://arewewaylandyet.com is getting fairly promising, but if you dig into the weeds, you can check out the issues and if you really want to get depressed, you can read this article.

I’m remaining positive, because I can afford to spend a bit of time configuring my machines. A lot of good news is on the horizon since I made my exhaustive last post. Some of this should wait until the gaming section, but we’re talking about Wayland now, so:

• DRM Leasing: Support for VR headsets in Wayland requires that resources can be “leased” - meaning Wayland clients can request exclusive access to a VR headset, for example. This was merged in September 2021 and is supported by wlroots now, so I’m hopeful that experiences like this and this and this will be a thing of the past and maybe Valve will get their shit together once the Steam Deck is out.

  • Oh, and XWayland is getting support for it as I write this post. Neat!

• HDR: I care more about HDR these days because I’ve tasted a bit of the forbidden fruit, and own both an LG C1 and an LG 34GN850-B. They look amazing, but unfortunately, HDR just isn’t a thing on X. For wayland, the color mangement protocol WIP is still pending but it looks like progress is still happening since the Collabora post about it in 2020.

• Wine on Wayland: Not only is Collabora involved in the color management talks for Wayland, they are also making significant progress on a Wayland driver for Wine. It even works with DXVK. I don’t have any testing experience with it yet, but perhaps once all of this comes together, I’ll give it a shot.

• Gamescope: Gamescope is a Wayland compositor that’s about to get some primetime on the Steam Deck! This is exciting news in itself. Essentially, it’s a very efficient compositor that removes extra copies and latency where possible, and you can even “spoof” the resolution that the game sees in order to accomodate all kinds of display situations.

Whoa, sensors and touchscreens work?

To add on to the previous section about wayland, since this stuff is kind of all integrated, something I was definitely not expecting was accelerometer and touch screen support to be as good as it was. Most of this is thanks to Sway, which is extremely consistent with i3 for me and a joy to use. I find things that took a large amount of toil under X, in terms of screen setup and configuration, are just easier. For example:

• Configuring a monitor

  • One line can define both resolution and the wallpaper. Nice.

  output eDP-1 mode 1920x1200 pos 0 0 bg /home/wallpaper/night.jpg fill
  

• Using a touch screen (I already mentioned this, but I’ll mention it again!):

  • It’s one line too. Yeah.

  input type:touch map_to_output eDP-1
  

• The 7390 is a 2-in-1, meaning it can fold and become a tablet. Install rot8 and launch it in .config/sway/config.

  • Just an exec line.

  exec rot8
  

• One of the things that’s not as easy to figure out is configuring lock during sleep/wake. The official recommendation is this arcane command, which I guess I understand, but seems wacky.

  exec swayidle -w \
           timeout 300 'swaylock -f -c 000000' \
           timeout 600 'swaymsg "output * dpms off"' resume 'swaymsg "output * dpms on"' \
           before-sleep 'swaylock -f -c 000000'
  

Once you get that done, it’s just a matter of configuring replacements for all of the X tools you use. For me, it’s:

• Rofi -> Wofi
• Dunst -> Mako
• qimgv -> imv
• polybar -> waybar

The most “it just works” experience I had using Sway was launching Slay the Spire, folding into tablet mode, and rotating the screen. Then I was able to play with the touchscreen seamlessly.

Bonus: one interesting thing to note is that if a game/application was made with SDL2, launching it with SDL_VIDEODRIVER=wayland and a recent version of SDL will actully make it Wayland native!

The Desktop Experience

Currently, I’m running a 5950x and a 6900xt that I was somehow able to snag at the height of the shortage last year. And now that I look at my initial parts list from 2019, quite a lot has changed.

• CPU: 3900x -> 5950x
• GPU: 5700xt -> 6900xt
• Motherboard: Gigabyte X570-I AORUS PRO WIFI -> ASUS ROG STRIX X570-I GAMING
• Corsair SF 600W -> Corsair SF 750W (due to the power hungry component upgrade)

Since we’re now in desktop land, turns out, you do get to pick your hardware when it’s in stock. The unfortunate part of my mini ITX form factor choice is that I’m limited to very few choices if I want X570 (and I did). More on what happened with the motherboard when we talk about USB issues, but this is kind of where I’ll start talking about issues that aren’t specific to laptops, but apply to my experience in general.

Steam In-Home Streaming

As I’ve been spending more time on the couch these past few months due to medical issues, I’ve had to rely on my Shield TV to do an insane number of tasks, from game emulation, playing 4k HDR video from the NAS, and most relevant to this post, using the Steam Link app to do in-home streaming from my desktop.

Once I figured out the best way to get the Shield a stable connection (it’s in a bad spot for wifi, and these powerline adapters couldn’t overcome the shit wiring in my house, so I just bit the bullet and ran another cable downstairs), it worked pretty well. I’ve encountered two main issues with it, though:

• Full-screen games simply do not stream.

  • This is a known issue on github for ~1.5y with no fix in sight. This is the more annoying of the two bugs, since it means I can’t just launch a new game from the couch, I have to get up and change the resolution (usually to windowed 1080p), then relaunch the game.

• After a while, audio will begin to degrade and crackle, and the session will start to act up.

  • Another issue that’s already tracked, but has gone ~2y without a fix. In my experience, this happens after about ~1-2h of remote play. Usually it’s fixable by just restarting the stream and you’re good to go, no game restart required. But it’s still a very annoying issue.

I was hopeful that maybe wayland and/or the newly added -pipewire flag for steam would help with these, but it looks like those come with their own set of issues, so I’ll stick with X for now. Overall the experience is almost there, but marred by these two big issues. Props to Valve for even implementing this at all, but with just a little more attention it could be great.

Systemd and PCI Bring-up

I still have absolutely no idea how to use systemd in order to delay services until such time as devices are “ready” for arbitrary modifications. It was a problem in my eGPU build, and it persists today, even when the GPU is connected from boot.

You can list devices with systemctl list-units -a -t device and block on them coming up with Requires or After, I think, but this doesn’t really seem to work with any of my use cases:

• Setting the RAM color with OpenRGB
• Setting the Motherboard LEDs with OpenRGB
• Setting the Kraken cooler settings with liquidctl
• Overclocking my GPU with upliftpowerplay

Even if I block on dev-dri-card0.device to wait for the GPU, running upp too early results in the powerplay tables not being modified.

So, I guess I’m just doing sleep 10!

e.x.:

sleep 10
chmod 666 /sys/class/drm/card0/device/pp_table
/usr/bin/upp --pp-file /sys/class/drm/card0/device/pp_table set --write smc_pptable/SocketPowerLimitAc/0=293 smc_pptable/FreqTableUclk/3=1075 smc_pptable/qStaticVoltageOffset/0/c=0.145000

or:

[Unit]
Description=OpenRGB Color Setting Oneshot

[Service]
Type=oneshot
ExecStartPre=/bin/sleep 10
ExecStart=sudo -i openrgb -d 0 -m Static -c "6902F9"
ExecStart=sudo -i openrgb -d 1 -m Static -c "6902F9"
ExecStart=sudo -i openrgb -d 1 -m Static -c "6902F9"

Partially, I blame myself for not digging deep enough, but the deeper you go into systemd, the more hellish it becomes, as illustrated by these confusing-as-hell examples.

What the hell, systemd-resolved?

While we’re talking about systemd, can you explain the following for me? I don’t get it.

$ kubectl create -f <some url>
Unable to connect to the server: dial tcp: lookup raw.githubusercontent.com: Try again

$ sudo resolvectl query raw.githubusercontent.com
        raw.githubusercontent.com: 151.101.192.133
                         151.101.128.133
                         151.101.64.133
                         151.101.0.133
                         (github.map.fastly.net)

??????????????????????????????????????????

$ sudo systemctl disable systemd-networkd.service
$ sudo systemctl disable systemd-resolved.service
$ kubectl create -f <same url>
<it's created>

Distorted Audio with a Scarlett Solo

This one was actually due to a kernel bug that was only recently fixed! Though I didn’t know it at the time.

This bug would cause audio output from my Scarlett Solo (a combo DAC and amp) to become distorted. Both apps were requesting different sample rates, one for input and one for output. Because I was using the same device for both, this issue cropped up. I eventually gave up and bought a separate Fiio DAC to use.

AMD Chipset USB Issues

This isn’t a Linux specific issue, but I’ve also been plagued by USB connectivity issues on my X570 motherboard that aren’t entirely fixed. Every now and then, the 3.0 ports will just… drop off the bus after the computer’s been on for a while. I’m on BIOS 4021, and it happens very rarely now, but when it does, I have to completely power off the system and shut off the PSU (!!) before turning it back on and rebooting - hot rebooting will not fix it.

This was much more pronounced when I had the old Gigabyte motherboard above, it’s since improved so I’m not too bothered, but I hope this type of thing doesn’t become a pattern for AMD in the future.

In an attempt to quantify this, I looked through my logs:

$ journalctl | grep "xhci_hcd 0000:06:00.1: Timeout while waiting for setup device command" | cut -d' ' -f3 --complement | uniq
Jul 08 kernel: xhci_hcd 0000:06:00.1: Timeout while waiting for setup device command
Oct 31 kernel: xhci_hcd 0000:06:00.1: Timeout while waiting for setup device command
Nov 01 kernel: xhci_hcd 0000:06:00.1: Timeout while waiting for setup device command
Nov 02 kernel: xhci_hcd 0000:06:00.1: Timeout while waiting for setup device command
Nov 04 kernel: xhci_hcd 0000:06:00.1: Timeout while waiting for setup device command
Nov 06 kernel: xhci_hcd 0000:06:00.1: Timeout while waiting for setup device command

It looks like I’ve only run into this 6 times in the past year, and only on my monitor’s USB hub attached to a 3.0 port (there’s nothing attached to the other 3.0 port next to it, so that checks out). I don’t really know what I was doing on those days, but I think my uptime was fairly long over that period in november, and my zsh history shows I tried to manually fix it before giving up. /shrug

$ history -i | grep 2021-11-06
 8365  2021-11-06 10:31  sudo dmesg | grep usb
 8368  2021-11-06 10:38  echo -n "0000:06:00.1" | sudo tee /sys/bus/pci/drivers/xhci_hcd/bind
 8369  2021-11-06 10:40  lsusb -tv
 8370  2021-11-06 10:50  mpv /dev/video0
 8371  2021-11-06 10:55  shutdown now

What the hell, OBS?

I do some streaming to twitch or movienight when I feel like it, and OBS is indespensable and pretty much the gold standard. And yet, despite getting a massive new release late last year that supports Wayland capture sources (!!), I still manage to run into a segfault every now and then, even just changing my config will sometimes cause a crash.

$ journalctl | grep segfault | grep obs  
Oct 14 15:53:15 kernel: obs[780273]: segfault at 38 ip 00007fe8601942c8 sp 00007fff58bc3ad0 error 4 in libpipewire-0.3.so.0.338.0[7fe860159000+5c000]
Dec 04 22:13:53 kernel: obs[3182519]: segfault at 38 ip 00007f31c03735b8 sp 00007ffc02c71000 error 4 in libpipewire-0.3.so.0.340.0[7f31c0338000+5e000]
Dec 05 00:21:57 kernel: obs[3189224]: segfault at 38 ip 00007fe2747885b8 sp 00007ffda7e81400 error 4 in libpipewire-0.3.so.0.340.0[7fe27474d000+5e000]

Looks like my history says pipewire is to blame.

There’s also a weird lua issue where, if you use the VLC plugin (for example, streaming a video file to movienight) on Arch, you’ll get a crash unless you install vlc-luajit from the aur.

Another thing to note is that since I’m still on X, I can’t take advantage of the low-latency copy tech from the Wayland capture patch. One of the ways you might better performance is to try obs-vkcapture, which has performed better (higher stream FPS, less dropped frames) than the native window grabbing for me, especially for demanding games like Control.

Open Source Drivers & The 6900 XT

When I was agonizing over my 5700 XT, I was scouring the mesa bug tracker almost daily to see what the progress was on fixes. When I finally got my 6900 XT, it was like night and day. Since I had rolled back to the Vega 64, I was expecting a massive perf uptick and I got it, along with few stability issues. I got to enable Resizeable BAR (Smart Access Memory), since it’s supported in the kernel and was excited to wait for AMD FSR to be open sourced.

The only real issue I ran into out of the gate was a nice panic when my previous openrgb configuration tried to set the LED colors on the 6900 XT, which clearly would not fly. I temporarily disabled it and checked the page for a fix, where unfortunately it was “let’s just not poke those buses” and it looked like I wasn’t going to get nice pretty colors on my new GPU. It’s being worked on, but not much progress at the moment.

Since the Vega and 5700 XT, I can count the number of lock-ups I’ve had on one hand. greping journalctl for ring gfx_0.0.0 timeout produces only one result, and it’s the problem from the previous paragraph. Games have locked up, but switching to more recent versions of Proton and updating generally resolve those issues.

So, with that out of the way, I guess this is where I talk about gaming on Linux for the past few years. I’ve said a lot, but I still have a bit more to say.

Weird Vulkan Issues - Layers and Env Vars

Another rant about environment variables! Look, I don’t mind setting them. In fact, since I can commit my .profile to my dotfiles repo, whatever, right? Who cares? Set and forget!

Around mid-2020, users of MangoHud ran into an issue where games just wouldn’t launch. I’m not entirely sure what the issue was, but it seems like it had to do with the device select layer and the number of GPUs that were presented. The workaround was to set NODEVICE_SELECT=1. I had this set for a while until it was fixed.

Then, in early 2021, AMD tried to make AMDVLK (the open source graphics driver that AMD maintains) aware of RADV by adding a Vulkan layer, VK_LAYER_AMD_switchable_graphics that would allow setting of AMD_VULKAN_ICD to the user’s preferred driver (rather than just setting VK_ICD_FILENAMES to point to the loader you want to use). As this issue explains (opened by the maintainer of vkBasalt), the implementation was botched and broke some apps for users. Of course, I ran into this, and had to manually set this to keep using RADV:

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json

When it eventually was “fixed”, AMDVLK still seems to behave badly for me and I’ve given up. I now just force AMD_VULKAN_ICD=radv in my .profile. I suppose I’ll take setting env vars as a workaround instead of patching and rebuilding mesa.

AMD FSR

In July 2021, AMD open-sourced FidelityFX Super Resolution, their kind-of-an-answer to DLSS, which doesn’t use AI/ML but instead uses a upscaling and sharpening algorithm that can run on any GPU to upscale a lower resolution image to a higher one, providing the performance benefit of the lower resolution without as much quality loss.

Like DLSS, game developers can choose to implement FSR in their game, and doing so will be the best experience for the end user. In this ideal implementation, FSR will apply to the frame before post-processing and the HUD render, since it might muddy the effects or distort the HUD.

But what about games that don’t support FSR? Since it’s open source, it was proposed to add it as an upscaling filter directly in winevulkan, and though that pull never got merged, it was shortly after added to GloriousEggroll’s Proton fork, where setting WINE_FULLSCREEN_FSR=1 will enable it for any Vulkan game. Take note that this approach applies to the frame last, since we’re not able to inject this render step into the game’s pipeline, and so it may muddy up the HUD a bit.

So this is clearly great, since now we have FSR on almost any game! I mentioned the pull never got merged, but it looks like an RFC has been opened on gamescope for FSR support - might this be something that Valve wants to advertise and use on the Steam Deck? 👀

Day One Game Support

If you are at all interested in gaming on Linux, I highly suggest you follow Pierre-Loup Griffais. He’s been working on supporting games on Linux for Valve, and always has interesting info to share. Recently, he has been tweeting about getting early access to large games so that Proton/vkd3d/dxvk devs can make sure they’re ready for release. Most recently:

• Deathloop (3 days late, radv only (!))
• Monster Hunter Rise
• God of War

These are huge wins! This shows a willingness from these companies to at least do the bare minimum and help their games become available on a new platform. Granted, it’s Steam with its massive market share, and the Steam Deck is likely a huge reason for them to do so.

Of course, the elephant in the room here is Microsoft. They have absolutely no reason to support Linux, or the Steam Deck when they’re focusing on Windows and Xbox, especially with Gamepass and xcloud. Halo Infinite doesn’t work after ~3 months, possibly due to some anti-cheat, or features of d3d12 that aren’t supported by Vulkan. If this trend continues, it’ll be worrisome to see Microsoft try and claw back the platform exclusivity that Proton has gained us, even if they do release their games for “PC”.

Anti-cheat

Playing on Linux comes with avoiding games that have too-invasive anti-cheat. I still check ProtonDB before every purchase, and am careful to ensure games work, but what this means is that generally, as long as I use Linux, I’ll have a smaller library available to play with friends. There have only been a few times where I’ve wished a game would run on Linux (Back 4 Blood, most recently), and hopefully this is a problem for less games in the future - Valve has made steps available for developers to use EAC and BattlEye with Proton.

However, there has been pushback from some developers who have been asked to implement EAC for Proton, claiming that it’s not “just a few clicks” if your game is on Epic and uses the “EOS” version of EAC.

Well, Valve has made another post in which they claim, well, it really is that easy now that they’ve worked things out with Epic.

adding Steam Deck support to your existing EAC games is now a simple process, and doesn’t require updating game binaries, SDK versions, or integration of EOS.

Per the partner docs:

Go into the EAC settings on the EAC partner site and enable Linux support from the dashboard. Once that’s done, download the EAC Linux library (easyanticheat_x64.so) for the SDK version integrated with your game, and add it to your depot next to the Windows library (EasyAntiCheat_x64.dll). Lastly, on the Steamworks site, publish a new build of your game containing the new depot contents. (You don’t have to make any changes to the game executable, just include the new files in the depot contents.)

Unless I’m missing something, Valve is breaking down all the barriers and leaving little excuse for why your game won’t run on Deck. This is great news, and I hope to see more games on http://areweanticheatyet.com/.

Vulkan Adoption In Popular Open Source Projects

One other trend I’ve noticed over the past few years, as Vulkan has received more attention from the general consumer as being more performant than OpenGL, is the implementation of Vulkan backends and renderers in emulators and game engines. PCSX2 most recently got this treatment, following the incredible Dolphin among others - it seems most popular emulators now have Vulkan backends set as the default going forward. This is undoubtedly a good thing and shows the success that Vulkan has had in becoming the new open graphics standard.

Feature Stability and Tweaks

Congrats, you made it to the part of the post where I brag about how cool I am.

Looking through my commit history, I’ve made plenty of changes to make my repeated tasks quicker, and it’s an incredible time saver to solve a problem once, record how it was solved, and make it available for future me. As someone who hoards and sorts a lot of data, I prefer to use command line tools to solve problems, and so make heavy use of classics like grep and find. curl and jq are also indespensable for what they do. So here’s a list of shortcuts, tweaks and programs that I use regularly, to illustrate my point and potentially make them useful for someone else:

• To-Do lists and notes: Neovim, Syncthing, and Taskwarrior
  • Using a text editor with flat files might seem archaic, but I don’t want to be stuck with a random database or file structure that I can’t read later.
  • Taskwarrior’s cli interface is amazing, and in particular its ability to add priority to tasks and annotate them with notes. I frequently use annotate to add links to tasks.
• i3, a tiling window manager
  • I thought tiling wms were a meme, but I can’t go back to floating. Using the keyboard to move windows and take advantage of an ultrawide monitor is just too good.
• A “scripts” directory
  • To reduce clutter, I have a .myname directory in my homedir for things like my OpenVPN profile, user icons, custom zsh themes, wallpapers, and scripts.
  • I use zsh’s hash to create two-letter shortnames for that directory, and the scripts directory
• nnn and bookmarks
  • nnn has increased the speed at which I can manage files drastically. I highly recommend setting up bookmarks which can be triggered with b and then a second letter to warp instantly to a directory. If d is my downloads directory, then mod+enter launches the terminal, n launches nnn, bd moves me to my downloads directory, vimkeys and space selects a file, bi moves me to my NAS, and v moves the file. It’s become faster and more intuitive than using cd and mv for me, plus it provides better visual feedback.
• updating everything at once with one script
  • I’m really bad about updating things if they’re not all managed by my package manager, so I have a script that runs:

    yay
    rustup update
    pipx upgrade-all
    nvim +PlugUpdate! +qall
    cd ~/apps/amdgpu-pro-vulkan-only;git pull;makepkg -si # check out https://github.com/Frogging-Family/amdgpu-pro-vulkan-only
    cd ~/apps/linux-tkg;git pull;makepkg -si # check out https://github.com/Frogging-Family/linux-tkg
    checkrebuild # check out https://github.com/maximbaz/rebuild-detector
    yay -Qqdt # shows orphaned packages
    

  • here’s the names of some of the rest of the scripts in that dir, you can imagine what they do. It’s easier for me to remember how to do something if I make a script and then commit it - it avoids me needing to re-google things like “how do I wipe a drive securely dd”

    clear_caches.sh
    discord_keepalive.sh
    drive_wipe.sh
    gdrive_download.sh
    mesa_git_switch.sh # switches to mesa-git, not incredibly useful now that the 6900 XT is so stable
    upgrade_all.sh # the above
    video_to_gif.sh
    wine_clear_extensions.sh
    zeropad.sh
    

• zsh, autocompletes and aliases
  • Probably the best thing ever. I have so many aliases.
  • whatprovides is “what package provides this file?” = pacman -F
  • ywhichfiles is “what files are provided from this package?” = yay -Ql
  • alias zipfolders='for i in */; do (cd "$i"; zip -r "../${i%/}.zip" .); done'
  • alias unzipfolders='for i in *.zip; do unzip "$i" -d "${i%%.zip}"; done'

In terms of tweaks I’ve had to make over the years to keep things running smoothly:

• The biggest one I can think of is this issue in ~July 2021.
  • gnupg uses sks-keyservers.net as its default keyserver, but as it stores people’s names and emails, it was apparently subject to a lot of GDPR “Right to Be Forgotten” deletion requests due to the way that SKS works. Due to this, the pool’s DNS records were pulled, causing pacman to fail to refresh keys, and fail to update packages in some cases. This default URL was changed in gnupg upstream, but could temporarily be worked around by editing /etc/pacman.d/gnupg/gpg.conf and adding keyserver hkps://keyserver.ubuntu.com/
• Neovim’s ShaDa file and network shares
  • I frequently edit text files on my NAS, mounted over NFS. Neovim stores a bunch of information about the file, and if the connection or mount isn’t working right, it can immensely slow down quitting nvim. So I’ve disabled shada.
• faillock
  • I didn’t know about this behavior and kept wondering why my password, which I clearly typed correctly, wasn’t working. You will probably want to customize /etc/security/faillock.conf to your liking on a desktop machine.

What have we learned? (tl;dr)

Hardware matters. Seriously.

My experience with AMD has been generally good and their support for open source is to be commended. I’ve laid heaps of praise at Valve’s feet for creating ACO and investing heavily into AMD and Linux with the Steam Deck, so I will reiterate:

Two-GPU laptops are absolute dog shit garbage fires that require the hardware and software planets to align and I will never purchase one again.

My next laptop must:

• Be 13 inches (maybe 14 is ok)
• Be able to cool itself decently
• Be power efficient
• Have USB 4
• Have an AMD CPU and GPU (or APU)
• Have decent single-core boost

I might have to try Lenovo again, because the Z13 looks promising. Or, hope that Framework goes AMD now that USB 4 is a thing.

On the desktop front, I am mostly satisfied. Valve’s efforts have parted the veil with moderate success, and now we get to see how the sausage is made - with lots of pain and suffering. I hope AMD’s next CPUs and GPUs are comparable in terms of support and power to this generation’s, with the quirks worked out.

---

The software that you run on your hardware matters too. And the open source community is working on solutions to a lot of the big problems that exist today.

Not everyone has infinite patience and time to dedicate to their computer. But, if you can sit down and figure out what works for you, I’ve found that you can make real and meaningful changes to the way you work that are satisfying - and importantly, aren’t subject to the whims of people who largely aren’t motivated to care about you and by extension, your devices. And they are your devices.

With all its quirks, using Linux as a daily driver has taught me that it’s important to me that I’m in control of what runs on my hardware. I choose when I update, I choose when to add new features, I choose when to change up my window manager, application launcher, or tray. I choose how I write code, browse directories, resize windows, and solve whatever task is presented before me. Arch Linux in particular has impressed me because it’s exactly what I want in a Linux distribution - I enjoy the PKGBUILD and makepkg system, and the defaults that Arch ships with are mostly sane to me. The AUR is irreplaceable for me - I actively dislike clutter and want to have a record of why something is installed on my system. Using an AUR manager is preferable to loose files, and I can’t tell you the amount of times I’ve used yay to search the AUR for something and it’s already there.

So, as long as you choose the right hardware for the job, or want to hack on it yourself and add support for it to Linux, I’ve found that minor roadblocks don’t have to ruin the entire experience. It’s not the right choice for everyone, though - for example, I don’t play many games with multiplayer, and therefore anti-cheat, I have a decent wealth of time to dedicate to maintaining my homelab, and I enjoy solving these problems in a sort of weird way.

I guess you could say it just works™ on my machine.

---

Hope you liked this post, or at the very least the resources in it! I had 114 tabs open at one point writing this. Until the next one!

---