Another month has passed, so time for another monthly update from the Haiku team. This time around, we get two for the price of one. First, the regular monthly activity report, where we can read that work on the ARM64 and RISC-V ports continues, and while these ports are nowhere near complete, they serve an important function both in discovering bugs and issues, as well as in getting Haiku ready for future architecture transitions. Tracker also received thumbnail support, but this is disabled by default for now, and of course, there’s a lot of low-level work being done, too.
The second update comes from waddlesplash, Haiku Inc.’s actual paid full-time developer. In his report, he details his work on fixing two Haiku bugs that caused frequent crashes in WebKit, as well as extensive work on the USB stack – more specifically, improving USB 3.0 support. On top of that, he also details a lot of his low-level work over the month of September.
Glancing through their coments they look like they need someone with business skills. That’s not to sell out and they’re right to be circumspect due to predatory cynicism but there’s some negativity there. Code portability is an issue. Nobody treats this seriously. The person whining about not needing GPU support has to bear in mind running Haiuku in a VM sluggishly is not going to win friends. Nor is a VM running Windows or Linux on Haiku riunning sluggishly going towin friends. GPU support is must to make it easy for people to bring none native applications over. Dual monitor support is a must to support laptops in dock configurations. I would also spend time producing a DDK or equivalent with sample code and case studies to make life easy for new developers and developers porting code. Make it easy so they don’t have to fight the system. Also expecting developers to immediately grasp BeOS/Haiki pervasive threading is a big ask. You way as well expect the world to dump C/C++ for Erlang. It’s not going to happen. I keep going on about it but there is a need for a universal portability layer which should be a default #include across all projects and every single project including so-called portability frameworks should include it by default. The only reason it’s needed is because C/C++is pseudo portable but the need is still there.
As for a paid contractor having a general brief speaking for myself I find this more workable. They’re just going to be more creative and engaged and be able to put maximum energy in more of the time so likely to get 2-3 times more work done even if it isn’t always visible. This was a good move by the Haiku project.
As for attracting games 90% of applications and games in existance are written for a Windows XP baseline. Almost all Windows games have a stupid number of none portable dependencies mostly due to DirectX. Nothing is going to be a straight recompile but for legacy Windows games support you have a fixed target. Newer games are easier in some ways as D3D 12 is Microsoft’s NIH version of Vulkan and a thin wrapper over common underlying hardware.