You probably have a higher attack surface from the gremlins in your walls. OTOH, Amazon knowing that you use Mullvad is a tangible downside, as they will probably use that to stick you in a marketing group or something. Monero is still an easy solution with the ~same cost if you’re concerned about that.

How would Amazon track a voucher? It’s a physical scratch off code, sealed by Mullvad before they send it over to Amazon. More importantly, if you think that was possible why would Mullvad be unaware of it and/or lie about it? Just go with the vouchers if you want untraceability. They’re also cheaper in USD than other methods IIRC, at $29/6 months and $57/12 months.

I feel piracy for demo purposes is fully justified if you buy it after you like it. People always say vote with your wallet but it’s more like gambling with your wallet if you don’t get to see and touch the product before you make the purchase. Giving proper demos should be more common with digital media.

Usually torrents remain seeded because private tracker users are encouraged to seed everything forever. In addition, often if a private tracker has a bonus system they will offer extra bonus points for seeding low-seed torrents, and some even automatically mark torrents as freeleech if they’re below ~5 seeds, encouraging people to revive its seed count in a targeted manner.

Mirrored vdevs allow growth by adding a pair at a time, yes. Healing works with mirrors, because each of the two disks in a mirror are supposed to have the same data as each other. When a read or scrub happens, if there’s any checksum failures it will replace the failed block on Disk1 with Disk2’s copy of that block.

Many ZFS’ers swear by mirrored vdevs because they give you the best performance, they’re more flexible, and resilvering from a failed mirror disk is an order of magnitude faster than resilvering from a failed RAIDZ - leaving less time for a second disk failure. The big downside is that they eat 50% of your disk capacity. I personally run mirrored vdevs because it’s more flexible for a small home NAS, and I make up for some of the disk inefficiency by being able to buy any-size disks on sale and throw them in whenever I see a good price.

The main problem with self-healing is that ZFS needs to have access to two copies of data, usually solved by having 2+ disks. When you expose an mdadm device ZFS will only perceive one disk and one copy of data, so it won’t try to store 2 copies of data anywhere. Underneath, mdadm will be storing the two copies of data, so any healing would need to be handled by mdadm directly instead. ZFS normally auto-heals when it reads data and when it scrubs, but in this setup mdadm would need to start the healing process through whatever measures it has (probably just scrubbing?)

ZFS can grow if it has extra space on the disk. The obvious answer is that you should really be using RAIDZ2 instead if you are going with ZFS, but I assume you don’t like the inflexibility of RAIDZ resizing. RAIDZ expansion has been merged into OpenZFS, but it will probably take a year or so to actually land in the next release. RAIDZ2 could still be an option if you aren’t planning on growing before it lands. I don’t have much experience with mdadm, but my guess is that with mdadm+ZFS, features like self-healing won’t work because ZFS isn’t aware of the RAID at a low-level. I would expect it to be slightly janky in a lot of ways compared to RAIDZ, and if you still want to try it you may become the foremost expert on the combination.

ZFS without redundancy is not great in the sense that redundancy is ideal in all scenarios, but it’s still a modern filesystem with a lot of good features, just like BTRFS. The main problem will be that it can detect data corruption but not heal it automatically. Transparent compression, snapshotting, data checksums, copy-on-write (power loss resiliency), and reflinking are modern features of both ZFS/BTRFS, and BTRFS additionally offers offline-deduplication, meaning you can deduplicate any data block that exists twice in your pool without incurring the massive resources that ZFS deduplication requires. ZFS is the more mature of the two, and I would use that if you’ve already got ZFS tooling set up on your machine.

Note that the TrueNAS forums spread a lot of FUD about ZFS, but ZFS without redundancy is ok. I would take anything alarmist from there with a grain of salt. BTRFS and ZFS both store 2 copies of all metadata by default, so bitrot will be auto-healed on a filesystem level when it’s read or scrubbed.

Edit: As for write amplification, just use ashift=12 and don’t worry too much about it.

ZFS doesn’t eat your SSD endurance. If anything it is the best option since you can enable ZSTD compression for smaller reads/writes and reads will often come from the RAM-based ARC cache instead of your SSDs. ZFS is also practically allergic to rewriting data that already exists in the pool, so once something is written it should never cost a write again - especially if you’re using OpenZFS 2.2 or above which has reflinking.

