Read (only) access should be fine. What makes it complicated is if there can be writes from multiple locations. Basically, the simple version would be to just periodically copy the data from the primary to all secondary locations.

I can see why you’d want to go with an off-the-shelf NAS. But, I would carefully check if it supports your use case, as it’s quite advanced.

If the data only needs to be read & written from a single server (and the others are just backups), you can also use simpler replication instead of synchthing. E.g. syncoid or TrueNAS replication. It sounds like you should be able to do that with separate datasets per household in your usecase.

I would probably go with a simple approach like this:

• ZFS: Each house gets a “NAS” that provides a ZFS filesystem to store the data. This gives you the ability to share the drives across your use cases (you, rest of the family), snapshots, RAIDZ support, and usage quotas. For the OS, you could use what you prefer (TrueNAS, Debian, Ubuntu, …).
• Syncthing to synchronize the files across the servers/houses. This allows you to read and write data from anywhere and syncthing will mirror the writes to the other places. I use it to synchronize data across 5 devices and it works quite well.

There are probably more advanced (enterprise?) ways to handle the file synchronization. But, I think this hould be good enough for normal, personal use. The main disadvantage is that you’re only synchronizing the current data (excluding the ZFS snapshots). On the other hand, this also allows you to mix file systems if necessary.

AFAIK, this corresponds to the snap package of Steam.

Did you do anything special during setup? I couldn’t find many reports specific to this card on ProtonDB, but lots of people were using different Proton versions that weren’t available on Steam so wasn’t sure if that was it.

For me, it defaulted to Proton Experimental. It worked fine so I haven’t changed it. But I can test 9.0 later. At some point I added “–launcher-skip” to skip the launcher, but it was also stable before that.

I’m running the flatpak version of Steam. Maybe you could try switching between the native and flatpak versions of Stream?

I’m also using the default Mint 6.8 kernel. Assuming that you are using the same, you could try switching to the newer HWE kernel.

Honestly, those two already kind-of feel like grasping at straws, but this one is even weirder (I’m only posting it because we both have AMD B650 mainboards): When I first switched to Linux, I noticed that I had a lot more weird crashes than on Windows. Eventually, I got a sufficiently specific error message (dxgi_error_device_reset I think) that led me to a workaround: After I switched the GPU PCIe Gen Mode to Gen4 in the BIOS the crashes were gone. I think the same issue occured on Windows too, but it somehow manages to recover from it. I would be surprised if you have the same issue, but I guess it doesn’t hurt trying.

An easy option to limit the GPU power on Nvidia cards is GreenWithEnvy.

Not sure what else it could be… For me it’s running fine on an RTX 3080 on Mint with the 570 driver… ProtonDB also doesn’t seem to have any relevant reports for the RTX 40 series…

Like many others here, I think the most likely explanation here is that you did not fully shut down Windows and it still holds a lock on this partition. You can force an actual shutdown in Windows by shift-clicking on the start button -> shutdown.

However, I would also recommend against sharing your Steam library between Linux and Windows. I also tried this with NTFS a few years ago and it caused me a lot of headaches. I had a lot of weird issues under Linux that went away after I finally switched to ext4.

It’s the unofficial updater for nVidia graphics on Linux. If you’re running Mint you should use the Driver Manager software instead, imo

The PPA just provides the packages, you can actually install them through the Driver Manager after adding the PPA. However, without the PPA, the newest available version seems to be 550, which is not new enough for a 50-series GPU.

It’s an unofficial repository (PPA) for Nvidia drivers on Ubuntu and Mint: https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa

If you add “ppa:graphics-drivers/ppa” in “Software Sources”, you’ll be able to install newer driver versions in the “Driver Manager”. For a 50-series GPU, you’ll want at least version 570 IIRC.

I think those should be fine with Mint 22. You’ll just need to use the graphics-driver-ppa to get an up-to-date Nvidia driver.

So, it’s basically up to you if you want to play around with another distro or not. But tbh it sounds like Mint is a good fit for you.

What are the specs of your new computer? Mint can struggle with brand-new hardware (e.g. new GPUs from AMD/Intel). Or did you purchase a new PC that officially supports Linux (Mint)?

Notebookcheck benchmarked the RX 6800 at 350 FPS in 1080p low and 107 FPS in 1440p epic (https://www.notebookcheck.net/The-Finals-review-Laptop-and-desktop-benchmarks.785549.0.html). Based on that, I’d expect better performance at 1440p low. This might be an issue with your hardware / configuration or with the driver/Linux. Are you getting the expected performance in other games?

I also second checking GPU utilization and temps with Mangohud.

• UMU as Default on Linux/Steam Deck: Unified Launcher (UMU) is now standard for Proton games. (by @arielj)

…

• Proton-GE as Default: Switched from Wine-GE for better compatibility. (by @arielj)

Nice, hopefully that should further improve game compatibility outside of Steam :)

It sounds like this will be your fist time running Linux. In that case I would recommend against using CachyOS or Arch. Those distros are meant for experienced users that are willing to solve problems on their. In the words of the Arch wiki:

Whereas many GNU/Linux distributions attempt to be more user-friendly, Arch Linux has always been, and shall always remain user-centric. The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users as possible. It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems.

In general, you can have a good gaming experience on almost any distro. The main limitation is probably running brand-new hardware, which can be a bit difficult on some of the slower distros (Debian, Ubuntu LTS, Mint, …). There are only very minor performance differences between distros.

If you’re a new user that wants to use a fast-moving distro with many options for customization, I’d recommend Fedora (e.g. Fedora KDE).

I think it is a disaster and that the lack of long-term API/ABI stability (outside of the kernel) is one of the biggest things holding commercial software on Linux back. It’s much less of an issue for FOSS software, which can easily be recompiled or adapted. However, a lot of people (and companies) want to run proprietary software (e.g. games) on Linux.

This type of breakage causes problems for both developers and users. If you develop software for Linux you need to continously maintain it in order to ensure that it keeps working. And as a user it can mean that software which was working perfectly suddenly no longer works after an upgrade. For example, you may just no longer be able to play any of your older Linux games. If they were built for Windows you can still run them after 20 years, and they probably even work on Linux too.

Forgejo became a hard fork about a year ago: https://forgejo.org/2024-02-forking-forward/ And it seems that migration from Gitea is only possible up to Gitea version 1.22: https://forgejo.org/2024-12-gitea-compatibility/

This seems to be a limitation of Intel host controllers. The USB 2.0 specification (including 12 Mbps Full Speed) allows for up to 127 devices. Each of those devices can have up to 16 IN and 16 OUT endpoints, c.f. https://www.usbmadesimple.co.uk/ums_3.htm Depending on how you count, that would be a maximum of 2k to 4k endpoints in total. I guess Intel thought it wasn’t worthwhile supporting that many endpoints.

Some quick searching turned up this post that claims that USB3 controllers often support up to 254 endpoints (in total). https://www.cambrionix.com/a-quick-guide-to-usb-endpoint-limitations/ Other posters have also said that AMD appears to have higher limits. You could also consider adding more USB root hubs to your system (with PCIe cards).

Unfotunately, I can help you with that. The machine is not running any VMs.

It’s possible, but you should be able to see it quite easily. In my case, the CPU utilization was very low, so the same test should also not be CPU-bottlenecked on your system.