I agree that the Gentoo wiki is almost always better than the Arch wiki (and would recommend it to any user), but i really doubt installing complicated packages is remotely as hard as on Gentoo.

While i have never used Arch before, i did use Manjaro, and there stuff was always just install the package and be done. I never had to alter the Kernel config, and all program features were just there. I also had VMs on Manjaro, and i do not remember any manual configuration (though that was many years ago, so maybe i misremember).

Recently i wanted to encode a video in ffmpeg, but it didn’t work. After a bit of searching i found that the codec requires a use-flag to be set. Classic Gentoo moment.

It’s not that i dislike Gentoo. In fact i do not consider returning to Arch (but i might switch to NixOS if my Gentoo install breaks). But i wouldn’t switch to any other distro.
It’s just that Gentoo is configured in a way that is so minimal by default that even basic use-cases require changes in the Kernel config: systemd? Kernel config. Bluetooth? Kernel config. LUKS? Kernel config. Amdgpu? Yes, exactly. BTRFS? Yes. Blender? Yeah OK, that goes without kernel config.
And the worst about the Kernel config: You don’t know which values are set by default. You might just end up in nconfig realizing that the values were already set.

Then there is the instability in the distKernel (which i use). I think i started with Kernel 5.10LTS ish. Every upgrade went well until like 6.1 LTS, when Emerge complained about i think module ordering or something. It would not emerge a newer Kernel any more, which made me reset my Kernel config and redo it entirely because i thought Kernel 5 and 6 configs might be incompatible. That worked (somehow) until 6.6 LTS, which i wanted to install at version 6.6.6 LTS. But emerge complained it could not install it. I waited and ignored the update, and eventually got trough at version 6.6.20 or so. After that it refused to update again, which made me blacklist all non LTS kernels. I am now on 6.12 LTS, even though i am not a LTS guy, simply because i don’t want the hassle.

And still, after all of this effort for being minimal, it boots in like 20s, while Arch does it in like 3 or so. Gentoo hates me.

The problem with Gentoo is that you can’t install anything in a hurry.

Run VMs on Arch:

1. pacman -S virt-manager
2. Done.

Run VMs on Gentoo?

1. Read the Wiki
2. Find out which USE-Flags you will want
3. Fnd out the dependencies it’s based on (QEMU), read that Wiki entry too
4. See what USE-Flags you want
5. See what Kernel options are needed. Recompile Kernel if changes were necessary.
6. emerge -av app-emulation/virt-manager
7. See if you have read the Wikis of all dependencies.
8. Install.
9. Read the dependencies wikis for how to set things up.
10. Done

Yes, this is an extreme example, but many large packages are a bit like this.
That’s why you will tripple-check if you really need sonething before installing it on Gentoo, or you are like me and install Boxes in a Flatpak instead.

Personally i like Gentoo more than Arch because of all the buttons and knobs, and once it’s set up it does not need more time than Arch, but installing stuff is sometimes hard.

…until the owners of that company realize how much more money they could make by introducing stuff like planned obsolescence.

Humans that have no price are really really rare.

There are 2 kinds of companies:

1. Evil companies
2. Companies that are not evil YET.

What this means in this case is that only your own E-Mail server running on a Raspi in your own home can be considered private or secure in the long run. Unfortunately this is really really hard to do, which is the only reason i have not done it yet.
Personally i do not consider any E-Mail private, because E-Mail is not E2E-encrypted, and 99.9% of times one side of the conversation is going to be hosted on some shady companies servers.

Of course Proton delivers a great service, because they make an insecure protocol a little less insecure, and i personally use Proton mail. Unfortunately their closed-source nature makes it impossible to switch providers without abandoning their great software.

As for services like Drive, they can actually be hosted privately and securely on your own Raspi with stuff like NextCloud/OwnCloud.
For those that can’t/don’t want to self-host, i would recommend paying for a hoster that hosts FOSS software and contributes to it either with money or code. In that case you would probably loose E2E-encryption, but gain the ability to switch providers once your provider turns on you. In that case at least some of your money would continue to offer value to you by having improved the software you are still using.

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.

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.

Here some info about how much and what kind of user data is being sold (GPS position,…), and the legality of it all.

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.

Extracting the keys locked to an TPM is supposed to be impossible, so you do not need to worry about somebody stealing your keys.

TPM sniffing

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.