My guess is you were reading about SLOG devices, which do need heavier endurance as they replicate every write coming into your HDD array (every synchronous write, anyway). SLOG devices are only useful in HDD pools, and even then they’re not a must-have.

IMO just throw in whatever is cheapest or has your desired performance. Modern SSD write endurance is way better than it used to be and even if you somehow use it all up after a decade, the money you save by buying a cheaper one will pay for the replacement.

I would also recommend using ZFS or BTRFS on the data drive, even without redundancy. These filesystems store checksums of all data so you know if anything has bitrot when you scrub it. XFS/Ext4/etc store your data but they have no idea if it’s still good or not.

More hard drive slots? No problem! Extra vibrations are good for hard drives probably.

gocryptfs which works like this, would be my recommendation. There’s also Cryptomator. They’re both cloud-friendly, so you only need to resync files that actually change.

Note that 100% accuracy on emulators is not always a goal. Super accurate emulators might take more computation/emulation and run slower.

Free egress is bittersweet. IIRC, previously if you ever actually needed your data back it would cost a lot to download. I don’t think this is better on average but it’s not quite a 20% bump considering that.

This also might allow more interesting integrations where you send and receive large data to your store frequently?

It’s completely down to your opinion. Legally I would guess that you’re not allowed to do it, but nowadays we live in a hellscape where we own nothing so I wouldn’t base your moral compass off of the rules that corporations set. Personally if I’ve already bought it somewhere it is mine. They’re lucky I even purchased one copy, they’re not getting anything else from me.

Yeah I really don’t trust GUI package managers yet. I feel like they shouldn’t be that hard to get working properly, but I always seem to get quirky behavior when I try to use them. As for readability apt is one of the worse tools IMO. I’ve been using nala lately and really like how it lays out its operations. Contrast that format to what Linus saw in his video.

Maybe we could have a blacklist of packages/metapackages marked “important” that cause warnings, like xorg, pipewire, pulseaudio, kde-desktop, gnome-desktop, etc. If you’re uninstalling something like that you better hit confirm twice because that’s not typical behavior.

Right, it was clearly LTT’s fault for not reading, but automatic upgrades are the same thing as not reading. I’ve been using Linux for a very long time now, and I’ve seen Apt try to do some very stupid things before. Maybe it’s better nowadays but I don’t know if I’ll ever shake the gut instinct to not allow Apt to do whatever it thinks is right.

Yeah lower usable storage sucks, but it’s an okay trade at the moment given its flexibility. raidz expansion is always “right around the corner” but never actually arrives - if it’s merged a raidz array might make more sense for a smaller NAS.

Personally I’ve found that if you’re really budget-conscious or have a low number of disks, MergerFS+SnapRAID backed by BTRFS disks is a better choice for flexibility (very similar to an Unraid setup), since you can add/remove at any time, and they can be mismatched drive sizes.

Not an expert, but as far as I know running with mismatched drives isn’t bad - it’s just a pointless long-term configuration.

Are you planning on mirroring the drives? If you upgrade to 4 drives in the future you could just do 2 mirror vdevs with mismatched drive sizes per vdev. Also I’m surprised you’re bothering with 6TB drives - you can get 14TB very cheap nowadays (recertified).

I think auto-upgrading Debian Stable is probably the one exception I’d make to “no blind upgrades”, though I still don’t feel comfortable recommending it due to potential dependency/apt problems that could somehow happen. In the case of Debian Stable it barely ever has package upgrades anyway so I’d just do it manually once a week and it would take like 30 seconds to grab 4 packages. If you’re public-facing you might want a tighter system for notifying about security upgrades, or just auto-upgrade security patches.

I’m not a real sysadmin so take it with a grain of salt, but in all reality this is probably why you would choose something like Debian for a server instead a bleeding-edge distro. Debian quickly backports security updates and fixes but otherwise keeps everything else stable and extremely well-tested, which pretty much 100% prevents serious bugs from reaching its Stable branch. You may still need to figure out an appropriate strategy for keeping your Mastodon container updated, but at least the rest of your system isn’t at risk of causing catastrophic errors like this. Also, Debian Stable does allow you to auto-upgrade security patches only, if you still want that functionality.