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.
http://www.reactos.org
https://appdb.winehq.org/
Which ReactOS tracks for their Windows compatibility.
https://en.wikipedia.org/wiki/C_POSIX_library
https://xkcd.com/927/
Also…
https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html
https://wayland-book.com/
Of course, the applications probably aren’t going to fit Haiku’s preferred hyper multi-threading paradigm and suffer as a result.
Except Wayland is Linux specific. So far from portable.
Why must they do or implement any of these things?
Because the 90s are going to be rad!
@123king
What have my comments on API compatibility, and portability of C/C++ and coding practcies got to do with your comments? You lack comprehension and expertise so further dicussion is a waste of time.
Take your meds.
Haiku has evolved with breakneck speed and is quite usable even without graphics acceleration.
Honest question: How many people are actually using Haiku day to day?
I have tried it several times in the past in a virtual machine. I think I might have done a bare bones install as well. However even after so many years, it never reached a point where I said “this is nice, I should use this on my computer”.
Many small OSes have a niche, ReactOS can be used to support industrial systems, FreeDOS can be used for BIOS update discs, QNX runs on NASA missions, OS/2 powers ATM machines. Even Linux back in the day was allowing a daily hobby system (now is much more mature of course).
But I can’t place Haiku on anything else than “curiosity”.
Maybe it is time they found their “killer app”, so that at least some use cases it will be a viable alternative. Otherwise it could forever stay as a moving target.
There were some AV solutions based on BeOS, and they use Haiku as a replacement from what I remember.
There’s a digital music management app for radio stations that ran on BeOS that was ported to Haiku. The name escapes me at the moment.
TuneTracker.
http://www.tunetrackersystems.com/
Nice.
Thank you for the link. According to their “Google Earth” file they are used by quite a lot of radio stations.
VxWorks runs on NASA missions. QNX runs on your car.
Haiku is basically a hobby OS. Basically the people using it are mainly its developers. Exists only to exist.
There’s no killer app. It was an evolutionary dead en into the race for a desktop OS. Some people like, so there’s no other reason needed.
That’s as good a reason as any.
The developers do it because it’s fun, if anyone else likes to use it then that’s just an added bonus.
I don’t imagine that any of them believe Haiku is going to replace Windows or even Linux on the desktop in any significant numbers.