Last year, this piece was written on it. And, based on an extremely small sample size (N=1), the takeaway was basically that the 1% lows (and the 0.1% lows) do seem to benefit on some games.

But, there are so many factors at play, it's pretty hard to back up any claim of performance increase (or decrease). However, if you've got the time and you want to play around, then please feel free to benchmark the 1% lows (and 0.1% lows) of the games you play on different distros and come to your own conclusions.

Small nitpick; layering is technically only a thing on Fedora Atomic. Not all immutable distros subscribe to it.

Windows ->

Fedora Kinoite: A relatively mature atomic/immutable distro combined with excellent security standards and that resembles Windows' workflow. Unfortunately, it broke almost immediately. Though, to be fair, it was a known issue with the ISO back then. As a newb, however, I couldn't be bothered with it. ->

Fedora Silverblue: Well..., I didn't have much of a choice 😜. Or I had to forego Fedora Atomic altogether. However, I actually really enjoyed GNOME's workflow. I used this as my main system for about year. Until I found a related project... ->

Arch: The memes got me 😅. In all honesty, though, it was mostly curiosity. Still, I didn't intend to throw away my working Silverblue installation for the sake of quenching my thirst for experiencing Arch. So, as dual boot, I tried to install it. This was pre archinstall, so it took a couple of tries before I booted into GNOME. However, I guess I did mess up something as I don't recall ever booting back into that system 😅. So, what if I want Arch, but don't want to spend more time with the installation... ->

EndeavourOS: Yup. I actually enjoyed it. I also took the opportunity to install another DE; KDE. Tried out the hardened kernel. Was able to make Davinci Resolve work, which just caused a lot of trouble on Silverblue. Access to AUR. It was cool, really. And, for some time, I was actually pondering to dismiss Silverblue altogether in favor of EndeavourOS. But, I started to miss the 'stability' that I was used to from Silverblue. Though, I don't exactly recall if it was the fault of being based on Arch, or rather linked/attributed to KDE instead. Regardless, I noticed that (over time) I spend more and more time on Silverblue. At some point, booting into EndeavourOS didn't work any more. It had broken. I did engage in some troubleshooting efforts, but to no avail... ->

Zorin OS lite: On backup laptop; the poor thing couldn't run Windows but (even today) it's still kicking on Linux ->

Nobara: So, I guess I did miss some of the functionality provided by EndeavourOS; running Davinci Resolve being the primary one. But, I didn't want to pass out of the opportunity to try something else. Back then, Nobara was released relatively recently and was received very positively by the community. And had even a special guide/tutorial to make Davinci Resolve work on AMD devices. Nobara was cool. But, it didn't feel very special. I actually enjoyed EndeavourOS a lot more. It was mostly utilized for Davinci Resolve and for gaming if Silverblue wasn't fit for the job (for whatever reason). Unfortunately, even this one broke at some point 😅. I could still boot into it. But, the system just didn't do what it's supposed to do. I tried troubleshooting. But, once again, to no avail. ->

uBlue; Silverblue image: Through all that was previously mentioned, I had stability in Fedora Silverblue. It was reliable. I could trust it. Well..., most of the time 😅. Decisions related to mesa or video acceleration in browsers definitely felt more like misses rather than hits. I can't blame Fedora as they're legally restricted. But, shouldn't we be able to do better? Enter uBlue. It seemed like some black magic shenanigans. The earlier issues would have never occurred (nor did they occur) on uBlue. This 'managed' aspect of uBlue was clearly, at least for me, the reason to consider it over regular Silverblue. And so, I parted with regular Silverblue and started using the Silverblue image provided by uBlue. Not long after, I even had my own (hardened) custom image. But, eventually (to be more precise; about half a year after switching to uBlue), keeping up with hardening took up too much effort for me to bear. But, thankfully, I had already found the perfect solution... ->

secureblue (based on the Silverblue image): This was Silverblue hardened by someone that actually knows their shit. And, thankfully, I didn't have to maintain this myself. I used this for a couple of months until the next best thing... ->

secureblue (based on the Bluefin image): Currently on this for I think half a year now. It has just been a lovely experience through and through. Everything I could have asked is provided.

Why does your brother use NixOS in the first place?

Don't get me wrong; I think NixOS is a very interesting project with a very bright future. It probably wouldn't be an exaggeration if I said that NixOS has single-handedly inspired the current immutable revolution. However, it's also a distro that wants you to learn and digest its ways before it will return the favor.

