I believe 3.0 finally moved to Python 3. Resynthesizer was also totally rewritten for 3.0, but I don’t think it’s in Python anymore (?).

Post system specs here just to be safe. If it’s an older machine, there could be various hardware failures. “Monitors” makes it sound like a desktop, but you should clarify just to be safe, and perhaps indicate if has PCIe slots or is more of a mini PC.

Also, what do you mean by “monitors going dark”? Are the backlights on, or are they absolutely dark?

It’s probably not Secure Boot. I mean, worth a test, but it sounds like the issue occurs in the middle of a running session, which is not consistent with the issues sometimes presented by Secure Boot.

It’s solidly okay. I wish it were in brush form like Photoshop was, and I wish it were better-optimized; it’s written in Python and a bit slow. I think Photoshop GPU accelerates this.

Still, usable for a lot of things.

I usually use my device’s native boot menu these days; booting through GRUB usually triggers the Bitlocker screen.

Sounds like a freak accident rather than the fault of the VM.

I literally use a GPU for passthrough on my Windows 10 (and macOS) VM; PCIe is a much more complex protocol and much easier to F up than USB.

I’ve used my iPhone many times through Windows and been fine, as well as whole USB keyboards and mice (just simple ones); I think I might have even updated an iOS device once, though I can’t remember if I actually did. I’ve also used an iPod Nano 7th through an 11 LTSC VM before.

I could see some things being a little finicky, but simply managing a Zune with a VM probably causes no issues. It’s probably been eons since it got a firmware upgrade anyway.

That’s just a VM running atop Docker container; convenient, perhaps, but a little misleading to users who don’t understand how Docker works and might think it’s better performance-wise than a VM.

Dual boot isn’t that bad if you just use separate drives; the issue is only with Windows and Linux on one drive.

It’s not possible on all devices, but my laptop has dual NVMe slots, and I used to boot Linux off an SATA SSD and Windows off an NVMe on my desktop before getting rid of Windows and moving my Linux install to the NVMe drive. Never had a problem.

The only hiccup you’ll probably run into is exorbitant storage prices, although you can probably opt for less storage (256GB or 512GB), you can still get well below $100 and have it be perfectly fine.

It might be possible, depending on if the screen is connected to the dGPU or iGPU (I’d guess iGPU). I wouldn’t know because I did my setup on a desktop with two dGPUs. I would think it’s possible, but you might need an external monitor (?). I don’t know how Optimus laptops are wired.

Where I started for GPU passthrough, which got me ~90% of the way there, is https://github.com/bryansteiner/gpu-passthrough-tutorial . Gives you the shell scripts, XML, etcetera needed to do it; I had to modify some bits (some of which you can see in issues), but this is my preferred tutorial. Basically, try it, get really frustrated, take a break for a while, get back to it and keep tinkering with it (check permissions, logs, PCIe driver binds, etcetera), and eventually, you’ll figure it out.

https://github.com/mysteryx93/GPU-Passthrough-with-Optimus-Manager-Guide is linked in one of the issues and specifically concerns your kind of laptop.

I might be able to send over some of my XML to get you started, but I don’t know how helpful that will actually be over the tutorial, as our systems are completely different, and the AMD GPU I use has different bugs/quirks when doing this than Nvidia ones. The truth of the matter on why there’s not really a single-click, easy way to do GPU passthrough is because each system is unique, from the motherboard PCIe implementation to bugs in GPU firmware. That doesn’t mean you shouldn’t try, but it takes a bit of ingenuity.

To be fair, I’ve heard Wii U isn’t particularly pleasant running Linux either. I’ve never run Linux on my homebrewed Wii U, but someone in my Linux Users Group brought theirs in once.

The Adobe installer doesn’t run on Wine; someone got a recent version of Photoshop running once, but it’s a pirated version and it’s super buggy.

You can’t use Windows as a Docker container. Docker containers are not running full operating systems; they just run software on top of the current kernel but isolated from the main userspace, making it look to programs inside the container as if it’s a separate system. Anything that claims to be a “Windows Docker container” is just running a VM in a Docker container, which falls into the same pitfalls.

Unlike what others say, a bog standard VM might be the wrong choice depending on which features you use due to lack of graphics acceleration in said VM.

You might be able to get GPU passthrough working on a VM, which I have, with both a Windows and macOS VM that can use the GPU (not at the same time); however, this is really complex (took me ages the first time, though I’ve since discovered tricks to make it a bit easier), and you have to have dual GPUs. Single GPU passthrough is technically possible, but then you can’t use your Linux DE while using the VM. I will say, though, that once it’s set up, it’s a better experience than dual-booting; you get to run graphics-intensive Windows apps quite snappily on one monitor (or monitor input) and use your Linux desktop on the other.

Honestly, it’s just a search engine search away, a pretty well-covered thing.

Here’s this for starters: https://wii.hacks.guide/

It’s basically jailbreaking the console, after which you can run pretty much anything that the console has the power for, including the Linux kernel.

The GPU driver issue would really only be a problem for Nvidia stuff.

For me, as long as Debian still packages it and disables these features, I’ll be fine, but LibreWolf looks more and more tempting these days, and having tried it a bit, I can live with the minor annoyances.

I feel like it was more than the package manager whining; I think xorg literally wouldn’t start after the update, although it’s been so long now that I could be misremembering.

Honestly, I probably could have salvaged the install if I’d wanted to without too much difficulty, but it was just a VM for testing distro packaging rather than a daily driver device.

Still, what you say is good to know, and perhaps I should hold back on the Pacman slander. I’ve just been using Debian for around 4 years now and had pretty good reliability; then again, Debian (and most distros, with their pitiful documentation) would probably be very hard to use without Archwiki.

Eh, I disagree with you on Pacman. It could be possible I was doing something stupid, but I’ve had Arch VMs where I didn’t open them for three months, and when I tried to update them I got a colossally messed up install.

I just made a new VM, as I really only need it when I need to make sure a package has the correct dependencies on Arch.

Eh; testing doesn’t break THAT often. Having used it on many of my devices for almost 4 years, I can count on one hand the number of times it broke in a way I had to chroot in to fix it.

This is very unlikely to be because they are using testing.

Still, using Debian Stable is probably a smarter idea for this user.

I like using this on my desktop, but it’s way too easy to trigger this by accident on a laptop, so I disable it on there.

My best guess is that it’s not a Flatpak permissions issue as others are claiming; the software is just trying to use your iGPU (which is usually crappy) instead of your dGPU.

Try taking whatever command you use to start the program and tacking DRI_PRIME=1 on the front. This has often worked for me on applications regardless of whether they’re native or Flatpak.