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.
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.
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.
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.
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.
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.
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.
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.
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.
Thatâs possible if not already implemented. We have the groundwork for this in Haiku but it isnât ready yet.
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.
You donât need WASM at all for this. LLVM can be used to do all of this anyway.
Perhaps some of the core Haiku devs can answer this one. Particularly @waddlesplash
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âŚ
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. https://yogalayout.com/
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.
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.
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.
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.
