Why I'm done with Nobara Linux: A Breakup Story with a Tech Twist

Linux Distro hopping for fun and profit. Wait, profit? When do I get paid?!

Hey everyone, I recently explored the world of Nobara Linux and shared my journey on Mastodon, Substack, and Lemmy. The response was fascinating – while it initially flew under the radar on some platforms, the Linux community on Lemmy had some strong opinions about me telling them to pick a distro. To say the discussion really took off there is an understatement.

Some of my favorite comments, grammar/spelling left untouched:

“I f***ing hate those titles and they make me automatically ignore them. who the f**k cares what you did Nathan and who the f**k are you that you tell me what I should or shouldn’t do?” Nice.

“You wouldn’t be a Linux user if you wouldn’t preach your distro of choice harder than any Mormon, Jehovah’s Witness or influencer would ever sell their s**t.” True stuff, preach.

“But if you don’t do it, they manipulated you too by NOT making what they say. It’s hard to be an independent individual sometimes, right?!” Indeed. I’m PROBABALY not a robot.

The debate in the comments section got feisty and is definitely worth reading when you have a moment. But let me add another perspective to the mix.
There's real value in experimenting and documenting the process. This is how we expand our knowledge. I'm not doing this for profit; my motivation is purely personal. My aim is to fully transition the fam from Windows to Linux. Given my history of dabbling with *nix since the 90s and my ability to share my experiences somewhat eloquently, I feel it's worthwhile to write about this journey. Maybe, just maybe, my insights could simplify someone else's path into the world of Linux.

Nobara has been a delightful discovery, especially for its seamless integration with proton-ge. It’s impressive how most games run smoothly on it. I did hit a snag with Mass Effect Legendary Edition, but let's just say that was more on me for choosing an EA game without doing my homework first. Lesson learned!

On that note, have you guys checked out ProtonDB? It’s a fantastic resource for gamers looking to venture into Linux gaming. It's mostly powered by user contributions and gives a real sense of how well games perform on the Steam Deck – a good indicator for their compatibility with various Linux distros. As of this writing, about 70% of games are either verified or playable on the Steam Deck, which is a big win for Linux gamers. So, before you buy your next game, check it’s compatibility on ProtonDB.

The problem I have though is, how can I keep writing articles that fuel your love for doom-scrolling through federated networks if I settle on the 'perfect' distro and never explore further? That's why, after spending some quality time with Nobara, I decided to jump into the then-newly released Kubuntu 23.10. Imagine if I could have declared to the Linux world, 'Snaps are fantastic, everyone just needs to embrace them!' But reality had other plans. Kubuntu 23.10, while promising, came with….issues.

• It had issues integrating with Flatpaks

• Its version of the Plasma desktop didn't play well with Firefox

• Steam performance was a bit laggy

• Snaps were frankly slow and annoying

• But most importantly, Kubuntu felt a bit sluggish and uninspired

So, what's on the horizon? The Linux landscape is dotted with an array of distros, each serving its unique niche. But then there are the standout 'flagship' distros that really draw attention. Think Linux Mint, Pop!_OS, Fedora, Manjaro, EndeavourOS, Garuda, and of course, Arch btw. There are some I've explored but never got around to writing about. Perhaps I should have. Take Manjaro, for example. During my college days, I was a huge fan of Mandrake Linux, and knowing Manjaro's lineage, I had high hopes. However, it turned out to be a bit of a letdown due to its bugginess. It reached a point where an update completely broke the system. That was the end of that experiment. Regardless of whether a distro follows a rolling update model or a major release strategy, I strongly believe, and practice in my day job, in the importance of a Test-Driven Development approach that prevents such disruptive updates.

I recently dabbled with Garuda Linux for a couple of days. Its unique artwork and themed UI were interesting, though not entirely to my taste. I considered trying Pop!_OS, but my laptop seems allergic to any Linux kernel prior to 6.2. So, I circled back to the familiar territory of Fedora, but this time, based on the Linux community's suggestion, I explored the Kinoite project.

If you aren’t familiar with Immutable operating systems, well here’s the shortest way I can describe it:
Immutable Linux refers to a type of Linux operating system where the core system files are set to be unchangeable, or "immutable." This means that these core files cannot be modified during regular use, which helps in preventing accidental or malicious alterations. This approach enhances security and stability, as it reduces the risk of system corruption or attacks. Users can still install and update software, but these actions are typically handled in a way that keeps the core system untouched.

