Some questions about future features

So, i would like to mention some features which would be nice to exist in Haiku in some future. I hope somebody explains his thoughts on these ideas.

Disclaimer: i understand that some of these were probably already mentioned before, but i also hope this might become a post for other developers to know what could be nice (or not, depends on opinions) to be implemented in some ways.

  1. Server edition (already mentioned before) While this would require separating graphics stack and possibly some other stuff from kernel, this would simplify hosting various Haiku-based CIs. Another point is that Haiku’s event loop is already similar to whats used in Node.js apps (libuv) which are used widely.

  2. Multi-user setup. Might be useful for such server setups, or even for shared PCs which still can be seen in (sadly) third world countries.

  3. Declarative GUI: while this could possibly take inspiration from such frameworks as React, Angular, Flutter, Jetpack Compose, Swift UI, or anything else, this doesn’t have to be part of the operating system - it could be distributed as an hpkg or even as a git submodule. Same comes to 4.

  4. WASM layer. While there appear additional CPU architectures in haiku build scripts, there we also might need to have a way to compile a binary which works on any architecture - Microsoft has solved that by writing .NET CLR, Oracle had done JVM which is used in Android and similar platforms. While JIT compiling like in these two would hurt app performance, it should be possible to AOT compile apps either on repository side or on user machine side (during install). So it might be a good idea to implement a WebAssembly->Native compiler which tries to map unresolved symbols to those from OS libraries, while library names could be specified in a config file. Of course this could be an optional feature or a feature installed from repositories, because this might potentially require dependencies like llvm for more efficient compile process and better performance.

  5. Extended Jambase. While haiku core developers enjoy pretty good custom Jambase which allows compiling any sorts of haiku stuff, such feature seems to not exist for regular package developers.

  6. Mobile support. While this has some GUI remake, cpu architecture, and telphony support prerequisites, Haiku would become a nice alternative to android and ios due to its general performance.

  7. Window host API. I don’t know if this already exists, but it would be interesting to be able to embed whole windows into other views, not just BDraggers.

1 Like

Hi @handicraftsman and Welcome!

  1. While Haiku isn’t primarily optimised for server use, it can be hosted on cloud based providers as a CI server. Not sure if we need a server edition but that’s up to the core Haiku devs.

  2. That’s possible if not already implemented. We have the groundwork for this in Haiku but it isn’t ready yet.

  3. This is a very good idea for Haiku GUI Development and I agree. A declarative and easy way of writing Haiku apps would be very interesting, similar to React, SwiftUI, XAML, Flutter, etc.

  4. You don’t need WASM at all for this. LLVM can be used to do all of this anyway.

  5. Perhaps some of the core Haiku devs can answer this one. Particularly @waddlesplash

  6. Well I would ask why? Haiku is a desktop OS and I don’t see any point in competing with Android and iOS economically. Alternatively, running Haiku on ARM devices like the Raspberry Pi or Laptops like the PineBook sounds much feasible and is a close as we will get to fitting the ‘running on mobile devices’ idea (If they have telephony). Who knows, I could be wrong…

  7. This looks like a suggestion for Haiku R2 rather than R1. Again, the core devs may give you a better answer.

Question 3 sounds like the most interesting idea that fits Haiku GUI development. But I think the BLayout API has this idea implemented using C++ templates. Facebook’s Layout engine called Yoga, looks like a inspiration point to implementing your question.

1 Like

Yeah, i agree that some of these ideas might not fit current haiku vision (like mobile version, but that could be done by somebody else i think, if thats ever needed of course).

And yes, ive seen yoga layout - it is really good, just like constraint layouts.

Question 1 doesn’t make any sense at all… since no server OS even does that. Linux doesn’t, BSD doesn’t and Windows doesn’t either. There are headless variants but that is clearly way outside of Haiku’s target audience as well as dominated by much more focused alternatives.

We should more focus on native apps instead of porting and porting.

1 Like

I agree with that. Porting should come after Haiku reached some decent “market share”. Haiku needs to offer great apps that are either not available on any other OS or provide a superior experience.

It’s the same game we play for decades. What does have the Amiga, PlayStation, Apple, “fill in any successful platform” in common? Great apps/games!

Regarding declarative UI, i decided to experiment a bit with it. Not sure if that will work, but i am trying to do that in React way, while (in future) supporting different layout variants. Currently i am implementing some kind of DOM library for easy BView and event management.

  1. Lookup the jamfile engine, it exists.
  • Are Haiku’s run levels and ring structure the same as Linux? Or are there differences?

  • If devs prefer native to ported apps, wouldn’t it be useful to at least port as many programming applications as possible, rather than just having a few like Paladin and Lazarus?

  • Most OSs end up having security apps. Just wondering if it would be useful to have a BSecure API with libraries giving readymade access to the filesystem and devices? So native security / logging / monitoring / firewall apps could be more easily developed?

We don’t have runlevels. The system is either on, or off.

I don’t know about rings. There is userland, and there is kernel, and that’s all.

Haiku devs write the OS. We cannot additionally take care of every language out there (same as web browsers and other things). So, we try to make a good OS with interesting features and push application developers to put the features togood use. That’s all.


Which can, of course, be checked with the function is_computer_on() from the Kernel Kit. :slight_smile:


Re #5

1 Like

Regarding points 1 and 6. These are not likely going to happen any time soon. See Haiku’s history for reference as this OS primarily exists be cause BeOS’s focus shift played a major role in killing the company that created it. Perhaps when Haiku gains a popularity similar to what Linux currently enjoys would this be feasible.

None of that seems feasible in the short (years) terms, specially the mobile version (which is a nono).
But the WASM part isnt too bad idea, in the terms of having a Haiku system os layer (microapi / syscalls?) to provide syscalls part for wasm interpreters.

For example, this one that runs even on every other OS, and on toasters:

Yeah i know, interpreting wasm is not Haiku native not Haiku native, it’s slow…, etc. But still “compile once” (with quotes) crossplatform code.

1 Like