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.
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.