Bo

For question 2, three commands answer nearly everything in this room:

uname -m                 # what this shell is: arm64 or x86_64
file $(which python3)    # what that specific binary contains
file <path-to-the.so>    # the library in the error message

file prints something like Mach-O 64-bit bundle x86_64 or arm64, and a universal binary lists both.

The surprise for a lot of people is the first one. If uname -m says x86_64 on an Apple Silicon Mac, your terminal is running under Rosetta — usually because the app has "Open using Rosetta" ticked in Get Info, which somebody turned on years ago to fix something else. Everything you install from that terminal will then be Intel, silently and consistently.

That one checkbox explains an enormous number of these threads.

Question 2: it changes nothing until something needs it, and that is by design.

Rosetta translates an Intel binary the first time it is launched, caches the result, and gets out of the way. A native ARM application never touches it. There is no background cost, no memory held, no daemon doing work when nothing translated is running.

So installing it is not a performance decision. The only thing it changes is whether an Intel binary runs or produces "bad CPU type in executable".

Which makes the practical answer to 3 fairly clear: there is no technical downside. The reason people hold out is the one you gave — you want to find out when something is not native, rather than have it silently work. That is a legitimate preference and it is about information, not about the machine.

For question 3 — you can have both, and it is better than it used to be.

Modern VirtualBox can run on top of the Hyper-V hypervisor rather than fighting it. It is slower than native, sometimes noticeably, but it works and it means you stop toggling settings and rebooting between tasks. Make sure you are on a current version; the versions where this was broken are exactly the ones people had installed when they wrote the advice to disable Hyper-V.

The other option, if you need VirtualBox at full speed, is to accept the trade and turn the hypervisor off when you need it:

bcdedit /set hypervisorlaunchtype off

WSL then stops working until you set it back to auto. Each change needs a restart, which is the real cost.

Most people are better served by keeping the hypervisor on and using WSL for the Linux workload it is good at, keeping VirtualBox for the cases that genuinely need a full VM.

Removing before reinstalling is the step I have never done — I have always just run the install and hoped. That would explain the times it took two attempts.