You can also get used to Arch over years until you find yourself editing kernel code directly and fixing the drivers by yourself

In theory, Kinoite is just the KDE spin of Bazzite (or the other way around, lol).

Using Linux was going out on a limb for a long time. Now it has matured enough to be stable without to much knowledge or work.

Bazzite also has a lot of extra gaming-oriented changes to Fedora, such as including the System76 scheduler, which can increase performance in games. Since Bazzite has versions with Nvidia drivers in the root image, it makes it easier to use Nvidia cards.

By the way, if you hadn’t figured out the install for Nvidia drivers in Kinoite, here is a simple guide for how to do it. Also, there is documentation from the RPM fusion repo on how to install the drivers, which you can find here (that’s where the commands from the article came from). There are more details elsewhere in the documentation if you need them, such as how to get the Nvidia drivers to work with Secure Boot on atomic distros (though I’d recommend just using Bazzite for that because it can be a pain to get working manually).

Fedora is not enterprise grade. That would be RHEL. And entreprise grade mostly just mean stable (some would say stale) packages anyway if you don’t pay for support.

Installing nvidia drivers on fedora workstation is as easy as enabling rpm-fusion non-free and then installing a few packages. The issue here comes from OP running an OSI-based immutable system, which makes layering stuff on top a bit more difficult.

OP’s already running something fedora based, might as well stay where they feel comfortable and just add a few drivers and gaming tweaks on top.

Nothing against opensuse though. I’m currently running aeon because their approach of immutability is more modulable than fedora’s one.

Yeah, OP definitely played hard mode lol

I just updated gdm-prime on Manjaro to 46.0, when gnome shell is 45.6, and now gdm keeps crashing on startup.

I’ve not had UI issues but agree on the Pop Shop. The next iteration with Cosmic looks to be significantly improved at least

The name “atomic” in the context of operating systems refers to an operation in which all steps are applied without interruption (for instance, atomic operations like locking a file cannot be stopped by system interrupts, and once started are ran to completion regardless of the scheduler). Atomic operating systems take that concept, and apply it to base operating system updates. All changes to the operating system are applied simultaneously without interruption. The methods that different operating systems use for this vary, but since we’re talking about Fedora, I’ll explain Fedora’s image based atomic model using rpm-ostree.

Fedora Atomic is based on an image of the root filesystem that is perfectly consistent across all installs. When you update your system (with rpm-ostree), you fetch the entire root image from the repo instead of fetching individual packages. Updating works similarly to version control software like Git, where each version has a list of changes from the previous one, branches, and a variety of other similar features like rebasing. The operating system essentially runs similarly to a Git repository. rpm-ostree pulls the latest image from the image repository, and creates a new local branch on your system with all the changes in it. The root filesystem covered by the image is immutable (which means it is read-only and cannot be changed), to ensure that the root image is always perfectly consistent with the image from the repo (everything is perfectly reproducible). In order to switch to the new branch, you must reboot into it. This ensures that nothing changes while updating, and since the whole root filesystem is immutable, it’s best for stability to load into the new branch through a reboot (to ensure all behavior is consistent). Technically, you can apply changes live, but it is not recommended to do that and requires you to use an additional flag with the rpm-ostree command. This ensures that, in practice, your system is never in a state “between” updates. Once an update starts, it will finish to completion (or it will fail and the update won’t be applied), making updating an atomic operation (an update runs to completion, or it essentially doesn’t run at all; nothing in between). This is a great safeguard against crashes or power losses during updates.

The benefit of atomic distros is that all installations have a perfectly consistent root filesystem, so the system can be tested by the developers in the exact configuration in which it will be deployed to the end user. Any packages you want to install on top of the root filesystem can be installed in a few ways. Most GUI apps should be installed as Flatpaks where possible (installed to the home folder, which is read-write, so you can do it without rebooting), terminal apps can be installed in a toolbox (a default containerization system installed in Fedora that allows you to emulate a read-write root filesystem by mounting extra folders inside the container), or you can overlay the packages on top of the root filesystem through rpm-ostree. Toolbox has dnf installed in it, so you can install packages inside a container as you would install them in non-atomic Fedora. Package overlays download the packages from the Fedora repos, and mount them read only on top of the root filesystem (hence the “overlay”, as the packages are independently mounted over top the root filesystem). Overlays have the highest chance to change the behavior of your system, so they are generally recommended as the last option, since they decrease the benefit of consistent install behaviors, meaning that your extra packages aren’t tested as thoroughly as the root filesystem. In practice, overlays don’t generally cause any more “instability” than installing a package on a non-atomic distro, but again, it slightly diminishes one of the main benefits of atomic distros.

Essentially, all updates are applied at reboot, which means that you can just have updates running in the background and keep doing whatever you want, and as soon as you reboot, changes are instantly applied (no “installing” to wait for). Your operating system will keep some amount of previous branches (usually the current branch and 2 or 3 most recent branches) so you can boot into a previous branch from GRUB if an update breaks anything without having to restore from a backup. You can then rebase rollback to the previous branch (make the image of the branch you selected your current root image) once you can be sure that everything works properly. You can also rebase into another image entirely at any time (from Fedora Atomic GNOME to Fedora Atomic KDE, or into Bazzite or Aurora for example). The root image will change, but all of your overlays and persistent data will stay. EDIT: Note that rebasing into an image with a different DE might cause config issues, as /etc is mutable, and would be essentially the same as installing a new DE on a non-atomic distro. Some recommend against doing it, whereas some have success at it. YMMV. Here is a blog post detailing some issues a user had when rebasing from Silverblue to Kinoite as an example.

Atomic operating systems are emerging as a great option for desktops, as they increase stability, reliability, and recoverability greatly over the traditional model.

Atomic means the core OS packages are in an immutable container such that none of its individual components can be updated separately; instead the entire container is replaced with a newer version when the system is updated. This makes it much less likely for something to break during normal use, and easier to rollback updates if something does happen to break. The ideal use case is a containerized environment where each app you use is installed in its own container, like Docker, or is otherwise self-contained such as flatpak installers, and doesn’t rely on any of the system’s packages.