Re: Loving the series, but...
My general decision tree goes something like:
[1] Give the OS an overall attempt in the simplest, quickest, easiest environment -- which is a VM. IMHO the easiest-to-use FOSS hypervisor, whatever Red Hat may think, is VirtualBox, which is easier, more complete and more flexible than GNOME Boxes, or KVM + VMM.
(It is not a very useful trial to attempt a company's OS only in its own hypervisor: that is the combination I would expect to be most thoroughly tested and to work best.)
[2] If it works well on that, then try it on hardware. If possible, try it on a complex existing configuration, because getting a machine to itself is easier for almost any OS. For instance, it is more instructive to try a laptop than a desktop; it's more instructive to try a complex machine, e.g. with a discrete GPU, or worse still switchable GPUs.
So, in this instance, I could not get Dragonfly working as a desktop in a VM, so it didn't make it to step 2.
The other BSDs worked very well as desktop OS in VMs, but I could not coax them into installing onto a complex multiboot scenario alongside existing installations of Linux _and_ Windows.
(This also defeated some Linuxes, including Deepin, ChromeOS Flex, Alpine, and Pop OS. Ubuntu Kylin was especially hard work although I did get it working.)
I've only got FreeBSD running happily on its own dedicated SSD on a machine where there is only one other OS and that too has its own dedicated SSD.
OpenBSD and NetBSD looked to be too limiting for me to dedicate a machine to them, so they didn't get that far.
I'm not saying this is an ideal scenario. I'd love to have a testing lab with multiple laptop, desktop and server boxes, with a few different CPU architectures, that I could dedicate to this, but sadly, I just don't have the space for that at present.
Biting the hand that feeds IT
