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