Sonotsugipaa

I don't know how this would be useful to someone reading the cheat sheet, but here's something interesting I just indirectly found out while skimming it through:

Ctrl+D does the same thing as ENTER, except the latter additionally sends the end-of-line character to the reader while the former sends nothing;
as is the case for shells or interactive programs like the Python REPL, Ctrl+D causes them to terminate only because it sends a string that is 0 characters long, and 0-size reads are universally interpreted as files reaching the end.

To test this: enter cat, type "hello" without pressing enter, then Ctrl+D: you should see "hellohello".
An extremely rare case of this being useful would be using netcat to send a string somewhere, without sending the end-of-line byte at the end.

GPU passthrough is possible if you only have one, but it's TWO pains in the arse to set up and operate

Tbf the US don't have the best drivers, since driving licenses are so easy to obtain as far as I've heard

If you're frequently creating new containers I suggest the Temporary Containers extension, it saves you having to manually clear everything when you're done with a specific session and want to start another

Firefox containers are basically just named cookie sets: they don't have per-container settings, they just let you create containerized tabs that don't share cookies between each other (maybe local and session storage too, idk).

They're useful if you want to make it a bit harder for websites to track you around, or for selectively keeping you logged into a website (alt account usage comes to mind), but your use case seems to be centered around actual profiles.

I played many games that didn't fit onto either of my SSDs, on an HDD, including Destiny 2 and for a while Baldur's Gate 3 - they had ~70% longer loading times, but they didn't freeze outside of loading screens.

As for recording, you'd be amazed at how filesystem caches are good at what they do

Chris Chan?

Given the automotive slang term for "transmission", I think this one has a chance

Doesn't that increase the degree of control I have over my lungs, if anything?

would I just need to add a RX580 as a PCI host device and run the script after shutting down the vm?

Indeed, although don't just copy-paste the snippet I wrote: I just wrote it on the spot without testing it, you have to tweak it to run the function for the PCI device(s) you have in the IOMMU group of the GPU you want to pass through. In my case it's just 0000:03:00.0 and 0000:03:00.1, perhaps you will also only need two since the GPUs are the same.

You can procrastinate on doing all that, I'm fairly certain nothing will blow up.
Unfortunately my setup is very complex, I hacked together a framework of Zsh scripts that use libvirt hooks - otherwise I would just copy them here.

I didn't mean to say that you must use 0000:05:00.0 specifically, only to follow the rest of the guide without having the script - I'm not sure about identifying the correct device, I did that a long time ago, but I am pretty sure the AL Wiki guide has a way to list GPUs.

The error you get is self-explainatory: along with 0000:05:00.0 (or whatever device), you must also list the ones in the same IOMMU group, which should also be identified along with the PCI device(s) you want to pass through.

EDIT: I skimmed through the guide, apparently it's extremely un-straightforward (gayforward? idk), I'll try to make a director's cut.

The following script should allow you to see how your various PCI devices are mapped to IOMMU groups. If it does not return anything, you either have not enabled IOMMU support properly or your hardware does not support it.

#!/bin/bash
shopt -s nullglob
for g in $(find /sys/kernel/iommu_groups/* -maxdepth 0 -type d | sort -V); do
    echo "IOMMU Group ${g##*/}:"
    for d in $g/devices/*; do
        echo -e "\t$(lspci -nns ${d##*/})"
    done;
done;

Example output:

IOMMU Group 1:
	00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:0151] (rev 09)
IOMMU Group 13:
	06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)
	06:00.1 Audio device: NVIDIA Corporation GM204 High Definition Audio Controller [10de:0fbb] (rev a1)

An IOMMU group is the smallest set of physical devices that can be passed to a virtual machine. For instance, in the example above, both the GPU in 06:00.0 and its audio controller in 6:00.1 belong to IOMMU group 13 and can only be passed together.

As to identifying which of the two is which GPU, your only safe bet is trying to determine which monitor is connected to which PCI device somehow, which I have no idea how to do - I went with trial and error, and hard resets.

Hey, I have two RX580s too!

I'm trying to wrap my head around this problem and I have no idea why a Permission denied would pop up if the script is run at boot, I'm not familiar with the process but I would assume that sh would run as root.

Have you tried following the rest of the guide, and just ignoring the actual VFIO passthrough step in particular? How I found this out is a long story, but apparently on my system libvirt is able to "yank" the GPU from the host and give it to the vfio-pci driver while the system is running, as long as the libvirt domain has the proper <hostdev> in it (or, if you're using virt-manager, you have the PCI 0000:05:00.0 and PCI 0000:05:00.1 thingies set up).

I'm not sure that's supposed to be the case in general, but if that doesn't work for you I don't think your system will explode, if anything you have both GPUs working for the host on boot.

The guide says this:

[...] due to their size and complexity, GPU drivers do not tend to support dynamic rebinding very well, so you cannot just have some GPU you use on the host be transparently passed to a virtual machine without having both drivers conflict with each other. Because of this, it is generally advised to bind those placeholder drivers manually before starting the virtual machine, in order to stop other drivers from attempting to claim it.

The con is that after running the VM, you'd most likely want to reattach the GPU like this:

pcidev0=  # Your passed-through GPU, something like  0000:05:00.0
pcidev1=  #                                          0000:05:00.1
pcidev2=  # ...
pcidevN=  #                                          0000:05:00.N

# You need to do this for all the devices in the IOMMU group
function rm_pci {
   echo 'Removing PCI device '"$1"
   echo -n 1 >/sys/bus/pci/devices/"$1"/remove
}

rm_pci "$pcidev0"
rm_pci "$pcidev1"
# ...
rm_pci "$pcidevN"

echo 'Rescanning PCI devices'
echo -n 1 >/sys/bus/pci/rescan

This is because I've found out the hard way that a GPU managed by the vfio-pci module may or may not spin its fans when it heats up, and if the VFIO GPU is sitting in front of the other one's fans... y'know, heat.
(consider the first paragraph of this comment)

If you manage to give the GPU back to the host via the pseudo scriptlet above, the actual GPU driver will be able to do its job with the fans; the alternatives is rebooting the system, or just assuming that the main GPU doesn't blow 300C° onto the VFIO one while the latter refuses to acknowledge it.

This is what infinite exponential growth does to a mf

... and all the other mfs in the near vicinity