Optimizing for virtualization on linux or hyper-v is probably a good idea. Running some OS in your vm and it beeing smoother than your actual desktop does have a way of impressing users 
If genode uses the same things qemu does as linux does it would probably benefit just as much if people really want to use it as a platform
As for applications like TuneTracker, much goes the way of specific drivers and specific hardware issues.
We tend to generalize the entire OS, but it usually is a smaller part of the whole.
This focus can get into application certification on a specific OS platform / OS release versus a specific hardware platform or family as well as specific drivers.
Secure sandboxing is another discussion as to what is being secured in a VM or container…. more about security and secureness for certain development.
Sandboxing is a key concept in Genode design. To that end it uses “capability based” security where it can only access resourced assigned by the user via an interface called Leitzentrale, which is that funny organisational chart that features in the stock screenshots of Sculpt.
Of course the discussion linked on the second post of this thread combines both methodologies, making it a bit of a flex of Genode’s technology. Haiku would run as a whole on Genode/Sculpt, whilst apps such as Tunetracker in the example can be recompiled to run natively in Genode and appear in windows run by that hosted Haiku.
In theory it should be better in many ways.
That’s really vague, tech usually isn’t better or worse, just different. To figure out if it is better for our usecase one has to consider what the requirements are. Haiku has a couple of things we want to improve.
For example:
Better Hardware support? Genode is unlikely to help there
Better Security? Again no help there. Wrapping “Haiku” in the most secure sandbox imaginable changes absolutely nothing about it offering no isolation from apps and data, the thing you’d want to protect. So again a fail there.
What’s more you could make this argumemt for any OS that has virtualization, windows, macos, FreeBSD. None of those can change Haikus security architecture by putting it in a box.
The discussion on genodes forum also reached a similar conclusion, genode does not help with Haikus stability, and security is only helped by running components in isolation.
I’d add to that that by doing that you loose the things Haiku is good at, and don’t gain much of anything.
The newer proposal there is using Haikus shell (i.e app_server) for their desktop to run their apps. And honestly, sure that makes sense. Everything here is open source, if they want to take components and integrate them that can work really well. But not in the “I made it more secure by shoving the entire thing in a box” sort of way. 
Personally I see Linux more interesting as Haiku virtualization host because of VirtIO Wayland, Venus and VirtIO GPU context passing capabilities. It can potentially share Haiku and Linux windows on the same screen and share GPU acceleration.
Also HyClone is available for Linux.
MicroKernel architectures are supposed to break up the monoculture of a huge kernel like Linux, that makes the code base unmaintainable and huge, to one smaller and more easily delegated to separate teams and individuals. The M4 series microkernels are the ones that Genode was designed to be a wrapper for.
Different hardware configurations are better suited by different microkernels. Military-grade drones (hopefully only for example) benefit most from the seL4 microkernel not only because of security but because a drone may have so few threads in its software that pinning a thread directly to a core simplifies both software and hardware by tight integration and simplicity.
https://l4re.org/ is a more multitasking-friendly L4 microkernel. It is used for automotive purposes but could be a secure replacement for the Linux kernel as well. This is documented at https://l4linux.org/ and there is an old, stale version in the tree for use with Android also. All that’s needed is driver support.
In short, Genode is a kernel abstraction layer with several microkernels supported for different uses. If the underpinnings can be made less monolithic, great! If it can’t, then why not? There are few enough hobbyists working together anyway, we should cooperate if it makes sense to do so.
This makes no sense to me.
You can architecture your OS as a microkernel and still store everything in a huge git repository with millions of lines of code, change APIs between the drivers and kernel all the time, and have strong coupling between various drivers so that everyone has to understand the entire thing before they can change a single line of code.
You can architecture your OS as a monolithic kernel with modules, and have 3rd party developping modules that you will never see, and your kernel can be developed by an independant team and be quite small. You just need to maintain a stable API between the kernel and the drivers (as BeOS and Haiku have been mostly doing).
Microkernel is about one thing: run as much as possible of the OS in userspace. That’s all. In fact that comes at the cost of more complexity, because achieving it in a way that doesn’t hugely degrade performance is quite tricky. The benefits are making the kernel more resilient to device driver crashes, and things a bit more secure since you can run each driver in its own address space.
You can. But that is against the purpose of a microkernel (or at least most microkernel projects.) Normally there’s a clear API/ABI. And even if all is in one git repo it is separated well. (Which it isn’t in the Linux kernel for example. Setting a simple flag at one end in the configuration might make recompilation at the other end neccessary. 
)
Good to know!
L4 series microkernels are among the highest performing microkernels around and very lightweight but need not involve core developers on Haiku proper. If somebody wants to write a Genode framework shim for running Haiku’s userspace on, that’s fine as well. Genode’s license compatibility with GPL drivers ported from Linux could be a mitigating factor. (Genode is AGPL licensed.)