yote_zip

@yote_zip@pawb.social

• ⁨Comment⁩ on ⁨[deleted]⁩ ⁨⁨7⁩ ⁨months⁩ ago⁩:

  That was my takeaway from this video as well. It was a lot of “aw shucks can’t we all just get along” and not understanding that in today’s world, getting along is a left-wing policy. I think there is still merit to saying that part of the reason we’re so divided nowadays is that we are forced to interact more often, but it shouldn’t be represented as the entire problem. In a way, I think a video like this is actually worse for discourse because it might convince people that there is only one problem that needs to be solved.

• ⁨Comment⁩ on ⁨The amount of communities I need to block to not see the same old stuff over and over again⁩ ⁨⁨7⁩ ⁨months⁩ ago⁩:

  The real problem is that everyone is using the “All” tab as a content feed. Ideally everyone would subscribe to communities and then they wouldn’t have to worry about seeing things they don’t want to see. Lemmy needs to be bigger before we can break that anti-pattern.

• ⁨Comment⁩ on ⁨[deleted]⁩ ⁨⁨7⁩ ⁨months⁩ ago⁩:

  There’s more discussion about this here and here.

• ⁨Comment⁩ on ⁨[PSA] Swapping your Deck's filesystem to Btrfs is easy to do, and can give you more space for free⁩ ⁨⁨9⁩ ⁨months⁩ ago⁩:

  I’m interested to see that reported somewhere - the duperemove repo might be a good starting point as that’s generally the standard BTRFS dedupe solution. I don’t currently see any issues on the GitHub repo about corruption (or at least the last one was 7 years ago). Again, I’m not sure if a RAM bit flip could cause this during a dedupe. Just because you scrubbed, deduped, and scrubbed again doesn’t mean there wasn’t a bit flip during the dedupe.

  As for btrfs-check vs fsck, there are just way fewer things that need to be repaired in BTRFS and ZFS because they are copy-on-write (ZFS doesn’t even have a fsck at all!). Because Ext4 is not Copy-On-Write, it’s highly vulnerable to powerloss events, and an fsck is required to replay the journal when this happens. BTRFS and ZFS make atomic COW transactions and will never be in a state of corruption on power loss. The other part of fsck is repairing the filesystem, which BTRFS and ZFS do through scrub and/or auto-heal on read instead. ZFS and BTRFS keep multiple copies of the filesystem metadata so that it can auto-repair itself while online. btrfs check is not something that should be used lightly, and I’ve seen a lot of people just run btrfs-check --repair expecting the same behavior as fsck, then wonder why they ended up with a broken filesystem.

• ⁨Comment⁩ on ⁨[PSA] Swapping your Deck's filesystem to Btrfs is easy to do, and can give you more space for free⁩ ⁨⁨9⁩ ⁨months⁩ ago⁩:

  What deduplication program did you use? Deduplication is not technically an end-to-end supported feature, and depending on how the third-party program implemented it there could be issues earlier in the pipeline. I’m also not sure how a RAM bit flip would interact in this scenario - I know ZFS checks the file checksum several times during transaction but I don’t know how often BTRFS does.

  The problem is that there are a lot of people online reporting vague problems with BTRFS, but all reports have little info on how they were actually caused and are not able to be reproduced. There is no solution if we’re operating under these rules, other than to completely stop using BTRFS out of pure superstition. If there are bugs we need to be able to point to the bugs in order to fix them. As I said before, this problem you had would not have even been detected by Ext4, so I think error reporting is biased against a FS that actually checks its work. W/r/t to checking work, I think ZFS gets away with a lot more because it’s normally run in RAID setups, where healing happens automatically. BTRFS, lacking RAID5/6 support, is usually just run on a single drive, and any data integrity error becomes a target of frustration as soon as it happens.

• ⁨Comment⁩ on ⁨[PSA] Swapping your Deck's filesystem to Btrfs is easy to do, and can give you more space for free⁩ ⁨⁨9⁩ ⁨months⁩ ago⁩:

  The filesystem metadata comes with 2 copies that can heal each other, and Copy-on-Write protects against power loss. The filesystem itself should be bulletproof.

  I feel like people reporting data loss on BTRFS are unaware that at least BTRFS is actually measuring the data loss. Bitrot is not rare, especially with how big our drives are getting. If you care about your data it should be backed up and/or RAIDed. Ext4 has no idea if your data is still intact - that’s not the same as no data loss.

• ⁨Comment⁩ on ⁨[PSA] Swapping your Deck's filesystem to Btrfs is easy to do, and can give you more space for free⁩ ⁨⁨9⁩ ⁨months⁩ ago⁩:

  I noticed this guide recommends compress-force=zstd, which sets the ZSTD compression to level 3. There’s a BTRFS benchmark and ZFS benchmark of the ZSTD levels which can give a rough idea of how ZSTD performs for transparent filesystem compression. Note that almost all of ZSTD’s compression gains happen starting at level 1, and levels after that have very minor improvements.

  Also keep in mind that ZSTD levels only affect how long it takes to write new data to the filesystem. ZSTD is somewhat unique as a compression algorithm in that as you increase compression effort, the decompression effort stays the same. You could compress everything with level 23 and it will decompress just as fast as level 1 (~generally). Setting higher ZSTD levels could arguably make more sense for a gaming drive because the data is usually write-once, read-many. I don’t know at what level the Steam Deck CPU will limiting your I/O though.

  BTRFS compression is enabled per-file, so you can change ZSTD levels at any time and old data will still be compressed with your previous algorithm. To recompress using a new level, change your /etc/fstab/ ZSTD level and remount the partition, then run a defrag to poke the data into recompression.

• ⁨Comment⁩ on ⁨Skyrim texture mods on Steam Deck⁩ ⁨⁨10⁩ ⁨months⁩ ago⁩:

  1GB is nothing - I would be surprised if that’s the most you can get. As for mod managers I’m not sure how best to do it on a Steam Deck. You can get Mod Organizer working tmk, but it’s not native. I’m not sure what the built-in mod manager is but yeah I would stick with Vortex and MO2

• ⁨Comment⁩ on ⁨Skyrim texture mods on Steam Deck⁩ ⁨⁨10⁩ ⁨months⁩ ago⁩:

  Textures are a little weird because they don’t affect performance how you might expect. Once you load a texture into memory, it doesn’t take any effort to keep displaying it. The main ways textures will impact performance is the time it takes to actually load them - typically through game startup or loading screens. In theory you can also run into stutters while trying to load textures on the fly, e.g. Skyrim loads objects in a cell system, so you’re always loading the next thing in front of you as you walk. If your big textures get paged in and out too much you might notice it.

  For the Steam Deck’s purposes, this basically means that as long as you have enough VRAM to load all those textures, they’re basically free to install. Bad things will probably start happening if you run out of VRAM though. There’s probably a way to configure the MangoHud onboard the Steam Deck to show how much RAM+VRAM you’re using at any given point. If you have enough headroom, I would feel free to install some texture packs and maybe give them a few stress tests in a city or etc.