Idk, specifically for Baldur’s Gate 3, I didn’t have to tweak a thing, installed it, pressed play and it just worked, no stuttering or messing with wine or anything
You will get there(although I haven’t heard great things about Fedora gaming). I made the switch November 2021 and I haven’t booted back into windows in about 9 months. I ended up picked EndeavourOS cause I wanted something Arch based to be as close to Steam Deck packages as possible(and I already prefer KDE Plasma, so picked that as well).
I still have my hiccups. I still can’t get SteamVR to work at all. I spent about 45 minutes yesterday troubleshooting why Outward stopped working, when all the protondb reviews say “it just works”. I did eventually get it working from a random suggestion from the arch forums to add PROTON_NO_FSYNC=1 %command% to the steam launch commands and that fixed it. If I had to guess I think it’s something to do with my 1070Ti not playing nicely with the latest nvidia drivers. Also Epic made some sort of stupid update to FallGuys and I can no longer get it working for more one initial run per install. So that’s frustrating.
But I also love how much I know my system now. I love being able to update everything from one or two commands. I love pipewire for doing music recording stuff.(I fought for years on windows to try and cobble together something similar). I love having bash macros to easily download embedded videos and do quick ffmpeg conversions. Really, it definitely comes down to how I feel much more connected to this system than I ever did to a windows install.
I don’t know why so many are talking about Debian with distrobox I’m currently testing with bedrock Linux with a hijacked nobara for gaming and GNOME things. I also fetched a arch strata for anything else like window compositor waybar librewolf etc
Maybe I have been lucky but I have not had much issue installing linux and having it just work. the "After delving into a few resources, I managed to get the system up and running." in the article makes me wary of the distro. I expect them to just work at this point.
ive gamed on just about every distro i’ve tried but i currently run debian sid its fine, linux is linux for the most part. kernel is recent enough so youre not gonna have to do any workarounds or anything.
Most of the time it isn’t about the kernel what is causing gaming problems it is most of the time other packages. I had problems with a few games on KDE neon what uses a ubuntu lts system as its base
nobara is great! I am on arch now, but for a plug-and-play gaming system it works great. It really feels like a fedora gaming “spin” and honestly I think fedora should try to upstream changes into that kind of distro.
I agree. I enjoyed the Arch landscape and kind of thought that’s where I’d end up after the Steamdeck being so awesome. But It was just turning into too much time/work.
I’ll do you one better: I’m using Debian Stable for gaming and there’s nothing bad to report. Based on my experience I’d recommend that you use Stable first, unless you feel you really need Sid. I previously ran Arch Linux, but after switching to Stable and manually sourcing a few critical cutting-edge applications through e.g. Flatpak, it feels the exact same. I don’t feel like running the entire system as bleeding edge is a good idea when you can just run a couple dozen things as cutting-edge instead.
If you plan on using Sid instead of Stable, most of the following will not apply:
If you use Flatpak Lutris and want to use MangoHud, you’ll need to install the Flatpak version with flatpak install flathub org.freedesktop.Platform.VulkanLayer.MangoHud (I don’t think it shows up in the normal store)
The one gotcha I’ve found regarding Debian Stable and gaming is that Mesa will fall out of date as the release cycle goes on and probably won’t be backported. The solution is that running games via Flatpak (Lutris, Steam, etc.) uses Flatpak’s Mesa instead, which is cutting-edge. You can also try to compile a local Mesa version with this script, and you can manually trigger games to use this version instead of the system version. It does work, but it’s more complicated and a little bit more messy.
I use the Xanmod “Main” kernel for a more recent kernel that isn’t too bleeding-edge - it stays on the previous Linux kernel version until a few point releases have come out.
CoreCtrl is available as a bookworm-backport. I manually backported it myself but it looks like it’s official now.
I’m running Wayland and KDE, with no issues to report (even with gaming)
I’ve manually compiled Libstrangle for FPS limiting, but I’ve found that I can use MangoHud to transparently limit FPS as well, by using the following environment variable: MANGOHUD_CONFIG=fps_limit=YOURFPSHERE,fps=0,frame_timing=0,cpu_stats=0,gpu_stats=0,background_alpha=0. When I want MangoHud to act as normal, I switch it to MANGOHUD_CONFIG=readcfg which uses my normal config instead. Notably, Libstrangle cannot be used with Flatpak Lutris, so FPS limiting will need to be done with MangoHud if you want to limit Linux games. DXVK games can be limited with DXVK_FRAME_RATE as well, if that’s all you need.
I make heavy use of Flatpaks for any user applications that I need to keep more modern
If it’s not available as a Flatpak, I tend to use Homebrew to keep any other critical applications up-to-date (usually some CLI tools)
I use cargo through rustup to keep some rust programs updated
I use deb-get with a couple programs that aren’t on any real repos in order to get updates
I’ve compiled a couple backports by following this guide in a stock Debian Stable VM, then copying the .deb files back out to my main system. So far this has been super easy, but I don’t want to do this unless I have to.
If a program needs to be manually compiled, I try to install it using checkinstall. checkinstall basically fake-runs an installation and notes where everything goes, then stuffs it all into a .deb for you for a proper installation that can be uninstalled later. It’s a little buggy and doesn’t always work, but if it does it’s preferable. I rarely am forced to compile something that actually needs to be installed to system, but I’ve used it a few times with good success.
I can’t think of anything else regarding Debian Stable that I’ve done at the moment. Anything else has just worked as I’m used to on a bleeding-edge distro like Arch Linux. Debian’s large package base has really helped me with obscure programs that I used to need to compile manually with Arch Linux.
This looks like a detailed write up. I need to sit down and digest this information (currently out and about). I’ll come back to you with questions I’m sure.
Most of it is relating to getting the stability benefits of Debian Stable while keeping your system modern like Sid (not necessarily just for gaming). Keep in mind that Sid is inherently volatile/unstable and a lot more prone to breakage, so I wouldn’t recommend going that route unless you feel you have a real usecase, as you might find yourself needing to manually fix problems every so often on a Sid install. For a typical gaming workload I don’t feel like Sid is required, and with just a couple tweaks (Flatpak Steam/Lutris + newer kernel version mainly) you can get Stable to perform the same role cleanly. You can always upgrade into Sid later if you feel like you really can’t handle Stable’s older native packages.
Also, idk if it was explicit enough but the point of the original post is that yes, Debian is great for gaming, even with Stable. I would base your distro decision on literally any factor besides gaming, because if Debian Stable can do it then every distro can do it. You mentioned annoyance with Red Hat in your original post, so a strong selling point of Debian is that it’s a community distro. Arch Linux is also a great community distro that’s bleeding edge like Debian Sid.
Debian is generally easy to use but it’s still a tiny bit more DIY than most popular distros - if you find Debian too annoying to set up you can always try Linux Mint/Linux Mint Debian Edition, which is a very reputable Debian-based distro.
Very valid points. Since the RedHat announcement, I’ve migrated all my home servers to Debian so I thought “why not switch over my gaming rig as well”. As I thought about which district to use I came to the realization that I don’t want another situation where I’m using a distro based on another distro and that other distro decides to do something that affects the distro I’m using and blah blah. So then that leaves me with using the base (Debian, Arch, etc.) to avoid what I just mentioned.
I’ve been using Linux for quite some time so I can usually handle some break/fix. I haven’t tried Linux Mint yet but again, I rather just go straight to the base and go from there.
Still want to read your post tho. I’ve got Sid setup and ready to go and I do want to see how much breakage it introduces as I continue to use it. If it’s a bit too much, I’ll give stable a try.
I don’t want another situation where I’m using a distro based on another distro and that other distro decides to do something that affects the distro I’m using and blah blah. So then that leaves me with using the base (Debian, Arch, etc.) to avoid what I just mentioned.
Yeah this is generally where I’m at as well. There’s no point tying yourself indefinitely to a downstream distro/maintainer because they configured some stuff that takes 1-3 hours to do yourself. Downstream distros may also break some stuff or configure things poorly, so it’s just better to get it from upstream and follow their guidance.
Linux Mint gets a special mention even though it’s derivative, just because it’s a solid and reputable distro with a long history of being sane and easy to use. If I’m recommending Linux to a new person they always get Linux Mint as an answer.
Out of curiosity, are you running Steam/Proton/etc on Flatpaks because the normal packages are too outdated in stable or because the dependencies for them are too outdated?
Also are you not running into issues where the flatpaks can’t talk to each other? For example, installing a proton version on the steam path. Since flatpaks are isolated and have limited access to the system, wouldn’t I run into issues there?
I run Flatpaks for gaming mainly because I want cutting edge Mesa (which is inherently used while running games from Flatpaks). It’s not necessary right now since Bookworm was just released and Mesa is not that old, but as a long-term plan I think this is more consistent. I don’t think Steam will have a problem keeping up to date without Flatpak, but Lutris is probably best kept cutting-edge via external Deb repo or Flatpak. In general Flatpaks are pretty terrific and I recommend using them for a lot of things nowadays anyway (I even used a lot of them on Arch Linux). There’s really no performance cost anymore, and most Flatpaks are configured seamlessly from the start so you don’t need to worry much about access issues.
Flatpaks can generally access anything they want, but you might have to allow that access manually, depending on how the Flatpak is initially configured (Flatseal makes this super easy). Usually this just means you’ll need to allow read-only or read/write access to specific directories where your personal files live. The biggest problem that Flatpaks have is that they absolutely can’t access /usr (and /usr/bin by extension), and this can make things like running mangohud %command% or strangle 60 %command% more or less impossible. You can actually still access stuff via /run/host/usr/bin from inside a Flatpak if you give it host permissions but things run this way usually get very confused and don’t work correctly. You can also try to use flatpak-spawn to do some interesting things from within the “sandbox”, but its usecases are limited in my experience. Notably you can cut off internet access from a game that’s being run, but flatpak-spawn also currently has a bug/oversight which wipes out the environment variables for the spawned process, which usually causes some havoc.
There are also “portals” that hook into Flatpak, which I don’t know nearly enough about. If you use KDE for example, when you “open” a file using a Flatpak’d program, KDE will swap in a native file dialog and let you pick a file from anywhere even if the Flatpak doesn’t have access, and then it grants a temporary one-time access to that file to the program. For example I disallow Discord from accessing practically everything, but I can still upload files from anywhere on my system to a Discord channel with the KDE file portal.
In terms of Proton versions and Wine versions etc, there’s no issues here. I usually use ProtonUp-Qt to install different versions, and Steam/Lutris/Bottles will have no issues accessing these even if they’re Flatpak’d.
Edit: Also, you can theme Flatpaks like this. You’ll need your system themes to be installed to ~/.themes and ~/.icons in order for Flatpak programs to access them, and then you can set default global overrides for the theming environment variables and access to ~/.themes etc. using Flatseal. This will allow all programs to use your themes without individual configuration.
Okay, on this thread alone a lot of people are suggesting to go stable (including yourself) so now I’m thinking you guys must know something I don’t. Truthfully, I only really need a few things for the games that I run like a recent kernel (XanMod maybe?) Wine staging, steam, nvidia drivers, lutris, bottles and proton (through ProtonUp-Qt). As long as I can run those things on recent versions, I think going stable would be fine too.
The advent of Flatpaks have really made Debian Stable into a serious contender for desktop Linux, and Debian 12 is a remarkably good release even by Debian’s standards. Bookworm has received a lot of praise since its release, and I think people (like myself) are starting to reconsider what a desktop Linux can look like.
It does take a little bit of extra setup to get more cutting-edge stuff for the applications you use most often, but after sourcing everything and stuffing all the individual updating mechanisms into an update script, you’ll get the best of both worlds - stable base and rolling user applications. If nothing else you should try Stable first before resorting to Sid - you may be inheriting Sid’s volatility without a proper usecase. If you don’t run Debian Stable or Debian Sid/Arch Linux, you’ll probably want to go somewhere in the middle like OpenSUSE Tumbleweed, which is cutting-edge with extensive testing baked-in.
I’m going to give stable a try and see how far I get with gaming and go from there. I’ve never run straight Debian as a desktop it’s always been on servers so my experience there is limited.
I’m curious as to the update script you are talking about. Care to point me to an example? Wouldn’t flatpak update do the trick for everything running in flatpaks? And apt update/upgrade for the rest?
Wouldn’t flatpak update do the trick for everything running in flatpaks? And apt update/upgrade for the rest?
Yeah exactly. An update script just runs all these updates in a single command
this is what mine looks like (apparently lemmy does not like &&'s so take care with the & bits):___ bash debupdate() { echo -e “##======================== Nala upgrades ============================##” sudo deb-get update 1> /dev/null # fetch deb-get repos ahead of time just for timing purposes sudo nala upgrade # nala is better than apt echo -e “##======================== Flatpak upgrades =========================##” flatpak update echo -e “##======================== deb-get upgrades =========================##” sudo deb-get upgrade echo -e “##======================== Rust upgrades ============================##” export CARGO_PROFILE_RELEASE_LTO=true export RUSTFLAGS=“-C target-cpu=native” rustup update && cargo install-update -a # this is a custom cargo package: https://crates.io/crates/cargo-update - take care as this doesn’t inherently recompile with the same flags you originally installed with echo -e “##======================== Homebrew upgrades ========================##” brew update && brew upgrade echo -e “##======================== yt-dlp upgrades ==========================##” # I let yt-dlp manage itself $HOME/Applications/yt-dlp/yt-dlp -U echo -e “##======================== Antidote upgrades ========================##” # antidote is a zsh plugin manager antidote update sudo -u root zsh -ci ‘antidote update’ echo -e “##======================== Upgrades Finished ========================##” }
How do you manage kernel updates when running a custom kernel? Do you have to regularly check for security patches that you need to apply? It seems like something you could easily forget about without the benefit of an auto-update checker reminding you.
I’m not sure what type of auto-update checker you’re referring to but with Xanmod it’s still installed from a Debian repo and updates with the rest of your system, so if you use e.g. KDE’s Discover software center it will still alert you when it finds that the Xanmod kernel can be updated. Personally I just update everything whenever I reboot my system and at least once a week otherwise. There is usually nothing to update with Debian, so this isn’t a big deal.
As for security patches I might need extra guidance on that - since Xanmod is inherently built from mainline Linux source I don’t think it needs security patches? Kernels like LTS Linux or Debian Stable’s still want the newest security patches from new kernel source code, so those have to be manually extracted from the newer kernel source and backported into the old codebase. With something like Xanmod there’s nothing to backport because it’s always got the newest source and all the current security updates. You can think of Xanmod like linux-zen on Arch Linux - it’s just a fork of the original kernel with a couple extra tunings.
Edit: Actually from my understanding, linux-zen from Arch Linux is equivalent to the Liquorix kernel, if you want to use that instead of Xanmod. I don’t really have a strong preference between the two.
I see what you mean, thanks. I had assumed you would be compiling it from source yourself and for some reason it didn’t occur to me that there are separate repos for alternate kernels.
Excellent write up. I just wanted to add I am also using Debian stable (bookworm) and it’s going great. I use steam and I’m playing Baldur’s gate with no issues. I have a nvidia 1070.
Luckily every gaming distro is just a bunch of configs already made that have a 50/50 chance to work. If you want rolling release your best bet is OpenSUSE Tumbleweed, it’s way more stable than Sid. If youre used to APT id say go to pop os. If you want to stay with Debian your best bet is to use the testing repo, Sid is for devs and people who are trying to find bugs
Yup, I use Tumbleweed and it seems to get updates as fast or faster than Arch most of the time, and it seems more stable to me. I used Arch for ~5 years and Tumbleweed for 3-4 now, and I’ve had to fix Tumbleweed much less (and each time was a simple snapper rollback and try upgrading again in 2-3 days).
When I used Debian, I would stick on the next stable (i.e. testing, but with a named release) until a few months after the release. For example, if I was on Debian right now, I’d probably be on bookworm (old testing, current stable) for another month or so, then upgrade to trixie and stay on that until a few months after trixie releases. Debian testing tends to get pretty unstable right after a release as a ton of things get merged from sid after the freeze, so I give it some time to stabilize.
Both are great. I just found I’m not a fan of how Debian does certain things and I generally prefer Arch and openSUSE.
linux_gaming
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.