Char Jackson wrote:
On Wed, 31 Jul 2019 09:04:59 -0500, Rene Lamontagne
wrote:

On 2019-07-30 10:13 p.m., T wrote:
On 7/28/19 7:26 PM, Rene Lamontagne wrote:
Besides I enjoy building and configuring the machines to my liking.
Fire up a VM and you can play to your hears content, but
nothing beats putting together the real thing.

No need for VMs in my case, My Coolermaster CM690 II case has a built in
SSD hot swap bay built into the top, I have 5 120GB Samsung and
Kingston SSDs on which I can install any operating system and slip on
one and reboot into any OS I want in about 2 Minutes.
At the moment I have the following OSs available.

Windows 10 Insider
Windows 7
Linux Mint 19.1
MX Linux 18.3
Xenialpup 7.5
And naturally Windows 10 1903 on one NVMe 512GB

So you see I have the best of all worlds All running on really fast
hardware and within 2 minutes reach. :-)

With VMs, you can have all of them running at the same time, so
switching between them is nearly instantaneous. Programs running in a VM
stay running when you switch the focus away. I find that to be very
handy.

I always have 4-6 VMs running, and depending on the project(s) I'm
working on, I may have 20-24 VMs running. That's for work purposes,
though. If I wasn't using them for work, I'd probably only have about 4
running. Once you go VM, you'll never ever go back to multiboot.

VMs are good, as long as the emulation is decent.

VirtualBox has poor UEFI support, and cannot really be used
for debugging UEFI problems.

Consequently, for those situations, I have to go back to
physical installs. Which isn't exactly pleasant by comparison.

The BIOS emulations in virtual machine environments, are like
a western town facade. You see a "second floor" on the buildings,
but there is nothing behind the second floor facade. It's empty.
Well, that's kind of what UEFI is like in VirtualBox. Installers
don't do exactly the same thing in the VirtualBox environment,
because the UEFI code isn't "mature". If I try to do a dual boot,
the EFI resources get put in the wrong folders.

The BIOS in one other VM environment was like that, with
legacy BIOS bugs that would bite you in the ass occasionally.
And yet, they were not interested in fixing it. It seems
once a BIOS emulation "doesn't crash", they ship it...
There is no "continuous improvement" model for the
VM BIOS behavior.

As an example of a legacy BIOS bug, when the OS was
considering the "SoundBlaster audio emulation", it
would compute the checksum of some bytes in the
emulated hardware, and get the wrong value. And I
would see, like a thousand times "disabling audio
because checksum is blah blah blah". In other words,
the bug in the emulation caused stuff to fail at runtime.

Paul