Ooops

The majority of "Linux issues" is created intentionally. It's often not enough to not support Linux officially (even if there would be no additional work involved anyway) and let players figure out problems on their own. A lot of studios, publishers and developers actually go out of their way and actively invest time to block Linux.

So nothing will obviously change. Windows could run on a fully compatible Linux kernel tomorrow and games would still check for Linux to artificially create issues.

with Apple dominating Europe...

Your own map diagrees, with 100% of the picked examples from Europe having Samsung as market leader.

Stick to a specific distro and train your staff

Linux is Linux. Train your staff to properly use one and they can use them all. "Distro" is just a fancy word for "which package manager and update cycle to we chose and what logo do we put on our pre-installed wallpaper".

Yes, I actually just use Wine with a default prefix and pray it works. If it doesn't (rarely) then the game gets his own prefix to tweak the settings.

you didn’t say what file system your /boot partition was using, so I don’t want to guess

It's actually easy to guess. There is exactly one filesystem UEFI has to support by its specification, everything else is optional... so unless you produce for Apple -because they demand apfs support for their hardware- no vendor actually cares to implement anything but FAT.

When you say system drive this will also have your efi system partition (usually FAT-formated as that's the only standard all UEFI implementations support), maybe also a swap partition (if not using a swap file instead) etc... so it's not just copiying the btrfs partition your system sits on.

Yes clonezilla will keep the same UUID when cloning (and I assume your fstab properly uses UUIDs to identify drivees). In fact clonezilla uses different tools depending on filesystem and data... on the lowest level (so for example on unlocked encrypted data it can't handle otherwise) clonezilla is really just using dd to clone everything. So cloning your disk with clonezilla, then later expanding the btrfs partition to use up the free space works is an option

But on the other hand just creating a few new partitions, then copying all data might be faster. And editing /etc/fstab with the new UUIDs while keeping everything else is no rocket science either.

The best thing: Just pick a method and do it. It's not like you can screw up it up as long if your are not stupid and accidently clone your empty new drive to your old one instead...

misinformation != desinformation

Both exist plenty...

And just lke with the war on drugs, countries will realize it's a lost cause. And will then instead try to coopt the system to spread their own desinformation. If you can't win, exploit it for your own gains...

Welcome to our wonderful post-factual age.

Btrfs can mostly fo everything you would normaly use LVN or raid for natively.

Btrfs raid0 lets you combine any number of differently sized drives into one (just without the speed boost of traditional raid0 because with flexible drive sizes data is not symmetrical striped). And btrfs raid1 keeps every data duplicated, again with flexible number and sizes of drive (also with metadata on every drive).

The sytemd hooks (instead of the traditional busybox ones) then manage the one other task you use LVM for: unlocking multiple partitons (for example multiple raid partitons and swap) with just one password. Because the systemd encrypt function tries unlooking all luks partitions it finds with the first password provided and only asks for passwords for each partition if that doesn't work.

PS: btrfs subvolumes are already flexible in size and don't need predefined sizes. So the only things that need to be created separately are non-btrfs stuff like the efi system partition or a physical swap (which you can also skip by using a swap file instead of a partition).

BTRFS raid on LUKS-encrypted devices (no LVM, all unlocked with one password via SystemD encrypt hooks).

The main trash you accumulate are config files in you home directory because they stay after the package is uninstalled. And they just sit there not hurting anybody.

Which is a good point to remind people to install pacman-contrib and make running pacdiff regularly a habit...