Running Haiku in Genode VM

The Register (a proper old-skool IT magazine - plenty of content on different operating systems and healthy skepticism of trendy stuff like “AI” and driver-less cars) has recently published a series of articles based on this year’s Fosdem talk by one of their contributors. It dealt with Plan 9 as a “better UNIX than UNIX” and suggested a way to reduce Linux’s software bloat by - and I simplify - adopting Plan 9 on which each Linux program opens in its own cut-down distro.

The author considers this better than compatibility layers that - for us - already allow haiku apps to work on other systems such as Hyclone (targets on Linux), Haiku on Genode, and another one for BSD.

Genode is designed explicitly to run virtual machines. I was looking at the latest Genode release and the rate of progress is amazing, as they follow their roadmap for this year. They have rebuilt their networking system, rebuilt their audio system for low latency, and loads more. As developers paid to push the envelope they are able to keep up nosebleed progress that a purely voluntary system is unable.

I have admired the progress of Genode for a while but had no use for it. Inspired by Liam Proven’s articles, I think it might be time to ride this galloping horse.

My idea is to have a “quiver” of different Haiku images for different tasks, thereby dealing with problems caused by Haiku being single user and root privileges. To this end I aim to acquire a computer that can run Genode and wonder if anyone has successfully run Haiku in a virtual machine on Genode. What was the experience like? The next Sculpt release incorporating recent Genode improvements arrives next month so I have some time to find a machine.

Would I be barking up the right tree? Or would Plan 9 (as discussed in aforementioned Fosdem talk) be a better bet for virtualization?

1 Like

A new proposal for using Genode’s virtualisation superpower to run a Haiku desktop is briefly explored in that community’s user forum. As best as I understand, this “hosted Haiku” would control applications - displayed in our trademark tabbed windows - that behind the scenes run directly on Genode. Effectively it is a combination of the approach in the original post of this thread combined with Haiku-on-Genode.

Whilst mindful of re-opening this thread, it turns out that Genode have decided this is their year for “building bridges” making it an auspicious time to reach out to each other.

Does it mean that Haiku VM will be able to show multiple Genode windows instead of one virtual screen? If so, what protocol can be used for that? VirtIO Wayland?

Are kernel crashes reported to Haiku bug tracker? Maybe it is possible to fix problem on Haiku side?

I trust you read the following couple of posts. It can be a little difficult to know where in a conversation to link but I thought that which I linked to gives context for the longer one by Norman, one of the founders Genode, no less. He summarises thus:

What if it was possible to use Haiku as a desktop shell (beautiful desktop) that allows for the spawning of HoG components that are executed besides Haiku, yet still displayed in Haiku windows? Technically this could be achieved by running Haiku in a VM hosted on Sculpt’s runtime, exposing Sculpt’s config and report file systems to Haiku (via VirtualBox’ shared-folder mechanism), and letting Haiku play the role of Genode’s window layouter and decorator.

The post itself expands on this, and for those who really want to get into the weeds, adds a link to a previous paper by both founders on this subject, research that dates back before Genode was even a thing.

1 Like

If I remember correctly, it is not really just a single or even a small set of problems.

Haiku just crashes from time to time for many reasons. As desktop users, we may get used to it and not even notice. A crash once a week or maybe every few months is no big deal. You reboot the machine, and 30 seconds or so later, you’re back at whatever you were doing.

But for a radio station, this means the broadcast goes off for 30 seconds to a minute. And that’s if you have set Haiku to reboot the machine immediately instead of showing KDL. Which means, no way to investigate what really happened. You certainly don’t want the machine stuck in KDL for several hours or even minutes, while someone at the radio station tries to call TuneTracker Systems hotline to get a developer to investigate it.

Which means… we don’t even really know what the crashes were. It would need some way to collect and save information about the crash, and automatically upload it after a reboot. Then we could collect such data and see what crashes pop up the most. But even then, it may be difficult to investigate them. Usually we take a bug report and we have further questions: what were you doing to trigger this? Can you check changing this or that setting? There would be no chance for that here.

So, it’s doable, but it needs a complete overhaul of the way we handle crashes and bugreports. Until then, we will likely not have a lot of information, only from ttcoder’s own testing, and maybe not from TuneTracker customers (even if some of them may visit the forum and bugtracker from time to time on their own).

Anyway, there are a few bugs that ttcoder did report over the years that never got fixed, so maybe we can start with those:

1 Like

Kernel crash report can be quickly collected using COM port connected to another computer.

The HaikuPorts builders definitely would notice, though. And I think at this point there are no longer any regularly-occurring KDLs at least for the x86 and x86_64 builders (there were in the early days, years ago, but they’ve all be fixed to my knowledge.) Overall I think Haiku is far more stable than when TuneTracker last shipped production systems using it.

1 Like

NetSurf development team uses Haiku VMs for their builds (using nightlies, I think) and they are hitting crashes quite regularly as well.

I don’t know if TuneTracker was using nightly builds or releases in their latest attempts.

Are these reported on the bugtracker? I recall you mentioning this before, but I don’t see a ticket for it.

1 Like

The stability of the system is important but as you rightly say it is something that Haiku can and should fix by itself. The other benefits that come to mind - the reduced attack surface and Genode’s use of different architectures and chip features (e.g. ARM Security Zone) that I suspect Haiku does not yet reach being others that are probably more significant. Genode is ported to PinePhone - a form factor and system architecture out of our reach.

My humble suggestion is that resources that get dedicated to the ARM port would be better directed into a stack running on Genode as per Norman Feske’s proposal. Efforts gone into ARM already would not be wasted, since you still want the binary running in the virtual machine to match the underlying architecture, this being virtualisation not emulation.

