Genode and Haiku

Development
1

Hello all,
We’re porting TuneTracker CC6 to the Genode OS framework (made possible by a compatibility layer).

Making Genode run Haiku apps seemed like a daunting project at first… And it certainly proved overhelming at times. But as of this week, our flagship app Command Center 6 is (barely) displaying its main window and playing ‘hardcoded’ audio files! Of course there is lots left to be done, including figuring out how to use FUSE/BFS, if possible at all. But it’s a big enough milestone that has been reached, so I thought I’d celebrate by posting here.

We achieved that with a “libhaiku.so” compatibility layer, which provides (a limited subset of) the Haiku APIs. The desired end state is that we’ll be able to recompile some userland Haiku apps with little to no changes, and that they’ll theoritically work as-is on Genode.

I believe this project, if it goes far along enough to be useful, would be beneficial to both communities: Haiku users would be able to recompile/run their userland applications on another “platform”, with its set of drivers, ported apps and security/sandboxing model; Genode users would gain Haiku applications, and possibly inspiration to extend their APIs, as the Genode APIs do not yet have the breadth and depth of Haiku’s.

If there is interest, the “libhaiku” source code should be ready to post to a fossil repo under the MIT license in a week or two, together with the virtually unmodified source for Pulse, Mandelbrot (to showcase what works and what doesn’t yet), and build instructions for Linux and Haiku (the latter requires building the toolchain from scratch, not for the faint of heart! But if I can pull it off, anybody can g). The resulting 10 MB boot image can be run in qemu (on Haiku that requires upgrading qemu to 3.1.0) or on bare metal if your hardware is compatible with Genode.

Again, this is not for end-users, and will remain a developers-only project for months. In fact there is no plan to even take the project far enough to port Deskbar and Tracker unmodified (we could take a page from the GoBe guys to hack entry_ref for instance, but not sure it makes sense). We’re focusing our work on what’s necessary to run CC full-screen, whereas doing full fledged “desktop” integration could be done in e.g. a community fork of our repo.

I realize posting a (coding) “call to arms” here might be controversial, or trigger second-guessing instead of contribs; but then again this forum has been very friendly and helpful to us in the past, so why not give it a shot…!

6 Likes
2

Does the above mean Tune Tracker will stop using Haiku in the long term by moving their software to another OS? Taking into account TT is the only (publicly known) company using Haiku in production, this would be sad to hear.

3 Likes
3

Out of interest, may I ask what the primary motivation of porting to Genode is…?

1 Like
4

@Akuji
Nope: as described above, haiku-on-genode (or HoG for short g) is a hybrid, not a “jump ship” type of thing. In fact, CC6 is and always will be developed on my Haiku thinkpad, because the turn-around time is just orders of magnitudes faster when you’re self-hosted, versus running through an emulator (compile-run-test, instead of testing through qemu!). But yes, the plan is that radio stations (and Dane, during testing) will run CC on the new HoG “core” instead of running it on Haiku-with-haiku-kernel.

Put another way, what the user will see on-screen will be BViews, BWindows (not sure I can implement yellow tabs though), playing-displaying BFile/attributes / BMediaFiles… There will be a few hints of Genode though: the Arora web browser, VirtualBox5 (if running a VM is to their fancy, which I doubt, stations want simple stuff) …etc.

It would be justifiable to say we’re “leaving” if we were porting to SculptOS (the operating system based on Genode), rewriting CC to use the Qt API instead of the Haiku API (Qt is the one production ready API available there, as of early 2019 the Genode “gems” code is not yet able to replicate what we need: BListView, BMenuBar …etc). Obviously that’s not technically possible and that’s not what we are doing.

I’m sticking to the Haiku API for the same reason I came to it/BeOS in the first place: no other API/feature-set on the planet is even remotely suitable to me. (though I’m starting to picture Genode pulling off the feat of doing as well or even better in a few years time, seeing as IMO they are to Haiku what Haiku is to *nix and windows).

@Dave
We’ve tried AMD and Intel mobos, but they still don’t run to Dane’s satisfaction (he consistently reports that they crash every 24 hours, whereas we need weeks or months of stability so that we can sell systems). We’ve filed tickets, harassed waddlesplash (who’s been incredibly nice and even pro active with us, thanks!)… Bottom line, my conclusion is that a macro-kernel can only take us so far. I can poke Dane with questions until we’re both blue in the face, I can harass the haiku dev team so that they interact with him and probe his hardware/software configuration… Essentially asking them to work (for free!) as system integrators for us… Or I can “switch over” Haiku’s kernel land for something more stable. That’s in the nature of being thousands of km away from each other: I want things to “just work” at his end. And so does he.

