SpaceCadet

Don't you control your dhcp server?

It was a bit rocky coming over from Plasma 5, but settled in nicely now.

Oh and don’t forget to take backups of your /home. Thats good practice for every desktop environment.

The config files of the major desktop environments have become a mess though. Plasma absolutely shits files all over ~/.config and /.local/share where they sit mingled together with the config files of all your other applications and most of it is thoroughly undocumented. I've been in the situation where I wanted to restore a previous state of my Plasma desktop from my backups or just start with a clean default desktop and there is just no straightforward way to do that, short of nuking all your configurations.

Doing a quick find query in my current home directory, there are 57 directories and 79 config files that have either plasma or kde in the name, and that doesn't even include all the /.config/* files belonging to plasma or kde components that don't have it in their name explicitly (e.g. dolphinrc, katerc, kwinrc, powerdevilrc, bluedevilglobalrc , ...)

It was much simpler in the old days when you just had something like a ~/.fvwmrc file that was easy to backup and restore, even early kde used to store everything together in a ~/.kde directory.

apt purge nano is one of the first things I do on a new Debian installation. Much easier to remember than having to use update-alternatives, select-editor and the $EDITOR variable to convince the likes of vigr,vipw, visudo,crontab -e,... that I really want to use vim as my primary editor.

Not really, because you're now going to make it do more, i.e. incorporate the functionality of sudo and expose it to user input. So unless you can prove that the newly written code is somehow inherently more secure than sudo's existing code, the attack surface is exactly the same.

The attack surface will be a systemd daemon running with UID=0 instead, because how else are you going to hand out root privileges?

So it doesn't really change anything to the attack surface, it just moves it to a different location.

We are talking about LTS distros, not about bridges. The context is pretty clear.

That's a you problem. Your interpretation is wrong.

Quoting from the Debian Manual:

This is what Debian's Stable name means: that, once released, the operating system remains relatively unchanging over time.

Stable means unchanging in this context.

Just go Debian.

Ubuntu used to bring a bit of spit and polish at a time when most Linux distros lacked that. Nowadays it brings nothing worthwhile to the table anymore, it's just brand recognition, but what it does bring is aggravation for experienced users.

I had this realization a few years ago when I found myself fighting against 20.04 and I asked myself: what exactly is Ubuntu doing for me that plain Debian can't? The answer was nothing really, so I moved all my Ubuntu VMs over to Debian Bullseye and never looked back.

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.