Second this. Tumbleweed is a great distro. Nearly everything you’ll need can be found in default repos. Then there are several endorsed (semi) official add-on repos, and if that fails there’s always OBS (opi is your friend for searching those).

Daily rsync to a local nas and weekly backups to offsite with pika-backup.

Excellent article. That’s why I use OSS first and foremost as they don’t have the incentive to bring in € instead they are more focused on a quality product.

It is against the GDPR.

In the EU this kind of automatic opting-in to marketing/data sharing is against the GDPR as it requires explicit consent from user/customer. I’m in the EU and have those settings but they were both toggled off, as expected.

I stand corrected. I use Tumbleweed so have not kept up to date on that front.

OpenSuse is already by itself a well rounded distro. It supports multiple desktops out-of-the-box, is highly customizable so it doesn’t really need forks.

SUSE Linux Enterprise isn’t really a fork. OpenSuse Leap is to SLE a bit like Fedora is to Red Hat i.e. the community version which is then frozen at some point to build SLE.

It is. It’s a rolling release so it has the latest packages. It’s not bleeding edge like arch. All software goes thru an automatic testing in OpenQA before they are allowed in the repo so there’s some quality control. It’s also very stable.

I’m on the Other category, both for home and work. I use Tumbleweed in both.

I’m in the EU and that section in the settings isn’t even there. I guess they aren’t doing it here, for now at least. Probably due to GDPR.

Have you tried Okular?

Valve releasing Proton.

Whatsapp uses the same protocol as signal so MITM is unlikely however there’s no way to know what happens before or after the messages are encrypted/decrypted and sent. They can do that scanning at that stage.

That is different than Signal which (unless they changed something with the profiles thing) was always P2P E2EE. You’re sending encrypted messages directly to the other persons phone, not to a server.

Sender cannot know where the recipient is and using P2P would be resource consuming on all client devices (i.e. everyone who uses Signal) so I guess the messages are routed thru Signal’s servers though messages are encrypted on device with keys that only the messaging parties know (couldn’t find an official diagram for this to confirm).

In a country with good consumer rights, this would be a valid reason to return it and get a replacement or refund: It’s no longer offering functionality that was advertised and that you paid for as part of the purchase price.

In the EU this would probably be a no-brainer.

Wonder how they’d manage that as they both are E2EE.

Here’s a good list: https://github.com/morrownr/USB-WiFi/blob/main/home/USB_WiFi_Adapters_that_are_supported_with_Linux_in-kernel_drivers.md

It can’t be removed. That info comes straight from the hardware itself (UEFI and individual devices).

This didn’t seem to occur in Windows, but I’m pretty sure the copy process was also slower so guessing it’s some sort of buffer or heat quirk that 'nix didn’t account for in the more generic driver

If the device says it’s a generic storage device (to the system that is) but actually isn’t (based on your description) then it’s 100% devices fault and not a Linux fault.

This command won’t show the real values when using btrfs. You need to use sudo btrfs filesystem usage <mount point>.