A few months after my contract with Haiku, Inc. began, I rewrote the implementation of the Haiku kernel’s condition variables (as opposed to our userspace condition variables, which are from POSIX.) As this new implementation has run in Haiku for over a year and shipped in the latest release with no sign of any remaining issues, I figured it is high time for a deep-dive on the API, its implementation history, and the design of the new implementation I wrote. I expect this article will be of broader interest than just to Haiku’s community, because Haiku’s condition variables API has some notable (and powerful) features not found in those of other operating systems, and its implementation is thus likewise unique (at least, as far as I have been able to figure out.) I’m currently working on a “state of Haiku” sort of article, and I’m incredibly impressed with just how stable, fast, full-featured, and usable Haiku has become on real hardware. I’ve always kept an eye on Haiku in virtual machines, but now I’m running it on real hard hardware – where it belongs – and it’s been an absolute joy. The fact that waddlesplash managed to pull off this switch basically without any issues and with few people noticing, is further illustration the project’s in a good place.
Java technology has been moving forward much faster in recent years with more frequent updates. Java 17 Long Term Support (LTS) was introduced in September 2021 and will be followed by Java 21 LTS in September 2023. With HaikuDepotServer (HDS) still on Java 11 introduced in September 2018, it was time to upgrade to 17 and then also make the transition from Spring 5 to SpringBoot 3 which was released in November 2022. Spring is a base technology for SpringBoot with SpringBoot providing more configuration and functionality by convention. These upgrades will bring HDS up to date with the current state of the art in backend Java and allow HDS to be maintained more easily going forward. An interesting look at the steps taken during this upgrade process. There’s also a brand new Haiku activity report with tons and tons of fixes, new features, and updates.
The way Haiku handles package management and its alternative approach to an “immutable system” is one of those ideas I find really cool. Here’s what it looks like from a desktop user’s perspective – there’s all the usual stuff like an “app store”, package updater, repositories of packages and so on. It’s all there and works well – it’s easily as smooth as any desktop Linux experience. However, it’s the implementation details behind the scenes that make it so interesting to me. Haiku takes a refreshingly new approach to package management. A deep dive into Haiku’s surprisingly robust and full-featured package management system.
The fourth beta for Haiku R1 over a year and a half of hard work to improve Haiku’s hardware support and its overall stability, and to make lots more software ports available for use. Over 400 bugs and enhancement tickets have been resolved for this release. There’s a lot here to talk about. The improved support for HiDPI looks amazing, and definitely a must-have in today’s world of 4K displays. There’s lots of new and improved drivers, including a new compatibility layer for OpenBSD WiFi drivers, a new NTFS driver, and more. The number of ports has increased by a lot thanks to X11, Gtk+, and even Wayland compatibility – Inkscape, GIMP, GNOME Web, and more. Wine has also been ported to Haiku, using a Haiku-native windowing and input backend. And much, much more. Pretty good way to start Christmas.
Tonight’s story time: the Power Macintosh that wouldn’t make any sound in BeOS R5, how I figured out the problem, and how I hacked the sound driver to fix it. OSNews bait, 100%.
This is a real 133MHz BeBox running otherwise stock BeOS R5, surfing Hacker News and Lobste.rs using a modified, bug-fixed NetPositive wired to offload encryption to an onboard copy of Crypto Ancienne (see my notes on the BeOS port). NetPositive is the only known browser on the PowerPC ports of BeOS — it’s probably possible to compile Lynx 2.8.x with BeOS CodeWarrior, but I’ve only seen it built for Intel, and Mozilla and Opera were definitely Intel/BONE-only. With hacks for self-hosted TLS bolted on, NetPositive’s not fast but it works, and supports up to TLS 1.2 currently due to BeOS stack limitations. This is a modified version of the latest official NetPositive browser from Be, updated to somewhat work on the modern web, specifically for PowerPC machines like the BeBox and BeOS-compatible PowerPC Macs. It can load various modern sites, but as the author notes, OSNews refuses to load (we used to have a complicated system of recognising individual obscure platforms and browsers so we could serve them a limited version of the site, but that became increasingly difficult and time-consuming to maintain, for effectively no benefit other than bragging rights). You can download and run it using the instructions in the post, and more improvements are being considered. Absolutely excellent work.
The latest Haiku activity report has been published, and this one is heavy on the driver work. The intel_extreme driver has received quite a bit of love, and Haiku now has an RNDIS USB ethernet driover, which Android uses to share its WiFi connection, so you can now use an Android phone’s hotspot to get Haiku online (only a few devices have been tested so far, though. Another big improvement is the overhauled MTU. waddlesplash overhauled MTU (“maximum transmission unit”) and also receive size handling in the network stack and the FreeBSD compatibility layer. Previously, we always stayed at the default ethernet MTU of 1500, which was fine but suboptimal (as ethernet can usually support jumbo frames up to size 9000 or so), but more problematic was that we could not handle receiving anything larger than this, as it would trigger errors in the ethernet handler related to scattered I/O operations. This required a number of changes: first to the stack itself and to the IPv4 & IPv6 handlers to check the correct MTU value, then to the ethernet module to use larger buffers if necessary when reading or writing data, and finally to the FreeBSD compatibility layer to activate the larger MTUs. These changes had a side effect of fixing “high packet loss” on some devices (or at least PulkoMandy’s very recent Intel ethernet device, anyway.) This is just a small selection – there’s tons more, such as further improvements to the ARM and RISC-V ports, the addition of the OpenBSD WiFi stack to further widen Haiku’s WiFi driver pool, and tons more.
The latest Haiku activity report is here – covering the month of March – and it’s a real grab bag of tons of changes, but I’m not seeing any big ticket items. This means there should be something for everybody in here, from improved support for various Intel integrated grahpics chips, to more work on the ARM port, to glibc fixes, to… Well, you get the point.
Haiku’s latest activity report is out, and right off the bat, there’s a big ticket item. That’s right, after many years of being requested, Haiku finally has support for USB WiFi devices! (Currently only Realtek controllers are supported, but Ralink and others should follow before too long; Realtek/“RTL” chips are generally the most common, however.). That’s great news. There’s way more in here than just this, of course, so head on over to find out more.
Haiku’s latest activity report is here, and while there’s a lot of stuff in there – as usual – I think the Gtk work stands out this month. After all that work, GTK3 worked “well enough” that it seemed ready for general consumption (or at least testing), so waddlesplash committed the necessary changes to HaikuPorts for Xlibe to be packaged, and then GTK3, and then finally the first GTK3 application: Inkscape. Already, GIMP has followed closely on its tail thanks to 3dEyes (with some quick fixes to Xlibe done by waddlesplash for it), and more GTK3 applications are sure to follow once the HaikuPorts team gets caught up to speed on things. You can find screenshots on the forums of both GIMP and Inkscape running on Haiku. With that, waddlesplash has deemed the “GTK3 porting adventure” complete, and has returned to development work on Haiku’s core for this coming month. That’s a lot of progress, and two great applications to have running on Haiku.
Haiku continues to be on its roll, this time making tons of progress porting Wine to run on Haiku. Rockstar Haiku developer X512 has managed to not just start porting Wine to Haiku, but also to get so far as to run actual Windows applications on the platform. The screenshots in the Haiku forum thread speak for themselves. This is amazing work, and I can’t even begin to imagine how so much progress can be made in such short time. That being said – and the reason I’m late with this story – I’m not entirely sure porting things like Qt, X.org, and Wine are the best way forward for Haiku. As an old BeOS nerd, what I want are fully native, platform-optimised Haiku applications that make use of all the unique features the operating system has to offer. I’m not interested in yet another platform to run Qt applications, LibreOffice, and a small handful of Windows applications. I really don’t like being a grumpy old man when it comes to relatively small, alternative projects whose members code for free, but none of the recent amazing news coming out of Haiku has made me more interested in Haiku – in fact, it has only made me less interested, and less enthusiastic. Haiku and BeOS occupy a special place in my heart, and the focus shift from focusing on Haiku as an API-compatible clone of BeOS to yet another platform that runs Qt, X, and a few Windows applications worse than Linux or BSD do is not something I’m particularly thrilled with. But here’s the cool thing – what I think is, and should be, entirely irrelevant, and these developers need to keep doing what they want to do, whether randos like me want them to or not. That’s the nature of open source.
An Xlib compatibility layer implemented on top of the Haiku API, in order to run X11 applications on Haiku without an X server. Xlib‘s API is relatively low-level, but it is just high-level enough that it can be emulated on top of a higher-level API like Haiku’s. At present, it provides “most” commonly-used Xlib APIs, but many of them are stubbed or incomplete implementations. (GTK, with some hacks, can compile, link, and open a window before it runs in to missing functionality.) This is crazy person work by Haiku developer waddlesplash. He also posted continuously updated progress thread on the Haiku website, which provides a lot more detail about the process, the current state, and possible future plans.
Thanks in large part to the hard work by X512 and everyone developing on Haiku, our nightly RISCV64 images are now functional. RISC-V marks Haiku’s first functional non-Intel/x86 port! This is still crazy to me. This port has taken relatively little time, yet it marks a major milestone in Haiku’s history.
I implemented RadeonGfx driver server mode and now it is possible to run multiple processes that use 3D acceleration. Because of GFX ring reset hack, command buffer scheduling is limited and only one command buffer can be executed at moment of time. That’s right – that’s X512, the amazing developer who ported Haiku to RISC-V, now working on bringing initial 3D acceleration to Haiku. There’s a long road ahead for this to become a default, working part of Haiku, but that doesn’t make these first steps any less impressive.
After successfully getting Mesa’s software-based Lavapipe Vulkan implementation building on Haiku last month along with related Mesa code for headless support, a developer independent of AMD has started work on porting the Mesa Radeon Vulkan driver “RADV” to Haiku. Haiku developer “X512” has been spending the past number of weeks so far trying to get the open-source Radeon Vulkan driver stack working on this BeOS-inspired platform. This would be the first major Vulkan driver working for Haiku though there is also interest in getting the open-source Intel Vulkan driver working there too. This is exciting work, but still early days.
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.
Dedication asks each of its adherents to have faith even as time and energy pass through from one year to the next. Dedication brings with it a variety of challenges, but also rewards. Dedication is something most people claim to have, but few readily exhibit it in the face of adversity. As of today, Aug. 18, 2021, the Haiku Project is celebrating two decades of dedication, marking the 20th anniversary of the founding of the Haiku operating system and the start of this ride to save, maintain, and expand upon the BeOS legacy it spawned from. Congratulations to the Haiku project and all of its contributors.
Poetry is in motion. The Haiku Project, its developers and team members announced the Haiku operating system released its third beta release, version R1/Beta3, July 25th, 2021. Version R1B3 continues the trend of more frequent releases to provide users and developers with an up to date and stable platform to work on. This release combines the best of Haiku’s history as a spiritual successor of BeOS and the hard work of a passionate community. It provides several new features and performance improvements that make Haiku even better. WebKit, the backend of the bundled web browser developed by the Haiku team, WebPositive, received multiple major improvements. This provides a good base for further improvements as well as an improved browsing and website rendering experience in WebPositive, which developers will continue to focus on for the next release, Beta 4 and as Haiku nears its first initial release, R1. Going from beta 2 to beta 3 is a giant leap if you haven’t been keeping up. Haiku is much farther along than people think, with the biggest drawback being, as always, that hardware support is going to be a mixed bag. Haiku is still every bit as clean, fast, and enticing as the original BeOS was over two decades ago, and I’ve scored two junkyard office PCs to see if I can get a proper Haiku box running.
Hot on the heals of yesterday’s summary about recent Haiku news, we’ve got a big one – Haiku’s desktop running on real RISC-V hardware, the HiFive Unmatched. I finally managed to run desktop. Crashes was caused by unaligned access to framebuffer, access seems to require 16 byte alignment. I made some quick hack to enforce alignment in app_server when copying to front buffer, but it currently introduce artifacts. I don’t know why 16 byte alignment is required, radeon_hd driver works fine on Acer W500 tablet without alignment tricks. This is a big milestone.
A random collection of Haiku news today – starting with the latest activity report. With the release of beta 3 creeping every closer, there’s a lot to report in this one, from improving POSIX support, to improvements to the Intel video driver, to work on the bootloader, and a lot more. Secondly, there’s news on the RISC-V front. Two months ago, a lot of progress was made on porting Haiku to RISC-V, and earlier this month, the Haiku project decided to really support this effort by buying RISC-V hardware and donating it to the developer in question. The HiFive Unmatched board has made its way to the developer by now, so expect a lot more progress on this front in the future. Lastly, the project has decided to push back the release of beta 3 by one week. There’s one remaining nasty bug in the WebKit port, and since the team wants to make sure the browsing experience is the best it can be, they’ve decided to give the developers a bit more time to iron out this final bug.