If at any time we find a good hardware combo that runs kernel_intel as well as nova/genode, we can “come back” to kernel_intel in the blink of an eye. In the meantime we have to put food on the table, and that will still be done with the InterfaceKit, StorageKit, DeviceKit and so on.

EDIT: I realize what is obvious to us developers, might not be to haiku non-developers. When I explain that the source code of the InterfaceKit …etc is copied and used as-is almost without change in HoG, a developer will immediately “get” what I mean. Maybe a non-dev will not though, sorry about that; would need to find a metaphor or whatever to convey the meaning…

EDIT2: filed https://dev.haiku-os.org/ticket/14964
And yes indeed anybody can query trac for “ttcoder or dsuden or AGMS” and see how many tickets we have had open and for how long. Some would choose to blame the development effort. I do not – dev effort has been nothing short of heroic for years.

3 Likes
5

I have repeatedly asked you to file a ticket with the kernel crash of this and that it was beyond my skill to debug. Why did you not do that? It takes literally 5 minutes.

We need Haiku to be stable also; spending months and months of effort re-engineering the Interface Kit to run on another OS to avoid fixing a single bug is frankly ridiculous. In case you haven’t noticed, we’ve fixed quite literally dozens of kernel panic tickets since the beta release; what’s one more?

Again, if you find bugs, we want to fix them. Losing Haiku’s one commercial application (and that’s what this would be; running a large chunk of our code on a different kernel is not Haiku) is something we want to avoid.

10 Likes
6

Indeed it would be especially sad considering how much progress has been made recently in stabilization and getting new hardware support back on track.

4 Likes
7

Calm yourself, waddlesplash. :neutral_face:

Before calling their decision ridiculous, you may want to consider that you don’t have all the information that lead them to it. That their stability (and probably other) issues hinge on a single bug sounds unlikely.

Instead of chastising them, which will rather drive them away, why not just offer to help? If they don’t take you up on it (again), that’s their prerogative.

7 Likes
8

Indeed the simple fact is it is hard to buy new hardware that supports Haiku well often enough as it takes a long time for support to be added for newer stuff.

That said, industrial PCs may be a way forward on that as they tend to have a very long lifespan of availability… if Haiku could guarantee good support for something like one of the newer Nexcom or similar industrial PCs it might alleviate some of these problems.

And like Humdinger said they wouldn’t have done it if they didn’t think it was worthwhile. Others wouldn’t have taken almost the same path as well… if they hadn’t seen it as worthwhile… but I digress. I actually like Haiku as it is and for what it is but it certainly may not be stable enough for their use case despite all of the work waddlesplash and others put into the beta.

Something like this perhaps? Probalby best to talk to a vendor and find a machine with a 5-10 year availability period.
http://www.nexcom.com/Products/multi-media-solutions/industrial-rackmount-computer/pbox-rackmount-system/backplan-pbox-4u912

1 Like
10

We demand screenshots.

3 Likes
11

This depends on two main factors for your setup::

  • HDA driver
  • OSS 4.2 drivers

The Conexant-compatible HDA driver which comes with Haiku may not work on all related Conexant audio chipsets from that vendor. I have one that works with Haiku that uses line in, audio out (headphones), There is a ticket specific to this effort to add additional Conexant audio chipsets and hopefully bring the HDA driver up to FreeBSD 12.x level…

Semi-pro/Pro-level audio stream workflows? There are motherboard audio chip limitations in which I’d
advise things like OSS 4.2 and/or a semi-pro/pro soundcard solution.

12

The HDA driver is our own. FreeBSD has their own (non-OSS) HDA driver that we will not be leveraging.

In addition, the ticket they just opened is a filesystem-related crash, not a HDA one. HDA has been working OK for them, I believe.

OSS does not support many “pro” soundcards made any time after 2011-2012 I think. So I don’t think that’s a solution.

13

After two years, I am interested in finding out if this project went anywhere and, if so, what was learned. Without raking over the old coals, I agree with the OP that his work seems an opportunity not a threat to Haiku. In fact it is would be flattering for Haiku to be a key source of ports to this embryonic OS, surely a testament to Haiku code quality.