The benefits are that the ARM port only has to target the virtual machine of Genode, not all the ARM SoC that are out there. There would not be an opportunity cost in doing so, since there are occasainally people curious to tinker with Haiku on ARM, but no real need for it at this stage. So redirecting the occational person who wants to play with the ARM port towards Genode virtualisation and maybe Tunetracker’s Haiku-on-Genode, itself desperate for volunteers, would not affect mainstream Haiku development but might create exciting new ecosystem for Haiku apps.

How Genode is better than Linux for this task? Linux is also able to do hardware virtualization and use hardware security features, but have much better hardware support.

That argument is absurd, since the same logic dictates we all simply give up on Haiku and use linux or windows for broadly the reasons you give. However we choose to use Haiku…

Attempting to answer your question in its own terms, I suggest that Haiku and Genode, as two niche OS, have the opportunity to mutually uplift each other. A director of Genode Labs is keen to give encouragement and advice whereas I don’t suppose Linus will trouble himself on the matter. Also Genode seems to be more more elegant and up to date in its design.

1 Like

That must be a big deal where you live, but I had literally never heard of PinePhone. Let’s see … Oh, right, it’s by the same people who make the PineBook. Yeah, the RiscOS folks love that one. Strange that there’s no PineBook version of Genode, then.

That would be great, if and when Genode runs on all those SoCs. Right now, they offer downloadable images for “commodity PC hardware“, which I suppose means x86, an “experimental” (their word, not mine) one for the PinePhone, and one for an equally obscure ARM laptop. What I don’t see are the words “Snapdragon”, “Apple M-Series” or “Raspberry Pi”. Those are the big guns. When we see images appearing for those, things will get serious.

Which apps? I imagine you mean native ones. Nobody wants to run the Haiku port of GIMP or LibreOffice when they can just use the more battle-tested Linux versions. But the shortage of native apps vs. ports is a perennial topic here.

I can see how your proposal would benefit Genode. It’s one more box they can tick off. What’s in it for Haiku?

Okay, I’ve gone to the Genode site and I must say, I’m confused. Does Genode have any actual applications of its own? Or does every application, no matter how minor, have its own guest OS? Sounds like Appimages or MacOS bundles, and you should hear people complaining how those gobble disk space and memory.

It seems like a lot of trouble to run, say, ArtPaint on another OS. But hey, you be you. It’s perfectly fine to be into different OSes.

1 Like

I still don’t get the hype around Genode.
I tried Genode some time ago,but it’s such an obscure user experience,I didn’t know what to do with it.
It booted into some sort of graphical environment,like what you can see here in the foreground:
Sculpt screenshot
But I didn’t find out how to install/use a browser on it,not even something as simple as a terminal or file manager.
Yeah,many screenshots prove that you can actually do something useful with Genode if you know what you’re doing,but I don’t think they’re targetting desktop computers and regular end-users like Haiku does.
I managed to install every single BSD variant in the past,tried them all,also Solaris and many Linux distributions in the past,but with Genode I totally failed.

That being said,I don’t think it’s a good idea to replace the Haiku kernel with something else.
Haiku is great as-is and is only getting better,faster and more stable with every release.
While I’m personally not a big fan of the ARM architecture due to how locked down everything is (good luck trying to install any random ARM operating system image on any random smartphone,like you could easily do with any random x86 operating system on any random computer),I don’t see the work towards supporting it in Haiku as a waste of time.
If Haiku needs ARM support,then it should be native,not through some obscure VM thingy like Genode.

4 Likes

Why do you think the ida of using Linux as an underlying environment for Haiku is ridiculous, but using Genode would be better?

My time spent on ARM is spent there because sometimes I enjoy working on a hardware driver, playing around with EFI, etc. It is not spent on Genode because I do not enjoy working with hypervisors and learning yet another operating system.

Actually, the idea to use Haiku to manage windows on Genode reminds me a lot Cosmoe.
Difference is that Cosmoe tries to recreate Haiku on linux when Genode would run Haiku in an hypervisor to avoid that pain.
I think both are missing an important point. Haiku is a lot more than just another desktop environment. All projects that have look at it in the same manner, didn’t go very far.

2 Likes

I apologise that the sentance was clumsily worded. A better way of saying would be: if we took @X512 ‘s argument to its absurd conclusion we do away with Haiku (and indeed any other niche operating system) in favour of a linux or Windows monoculture.

That neither of these projects advanced very far is perhaps due to Haiku thus far being a niche and efforts to run it on other OS being a niche within a niche. However this might change as Haiku gets more momentum.

I would personally feel more comfortable in my decision building my own life around Haiku if an alternative way of hosting the apps was to exist, as a lifeboat. They say you don’t determine the need for a bridge by counting the number of people swimming across the river, and projects like Cosmoe and Haiku-on-Genode are literally those bridges.

Which handily takes us back to Genode’s resolution of this being their year of “building bridges” (neat!). We should take the opportunity for dailogue and mutual benefit.

No. We are on Haiku forum, so we need Haiku by definition. People who don’t care about Haiku are not an auditory of this forum.

But position of Linux or Genode are the same here. Both of them are not Haiku. If comparing which will perform better to virtualize Haiku, Linux will clearly win. I simply can’t see where Genode is better than Linux if we assume that we need to virtualize Haiku.

1 Like

Well, I don’t intend to speak for @squizzler but I suppose the argument would be that Genode was built from scratch as a virtualising environment, whereas Linux is a work-alike of a networking OS with a desktop bolted on top of it, and virtualisation bolted on top of that.

But we’ve seen versions of this argument for years. “Let’s develop Haiku specifically as something to run in a VM!” Sorry to play the part of the crusty old boomer, but while VMs have their place, if it doesn’t run on bare silicon it’s not an Operating System.

3 Likes