Suffering is bad, and the intentional or neglient creation of suffering is evil.

Those that have created suffering have done evil, and those that are currently creating suffering, or plan to create suffering are evil. The larger the suffering, the greater the evil.

Those that have done evil, but are no longer willing to do evil are not evil.

In the end, evil is a simplification that allows us to take power from those that want to create suffering without needing to know what exactly they are doing or planning.

Personally, i have never experienced problems while reading from USB sticks, but i have while writing. I have a 15+ years old USB2 stick and a new USB3.x stick. The USB2 stick writes with constant ~20MB/s, while USB3 is all over the place between 200MB/s and ~0.1MB/s. Unusable for me. For a while i used external HDDs and SSDs over USB3, as they somehow run without problems, but they are cumbersome and expensive.

Therefore i have switched to transfer files over the network (for large files i plug in Ethernet) using KDE connect. Unfortunately it can not send folders (yet), so i would .tar them before sending, and untar them after.

LocalSend would also be an option. Maybe that can do folders natively.

When your router’s chips are made in China, flashed in China with closed source firmware and the money you pay goes to Chinese companies, then it’s backdoored.

When your router’s chips are made in China, flashed in China with closed source firmware and the money you pay goes to American companies, it’s bulletproof.

Just open your “secure” “American” router and look where they are made and flashed. I bet it’s not USA.

I am running BTRFS on multiple PCs and Laptops since about 8-10 years ago, and i had 2 incidents:

1. Cheap SSD: BTRFS reported errors, half a year later the SSD failed and never worked again.
2. Unstable RAM: BTRFS reported errors, i did a memtest and found RAM was unstable.

I am using BTRFS RAID0 since about 6 years. Even there, i had 0 issues. In all those years BTRFS snapshoting has saved me countless hours when i accidentially misconfigured a program or did a accidential rm -r ~/xyz.

For me the real risk in BTRFS comes from snapper, which takes snapshots even when the disk is almost full. This has resulted in multiple systems not booting because there was no space left. That’s why i prefer Timeshift for anything but my main PC.

Tipps to prevent future accidents:

• Set up BTRFS snapshots with Timeshift or Snapper. Switching to BTRFS is worth it for snapshots alone.
• Do regular backups on a device that can not be reached by rm: vorta local on external hdd that you connect once a week OR vorta/borg2 to a NAS/Server that does BTRFS snapshots itself OR Nextcloud to sync to a server that has a trashbin OR git to a server. Just remember that Nextcloud and git are unencrypted, so the server has to be secure and trustworthy. Vorta and borg2 can be set up with encryption.

Mistakes are unpreventable due to our error-prone brains, but it is a choice to repeat them.

If you are having sensitive information stored using closed-source software/OS, you can stop reading right here. This is your biggest vulnerability and the best thing you can do is to switch to FOSS.

For those that have already switched:
It made me think about how to improve the resistance of large FOSS projects against state-sponsored attackers injecting backdoors.

The best thing i came up with would be to have each contribution checked by a contributor of a rival state. So a Russian (or Chinese) contributor verifies a contribution by an American.
The verifying contributors would have to be chosen at random in a way that is not predeterminable by an attacker, otherwise a Chinese-state contributor will contribute harmless code until the next verifier will be a US-based Chinese spy. Then they will submit a backdoor and have it checked by an American citizen paid by China.
Also the random number generator has to be verifiable by outsiders, otherwise a spy in the Linux-Foundation can manipulate the outcome of choosing a favorable verifier for a backdoor.

This can obviously only be done as long as there are lots of contributors from rivaling states. If the US decided that Linux can only allow contributors from USA/EU, then this model can not work and Linux would have to relocate into a more favorable state like Switzerland.

What one should keep in mind that even if the US would ban all foreign contributions and the foundation would not relocate, Linux would still be more secure than any closed source OS, as those foreigners can still look at the code and blow the whistle on bugs/backdoors. It would however be much more insecure than it is now, as the overhead for finding bugs/backdoors would be much larger.