You should be using flatpak everything you can in any modern Linux distro, to be honest. Flatpak packaging and dependencies ensure that everything that you’d have to hunt down and optionally install then configure on your bare system is just provided and works by default.
Fedora Silverblue is awesome for taking that to the extreme.
They’d probably contract Bethesda to develop it and make another soulless open world grindfest on an engine that’s about as overdue for retirement as Mitch McConnell
Universal Blue has some really good ideas. I really think immutable and atomic updating linux distros are the future. Most applications have flatpaks available.
Bazzite has alot of gamer forward features, has Nvidia specific builds, and even supports a SteamDeck replacement version of their OCI images.
Even though people may not like Fedora, I think universal Blue solves a lot of the Fedora style problems people experience.
There are also BlendOS and VanillaOS but I haven’t tried them with NVIDIA GPUs.
I’ve had good luck with OpenSUSE Tumbleweed, but I usually recommend Linux Mint because it’s so much more common so it’s probably easier to get help. So that’s my recommendation, check out Linux Mint.
The kind of game-specific fixes that get added to GPU drivers on Windows are typically added to Proton, not the Linux GPU drivers. Waiting a week for the Nvidia driver so you can be sure it won’t break your system is only a plus in this instance.
Gentoo. It will be the last distro you hop to. Because it’s whatever you want it to be. Don’t be afraid. It even has a special command and portage repo to install all the support files and ancient libraries from 2002 your old games need in one shot.
You can snag a binary kernel, browser and some compilers now too if you don’t want to deal with that. It’s not much more difficult than Arch nowadays.
Gentoo takes a serious commitment if for no other reason than build time. I would not go around recommending it to anyone who isn’t an enthusiast. PopOS to Gentoo is kind of a crazy jump.
That version number doesn’t look right and probably isn’t the driver (given it’s well before the 7xxx cards were released). Make sure you have a recent version of mesa and the kernel (and vulkan drivers) and that amdvlk and amdgpu-pro are not installed.
If you enter vulkaninfo into a teriminal, which driver does it use? You want RADV; 23.something or later. If it says AMDVLK, you want to uninstall that.
Which kernel are you using? You probably want the latest kernel (6.5) right now.
Possibly because of better reliability. If a filesystem breaks, all subvolumes it contains break in turn. Whereas independent filesystems will continue to run if one is corrupted.
This is standard for devices which receive firmware and OS updates non-interactively. Edge devices, phones, routers…etc. It’s a simple and effective way to lessen the chance that a device may brick during an update failure or similar event.
One running partition is the primary known-good copy of the system, and the other is a failover of a previous known-good. When an update is received, it isn’t applied directly to the current primary, it’s applied to failover. When the system reboots, the bootloader attempts to boot the newly updated partition to see if it works, and if it does, it is marked as the “new” known-good primary and boots from then on. If not, the existing primary is rebooted, and the user is notified that a failure occured, and dually an error or recourse to take if so.
Subvolumes and such require a kernel to be loaded in order to use, so that’s why the base device partitions don’t run that way. Even if you wanted to go that way, it’s safer working at the lower levels as above when you’re dealing with deployed devices out in the world. Nobody wants a customer service disaster on their hands if devices start bricking themselves from a bad update.
Subvolumes and such require a kernel to be loaded in order to use, so that’s why the base device partitions don’t run that way.
That’s a great point I never thought about. I really wondered why they wouldn’t go with btrfs subvolumes, since they could easily btrfs send and receive subvols like they do now with whole partitions. Subvols would even have the benefit of less space needed since many files probably stay the same between updates.
My guess was that the update mechanism used doesn’t support btrfs, though after a quick search on the rauc github it might actually support it.
Pretty much every Linux bootloader supports BTRFS these days.
The critical thing though, is that happens if your BTRFS partition gets corrupted? You just lost your failover since both your primary and failover are on the same partition.
That’s fine on a desktop system where the user can boot into a recovery image and repair the filesystem, but it’s not fine when you do a completely automated system upgrade. So for a kiosk, console, or other embedded system, the two partition setup is more reliable than a BTRFS root with subvolumes.
the Manjaro hardware driver setting is absolutely confusing or straight up misleading
also hilariously easy to bork your system here if you ever think about trying the video-vesa driver for whatever reason
the solution is to use the newest linux kernel and update all your packages (which updates Mesa and Vulkan tools) and afterwards rebooting (I still believe Manjaro doesn’t reload kernel modules on kernel updates automatically?)
if you experience graphics issues switch between Xorg/X11 and Wayland compositor
if you actually want worse gaming performance try the proprietary driver
linux_gaming
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.