But, based on my reading/understanding of your comment, your brother doesn't strike me as a seasoned Linux user. Am I right? Btw, NixOS is hard unbeknownst of how many experiences you got with other distros. However, I would simply never recommend a new user to use (Gentoo, Guix System or) NixOS. There are definitely outliers, but they would have to find it themselves then.

Furthermore, a CLI instruction is DE-agnostic. So you don't need to cover the same topic with explanations for at least 3/4 desktop environments. GUI instructions also change a lot faster than their CLI counterparts; so by providing the commands one provides the method with the best longevity. Overall, it's just so much more efficient.

Thank you for touching upon the human-side of things! I wonder if my original point could be distilled to "Can we, humans, simply act more rational?" 😅.

Traditionally; definitely. But if the purpose of package managers is to acquire packages fit for use with the distro, then the position of alt packaging formats (e.g. Nix) and/or solutions that make use of container technology (e.g. Distrobox) at least provide some food for thought.

Like, if I choose to install Debian (Stable) and openSUSE Leap and then proceed to install all my packages through distro-agnostic ways accessible on both distros (e.g. Flatpak, Brew, Nix etc.), then wouldn't you agree that these systems become remarkably close to one another?

Fam, with all due respect, reconsider how you go about interacting with the community for support.

We love to help, so don't get me wrong. But you have to allow us to help you. Paramount with this is communication; so consider responding to questions asked by those who reach out to help.

Like, I'm not exaggerating when I say that your issues would have already been resolved if you had been (more) responsive.

Alright. I'm just guessing at this point. But could you give it more permissions through Flatseal and see if that resolves it? I'm not behind my laptop currently so can't look at it with you*. But I may come back at it within a couple of hours.

ChatGPT gave the following. Follow at your own risk. Most important is to check if the file locations are compatible with Fedora.

To automate running the update-grub command after each kernel update, you can create a script and set it up to run automatically. Here's a more direct approach:

1. Open a text editor and create a new script file. For example, you can name it "update_grub.sh".

2. In the script file, add the following lines:

   #!/bin/bash
   /usr/sbin/update-grub
   

3. Save the script file in a location where it can be easily accessed, such as your home directory.

4. Make the script executable by running the following command in the terminal:

   chmod +x /path/to/update_grub.sh
   

5. Next, you can set up a cron job to run this script automatically. Open your crontab file by running:

   crontab -e
   

6. Add a new line at the end of the crontab file to schedule the script to run after each kernel update. For example:

   @reboot /path/to/update_grub.sh
   

7. Save and exit the crontab file.

With these steps, the update-grub command will be executed automatically after each kernel update, ensuring that the new kernel version boots successfully.

A bit late, so my apologies*. Just to be sure, the Writer is installed as a Flatpak right?

Thank you for answering!

Btw, OP, I foresee a switch to Linux Mint Xfce Edition. Please consider writing about your experiences in which you compare Xubuntu to Linux Mint Xfce Edition. Thanks in advance!

How does signing up work? What do they ask in terms of your data (email, name, address, more)? I tried finding out myself but their website misbehaved for some reason.

Until its drivers are completely open source, Nvidia will continue to cause trouble every once in a while.

Therefore, if you liked Sway, then don't leave it expecting to be a lot better elsewhere.

However, Hyprland's community is pretty big and I can only be positive regarding the pace of its development. Therefore, if anything, Hyprland might be able to offer a solution. But, don't forget what I said earlier*.

Linux Mint Xfce Edition should be right up your alley.

Unfortunately, the required steps to rid your Ubuntu (non-pro) system from this and other forms of advertisements are a lot more involved than it has any right to be.

Or, perhaps, consider another distro.

I’m still on the hunt for a distro where everything I need is easy to install. I don’t think any exist, primarily because GPU drivers suuuuuuuck, especially when you need CUDA or ROCm to work.

Have you looked at the opinionated images by uBlue, i.e. Aurora, Bazzite and Bluefin? FWIW, e.g. for Bazzite, AMD's ROCM OpenCL/HIP run-times are fully supported OOTB and there's a workaround for CUDA. It does a lot of good stuff in general. Heck, I'd argue they're one of the most handsfree and easy experiences you may find on Linux.

Unfortunately, I can't take this seriously as 1% lows and additional variance due to difference in DE haven't been accounted for.

Furthermore, you bet that Tuxedo OS has done a splendid job at optimizing performance on a device that's sold by Tuxedo. Therefore, I wonder if it's even a fair comparison to begin with.

OS is xubuntu 24.04

Ubuntu defaults to ufw. That, by itself, justifies the use of ufw in your case.