EndeavourOS isn't a gaming distro it's just an Arch installer with some defaults. It's still Arch and comes with Arch's woes. It's not a beginner friendly just works kind of distro.
Coming from kionite, you'd probably want Bazzite if you want a gaming distro: it's also Fedora atomic with all the gaming stuff added.
Yeah that's why I put it in quotes, it just kept popping up when I searched for distros more inclined towards gaming lol.
Yeah I didn't know about bazzite before going about this whole thing, but I am not going to try gaming on my system until nvk becomes more capable. Even then only light work.
I'm not necessarily a begginer as I have been using Linux for a few years now, but arch is definitely out of my wheelhouse
You can also get used to Arch over years until you find yourself editing kernel code directly and fixing the drivers by yourself
Gentoo has a lot of nice quality of life features if you want to roll a custom kernel. You can do it on any distro though.
In theory, Kinoite is just the KDE spin of Bazzite (or the other way around, lol).
Stick with the beaten path. Ignore the people who confidently tell you to use anything new or obscure.
Fedora Workstation, Linux mint or Pop os is what you want
I've had good luck striking out on a new path with Nobara after years of only ever using Ubuntu. There was a bit of a learning curve (and I still haven't gotten everything I wanted to work the way it did before), but I mostly got it figured out.
But that may well be a Survivor case in the sense of Survivor Bias, no idea how many people tried and decided "wasn't worth it".
I did have a bone to pick with pipewire because my old pulseaudio config no longer worked and I had difficulties figuring out just how to redo it in pw, but that's probably not distro-specific.
This is the voice of reason. Good to see there are some reasonable people still out there.
This makes a lot of sense, though I can't help but think about the fact that all these distros were once brand new projects that people had to go out on a limb and try out before they became what they are today.
Though I also guess these projects had more official dedicated support.
In any case, I won't be the one going out on a limb for a while now lmao
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.
If you find yourself wanting to game on your distro again, layering nvidia drivers ontop of immutable fedora is do-able. If you want a more hands off approach you can use bazzite (https://bazzite.gg/), which has an nvidia compatible version and is just a kinoite-based OSI image with gaming oriented tweaks and extra apps.
You can even just rebase to it if you're already using kinoite (and rebase back to kinoite if you don't like it), no need to reinstall your system. The download page has a one-command exemple on how to do that.
Rebasing is easily one of the coolest features of the atomic suite. I will definitely look into bazzite more in the future, just wish I knew about it before all this lmao
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).
I reckon if I go about trying to game again I will just go ahead and rebase to bazzite. Seems the easiest route
If you want something like Fedora that supports nVidia, just run OpenSuSE. It's also enterprise grade and happily chugs along whatever you do to it.
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.
Anyone who tells you that gaming on Linux isn't somewhat experimental is lying. I think it's getting there, though.
I mean, OPs distro choice didn't help here:
EndeavourOS is an Arch-based distro that provides an Arch experience without the hassle of installing it manually for x86_64 machines. After installation, you’re provided with a lightweight and almost bare-bones environment ready to be explored with your terminal, along with our home-built Welcome App as a powerful guide to help you along.
If you want Arch with actual training wheels you probably want Manjaro or at least a SteamOS fork like Chimera/HoloISO.
It probably would have been much smoother with an actual beginner friendly distro like Nobara and Bazzite, or possibly Mint/Pop for a more classic desktop experience.
It's not perfect and still has woes but OP fell for Arch with a fancy graphical installer, it still comes with the expectation of the user being able to maintain an Arch install.
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.
gnome-shell is at 46.1. Also, gdm-prime is AUR so it's not supported.
This is one of those problems that Manjaro fans on Lemmy keep telling me are impossible.
I am on EndeavourOS and gnome-shell is on 46.1-2. gdm-prime is on 46.0-1. Everything would work fine using gdm-prime from the AUR.
The issue is that Manjaro holds back the packages in core and extra for weeks but the packages in the AUR are up-to-date ( and expect the version numbers found in Arch ). So you have this incompatibility.
You may find a newer version of gnome-shell in the AUR but, if you do, you may find that the Manjaro package never catches up and you are stuck with an AUR version forever, or worse, end up with packages that cannot be upgraded one the one in the AUR gets abandoned.
In my opinion, using Manjaro is “hard mode” much more than EndeavourOS is for exactly these kinds of reasons.
I fixed the problem by updating gnome-shell with the terminal
It's gotten a lot better, particularly for Steam games, but yeah, there's still some way to go.
PopOS has an ISO with Nvidia drivers included, no issues gaming straight away on my old 1080ti. As I'm a simpleton who just likes their system to with I've stuck with it even after upgrading to an AMD card
The UI xan be buggy and and pop shop is a resource hog but other than that it is fine.
I've not had UI issues but agree on the Pop Shop. The next iteration with Cosmic looks to be significantly improved at least
Feels good to know that with my dedicated /home partition I can re-install my OS in about an hour. So the very notion of "system" feels strange to me, I mean I feel no attachment to it.
PS: yes I have NixOS install on my slow HD but still didn't take the plunge. I imagine it "feels" even better to have "it" declarative.
I previously used Nobara but recently switched to Bazzite. I think you can give either of these two a shot. I recall Nobara includes a one button install of nvidia drivers. Not too sure about Bazzite since I have an AMD gpu.
Both these distros are gaming focused. Only difference is Nobara is a traditional distro while Bazzite is atomic desktop based.
What is atomic desktop, roughly? Google doesn't give me a concise answer and I prefer not opening news blogs that give me an entire article on my limited mobile data plan.
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.
Wow, what a very detailed response. I've only been using Bazzite for about two weeks and still learning about it. Now I have a slightly better understanding of how it all works. 👍
I asked for a rough description because I didn't wanna bother anyone to take the time for a full, detailed explanation...
...then you come along and write a whole article on it that's most certainly more informative and useful than anything Google would have spat out.
I love that. Thanks so much for taking the time. I also think I'll give Bazzite / Fedora Atomic a shot. The idea of simply rebasing onto a different option to try different things is definitely appealing.
Bazzite is definitely a great option if you have an Nvidia card or you are looking for gaming performance. It includes some gaming oriented features and optimizations like the System76 scheduler that aren't in the regular Fedora Atomic builds that have the potential to increase performance, and make things easier (such as having a build with Nvidia drivers in the root image). I don't really game at the moment, so I don't have personal experience with Bazzite, but I've been on Fedora Atomic KDE for a while now and it has been a great experience. I've heard lots of great things about Bazzite, so I would expect it to be a similar experience (maybe a bit easier). I feel comfortable recommending both, but the more appropriate choice will depend on what you use your computer for and your own preferences, of course.
While I haven't personally rebased to a different image before, it should be pretty seamless, except for some potential config issues if you are switching to an image with a different DE (i.e. switching from GNOME to KDE). I've seen people in this community mention successfully rebasing to another DE, but Bazzite's documentation recommends against it. I imagine that there may be config issues in /etc or in your home folder from switching DEs, just as may be expected when switching to a different DE on a non-atomic system. Your milage may vary there, essentially; Fedora and uBlue just don't officially test rebasing between different DEs. I usually tend to be cautious in my recommendations, so I generally recommend users to try out different DEs on a VM before deciding on one, and to do a full reinstall when switching DEs. There's a chance that is overkill, but it is certainly safe. Here is a blog post detailing some issues a user had when rebasing from Silverblue to Kinoite as an example. It seems that the issues can be fixed, but since the rebase between DEs is not officially tested, it is prone to small issues like these (though it appears at least some of the ones in that post have been fixed upstream now). The issues in that post were all incredibly minor, so you could likely fix your system in place if you were to try this (maybe you won't even have any issues; half of the post was about an issue caused by the fish shell, which is not the default), though you'd have to know where to look to find any issues (I'd start by checking overlaid packages and seeing if there are any from the old DE). You can always rollback safely, as each previous version the OS saves has it's own unique /etc folder (even though it isn't part of the root image).
Switching between Fedora Atomic and Bazzite is more supported (when you keep the same DE), but different images can add and remove packages from the root image, so you may find that you'll need to overlay packages/remove overlays when switching between them (such as Nvidia drivers). I don't imagine that posing an issue as an end user in most cases (outside of the Nvidia drivers), just thought it was worth mentioning, as it is an edge case that could pop up. That's one of the reasons that adding overlays isn't the first recommendation for installing packages, as they have the potential to make rebasing a bit more complicated for a handful of packages that may be different between different images. I would imagine that an update (or even the rebase itself) would fix any dependency issues (hence why I don't see it being an issue for an end user in most cases), but I don't know that for a fact. None of my information on rebasing is based on experience, except for rebasing to a new major version (i.e. Fedora 39 to Fedora 40), so you should look into that more yourself if you want more concrete details. Also, I mistakenly mentioned rebasing to a previous version of your image from before an update. That is actually called a rollback, and uses the rpm-ostree rollback command, more info here (I've edited my previous comment to reflect that). Bazzite has some good documentation on rebasing here, and I don't see any mention of package conflicts between Bazzite and Fedora Atomic, though you will likely want to remove an Nvidia driver overlay if switching from Fedora Atomic to Bazzite. You very likely won't need to make any other changes. There are people in this community with far more rebasing knowledge than I can provide/find from searching, so you can always make a post asking about it if necessary, and someone should be able to help.
It's also helpful to note that documentation for Fedora Atomic (sometimes you get better search results by using "Silverblue", as that was the original project name), Bazzite, and Bluefin are often interchangeable, as they are all based on Fedora Atomic. You may find some things more easily documented in Bazzite/Bluefin than on Fedora Atomic or vice versa, but much of that documentation applies exactly the same to any version. For any additional information about rpm-ostree, I would unironically suggest reading the manual page through man rpm-ostree or online at a site like this if you aren't comfortable with the terminal interface for man pages (quick tip: you can search for a term in man by typing / followed by the search term, and you can use n and N to go to the next/previous occurance).
I'm just here to help people out when I can, so if my comments are able to help anyone, I see it as time well spent. Sometimes it even helps me learn new things myself, and cements concepts I was already familiar with, so it's mutually beneficial!
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.
Thanks for the explanation! I think I'll give that a try. I've got a spare disk, might slap some Bazzite on there, see if it works for me.
Bazzite offers a variant with Nvidia drivers already baked in too.
You don't have to reinstall anything btw, you can just rebase from Kinoite to Bazzite with rpm-ostree rebase *link to Bazzite*.
(You find the instructions on the website).
It takes about 5 minutes and you can keep all your configs and data, including Flatpaks, pictures and WiFi password. And if you don't like it, you can revert that or rebase to some other variant, e.g. Aurora, the Sway spin, or whatever. I find it pretty neat.
Both are semi obscure and aren't as well proven. Don't recommend new users leave the beaten path.
Potentially SteamOS might be an option for you if you are wanting a gaming oriented distro. I believe you can boot it into desktop mode and it ships with KDE.
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0