Although enthused to find out more, there are very few reviews of Genode or Sculpt (their attempt at a desktop). The only recent one I found was this YouTube. Their implementation of capability-based security (a feature of Fuchsia as well) is fascinating.

I feel Haiku and Genode are too far apart in their heritage, implementation and usage to tread on each others toes. But whilst the products may wildly differ, as organisations they share certain similarities. Like Haiku, Genode has a company established to furthering its development and adoption. They are both less US dominated than most “tech” projects. Both seek to empower users over their computers. As two very niche players in the OS scene, maybe there is the opportunity for Haiku Inc and Genode Labs to collaborate or exchange knowledge, contacts and opportunities?

Forgive me for flying a kite here. I am thinking of something along the lines of the Town Twinning movement. Perhaps, for example, Genode and Haiku conventions and hackathons could be co-ordinated so that developers from one could learn about the other?

I have been guilty in the past of suggesting Haiku should adopt more ideas from Google Fuchsia. However I now feel that for developing future technologies in Haiku mutual collaboration, as equals, with Genode might be better for the projects self esteem than just bottom-feeding from Fuchsia’s codebase.

1 Like
14

I see that Genode have ported their latest release to the Pinephone. Being able to run Haiku apps more securely on a mobile phone because it is exposed to the risk of taking it out your house into the mean streets seems to perfectly compliment being to run the same apps natively on the home PC in the less locked-down Haiku.

15

If 2 compatible system exists, but one is safer or otherwise better than the other, why do you need the other one?

16

Speed != safety. That’s why. Safety often cuts into performance.

1 Like
17

This is true for traditional systems, but is it a general truth?

Generally speaking the computing scene is like:

  • Safety is slow, lets go with this smart middleway solution.
  • You forgot to check this, now all your base belong to us.
  • Oh, lets use this smart mitigation.
  • You forgot to check this, now all your base belong to us.
    (repeated indefinetely)

Question: why do we do this, why don’t we break the chain, and why the decision-makers sill prefer “speed” against “safety”? I am naive, so i assume, this is either a business or a political decision. What did i forgot?

1 Like
18

Perhaps it is more helpful to think of Genode and Haiku in terms of Apple’s iPhone versus the Macintosh. The former is regarded as very secure for user data, even if your phone got stolen, whereas the latter is a proper computer, albeit one that no longer tries to hide its dissatisfaction with users who insist on installing software from the web or otherwise deviate from the script.

I would suggest it is impossible to foresee everything that might possibly go wrong, which is why for example air travel is extremely safe and they take great care to aim to eliminate sources of failure but plane crashes still happen. Air accident investigations are the process of learning from failure, so that cycle you mention is necessary part of the learning.

On the subject of Apple, that is what they tried to do with the iPhone OS by locking the whole thing down to resemble what some have termed a “walled garden”. And on the whole it has been remarkably successful compared to Android, but to prove they can’t think of everything, even the iPhone got cracked by so-called Pegasus spyware.

Oh, and it’s “all your base are belong to us”! :grinning:

1 Like
19

I don’t know this things, therefore i am not able to understand your example. Explain with basic words without relying on trademarked products if you care.

afterwards: So close everything, create walled-gardens, which doesn’t help, because it will be still get owned, because?
Speed.

From my POV this is a deprecated way of thinking. If we want to see a change we need a breakthrough in every front. It is guaranteed to be painful process, therefore not too many people want to do it. Which i find pretty sad.

Seemingly the 70’s will never end.

20

Back to the soundcard problem in some of the original replies, two things

1: Surely Genode has no better driver support?

2: The radio industry has long since abandoned actual soundcards in major installations.

There is not one single PC putting analogue audio in to the air-chain where I work, and that’s a 12 year old install about to be replaced from the ground up. You use AES67 IP soundcards and when you finally need analogue audio (or AES3 digital) you use an AES67 to analogue (or AES3) convertor node.

There are commercial and/or F/OSS drivers for Windows, Linux and MacOS for this. A driver could be written for Haiku to provide AES67 in/out; or direct AES67 out could be implemented in TuneTracker for that matter.

I created an enhancement ticket so that it may vaguely be on someones radar; although I imagine it may be something I need to try and figure out myself! I do obviously have access to piles of hardware.

https://dev.haiku-os.org/ticket/16956

Oh, and 3: Pro soundcards are now nearly all USB anyway!

5 Likes
21

If you can find them, the delta 1010 and sister PCI cards have a working driver.

Ice envy 24 chipset iirc