I've been seeing a lot of bazzite recommendations recently, and it sure sounds great. An atomic fedora, gaming optimisations out of the box. It just works.
We'll that's not been my experience for V-rising, and I wanted to share it incase others anyone else encounters the issues I did.
First and foremost I am sure there major issue is the game, more than any given distro. I've been happily running arch on my home PC for 7 years. Its been great, no issues, I've loved it. As my free time decreased, that computer had become just for gaming. The maintenance debt was building up, I knew the dream run with arch must end. That end was V rising, crashed frequently, all kinds of stage behaviour. I assumed a vulkan issue, but couldn't easily find a fix, and didn't want to waste any more time on it.
I went with Bazzite, but to no avail. The crashing problem got worse. Only now i had to deal with the sluggish flatpack versions of things. Its not that bad, but us a was a very noticeable change.
If it had just been me, I think this is whereui would have given up. But I was playing with my wife and mate online, both of whom also use Linux and weren't having the crashing issue. On my wifes computer i had recently installed bazzite. It did have issues, mostly flickering which i chalked up to a too early switch to Wayland on a gtx1080. My mate was on mint, with a 3060 and v rising was working perfectly.
I switched to mint (I am running and a 5700xt), and my problems were fixed just like that.
Next was to solve the wife's woes, so I switched her to mint too. Which resulted in v rising not being able to load, freezing up the computer every attempted requiring a X restart. Didn't matter which version of the nvidia drivers i used. The flickering was gone though, so that was something. Pop-os was the solution, took a bit of understanding popshops preferred order of events to get nvidia drivers installed, but now all is fine.
So the lesson I think i might have learned, old hardware and new (vulkan) games require unidentified settings to work and easiest solution is just distro hop till success. Big shout out to steams transfer over network functionality (i also needed to install bg3 each new distro, it ran fine on every combination but bazzite was noticably more flaky).
It doesn't matter, but does any one have and ideas as to why v rising caused such headaches? 7 years a Linux gaming, and nothing has required more than a few hours of tinkering at most to get to work until this.
Tldr. Needed a safe space to debreif, everything worked out in the end.
I use celluloid flatpak which has native wayland and pipewire support. Its an MPV GUI.
But browsers should be installed as an RPM, because Flatpak uses the same seccomp filter for all apps. That isnt even really secure, but prevents browsers from spawning user namespace sandboxes. Which means they have very little process isolation.
User namespaces are not the only method of sandboxing in Linux. I use Mullvad browser, which is a fork of Firefox maintained in tandem with the Tor browser (without Tor integration), so I'll mainly discuss Firefox. Here are some relevant comments on Firefox's internal sandbox in flatpaks:
Firefox's internal sandbox is designed to function properly without user namespaces or chroot
Firefox uses nested seccomp filters to achieve process isolation
The TL;DR is that Firefox uses seccomp-bpf on each process (with per-process nested seccomp filters) to intercept all syscalls for sandboxing, which does not require the use of user namespaces. User namespaces are used where possible, simply to add an additional layer of padding as a method of defense in depth. Since the syscalls are already intercepted and handled with seccomp-bpf, it could easily be argued that this is redundant and unnecessary given the way the Firefox sandbox works, based on the comments of the Firefox developer I linked to.
Chromium browsers had very bad issues with sandboxing, as they assumed that user namespaces would always be available (which breaks on any distro with them disabled in the kernel, as was the case with Debian and Arch just a few years ago, or any install that uses the linux-hardened kernel), and Chromium does not use seccomp-bpf for their process isolation like Firefox (or at least it didn't when the bugzilla I linked to was made). I believe those issues have been fixed however, and Chromium-based browsers (at least the ones that implement the patch or something similar) should also have proper process isolation in flatpaks now. I don't follow that very closely since I don't use Chromium-based browsers, though. Here's the flatpak Chromium patch that uses
flatpak-spawnto fix process isolation in Chromium-based browsers for reference. It was mentioned in one of the Firefox bugzilla pages I linked to earlier. Since it isn't an upstream fix, I wouldn't trust that all Chromium-based browsers use it, but that's an issue to bring up with Google (assuming it hasn't been fixed upstream in the past couple years). Firefox specifically designed their sandbox to work in these situations where Chromium may fail.Mullvad Browser isn't available as an RPM (or even DEB), and while they have a tar.xz download that I imagine just installs the browser in the folder it's extracted to (not source tarball; it's all pre-compiled), I have no idea if that receives automatic updates, and I've never used a Linux app packaged like that, so I choose to use the flatpak instead.
Late reply, had this in my inbox for a while.
Interesting bugzilla thread indeed.
seccomp vs userns
I dont know about the security difference between nested seccomp filters and user namespaces. I dont know how good the achieved process isolation is.
But I can imagine that the Firefox approach is better.
chromium
Also note that Chromium has a setuid sandbox mode which is kept as fallback. Found that through secureblue.
I know that bubblejail is currently broken for me, I will uninstall it, remove the configs and reinstall it again.
I think running FF with userns enabled AND isolated with bubblejail is best, and it is possible.
flatpak and seccomp
Flatpak has a real issue with their loose and kinda random badness-enumerating seccomp filter. See this issue
The problem is, app devs dont know shit about seccomp, some other project (was it GNOME?) just uses the Flatpak filter because they also dont know enough about it.
It would be best to have a modular approach, with "security building blocks".
Browsers have the "
base" set of rules, which is the most unrestricted there is, allowing user namespaces.All apps by default get the "
standard" set which is base, without userns.And there can be a more secure one for
strongandverystrongisolation.browser updates
Firefox has a builtin updater, Distros just remove that. So the Mullvad Tarball and also an official Firefox or Thunderbird tarball will autoupdate.
But as the app lies in an insecure location, its source could be modified. So it is always best to have apps somewhere only root can change.
Same for flatpaks actually,
--userflatpaks are installed to the user homedir without any permissions and could be tampered with by any process.