The Immutable Fedora project seems awesome, and I was instantly intrigued. The idea of a stable, unchanging system base appealed to me, so I dove in headfirst – without fully reading the manual. This oversight led to a rather frustrating situation: my dual-boot Windows setup was broke, leaving me stuck at the EFI shell. No stranger to such predicaments, I spent the morning wrestling with the EFI shell and the Grub bootloader. Eventually, after hours of failing, I questioned why I was enduring this hassle, especially since I had a Windows recovery USB and all my data backed up via Syncthing. Restoring Windows was a time-consuming ordeal, and it was then that I discovered an important detail in the Kinoite instructions – dual booting isn't supported, but a workaround was suggested. To save others the same headache, I highly recommend reading the manual thoroughly. Another community member also posted some helpful tips on dual-booting with Kinoite. Once Windows was back up, I switched to the KDE Fedora spins project. Why KDE? Simply put, Gnome just doesn't suit my workflow (I hate it).

It hasn’t been perfect, but it’s super close! I had a lot of small issues with it’s Firefox install, including that irritating issue with Plasma Integration. I ended up switching to the Flatpak install which helped with most of them, but not Plasma. I don’t know what’s wrong, but it’s not a deal breaker. Steam works great, and since I have all my games on a second NVME drive, I just added the drive to steam and they all worked. I then put syncthing back on and all my docs/pics/downloads etc were there. Man I’m getting real good at distrohopping.

Here’s where this fairly boring story is going to end though… Over the last few weeks I’ve been compiling some “quick start” scripts so I can quickly get going on Fedora. I wrote them because I tried four different iterations of Fedora in quick succession.

• Fedora

• Fedora Kinoite

• Fedora uBlue

• Fedora KDE

But before you go on and copy my homework, why don’t you hit the subscribe button, and maybe the little heart to show me that it’s worth writing these articles.

So without further ado, here’s my fresh OS install scripts:

#set clock to be compatible with windows:
timedatectl set-local-rtc 1

#Setup second drive for fstab
sudo mkdir /mnt/my_nvme

#find uuid:
sudo blkid

#edit fstab
sudo nano /etc/fstab

#add this:
UUID=your-UUID-here /mnt/my_nvme ext4 defaults 0 2

#set permissions
sudo chown yourusername:yourusername /mnt/my_nvme
sudo chmod 755 /mnt/my_nvme
sudo mount -a

#Enable RPM Fusion:
sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm

sudo dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

#install steam
sudo dnf install steam

#enable flatpak:
sudo dnf install flatpak
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install flathub [ApplicationID]

#update flatpak:
flatpak update

#Run flatpak:
flatpak run [ApplicationID]

#Installing Syncthing:
sudo dnf config-manager --add-repo https://syncthing.net/release-key.txt
sudo dnf copr enable decathorpe/syncthing

#sudo dnf config-manager --set-enabled syncthing
sudo dnf install syncthing
systemctl --user enable syncthing.service
systemctl --user start syncthing.service

#http://localhost:8384

#Installing Signal
sudo dnf install flatpak
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install flathub org.signal.Signal

#install multimedia codecs
sudo dnf groupupdate multimedia --setop="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin
sudo dnf groupupdate sound-and-video

sudo dnf install gstreamer1-plugins-{bad-freeworld,good,ugly} gstreamer1-libav --exclude=PackageKit-gstreamer-plugin
sudo dnf install ffmpeg

#If you still have choppy video, in firefox do this:
Enable Hardware Acceleration in Firefox:
In Firefox, go to about:config
Search for layers.acceleration.force-enabled and set it to true
Search for gfx.webrender.all and set it to true
Restart Firefox and check if the playback improves

This actually fixed choppy gifs:
Open about:config in Firefox.
Set webgl.force-enabled to true. This will force-enable WebGL for us.
Set layers.acceleration.force-enabled to true. This will force-enable Layers Acceleration.

Set layers.offmainthreadcomposition.enabled to true. This will enable Off Main Thread Composition (OMTC), which should contributes to a faster and smoother composition.

If you made it this far, I’m going to share one last cool little trick I love. If you have both an onboard iGPU and a discrete GPU, sometimes gaming on linux can pick the wrong one. Here’s a little nugget I’ve found over the years to make steam use a specific GPU.

First set two aliases in your .bashrc file that look like this (assuming amd iGPU and nVidia discrete, adjust to fit your hardware):

alias amd="DRI_PRIME=1"
alias nvidia="__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia"

Next test it with glxgears:
#Should show what the default GPU is
glxgears -info | grep GL_RENDERER

#should show dgpu:
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxgears -info | grep GL_RENDERER

Example using it with steam under Launch Options:
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=amd %command%

Thanks for reading, I hope this post provides value for your Linux gaming experience!