Maybe a dev just right click propertied their folder and typed that in haha. I think it's probably downloaded and cached community content. Unless it's a hint at new danger zone stuff
Bought include both storage for downloaded compressed archives and then to unpack before deleting them?
I’ve run into this when updating games where I have the game installed and enough space for the update but not enough for that middle ground when it’s getting unpacked
A lot of people came to lemmy because it is open source and will NEVER have the monetization issues reddit has (because hosting and development becomes free if you are open source, I guess?).
So we basically have a LOT of people who are the equivalent of a comp sci 101 kid learning that linux exists and insisting that is the answer to all problems and wanting to show off how much cooler they are.
Personally? I prefer FOSS when it is viable. But I am also not going to go too crazy over using a closed source app or driver to… better play my closed source games that I installed via my closed source Steam client.
But also: Honestly, a few rsync scripts running as part of a cron job handles most of this. Because most games I play are through Steam so they already have save file sync. Which mostly leaves my emulator saves and what not.
@Puzzle_Sluts_4Ever@V0lD personally, I use systemd timers, in combination with the btrfs tooling to backup certain snapshots of my filesystem, which include game saves. I can't use steam because it's entirely screenreader inaccessible, so I play stuff with retroarch and other emulators, plus the occasional audiogame in wine, and very rarely, native ones, those are so rare.
Yeah, a lot of lemmy users were already into free software as a whole and liked lemmy because it’s libre and federated. So it’s only natural you see the focus on software freedom everywhere.
I just think that we should strive to use libre alternatives, especially when they are as useful/better than closed source ones.
The philosophical side of free software is much more important to me than anything else. For me, it’s not just about using open source software for the sake of it. It’s about software freedom.
But I don’t go around telling everyone to use open source or die. If you just don’t like the libre alternative and prefer using closed source software, whatever. If there isn’t a general reason to use a closed source software, I’ll just point out the libre alternative (or try to convince that a somewhat inferior libre alternative may not be that bad) :)
Its reliance on PCGW is problematic. Anyone can edit it and there are cases of the wiki paths being wildly incorrect. Good luck finding the config of the Game Pass version of Starfield at this location.
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.
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.
linux_gaming
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.