That’s because linux is primarily a server operating system. On a desktop machine this makes little sense.
Sure we can employ better security for Haiku, but starting at virtualizing doesn’t seem like a good idea. we have more fundamental problems to solve first.
True, but I wanted to challenge the perception that running in a VM is only for “toy” OS.
I suggest many of “problems to solve first” fall away when Haiku runs in VM. As per Liam’s talk:
A lot of issues ordinary distros face just… disappear. It doesn’t need an installer, because a VM image is just a file. It doesn’t need an
initrd, because we know the host hardware in advance: it’s virtual, so it’s always identical. It doesn’t need to boot from disk, because it won’t have disks: it will never drive any real hardware, meaning no real disks of its own. That also means no disk filesystem is needed.
I have just acquired a mini-desktop and am trying to install Genode Sculpt (tbh I’m having a hard time of it and might give up 
). I would like in turn to run Haiku in a VM on Sculpt. What I hope to get from this is to be able to run the official beta and nightly builds at will -possibly at the same time - and to enjoy the security benefits of Genode with its capablilty-based security and microkernel. I’m sure 9Front (as per Liam’s suggestion) would also be a good platform. This does not seem so different from Google’s plans for Fuchsia, although better if Google had not pulled the rug from under it.
The problem is really what you are trying to secure. There is a nice xkcd comit about this xkcd: Authorization ,if you run Haiku ontop of sculpt, even if it has capabilites. if the haiku “vm” gets all the capabilities it needs, then your important stuff, your user data, is not any more secure than it was. But in turn you loose proper hardware support for devices haiku knows what to do with on it’s own.
mircokernel vs non-microkernel can be debated. but running a kernel designed for monolithic operation on a microkernel seems like the worst of both worlds 
you can’t harness the benefits of either model like that.
My main selling points when someone asks me “Why are you doing this? Why do we need a new operating system?” are:
So, if we ran in a VM, who would be the hypervisor? Probably an OS that 99% of people use, even if they do very differet things on top of it. We lose the technodiversity, then. Or, if there are many hosts, we have done nothing but move the problem of writing drivers and handling hardware support to a different place.
And, in either case, it means we are not in control of the hardware anymore. There is some abstraction layer under us. In that case, why bother doing an OS at all? If you’re not interesting in making your own kernel and handling all the hardware, and you want to outsource that to another team, then you should be writing a desktop environment. That will bring you 80% of what you can do in an OS. A VM will make that maybe 90%. But, the interesting parts may very well be in the remaining 10%. Yes, these 10% are also 90% of the work you need to do to write an OS. It’s about getting the best performance out of the hardware. It’s about being able to handle hardware diversity.
If your OS runs in a VM, the problem isn’t that it’s a toy. It can be very serious and productive. But, it’s not an OS anymore, since you have removed the part that an OS is supposed to provide: an abstraction of the hardware, and resource management. You’re making a virtualized desktop environment now. Which is great, but only half what an OS needs to do. And, here, we have people very much interested in working on the other half.
Where Liam, in his article, suggested Plan9, I presume he wanted to redeem a very competent OS that had no applications. I am thinking along the same lines in trying to use Sculpt. I would agree if you use a system like Linux or Windows there is no point in virtualising something like Haiku because you can do everything you need to in the host OS. In today’s world you struggle to make the case to use something that is less convenient - why use a bicycle when you can drive a car?
But if you purposely use a less featured but lightweight and elegant OS like Plan 9 or Genode to host VM, Haiku might meet a niche. I appreciate that, under virtualisation, Haiku might be considered a desktop environment you load into. For some, squeak or Pharo may do this role better.
But VM-specific Haiku may, for some, fill a sweet spot between Liam’s proposed cut-down-VM-Linux and an environment like Squeak? After all, Haiku is a more rounded and consistent thing than Linux. I understand one of this years GSoC proposals was to optimise Haiku for VM, so we might get to see how that goes.
TBH, my experience in trying to get Genode up and running is making me think I will probably give up and go for a native install of Haiku on my new miniPC anyway.
Genode is based primarily around the L4 series microkernels. This includes seL4, the “security-enhanced” version. Among its use cases are military drones so it’s definitely got security when using that kernel.
As usual, when hosting a bag-standard desktop kernel via virtualization on top of a secure kernel, the drivers have to be written for the secure kernel independently of the bag-standard desktop kernel to prevent compromised security. Therein lies the problem.
Adding to that, Genode is under the AGPL license that is more infectious than regular GPL. All the same, I may have Sculpt running on my PinePhone someday. I’d prefer a secure operating system based on Genode to Linux, after all.