SpaceCadet

Binaries in the former are installed by the OS/package manager, binaries in the latter are installed manually by the user, for example by compiling from source and running make install

100% possible with a Windows 10 guest in kvm/libvirt.

You can connect the disk to your Linux system, and then pass through the disk's entire block device to the VM. Windows will see the device as an actual disk, and you can perform your repairs that way. I have something like this in my domain definition to pass through my game drive to my Windows 10 VM: https://pastebin.com/GzuvMTWP

I can even use the manufacturer's SSD maintenance tool from my VM.

Edit: lemmy doesn't seem to like XML in code blocks, so used pastebin instead.

So little is done by others that, if Red Hat stops, Xorg is effectively done.

Source?

As far as I know the X.org foundation is an independent non-profit organization, and while Red Hat is a sponsor and they have 1 member in the board of directors (out of 8), they don't appear to be the main contributor.

Who made Red Hat the arbiter of when xorg should end?

I mean, sure they're a major Linux vendor but their market is servers with hardly any foothold in the desktop market. It would be more interesting to see how long Debian, Ubuntu or Arch will keep xorg alive.

Just use rsync -va

NO STOP!

The default quick check algorithm of rsync is not safe for this. It only checks filesize and modification time to determine if files are equal. After a b0rked copy, these are not to be trusted.

You should add the -c flag so that files are properly checksummed, unfortunately if you have slow storage on either end, this often negates the speed advantage of rsync.

For example, consider this example:

mkdir source
mkdir destination
echo "hello" > source/file.txt
echo "world" > destination/file.txt
touch -r source/file.txt destination/file.txt
rsync -avh source/ destination/
cat source/file.txt
cat destination/file.txt

Contrary to what you might expect, the rsync command copies nothing and the output at the end will show:

hello
world

If you change the rsync command in the example above to rsync -c -avh source/ destination/, it will work as expected.

Trim support is standard. Any kernel released in the past 15 years or so will have trim support built in. So that's not something you should worry about.

How trimming is triggered is another matter, and is distro dependent. On Arch and Debian at least there is a weekly systemd timer that runs the fstrim command on all trimmable filesystems. You can check it if's enabled with: systemctl list-unit-files fstrim.timer. I can't tell how other distributions handle that. On Debian derived ones, I imagine it's similar, on something like Slackware, which is systemd-less and more hands-off in its approach, you may have to schedule fstrim yourself, or run it manually occasionally.

There is also the discard mount option that you can add in /etc/fstab, which enables automatic synchronous trimming every time blocks are deleted, but its use is discouraged because it carries a performance penalty.

Hope that answers your question.