Thank you for asking!
For the sake of objectivity I ought to go beyond the question and list both the list of ‘pros’ of running Be stuff on Genode, but also the (way longer) list of shortcomings of that project in its current state, i.e. all the ‘Be’ stuff that I did not bring over to Genode yet…
But since you asked about the former 
, here’s a few thoughts in no particular order:
- Falkon: I was never able to run a web browser to my satisfaction in Haiku ever since I got on board with Alpha1, even with Haiku’s build of Falkon. By contrast, Falkon on Genode does most of what I want. Heck, it even shows Telegram pages better than FireFox on Linux for some reason I can’t fathom (my T410 gets horribly hot and laggy in Debian, whereas Falkon on Genode does not break a sweat). It has come to the point where I installed the package on all 4 computers here (even the family one) so that I can do my daily web browsing anywhere at home. I kinda hoped for that when I started using Genode, now it’s a reality.
- VirtualBox: unless I’m mistaken, Haiku does not have a port of VirtualBox yet, though I seem to recall it’s in the works. In Genode VB is a “daily staple”. I’m not a VM guy so can’t speak more about it (I plan to give it a try though)
- Now we come to the reason I moved to Genode in the first place : stability. Some of our stations started crashing once a day right out of the gate, due to their usage patterns (and we had to refund them of course, until we decided to throw the towel), with KDLs. Guess what: there is no such thing as a “KDL” with Genode. The difference in stability is very very very obvious when looking at the infamous “sea of red” graph (and yes, all we ever hear is “your KDL is not reproducible here”, so we lost hope they would be resolved).
- Next, probably equally as important : file system stability ; I lost count of the number of files we lost (or even whole filesystems, needing to reformat) with our stations over the years, not counting C++ files lost on my own development machines. With Genode I have 100% peace of mind, that’s priceless. Don’t get me wrong, I’m grateful for the work Axel did over the years, but I simply can’t use the Haiku BFS implementation in production for our stations, just the idea of going back that way gives me cold sweats.
- security: that’s not my paygrade, but I understand Genode has lots of potential for being a super secure OS – and, unlike say, OpenBSD, it reaches that goal by design, rather than by applying hard work/sweat to an unsecure foundation. Someone more knowledgeable might express this better. Our stations tend(ed) to get “probed” by script kiddies a lot, which would sometimes seemingly trigger KDLs (!!), so it’s more important than it would appear at first.
- from a developer point of view, I understand Haiku’s code base better than other competitors (say, e.g. Linux) obviously, but I also understand Genode’s codebase better than Haiku’s. Plus the team is always world-class professional and responsive to my requests for help. So much lower chance of behing “hung out to dry” and S.O.L if I run intro trouble with a customer.
- one could add lots of “small” features that add up, like the ability to S3 suspend the system. Of all the OSes we use at home, all can do it (windoze, linux, Genode etc) but Haiku cannot.
EDIT: another item in the “small things that add up” category : Genode’s nitpicker has full-fledged composition and transparency, which means it’s easy to create round-shaped “pie menu” BWindows, unlike in Be/Haiku where this requires crazy hacks.
Anyway all that is nice but still, as things currently stand, the above is going to be of interest to a narrow segment of people. It would take tons more development efforts for this project to 1) fully use all of Genode’s features and 2) bring over all Haiku features on this side of the divide. At the snail pace I’m going, it will occur when the sun goes super-nova
EDIT: To bounce on the “kernel-land” debate, since I hear distant rumbles about it elsewhere:
I know it’s not easy, explaining the benefits of a micro-kernel to people who are used to the miseries of multi-thousands (millions ?) of lines of code residing in the fragile kernel space, and think of all the grief as “the cost of doing OS business”, or “as certain as taxes and death”, or as “completely inevitable”… It’s like trying to describe vision, to someone who was born blind. If all they ever knew in their life was Amiga-like “all non-user components live in the same memory space”, then they can’t imagine there could be an alternative. It’s the same as everything else in life, really : people don’t know what they don’t know… And often don’t want to know.
I think it bears repeating, though, that there is no-one to “put in the spotlight” and no-one to “blame” for the original design of Be and Haiku. It made sense back then to take shortcuts to fit an Operating System in the then-limited hardware of the day. I remember BeOS R3 ran with 32 MB of RAM if you really had to, but the Be engineers had managed that only with some special kernel tricks and memory layout. So using a micro-kernel was probably beyond their concern. There were talks about it in comp.sys.be.misc and BeDevTalk, but no-one was really convinced it would be a realistic idea back then. There weren’t a lot of “prior art” in that department. So we can’t blame Haiku for using the big-kernel model. If it had to be done all over again (with the hardware that existed), it would have to be done the same way again. That’s just what made sense back then.
In a way, the situation reminds me of my transition from AmigaOS to BeOS (on the impulse of Dave Haynie especially, who saw it as a true ‘successor’). I migrated to BeOS, still cherishing the memories I had of my Amiga. I had to give up all my “muscle memory”, but it was worth it, going from a unified memory space (with all its “Guru Mediations”) to one where, at least, the user-space was separated from the kernel-space (i.e. useland apps could not crash the kernel). We’re in a much better situation here, though : I don’t have to “give up” much or anything, I can take Haiku with me on the Genode side. Still again cherishing all the good memories I’ve had with kernel_intel (both the Be and Haiku one), but continue with the same API and (once that’s implemented) user experience, and above all, benefit from true component separation, whereby no component can buffer-overflow into another component. That I now regard as the pre-history of computer science (a cherished pre-history, of course, rich in memories).
).