Published on , 4399 words, 16 minutes to read
Forward and back and then forward and back and then go forward and back, then put one foot forward
Co-Authored-By: @scootaloose.com
Windows has been a pain in the ass as of late. Sure, it works, but there's starting to be so much overhead between me and the only reason I bother booting into it these days: games. Every so often I'll wake up to find out that my system rebooted and when I sign in I'm greeted with yet another "pweez try copilot >w< we pwomise you will like it ewe" full-screen dialogue box with "yes" or "nah, maybe later" as my only options. That or we find out that they somehow found a reason to put AI into another core windows tool, probably from a project manager’s desperate attempt to get promoted.
The idea of consent in the tech industry is disturbingly absent, I hate it here.
The silicon valley model of consent
[image or embed]
— Xe ( @xeiaso.net ) March 31, 2025 at 11:59 PM
As much as I'd like to like Copilot, Recall, or Copilot (yes those are separate products), if a feature is genuinely transformative enough to either justify the security risk of literally recording everything I do or enhances the experience of using my computer enough to hand over control to an unfeeling automaton, I'll use it. It probably won't be any better than Apple Intelligence though.
When we built our gaming towers, we decided to build systems around the AMD Ryzen 7950X3D and NVidia RTX 4080. These are a fine combination in practice. You get AMD's philosophy of giving you enough cores that you can do parallel computing jobs without breaking a sweat and the RTX 4080 being one of the best cards on the market for rasterization and whatever ray tracing you feel like doing. I don't personally do ray tracing in games, but I like that it is an option for people who want to.
The main problem with NVidia GPUs is that NVidia's consumer graphics department seems to be under the assumption that games don't need as much video memory as they do. You get absolutely bodied in the amount of video memory. Big games can use upwards of 15 GB of video memory, and the OS / Firefox needs 2 GB of video memory. In total, that's one more gigabyte than the 16 I have. You can't just plug in more vram too, you need to either get unobtanium-in-canada RTX 4090s or pay several body organs for enterprise grade GPUs.
AMD is realistically the only other option on the market. AMD sucks for different reasons, but at least they give you enough video memory that you can survive.
As someone that uses an IRC nick that's the same as the Intel Linux GPU driver, I'm never using an Intel GPU on linux.
One of the most frustrating issues we've run into as of late is macrostutters when gaming. Macrostutters are when the game hitches and the entire rendering pipeline gets stuck for at least two frames, then everything goes back to normal. This is most notable in iRacing and Final Fantasy XIV (14). In iRacing's case, it can cause you to get into an accident because you get an over 100 millisecond to 5 second pause. Mind you, the game is playable, but the macrostutters can make the experience insufferable.
It’s all the rage in the iRacing forums when they’re not slinging potatoes at each other over other issues, it’s great!
In the case of Final Fantasy XIV (amazing game by the way, don't play it), this can cause you to get killed because you missed an attack telegraph due to it happening while your rendering pipeline was stopped. I have been killed to macrostutters as white mage (pure healer class for fellow RPG affictionados) in Windows at least 3 times in the last week and I hate it.
So, the thought came to our minds: why are we bothering with Windows? We've had a good experience with SteamOS on our Steam Decks.
It probably helps that you don't mess with the Steam Deck at all and leave it holy.
We have a home theatre PC that runs Bazzite. A little box made up of older hardware we upgraded from. Runs tried and true hardware that has matured well and not a single unknown variable in it (AMD Ryzen 5 3600 and an RX5700XT, on a B450 motherboard, the works). Besides the normal HDR issues on Linux, it's been pretty great for couch gaming!
I've also been using Linux on the desktop off and on for years. My career got started because Windows Vista was so unbearably bad that I had to learn how to use Linux on the desktop in order to get a usable experience out of my dual core PC with 512 MB of ram.
I’m honestly amazed Vista even attempted to run – much less install – on that low of memory configuration… I’ve been a Windows user for as long as I remember, my oldest memory of using it dating back to Windows 98, but there’s probably some home video of me messing around in MS Paint with Windows 95 somewhere in a box. Around 2009 I used a shared family laptop that came shipped with Vista that suddenly decommissioned itself out of existence. I installed Kubuntu (KDE flavour of Ubuntu, I could and still cannot stand GNOME lol) on it for a time until Windows 7 came around to save it. My mother and sister did not really adapt to using Linux and I was the only one trying to use it around that time. It was functional enough back then I suppose – the hardest I drove that laptop was playing Adobe Flash games – but we could not do my schoolwork on it properly, namely because OpenOffice and Word hated each other.
Surely 2025 will be the year of the Linux Desktop.
Foreshadowing is a narrative device in which a narrator gives an advance hint as to what comes up later in the story.
The computing dream
My husband has very simple computing needs compared to me. He doesn't do software development in his free time (save simple automation with PowerShell, bash, or Python). He doesn't do advanced things like elaborate video editing, 3d animation, or content creation. Sure sometimes he'll need to clip a segment out of a longer video file, but really that's not the same thing as making an hbomberguy video or streaming to Twitch. The most complicated thing he wants to do at the moment is play Final Fantasy XIV, which as far as games go isn't really that intensive.
I still have my library of simulators where most of them would technically work fine under Proton, as most have been tested to work there. However, given the mishmash of hardware and the fact that iRacing has anticheat and the launcher barely functions in Linux under Proton, I decided to delegate my expensive hobby machine to secondary duty and I left it running Windows as is. Its sole purpose now is for my racing sims and any strange game that does not play nice with Proton. Namely any multiplayer games that have kernel-level anticheat. I scrapped the idea of dual booting before anything else because I have had enough bad experiences with Windows’ Main Character Syndrome that I was going to airgap my install of Linux to a whole other computer.
I have some more complicated needs seeing as software I make runs on UNESCO servers, but really as long as I have a basic Linux environment, Homebrew, and Steam, I'll be fine. I am also afflicted with catgirl simulator, but I do my streaming from Windows due to vtubing software barely working there and me being enough of a coward to not want to try to run it in Linux again.
When he said he wanted to go for Linux on the desktop, I wanted to make sure that we were using the same distro so that I had enough of the same setup to be able to help when things inevitably go wrong. I wanted something boring, well-understood, and strongly supported by upstream. I ended up choosing the most boring distribution I could think of: Fedora.
Fedora is many things, but it's what systemd, mesa, the Linux Kernel, and GNOME are developed against. This means that it's one of the most boring distributions on the planet. It has most of the same package management UX ergonomics as Red Hat Enterprise Linux, it's well documented and most of the quirks are well known or solved, and overall it's the least objectionable choice on the planet.
In retrospect, I'm not sure if this was a mistake or not.
He wanted to build a pure AMD system to stave off any potential NVidia related problems. We found some deals and got him the following:
- CPU: AMD Ryzen 9 9800X3D (release date: November 2024)
- GPU: AMD RX9070XT (16GB) (release date: March 2025)
- A B850M based motherboard (release date: January 2025)
- 32GB of DDR5-6000 RAM
- A working SSD
- A decent enough CPU cooler
- A case that functions as a case
I will spend more money on a case if it means it won’t draw blood while trying to work on it, so far my last two cases spared my fingers. This build was also woefully overpriced because I was paying for the colour tax on all my components, going with a full white build this time.
Fedora 41
I had recently just installed Fedora 41 on my tower and had no issues. My tower has an older CPU and motherboard so I didn't expect any problems. Most of that hardware I listed above was released after Fedora 41 was released in late October 2024. I expected some issues for hardware compatibility for the first boot, but figured that an update and reboot would fix it. From experience I know that Fedora doesn't ever roll new install images after they release a major version. This makes sense from their perspective for mirror bandwidth reasons.
When we booted into the installer on his tower, the screen was stuck at 1024x768 on a 21:9 ultrawide. Fine enough, we can deal with that. The bigger problem was the fact that the ethernet card wasn't working. It wasn't detected in the PCI device tree. Luckily the board shipped with an embedded Wi-Fi card, so we used that to limp our way into Fedora. I figured it'd be fine after some updates.
It was not fine after that. The machine failed to boot after that round of updates. It felt like the boot splash screen was somehow getting the GPU driver into a weird state and the whole system hung. Verbose boot didn't work. I was almost worried that we had dead hardware or something.
Fedora 42
Okay, fine, the hardware is new. I get it. Let's try Fedora 42 beta. Surely that has a newer kernel, userland, and everything that we'd need to get things working out of the box.
Yep, it did. Everything worked out of the box. The ethernet card was detected and got an IP instantly. The install was near instant. We had the full screen resolution at 100hz like we expected, and after an install 1Password and other goodies were set up. Steam was installed, Final Fantasy XIV was set up, the controller was configured, and a good time was had by all. The microphone and DAC even worked!
Once everything was working, I set up an automount for the NAS so that he could access our bank of wallpapers and the like. Everything was working and we were happy.
Again, foreshadowing is a narrative device in which a narrator gives an advance hint as to what comes up later in the story.
Coincidentally, we built the system the day before Fedora 42 was released. I had him run an update and he chose to do it from the package management GUI, “Discover”. I have a terminal case of Linux brain and don't feel comfortable running updates in a way that I can't see the logs. This is what happens when you do SRE work for long enough. You don't trust anything you can't directly look at or touch.
I am Windows Update brained, it’s ingrained into my soul after 27 years @_@
We rebooted for the update and then things started to get weird. The biggest problem was X11 apps not working. We got obscure XWayland errors that a mesa dev friend never thought was possible. I seriously began to get worried that we had some kind of half-hardware failure or something inexplicable like that.
I thought that there was some kind of strange issue upgrading from Fedora 42 Beta to Fedora 42 full. I can't say why this would happen, but it's completely understandable to go there after a few hours of fruitless debugging. We reinstalled because we ran out of ideas.
Why the iGPU, Steam?
Once everything was back and running, we ran into a strange issue: Steam kept starting on the integrated GPU instead of the dedicated GPU. This would be a problem, but luckily enough games somehow preferred using the dedicated GPU so it all worked out. After an update got pushed, this caused Steam to die or sometimes throw messages about chromium not working on the GPU "llvmpipe".
Life pro tip: if you ever see the GPU name "llvmpipe" in Linux, that means you're using software rendering!
Debugging this was really weird. Based on what we could figure out with a combination of nvtop, hex-diving into /sys, and other demonic incantations that no mortal should understand, the system somehow flagged the dedicated GPU as the integrated GPU and vice versa. This was causing the system to tell Steam and only Steam that it needed to start on the integrated GPU.
After increasingly desperate means of trying to disable the integrated GPU or de-prioritize it, we ended up disabling the integrated GPU in the bios. I was worried this would make debugging a dead dedicated GPU harder, but my husband correctly pointed out that we have at least 5 known working GPUs of different generations laying around with the right power connectors.
Shader pipeline explosions and GPU driver crashes
Anyways we got everything working but sometimes when resuming from sleep Final Fantasy XIV causes a spectacular shader pipeline explosion. I'm not sure how to describe it further, but in case you have any idea how to debug this we've attached a video:
Seizure warning
No, really don't say I didn't warn you
HOOOOOME RIDING HOOOOOOME DYING HOOOOOPE HOOOOOOOLD ONTO HOOOOPE, OOOOOOOHGQEROKHQekrg’qneqo;nfhouehqa
I'm pretty sure this is a proton issue, or a mesa issue, or an amdgpu issue, or a computer issue. If I had any idea where to file this it'd be filed, but when we tried to debug it and get a GPU pipeline trace the problem instantly vanished. Aren't computers the best?
Going back to the NAS
S3 suspend is not a solved problem in the YOTLD 2025. Sometimes on resume the display driver crashes and my husband needs to force a power cycle. When he rebooted, XWayland apps wouldn't start. Discord, Steam, and Proton depend on XWayland. This is a very bad situation.
Originally we thought the display driver crashing was causing this, but after manual restarts under normal circumstances were also causing it it got our attention. The worst part was that this was inconsistent, almost like something in the critical dependency chain was working right sometimes and not working at all other times. We started to wonder if Fedora actually tested anything before shipping it because updates made the pattern of working vs not working change.
One of the most simple apps in the x11 suite is xeyes. It's a simple little thing where it has a pair of cartoon eyes that look at your mouse cursor. It's the display pipeline equivalent to pinging google.com to make sure your internet connection works. If you've never seen it before, here's what it looks like:
Want to watch this in your video player of choice? Take this:
https://files.xeiaso.net/blog/2025/yotld/xeyes/index.m3u8
Alas, it was not working.
After some investigation, the only commonality I could find was the X11 socket folder in /tmp not existing. X11 uses Unix sockets (sockets but via the filesystem) for clients (programs) to communicate with the server (display compositor). If that folder isn't created with the right flags, XWayland can't create the right socket for X clients and will rightly refuse to work.
On a hunch, I made xxx-hack-make-x11-dir.service:
[Unit]
Description=Simple service test
After=tmp.mount
Before=display-manager.service
[Service]
Type=simple
ExecStart=/bin/bash -c "mkdir -p /tmp/.X11-unix; chmod -R 1777 /tmp/.X11-unix"
[Install]
WantedBy=local-fs.target
This seemed to get it working. It worked a lot more reliably when I properly set the sticky bit on the .X11-unix folder so that his user account could create the XWayland socket.
In case you've never seen the "sticky bit" in practice before, Unix permissions have three main fields per file:
- User permissions (read, write, execute)
- Group permissions (read, write, execute)
- Other user permissions (read, write, execute)
This applies to both files and folders (where the execute bit on folders is what gives a user permission to list files in that folder, I don't fully get it either). However in practice there's a secret fourth field which includes magic flags like the sticky bit.
The sticky bit is what makes temporary files work for multi-user systems. At any point, any program on your system may need to create a temporary file. Many programs will assume that they can always create temporary files. These programs may be running as any user on the system, not just the main user account for the person that uses the computer. However, you don't want users to be able to clobber each other's temporary files because the write bit on folders also allows you to delete files. That would be bad. This is what the sticky bit is there to solve: making a folder that everyone can write to, but only the user that created a temporary file can delete it.
Notably, the X11 socket directory needs to have the sticky bit set because of facts and circumstances involving years of legacy cruft that nobody wants to fix.
$ stat /tmp/.X11-unix
File: /tmp/.X11-unix
Size: 120 Blocks: 0 IO Block: 4096 directory
Device: 0,41 Inode: 2 Links: 2
Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2025-05-05 21:33:39.601616923 -0400
Modify: 2025-05-05 21:34:09.234769003 -0400
Change: 2025-05-05 21:34:09.234769003 -0400
Birth: 2025-05-05 21:33:39.601616923 -0400
Once xxx-hack-make-x11-dir.service was deployed, everything worked according to keikaku.
Life pro tip: keikaku means plan!
A gnawing feeling at the fabric of reality
The system was stable. Everything was working. But when multiple people that work at Red Hat are telling you that the problems you are running into are so strange that you need to start filing bug reports in the dark sections of the bug tracker, you start to wonder if you're doing something wrong. The system was having configuration error-like issues on components that do not have configuration files.
While we were drafting this article, we decided to take a look at the problem a bit further. There was simply no way that we needed xxx-hack-make-x11-dir.service as a load-bearing dependency on our near plain install of Fedora, right? This should just work out of the box, right???
We went back to the drawing board. His system was basically stock Fedora, and we only really did three things to it outside of the package management universe:
- Create a mount unit to mount the NAS' SMB share at
/mnt/itsuki - Create an automount unit to automatically mount the SMB share at boot time
xxx-hack-make-x11-dir.serviceto frantically hack around issues
Notably, I had the NAS automount set up too and was also having strange issues with the display stack, including but not limited to the GNOME display manager forgetting that Wayland existed and instantly killing itself on launch.
On a hunch, we disabled the units in the reverse order that we created them to undo the stack and get closer to stock Fedora. First, we disabled the xxx-hack-make-x11-dir.service unit. When he rebooted, this broke XWayland as we expected. Then we disabled the NAS automount and rebooted the system.
XWayland started working.
My guess is that this unit somehow created a cyclical dependency:
# mnt-itsuki.automount
[Unit]
Requires=remote-fs-pre.target
After=remote-fs-pre.target
[Automount]
Where=/mnt/itsuki
TimeoutIdleSec=0
[Install]
WantedBy=remote-fs.target
Oh...this was me, wasn't it...
Your sysadmin privileges are revoked for 24 hours.
Gasp! Not the sysadmin privileges!
Turns out it was me. The actual unit I wanted was this:
# mnt-itsuki.automount
[Unit]
[Automount]
Where=/mnt/itsuki
TimeoutIdleSec=0
[Install]
WantedBy=multi-user.target
Thanks, Arch Linux Wiki page on Samba!
Other than that, everything's been fine! The two constants that have been working throughout all of this were 1Password and Firefox, modulo that one time I updated Firefox in dnf and then got a half-broken browser until I restarted it. I did have to disable the nftables backend in libvirt in order to get outbound TCP connections working though.
Fedora tips m'lady
Fedora is pretty set and forget, but it's not without its annoyances. The biggest one is how Fedora handles patented video codecs and how this intersects with FFmpeg, the swiss army chainsaw of video conversion.
Seriously, FFmpeg is one of the best programs ever made. If you have any image or video file format, you can use FFmpeg to make it any other video or image file format. Seriously one of the best programs ever made and it's absolutely surreal that they use Anubis to protect their bug tracker.
Fedora ships a variant of FFmpeg they call ffmpeg-free. Notably this version has "non-free" codecs compiled out, so you can deal with webm, av1, and other codecs without issue. However h.264, or the 4 in .mp4 is not in that codec list. Basically everything on the planet has support for h.264, so this is the "default format" that many systems use. Heck, all the videos I've embedded into this post are encoded with h.264.
You can pretty easily swap out ffmpeg-free with normal un-addled ffmpeg if you install the RPM Fusion repository, but that has its own fun.
Forward and back and then forward and back and then go forward and back, then get no downgrading
RPM Fusion is the not-quite-official-but-realistically-most-users-use-it-so-it's-pretty-much-official side repo that lets you install "non-free" software. This is how you get FFmpeg, steam, and the NVidia binary drivers that make your GPU work.
One of the most annoying parts about RPM Fusion is that whenever they push new versions of anything, every old package is deleted off of their servers. This means that if you need to do a downgrade to debug issues (like strange XWayland not starting issues), you CANNOT restore your system to an older state because the package manager will see that the packages it needs aren't available from upstream and rightly refuse to put your system in an inconsistent state.
I have tried to get in contact with the RPMFusion team to help them afford more storage should they need it, but they have not responded to my contact attempts. If you are someone or know someone there that will take money or storage donated on the sole condition that they will maintain a few months of update backlog, please let me know.
Conclusion
I'm not really sure how to end something like this. Sure things mostly work now, but I guess the big lesson is that if you are a seasoned enough computer toucher, eventually you will stumble your way into a murder mystery and find out that you are both the killer and the victim being killed at the same time.
And you’re also the detective!
But, things work* and I'm relatively happy with the results.
Facts and circumstances may have changed since publication. Please contact me before jumping to conclusions if something seems wrong or unclear.
Tags: