stuner

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.

Gnome and KDE are not doing the same thing.

KDE will continue to offer an X11 session for the time being:

Current status: Plasma’s X11 session continues to be maintained.

https://pointieststick.com/2025/06/21/about-plasmas-x11-session/

Gnome will disable the X11 session in the next release and then remove the code:

The most likely scenario is that all the X11 session code stays disabled by default for 49 with a planned removal for GNOME 50.

https://blogs.gnome.org/alatiera/2025/06/08/the-x11-session-removal/

I'm not quite sure what you're trying to do here. Are you

1. Trying to create a new owncloud instance and put your data somewhere other than in /var, or
2. Try to move the data location of an existing owncloud instance?

If you're trying to do the second one, there's a useful guide on it here: https://omiid.me/notebook/25/move-docker-volume-to-bind-mount. The first one should be even simpler, you can just replace the volumes in the compose file by bind mounts (basically, just this step of the tutorial: https://omiid.me/notebook/25/move-docker-volume-to-bind-mount#modifying-docker-compose).

Yeah, that seems quite weird and not customer friendly at all. I was wondering if it has something to do with Steam's in-game purchase conditions (mostly the fee).

Players can only access the lowest rank of competitive gameplay for free, and access to any higher levels costs a subscription fee of $2.50 a month. That's right, you'll need a subscription to play GeoGuessr on Steam, for some reason.

Not only is this price point bizarre for a game that you can literally just hop into similar browser versions and play for free, but [...]

GeoGuessr has required a subscription to actually play for a while now. I think they had a very limited Free tier until 2024, but it was not a great experience. The developers claim that they need to charge a subscription fee because they need to pay Google for the Streetview API access. To me, that seems plausible and would justify a subscription model (as opposed to a one-time purchase).

On the other hand, OpenGuessr seems to be a free alternative that offers a very similar game. That certainly seems like a better alternative if it's sustainable.

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.