Hopefully Valve will release a general version of SteamOS with Steam Machine coming (and even they are questionable with their track record)
While what you're saying isn't impossible, it's unlikely. In the event it did happen, Bazzite is a fork, a signing key, and a couple forked Fedora Copr repos away from being made completely in someone else's control.
Note that this was in a change proposal which was rescinded without a vote by it's proposer.
> As much as I’d like this change to happen, it’s too soon. This change would kill off projects like Bazzite entirely right as Fedora is starting to make major headway in the gaming space.
> I’m speaking as it’s founder, if this change is actually made as it is written the best option for us is to just go ahead and disband the project.
Now, whenever you would've actually shut down the project is a different story, but your messaging was very clear.
The messaging was very clear that the upstream change would make Bazzite almost untenable.
It was a criticism of Fedora, not a threat to quit.
If nothing else, the only way these problems ever get solved is by bringing them up, surfacing the issues and providing an impetus to get them solved.
Did you mean diktat?
It's an important question to ask.
I did voice that concern in some Bazzite-related spaces before and it felt like it got brushed off with a weird undertone.
Note that we remove rpm Firefox for security reasons. You do not want your browser to only update with your entire operating system.
Just need the Atomic Fedora base to still be around and everything else is already pre-setup to run on GitHub infrastructure neither of which I anticipate going away soon. (Famous last words)
Calling it a superset of Fedora rather than just being its own bespoke distro can be a fine line, but really there's nothing stopping anyone from forking it and continuing on, a good few people run their own forks already to meet their own needs a bit more specifically.
So if Bazzite did go that way you could have fedora running in under an hour and with flatpak most thing will just work.
I'm a fan of my Steam Deck and SteamOS, but I'd like that experience to eventually be available via community supported distros, which Valve/Igalia can rebase from, and instead focus on Proton.
Bazzite is the closest to that that we have so far.
Anyways, I get that this is a "risk" to consider, but installing a new distro isn't so bad that it should prevent one from trying and using a currently extant distro if it works for them.
This is a bit of an oversimplification, but Bazzite, Bluefin, etc, are basically just Dockerfiles that use Atomic Fedora as the base image.
So you are basically getting a pre-built docker container that is "Fedora + various configs added on top", and then you are booting that docker image.
Since it's just a container file, anyone could theoretically just fork the Bazzite repo, make some changes to the Dockerfile, then push it to github + let github actions build a custom docker image.
So is that custom docker image a distro? Some would say yes, others would say no.
Games are something I do to relax. I want as little friction to play the games as possible. For tech projects and work stuff having to mess with the OS and move away from deprecated stuff isn’t such a big deal, it’s part of the work. But for games I want them to just work as much as possible, I don’t want to have to find a new distro and install it and set everything up again on my gaming PC.
Despite Windows sucking in so many ways, it is the OS with the most assurance that a game will work without fuss. I am happy to see Linux closing this gap.
Currently I literally can’t find the time to convert my drive from master boot record to GPT for Windows 11. I can’t imagine having to completely switch operating systems/distros because it just disappeared. Worrying if it will still be around is legitimate.
I am/was a big PC enthusiast but could no longer keep up with all the stuff due to real-life, eventually even gave up gaming for a few years as I just did not have the time.
The Nintendo Switch bought me back into (limited) gaming. I liked that I could just play from anywhere in short bursts, or could just hook it up to my TV and pick up the controller for longer sessions. The best part, I never had to worry about updates breaking things, or doing system maintenance - I could just power it on and jump straight into gaming. But I still missed my old PC games, especially playing games like Diablo II and Age of Empires.
When the Steam Deck came along, it changed everything. Well, technically I didn't get the Deck, I got a GPD Win Mini instead, and installed Bazzite on to it... but same thing. I get the same convenience as I had with the Switch, except now I had the added advantage of being able to play all my PC games (yes, all of them. No, I don't play games with nasty kernel anticheats).
Regarding your concern about Bazzite completely disappearing, the good news it it doesn't really matter. Since everything you customised lives on your home drive, all you need to do is backup your home drive, and that backs up everything you'd care about. You can use this same backup in Windows (Steam allows you to easily import a library from a different drive/folder) and your Pictures/Documents etc are basically the same folder layout as Windows. I actually ended up setting a triple-boot setup of Windows, Bazzite and CachyOS on my handheld, and they all point to the same Steam Library, same Documents etc. So not only do I have tripe redundancy, it shows how portable and migratable this stuff is.
I miscounted though, I’ve been running the same OS since Windows 7. Probably 2014. I’ve been able to upgrade without having to throw away my entire operating system. Consoles aren’t a solution for longevity.
How is that longevity?
It’s not in a consumer friendly state yet, but I’ve been using my steamdeck with encryption for a month now with zero issues. I guess technically this is not “full” disk encryption since it’s just the home dir, but I only care about protecting my personal info which is all in the home dir anyway.
FDE would be nice though.
I’m not familiar with how the process works, but if you are setting the password somewhere, it’s exposed to being extracted. You want the password to be something you type in on boot.
Steam OS I believe is based on Arch. Bazzite is based on Fedora. Personally I have experience with Debian distros so if I wanted a gaming-focused distro I would pick maybe something like Pop OS.
There are limitations but if you want a gaming machine, bazzite is a no-brainer to me. Poo is very impressive but I just don’t want to fight my OS constantly when it comes to gaming.
The good news is, you can easily rebase to any other uBlue or even Fedora Atomic distro with just one or two commands, or if you're technical, you can even fork Bazzite's repo and build your own Bazzite (they even provide instructions on how to do this, it's very very simple, relatively speaking).
A community distro (be it a console-like gaming focused distro or not) is going to be the way to be the way to go for the foreseeable future. I'm pretty happy with running EndeavorOS w/ KDE, Steam, and Heroic. The Steam client with Proton is where most of the magic happens in Linux anyway. If I wanted to get fancy, I could set up GameScope with Steam Big Picture to take a SteamOS/Bazzite approach.
Additionally, I think Valve doesn't want to end up over-committed to replacing Windows. They can handle the storefront side and do a decent job with handling the runtime, but actually committing to a desktop alternative to Windows would be spreading their resources thin. It feels like a smart call to not jump into that arena if your hardware products don't need it.
One issue I had with OpenSuSE was that once a new release drops you have around 6mo to migrate all your machines over to it. Which, for most businesses, is a pretty short timeline, in my experience.
I've always preferred authoring RPMs over debs, but Caninical having basically one distro without the forks, I think is a huge benefit for a business using them.
1. It’s not exactly some fly by night thing at this point, it’s extremely popular, which means the likelihood of having maintainers and sponsors step up with, at the very least, an easy migration path is high.
2. You could say the same thing about enterprise-oriented distributions like CentOS that actual companies relied on and had to migrate away from. Some of those arrangements are more fragile than they look. What happens if Canonical is acquired? What happens if IBM spins off Red Hat?
3. Bazzite is arguably even easier to migrate away from because it’s immutable. You’re not supposed to be making major changes to layered packages, you’re mostly installing things with Flatpak, Homebrew, throwing stuff in your home directory, or leveraging distrobox. In other words, my entire backup/restore strategy is to backup my entire home directory, my brewfile, and listing out all the flatpaks I’ve installed (might be handled by the home directory backup anyway? I have to do a restore exercise sometime soon)
I really think immutable distributions are the future of linux desktop, and maybe distributions that use OCI images, beacause they are a lot easier to work with than say, NixOS for example.
If you want to have your custom bazzite, you just do a "FROM bazzite:<whatever-version-you-want-to-pin" and add stuff you want.
Of course, you loose a bit of the reproducibility, since usually container images do not pin packages (and maybe other reproducibility issues I am not aware of) but it is way easier to work with.
Switching over to my images using bootc failed because of what I eventually tracked down to permissions issues that I didn't see mentioned in any of the docs. In short, the packages you publish to Github's container registry must be public.
Another wrinkle: The Bazzite container-build process comes pretty close to the limits of the default Github runners you can run for free. If you add anything semi-large to your custom image, it may fail to build. For example, adding MS's VSCode was enough to break my image builds because of resource limits.
Fortunately, both of these issues can be fixed by improving the docs.
It takes away a tad bit of the direct control of the process, but covers the majority of things you would want to configure.
I installed this begrudgingly after fighting edge cases with Waydroid on Arch. It's the first "batteries included" distro I've actually liked. I usually hate the "omakase" approach, but the setup here is pretty much how I would've done it myself.
Side note: GNOME + Waydroid is the best experience I've had with a desktop OS on a tablet. Finding tools like scrcpy included out of the box was a nice surprise, too.
just relax, install windows and late the escapism take over.
Based on their results, it sounds like there's still quite a way to go Linux gaming/Proton (ie: very inconsistent frametimes on Nvidia hardware), but it's definitely been taking steps in the right direction.
I'm currently working on few very targeted optimizations for several hotspots I've found out from messing around so it will be interesting if I can solve those horrible stutter issues on cyberpunk since if I can fix it (in a ghetto and janky way), so can valve.
I can also achieve higher fps in games like overwatch (dx12) out of the box on nvidia on proton experimental which is surprising as 4 years ago the input latency was unbearable and I had drops as low as 30 fps, now I can achieve consistent 600 fps with minimums of 450 whereas on windows I get as low as 220fps and averages of 500ish. I do have anticheat related drops to <300fps due to the amount of translation happens when they decide to scan memory, registry and whatnot although it lasts <1s and doesn't happen during games it seems.
For some games it can be. For some games Proton performs far worse than Windows. It's not steady across the board. And some have stability issues, bugs, major performance problems, or just flat out don't work.
I want Proton to be the future as well, but I think it's important not to oversell it as a drop-in replacement either.
EDIT: GN highly recommends against apples-to-oranges comparisons of the two, but even looking at their own data for AMD cards (with exact same CPU, RAM, and motherboard) it clearly shows Proton being behind on the order of 6-15%. Not a lot, but not ahead either. You can compare the numbers for the AMD cards against this video's here: https://www.youtube.com/watch?v=yP0axVHdP-U
EDIT 2: Instead of just down-voting because the result makes you unhappy, how about responding with well-sourced proof otherwise?
I dunno. I remember a little while back some reviewers got a hold of both a Windows version and Linux version of a handheld gaming machine that had exactly the same hardware. The conclusion reached was that the Linux version was better in nearly every way.
As I remember it, a little while after this happened, some muckety-muck in the Gaming Division in Microsoft announced something like "We're making a new committment to consistent, high performance in Windows on handheld gaming devices! We're going to ensure all those little game-spoiling roadblocks are removed!". Which, like, good job making it NOT look like you're spasmodically reacting to bad press, guy.
The handhelds we're talking about are -essentially- a low-power [0] laptop in a tiny case. Again, we're talking about exactly the same hardware, that provides substantially worse performance when Windows is the OS than when Linux is the OS.
For reference, here's one instance of the original coverage of the phenomenon about which I spoke: <https://www.youtube.com/watch?v=CJXp3UYj50Q>
[0] But higher power than one might naively expect!
Do note that they make it very, very, very clear that their results are preliminary, and while they've put a whole lot of work into setting up benchmarking on Linux, they're not at all sure that they've got it all correct.
> ie: very inconsistent frametimes on Nvidia hardware
Yeah, Nvidia on Linux for non-"compute" use has always been a terrible, godawful shitshow. Given Nvidia's recent and fairly-clear disinterest in the "selling graphics cards for people to play video games with" market, [0] I can't imagine things will get consistently better anytime in the near future. [1]
[0] Why sell that silicon to video gamers when you can sell it to cryptominers and -these days- "AI" companies for a much, much, much higher profit?
[1] I mean, it took them how many Windows driver revisions for them to release somewhat-non-garbage drivers for their spanking-new fancy-ass 5000-series cards? And Windows is the only consumer OS that they care about! For video game use, the Linux drivers are gonna be starved for development resources, and -unlike ATi/AMD's drivers- noone in the world can work on them but Nvidia.
If Bazzite goes poof overnight, though, that's a major problem. At least Fedora's official spins will continue to receive necessary updates.
I realize that, in a way, it's no different than installing from AUR or ppa's, but something about both of those (and the fact that package installs are manual) feels safer than copr packages with fewer eyes on them...
I treat my gaming computer as a video game console, it wouldn't occur to me to share passwords, accounts, data or anything sensitive on my gaming machine. And I only connect it to the network if I need to download a game/update.
I wish there was better documentation for this, because "random indie game demo cannot upload my family photos" would be a great selling point for SteamOS/Bazzite.
As it stands, the Steam flatpak is probably the safest way to play games (which does not work on Bazzite).
It's been tried but I don't think it's ever been very successful. The Battlefield series used to use Fairfight, which is based on server-side heuristics, but they ultimately gave up on it and switched back to client-side detection for the more recent games.
But if your definition specifically refers to shooters like Fortnite or BF6, then yeah, they're not going to work. Except CS of course, but not sure if CS counts as "AAA" in your books.
If you wanted to teleport (and the server was poorly implemented enough to let you) you could just intercept your network packets and add a "teleport plz" message. Real cheats in the wild used to work this way. However a wallhack will need to read the game's memory to know where players are.
What modern anti cheat software does is make it difficult for casual cheats to read/write the game's memory, and force more sophisticated cheats down detectable exploit paths. It's impossible to prevent someone from reading the memory on untrusted hardware, but you can make it difficult and detectable so you can minimize the number of cheaters and maximize the number you detect and ban.
Linux is incompatible with client anti-cheat because there is no security boundary that can't be sidestepped with a custom compiled kernel. Windows is Windows, with known APIs and ways to read process memory that can be monitored. Secure boot means only Microsoft's own built kernels can boot and you now have a meaningful security boundary. Monitor what kernel drivers are loaded and you can make it harder for cheaters to find ways in. Sure you can run in a VM, but you can also detect when it happens.
Sure we can just run with no client side anticheat at all (functionally what Linux always is unless you only run approved, signed kernels and distros with secure boot) but wallhacks and aimbots become trivial to implement. These can only really be detected server side with statistical analysis. I hope you don't ban too many innocent people trying to find all the cheaters that way.
I would still argue that there are technical issues leading to some amount of cheating. In extraction shooters like Hunt Showdown, Escape From Tarkov and a few others, people can run pcie devices that rip player location and other information from the machines memory in order to inject it into an overlay with a 2nd computer, and they do go to these lengths to cheat, giving them a huge advantage. It wouldn't be possible to rip that info from memory for these "ESP cheats" if the server didn't needlessly transmit position information for players that aren't actually visible. IMO this is a technical failure. There are other steps that could be taken as well, which just aren't because they're hard.
It has been (and continues to be) an enormous amount of effort, and some cheaters are absolutely going to get through anyway.
If they actually cared about stopping cheaters (rather than pouring tons of investor money into the appearance of anti-cheat), then yes, the future must be that.
But. I'm a USian and I notice that the TSA is still strip-searching people at airports and -worse- wasting assloads of everyone's time, effort, and tax money. I have zero faith that a sudden attack of common sense will redirect efforts (whether they be in the arena of airport security or eviction of match-damaging video game cheaters) in a more sensible direction within what's left of my lifetime.
Atomic updates means updates either apply or don't: there's no partial/fail state that can stop your PC from working. And in the rare event that an update has issues, you can instantly boot the previous two images, without typing any commands or using any fancy restore tools. And if you're a bit tech savvy (ie you know how to type a single command), you can even go back upto the last 90 days worth of images (via github).
The best part of atomic updates is OS upgrades, they work flawlessly. In fact since updates are delivered as images, an OS upgrade is no different to any other regular update, unlike regular distros like Mint where you have to cross your fingers and hope that your system still works after a dist-upgrade (and I believe Mint's official stance was that they didn't support dist-upgrades, they recommend you to backup, format, clean-install and restore with every OS release. Not sure if that policy has changed now, but that used to be their stance for a very long time).
Bazzite just works like I’d expect an iPhone update or a Nintendo switch update to work.
You'd also want stable, atomic, updates that can go from "one version of system software to the next" without breaking the system.
Recently, i had to reinstall my 7 year old arch install because a system upgrade after a year or so broke it... It's not like i can't sit down and fix what went wrong manually, it's just that i wouldn't want to ever worry about these things on my home theater/"gaming console" pc...
- Out-of-the-box support for Xbox, Wii, Switch, PS3, PS4, PS5, and numerous other controllers.
- Nvidia drivers and the latest Mesa for AMD & Intel pre-installed, with tweaks applied as needed
- Bazzite ships with support for additional Wi-Fi adapters, display standards like DisplayLink, and more
- Out of the box support for not only desktop PCs, but handhelds, tablets, and home theater PCs.
https://www.youtube.com/watch?v=fqIjUddUSo0
Why others are better than Bazzite if it's made for gaming?
Bazzite also has a much more frequent release cadence which is important for the kernel and Mesa. SteamOS only ships a major version every year.
SteamOS 3.7 is still on Kernel 6.11 and KDE Plasma 6.2, for example. Bazzite is 6.17 and Plasma 6.5.
This matters if you're using more recent hardware or want the latest driver optimizations. My 9070 XT is supported by Bazzite, SteamOS won't even boot.
SteamOS release notes are public at https://www.steamdeck.com/en/news, it still uses a 6.11 kernel from September 2024.
I love the idea, but honestly, juggling all these package managers gets annoying really fast; for now what I use is rpm-ostree (which you really shouldn’t touch unless you absolutely have to), Flatpak, Homebrew (some package are mac only or mac first), and distrobox (with arch).
Every now and then I think of going back to arch cause they are the only distro that made it very convenient to install some obscure packages that is only used by handful of people
Like yesterday, I tried setting up Flutter with the Android SDK command-line tools and the rest of the Android dev stack, and it took me almost 2 hours to get everything working; On Arch? That’s just a few packages, all sitting right there in the main repo or the AUR.
I'm very much like you infact, so I ended up resorting to just using an Arch Distrobox for pretty much everything. I leave rpm-ostree and Flatpaks alone as far as possible, so I only really have to worry about my Arch for updates and everything else takes care of itself.
You may ask then why not just use Arch? Well of course you can, but I like the idea of having a rock solid base where I know for a fact that I can let it happily update without breaking something. Arch still requires manual intervention every now and then (such as package migrations or some dependency conflicts). Not a big deal if you keep up with the Arch News and Discord announcements etc, but sometimes IRL gets in the way and I'm not up-to-speed with what's happening. With my Bazzite+Arch setup, I'm not super bothered with this, plus it's easy to blow my whole container and set it up again, and in fact I've got a bash script to do just that on one of my other PCs that I don't use regularly (because Arch needs to be updated regularly, otherwise you're in for a nasty surprise when you find out your keyring is out-of-date and pacman has been upgraded and nothing works... with a container, just blow it up and fetch the latest version, reinstall your packages and you're up and running in no time).
For normal non dev usage it works great. On my steam deck I just get everything through Flatpak or steam and it just works.
- Newer core packages (kernel, graphics drivers, desktop environment). This often translates to better hardware support (especially if it's recent hardware), and often better game compatibility (newer graphics drivers often include fixes for games), and often better performance as well.
- More suitable as a general purpose OS. SteamOS heavily leans into the gaming use-case (naturally), and whilst you can use it as a regular PC, its immutable nature can make it a bit annoying depending on your workflow. Bazzite includes a bunch of useful defaults (apps/config/shortcuts) that makes it much more conducive for regular PC usage, or advanced gaming usage (like if you want to install an overclocking utility or do something more "advanced", it's far more easier and convenient).
Does these custom scheduler bring noticeable gains during usage? My previous linux desktop was a non-gaming distro, so I'm a bit curious on these fancy stuffs.
- BORE, CachyOS scheduler: https://wiki.cachyos.org/cachyos_basic/why_cachyos/#advanced...
- LAVD, SteamOS scheduler: https://www.igalia.com/2025/11/helpingvalve.html
> improved CPU schedulers for responsive gameplay,
on their homepage https://bazzite.gg/
Bazzite does look very promising and happy to see innovation in the Linux gaming world!
It also has a command `ujust regenerate-grub` which adds a Windows entry to the bootloader.
Each of these is a single command which only must be run one time after install. I suppose it could take a few hours to either do it by hand, or to discover one of these options, but they are both documented and in particular the guide at https://docs.bazzite.gg/General/Installation_Guide/dual_boot... (which you implied you followed) mentions the latter command.
It works on each of my Bazzite machines without any manual tinkering/intervention. Not sure why it would not Work On Your Machine (TM).
I have a system that I kind of want to have Linux forward with Windows on secondary m.2 drive to dual boot if I need something there. Following protonDB, I see all the games that I play work just fine and are either gold or platinum status.
Would you recommend Bazzite or Cachy? I main do gaming, development and web stuff. I tend to run multiple dockers, multiple different versions of python and other packages. How would immutible OS affect me here?
I would recommend CachyOS if you're after raw performance and you're technically inclined, and don't mind ocassionally going into the terminal to fix something or do some maintenance (maybe once or twice a year).
Bazzite on the other hand is great if you don't care much about minor FPS improvements, but value your time and system stability more. I have both installed, and use Bazzite when I want stuff to "just work" and not think about updates and maintenance. I use it for work, and for braindead gaming (ie I'm back from work and just want to dive into gaming without needing to worry about any PC stuff).
Both OSes are fine for docker/dev workflow. Multiple versions of python isn't an issue on ANY Linux system, as you would never be installing them across the system, you'd be installing them in a container or a sandboxed environment. I'd also recommend checking out Flox[1] as a fast and lightweight alternative to containers, it's great for working with Python in particular.
I did briefly consider Bazzite, but the thing that stopped me was that I wasn't sure how well it would work with an eGPU. With Jovian and NixOS, it is ultimately still just NixOS minimal under the covers, and that is low-level enough for me to play with boot parameters and kernel modules to get the eGPU working, and it wasn't clear to me that it would be that straightforward with Bazzite.
Give it a shot, not like it costs anything!
For diy you can use moonlight / sunshine or steam remote play. I find latencies lower than around 30ms perfectly playable for everything except twitch shooters etc.
For true diy look into leveraging nvenc or equivalent hw encoder using a “zero latency” profile and build on top of UDP. TCP could be feasible for client input -> remote traffic, but even then building a minimal custom reliable layer on top of UDP probably makes sense to avoid nagle type issues. If you want to support arbitrary input devices (joysticks, wheels etc) that can’t be represented as an Xbox controller things will get pretty tricky. Especially if those devices require drivers, at that point your into proxying usb.
DIY in a weekend? Definitely.
True DIY in a weekend… probably not :)
One insanely underrated Linux software is Lutris, if you have non-steam games, it is phenomenal at helping you wire them up for Wine, especially when Steam itself behaves weird (like installing third party things is not exactly done intelligently by Steam).
After that, just use EndeavourOS.
I used Antergos before that and EndevourOS has been great since.
The actual user does not give any shits. And while I love tinkering around and understand my OS/distro/$software I can absolutely relate. Linux should be at last so accessible that most of the things just work and a broad audience can just use their computer.
Part of the reason new users struggle so much is because they forget they have spent 10 years or whatever using windows / macos and linux is definitely not those.
As much as Linux has become far more user friendly in the last couple years it still has its warts and a quick boot camp like installing arch can be very beneficial.
Zorin OS and Bazzite... I was hoping someone who has tried both could enlighten me as to why one is better than the other?
[1] I say recently because I'm not following linux very closely.
Zorin is a more "traditional" OS, where things work like most PC operating systems, whereas Bazzite is an immutable OS with atomic updates. Immutable means the core system files are read-only, which makes it less susceptible to corruption and breakage (due to user error or malware). Atomic updates means updates either apply or don't: there's no partial/failed state that can break your PC.
Updates are also image-based, where your entire OS image gets updated in one go, kinda like how mobile OS's work - this means there's no chance of package conflict/version/dependency issues that can sometimes plague regular Linux distros like Zorin. This also means that major OS upgrades are trivial - they're treated like any other update. In Zorin and even Windows for that matter, major OS upgrades are always messy, and there's a chance something can break or get corrupted. You don't have that issue with immutable, image-based distros like Bazzite.
The only area where Zorin would be better is in low-level customisability - like say, you want to switch out your kernel to a custom kernel, or use a different DE, or change login managers etc. You can do that in an immutable system, as these are core components. But most people don't do this, so for regular users, an immutable system like Bazzite would be a much better choice.
Okay. I think I get a feel for their target audience.
Overall I will say things are going like 80% smoothly but there are still some very Linux-y problems with it:
The default grub has options for ostree:0 and ostree:1. 0 is the default and if you pick 0 it just hangs and doesn’t boot. I can’t figure out how to change this because the normal grub config files are read-only. So I have to quickly press down arrow when the computer is booting and select the right option.
Installing certain packages is difficult or impossible, for example I had to get pycairo and some other packages to run a Python program and you can’t add them normally. But I think the proper way is to just run everything in a container so maybe that’s on me.
90% of games work fine, but many have weird bugs like crashing when you Alt-Tab out. I could not get modded Skyrim to work after several attempts. Prism, the Minecraft launcher, has some sort of memory leak because if I leave it on in the background it eventually crashes the desktop and I have to hard restart. And of course anti-cheat games like Valorant/League don’t work at all.
KDE has tons of bugs - tooltips randomly scale to the wrong size, Dolphin refusing to copy a file to another drive for no reason, Dolphin freezing when loading a directory with lots of images, detaching a tab in Konsole sticks the window to your mouse until you click something else, Konsole has like 50 themes and none of them are named so you just have to squint and click one that looks good, drag-and-drop into Electron apps like Discord randomly fails, adding a new widget to the panel and suddenly it’s invisible, notifications appearing floating in the middle of the screen, removing an audio output (like unplugging headphones) seems to cause it to randomly choose an alternative, brightness on my monitor randomly shifts even after turning off DCC, GNOME apps have wonky themes, GNOME apps can’t detect light/dark mode so they just pick one… I could go on.
RE Anti-cheat, it's not ALL of them, it's only kernel-based ones. For eg, BattlEye, EAC, VAC, and nProtect Gameguard all work just fine, but of course, the game studio will need to enable that support. Arc Raiders, Marvel Rivals, Fall Guys etc all use anticheat and they work fine.
RE KDE, I haven't experienced most of those issues. I don't use Konsole (Ghostty is far better anyways). As for Discord, Equibop is a far better client compared to official.
RE GNOME, unfortunately GNOME and KDE have never really gotten along, personally I avoid GNOME/GTK apps are far as possible.
This isn't particularly linux-y of an issue. I've had the same sort of behavior in numerous games on Windows, up to and including crashing the graphics driver when alt-tabing out of a full screen game. Seems to be something gamedevs are not commonly testing, and perhaps difficult to defend against when a game is directly interacting with the GPU.
I can guarantee you any gamedev worth his salt will have used alt-tab at some point in the game's development on windows. It's an incredibly common hotkey to use, and the devs very likely have multiple ides, notepads, image editing software running concurrently. You seem to be trying really hard.
> when a game is directly interacting with the GPU.
Most devs are using cross platform graphics APIs. OpenGL/DirectX/Vulkan. Alt-tab breaking is likely an OS issue.
Not exactly a repeatable testing framework, that.
> You seem to be trying really hard.
I almost strained a typing finger! /s lol
> Most devs are using cross platform graphics APIs. OpenGL/DirectX/Vulkan. Alt-tab breaking is likely an OS issue.
All the OSes seem to suffer from it similarly. More likely an issue that even the cross-platform graphics APIs rely heavily on shared memory buffers and most games depend on code written in languages which aren't strictly memory safe. Sharing a memory buffer between CPU and GPU (or even just multiple CPU cores) is quite difficult to do safely under all possible circumstances without proper language support.
In fairness to game devs, alt-tab'ing out of a running game would be a challenge for many testing frameworks as it's not something you can do at compile time, requires running the game for a period of time (CI servers don't typically have GPUs), requires some sort of keyboard/mouse automation, and interaction with the underlying OS in addition to the game.
Issues which aren't added to some sort of test suite/CI tend to creep back in to codebases. Especially rapidly developed codebases like games. And threading issues are notoriously challenging to reproduce. Hopefully that helps you understand the difference.
Hey, you can't possibly be having these problems! You're using a RedHat-derived distro! That means it uses Wayland! And the Wayland people have been telling us all for years that Wayland is good for daily use for everyone, and that it should be the default everywhere!
(Do note that the above is bitter, bitter sarcasm. I'm so, so disappointed by how the Wayland folks tend to use political pressure (rather than plain declarations of both capabilities and shortcomings) to muster up general support for their project.)
Would it be easy for you to compile a list of like five or ten games that do this? I'm curious to see if I can reproduce this on my Steam-on-xorg-on-Gentoo-Linux machine with an AMD graphics card.
I don't doubt your report, not even a little bit, but -personally- I've found window management on Linux to be light-years better than on Windows. I can put nearly every game I've tried in my huge-ass Steam library on fullscreen on another virtual desktop, flip over to some other desktop (or window) to check something, and flip right back to find the video game still fullscreen and still running happy as a clam. [0] (To say nothing of the total lack of Windows-typical jankiness when changing the screen resolution on an "Exclusive Fullscreen" game.)
Whereas on Windows, it's kinda a crapshoot regarding both what state your desktop will be in when you Alt+Tab out of a fullscreen game and what state that game will be in when you Alt+Tab back. And if that game is "Exclusive Fullscreen" and is not running at your desktop's resolution, all the windows on your secondary monitor are probably going to be rearranged when the game starts, and will definitely be rearranged when you Alt+Tab out and maybe then again when you Alt+Tab back in.
[0] Two very notable exceptions to this are Red Dead Redemption 2 (it notices that its no longer the foreground window and "helpfully" makes itself windowed) and the Linux version of Dead Cells (it "helpfully" minimizes itself when it's no longer the foreground window.).
I'm far from a Linux super-user, I only use it for my servers and Raspberry Pis, but even I would rather pick Debian and install the necessary stuff by hand. This feels like opting-in to bloat on your newly installed OS.
I'll happily listen if anyone has a good selling point for those, but I can't think of any OS less attractive than something tailored for a single use-case on my generalist PC build.
But it is also part of the Universal Blue family, which means that updates are atomic and can be rolled back. SteamOS, GNOME OS, and KDE Linux are all trying the atomic distro thing, but you don't get it out of the box on the mainstream distros (yet).
With previous distros I always had issues configuring something or another with games/drivers. Bazzite has been the closest to Windows/console experience for me wrt Linux pc gaming.
If this is a generalist computer, then you are absolutely correct. This is not the distro for you. This is very specifically built for gaming.