SpaceCadet

To get basic GPU passthrough working, I mainly followed the Arch Linux guide: https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF

Be warned though that this is just the start of the journey. There are all kinds of issues that you need to deal with and decisions that you need to make if you want to practically use it for gaming, and those require lots of googling, piecing bits of information together from all over the place, and trial and error. From memory these are things I had to deal with:

• How to handle storage? Just a qcow2 file or pass through a partition or drive?
• How to handle mouse and keyboard input? Emulated or through a passed through USB port? Both have their pros and cons.
• Audio is a pain in the ass... emulated it either crackly or laggy. There is a way to pass it through to pipewire through a unix socket, but it's convoluted to setup. Or perhaps you can pass an entire audio device through to your guest?
• Bluetooth audio, for my wireless headset, was an even bigger issue because audio did not get routed correctly to the headset if I just connected to the host. In the end, I got a separate bluetooth dongle for my VM, and passed it through.
• How do you handle the display between guest and host? Two separate monitors? A monitor with dual inputs, and toggle between them? Or something like looking-glass, which sounds appealing but again introduces issues like vrr not working properly, and your GPU will probably need a dummy "dongle" to work without an actual monitor connected.
• Then there's the CPU and how to divide the cores between guest and host: for best performance, the guest's cores need to be reserved, and should take into account the CPU topology. For example, I have a 5900x and reserved the 6 cores on one CCX for my VM , leaving the other 6 for my host.

For more information, there's the /r/VFIO subreddit. Yeah I know, f*** reddit, but it has a lot of useful information. The looking glass site has some FAQs too, even on things not directly related to looking-glass itself. There is some VFIO discussion on the level one forums as well, but they're not so active.

Anyway if all this sounds like a cool project to spend a few weeks on, I heartily recommend you try it. I sure enjoyed setting this all up and getting it working, but I spent way more time configuring and troubleshooting things than I did gaming with that setup, and in the end I decided that just gaming on Proton and occasionally dual booting for problematic games is a much more practical solution.

It does work with AMD GPUs too, I did it with an RX6800XT myself, but there are some (most...) AMD GPUs that have a reset bug which means they hang if you reboot the guest and you need to powercycle the physical host machine to make the GPU usable for the guest again.

"Building with concrete blocks? What is even wrong with you, where you never thought proper construction? What do you mean cheap building costs? People who want to build cheap buildings shouldn't be allowed to build anyway".

The internet suddenly makes a bit more sense to me

That's not GPU passthrough. That just enables VirGL, which is a translation layer that passes some OpenGL calls through to the host's Mesa installation. It has rather poor performance though, it's extremely limited and is rather buggy too. You certainly can't use it for cutting edge gaming.

GPU passthrough is when you pass through an entire GPU device as-is to the virtual machine. That is: if you have an Nvidia RTX 3060, the guest operating system will see an Nvidia RTX 3060 and it can use the native drivers for it. This gives you near-native performance for gaming.

Now, I didn't even know this was possible with VirtualBox (if so: cool!), but it's certainly doable with KVM if you have the right motherboard and GPU combination. I have done it, but it is quite the hassle indeed though that isn't really KVM's fault.

You don't have to choose just one though. It's perfectly ok to share a directory via Samba for Windows clients and share the same directory again with NFS for Linux clients.

Performance of those is atrocious.

100% this

We need a networked file system with real authentication and network encryption that's trivial to set up and that is performant and that preserves unix-ness of the filesystem, meaning nothing weird like smb, so you can just use it as you would a local filesystem.

The OpenSSH of network filesystems basically.

one could say RH is leaching on FOSS projects anyway

Not "one could say", that's exactly how it is.

Red Hat is standing on the shoulders of thousands of FOSS projects, and all that is asked in return is that they should allow others to stand on their shoulders too.

Heartbleed existed for two years before being noticed

That's a different scenario. That was an inadvertently introduced bug, not a deliberately installed backdoor. So the bad guys didn't have two years to exploit it because they didn't know about it either.

It's also not new that very old bugs get discovered. Just a few years ago a 24 year old bug was discovered in the Linux kernel.

In the fallout, we learn a little bit about mental health in open source.

Reminded me of this, relevant as always, xkcd:

It is the most popular lemmy instance though, so them banning a community like this is quite impactful.

IIRC they banned piracy@lemmy.dbzer0.com months ago. Not sure why it pops up again in the modlog. It was the reason I left lemmy.world.