Secure against crackers online, (i.e. needing passwords to access personal data, & the system files), with a secure filesystem, one that won’t lose or corrupt data, (as I have read can happen with the present one)….
May I ask about the progress on VisionFive 2 risc-v port? Or, Nvidia 3D acceleration is your focus now?
No progress there yet. I ordered Milk-V Titan (it is currently most performant RISC-V machine available) and plan to work on it later. It should be easier to upstream Haiku support for Milk-V Titan because it is more PC-like hardware.
Vulkan with Mesa NVK is working, but without asynchronous submit support yet. Recently I managed to make NVKMS working, so it is I will make Nvidia Haiku accelerant add-on soon (it is required for modesetting, changing resolutions, refresh rates, hardware cursor and overlays).
I plan to publish Haiku Nvidia driver this year.
17 Likes
These are different things. On Trac there are 4 milestones to accurately represent this:
- R1: things that “we” consider critical to the R1 release (in quotes, because as far as I know, I’ve been the only person to move things to R1.1)
- R1.1: “nice to have” for R1, but we’re ready to make compromises in order to ship R1 faster. So, less important problems can be put here
- R2: things that require compatibility drop
- Unscheduled: everything else: things that does not require a compatibility drop, and are also not important enough to be in R1
So, after R1, we don’t have to immediately start to work on R2. We can work on R1.1, then R1.2, and so on.
The wiki page “API changes on compatibility drop” on Trac also gives more details about ideas for R2. I don’t see a lot of activity going on there, and it is a lot of “internal” things in a way. And for some of them, we even have workarounds, so it can end up with “we introduced a new class, we deprecated the old one, we added some symbol versioning, and eventually we can actually ship this in R1” (and it did for various things). When I think of exciting new features for Haiku, few of the things are actually on that list?
2 Likes
Another problem that worths our concern is whether x86 is still popular in 2043, or become a legacy system. I see how Haiku serves for a system for making legacy systems usable, but we have to evaluate this possibility, and figure out what should we do.
I agree there is stuff I probably could be doing. However the more cheeky side of my nature is to say: “back at’ya!”, since I feel you are the worst offender when it comes to wasting your time in the forum. I find your posts actually very informative and well crafted, and feel that the same effort would benefit haiku more if directed elsewhere. Whilst I can do my bit by trying to refrain from such questions as you feel the need to answer, for your part if you addressed the question in documentation rather than directly, it would be read many more times than if buried in a thread. Hopefully I will also be doing the same, since I cannot code but am quite capable of writing and evangelizing.
Seek external support for development projects that has affiliations with other communities is also very important, for example, hardware drivers. When part of the tasks can be distributed to partners, our own developers can focus more on core development tasks regarding the system itself.
To sell the cryptocurrency assets Haiku Inc. has been owning is another issue that has to be tackled to gain fundings for hiring more developers.
Unfortunately, my time sitting in front of an Haiku computer with my brain not exhausted from a day of C++ coding from my paid job, and able to dive into programming tasks, is limited.
My time posting on the forum, not so much limited, since I can access that from work during breaks, on my phone, and so on.
6 Likes
Don’t get me wrong, I’m not trying to be disrespectful, and of course your time is yours to spend as you want. Although often I feel a little guilty when I share a half-formed thought in the forum and get a long and insightful reply that would take me probably a morning to research and type out:)
1 Like
I started following BeOS and then Haiku just as I was out of high school and with not much experienge as a software developer. Then people took the time to explain things to me and I learnt a lot. I hope that I can give some of that back, and it seems no less important than writing code.
9 Likes
Thank you very much for writing so many insightful posts.
I have already learnt a lot from your detailed posts about Haiku internals.
I’m following this project for a few years now,and still I learn something new almost every day.
2 Likes
I’m sure you hear this a lot, but your efforts are appreciated!
4 Likes
API docs is really must for meaningfull development, even tho after API page is completed, is Examples page next? 
That would be a beneficial blog, showing how were these thing problematic.
Wow, thats a long way, true to 3d acceleration one of hardest part to start working on, but looking at recent ticket with Hyper-V support, it looks that something more neccessery is comming this year. Not just hope.
At which stage would you describe this OS..? in MacOS version: 10.6, 10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.15, 11, 12, 13, 14, 15, 26
To me POSIX and some BeOS goodies are already there, but when we look at DE side of joy, I mean desktop is in sorrow.
Could Haiku generaly benefit from this, besides Nvidia driver, I mena compositing and acceleration? Lets share knowleadge and branch, Im atm. learning this with AI chats
Looking at Trac, some of bugs a re-duplicate, and with similar bugs already in progress. I can make some time to wrote down bugs that fall down in this category. So its clear what is need and what is not. Imagine Alpha/3 bugs/issues still there and noone doing shit about them.
OpenGL|Vulkan + Skia can work with any other GPU, not just Nvidia. Skia also support software rendering. The problem with other GPUs is that it is much harder to make Haiku driver for them. Nvidia official open source kernel driver is made to be portable, so it consist of platform independent part and OS-specific part. So for Haiku you need to only make OS-specific part, platform-independent part will just compile almost without changes. Open source kernel drivers for other GPUs are heavily hardcoded to Linux kernel so it is a lot of work to port them to some another kernel. *BSD did this by implementing Linux kernel modules compatibility layer in their kernel: something like Wine, but for kernel mode modules. No such layer exists for Haiku for now and it will be not trivial to make it, Haiku and Linux kernels are quite different.
As for compositing, you can just use Skia draw bitmap functions and Skia will automatically call corresponding accelerated OpenGL/Vulkan API, so no need to make custom composited renderer.
Okay but then in the Future whole app making require some abstraction, for plesable devloping, Declarative UI or some other thing also with making nice animation and transparency with blur etc. I mean after API Docs complete, Is this the way to start? What Is your way of pushing? app_server_neo to prod. And then rest of code contributions via Skia? Im looking for some some general.
app_server_neo project have no plans to significantly extend API for creating GUI applications. Things like declarative UI or animations are out of scope. Only small API extension is planned for semi-transparent windows, GPU memory backed BBitmap, GPU synchronization and cache coherency.
Client applications will not use Skia directly, it will use BView::Draw* APIs as before.
Declarative UI stuff can be made unrelated to app_server improvements.
It is planned to put it first as GitHub repo when it will be usable enough and create HPKG packages for testing. Then make negotiations with Haiku development team what to do next.
3 Likes