There’s a new Haiku monthly activity report, and this one’s a true doozy. Let’s start with the biggest news.

The most notable development in November was the introduction of a port of the Go programming language, version 1.18. This is still a few years old (from 2022; the current is Go 1.25), but it’s far newer than the previous Go port to Haiku (1.4 from 2014); and unlike the previous port which was never in the package repositories, this one is now already available there (for x86_64 at least) and can be installed via pkgman.

↫ Haiku activity report

As the project notes, they’re still a few versions behind, but at least it’s a lot more modern of an implementation than they had before. Now that it’s in the repositories for Haiku, it might also attract more people to work on the port, potentially bringing even newer versions to the BeOS-inspired operating system. Welcome as it may be, this new Go port isn’t the only big ticket item this month.

Haiku can now gracefully recover from an app_server crash, something it used to be able to do a long time ago, but which was broken for a long time. The app_server is Haiku’s display server and window manager, so the ability to restart it at runtime after a crash, and have it reconnect with still-running applications, is incredibly welcome. As far as I can tell, all modern operating systems can do this by now, so it’s great to have this functionality restored in Haiku.

Of course, aside from these two big improvements, there’s the usual load of fixes and changes in applications, drivers, and other components of the operating system.

Now this is a great initiative by the Haiku team: highlight a number of stale commits that’ve been without interaction for years, explain why they’ve stalled, and then hope renewed interest might grow (part 1 and part 2).

Recently some discussions on the forum led to asking about the status of our Gerrit code review. There are a lot of changes there that have been inactive for several years, with no apparent interest from anyone. To be precise, there are currently 358 commits waiting for review (note that Gerrit, unlike Github and other popular code review tools, works on a commit-by-commit basis, so each commit from a multiple-commit change is counted separately). The oldest one has not seen any comments since 2018.

Today, let’s have a look at some of these changes and see why they are stalled. Hopefully it will inspire someone to pick up the work and help finishing them up.

↫ Pulkomandy at the Haiku website

Browsing through the highlighted stalled commits, there’s a few that seem quite interesting and relatively easy for a (new?) contributor to seek their teeth into. For instance, there’s a stalled commit to remove GCC from Haiku images built with clang/llvm, which stalled mostly because there are still other issues when building Haiku with clang/llvm. For a more complex problem, there’s the issue of how every menu in BeOS/Haiku is also a window, including its own thread, which means navigating deeply nested menus creates and destroys a lot of threads, that all need to be synchronised, too. If you want to get really ambitious, there’s the stalled commit to add initial 64bit PowerPC support.

There’s more of these, of course, so if you have the skills and will to contribute to a project like Haiku, this might be a great place to start and get your feet wet. Now that these commits are back in the spotlight, there’s sure to be team members and regular contributors lined up to lend an extra hand, as well.

Another month, another Haiku activity report, and this time we’ve got a major change under the hood: a brand new guarded heap. The old guarded heap was suboptimal and had started to lag behind, so the new one attempts to rectify some of these shortcomings.

So, to rectify these limitations, I rewrote the kernel guarded heap more or less from scratch, taking the old code into account where it made sense but otherwise creating entirely new bookkeeping structures, interacting directly with the page table and virtual memory systems, and more. This new guarded heap implementation frees physical pages when not in use, meaning that the “virtual memory reuse disabled” mode now runs for quite long periods of time (indeed, I could successfully boot to the desktop and run compile jobs.) It also prints more diagnostics when kernel panics due to memory faults inside the heap happen, which the old kernel guarded heap didn’t (but the userland one has always done).

↫ Haiku’s activity report for October

The new guarded heap is optional for now, but Haiku is planning on releasing some pre-built test builds so users can start testing it out. Of course, this isn’t the only change or improvement from this past month – the list of changes is long, but there’s no real tentpole features here. Haiku’s development pace is still very much on track.

Another month, another activity report from the Haiku project. This past month, a lot of work went into the FreeBSD/OpenBSD network driver compatibility layer, opening the door to drivers using interfaces other than PCI or USB. Support for NFS4 took a bit of a hit with last month’s changes to VFS, and these have been addressed, and other aspects of NFS4 have been improved as well. On top of these two bigger items, there’s a list of smaller changes and fixes as well, but it’s been a calm month for Haiku so there’s less activity than normal.

I’m not sure what to add in a second paragraph here. I’m nearing act 3 in Silksong? Is that relevant here? I doubt it, but I still wanted to mention it. Only a few loose ends in act 2 and on Hornet goes!

Another month, another summary of changes in Haiku, the BeOS-inspired operating system. The main focus this past month has been improving the performance of git status, which has been measurably worse on Haiku than on Linux running on similar hardware. This work has certainly paid off, as the numbers demonstrate.

The results are clearly more than worth the trouble, though: in one test setup with git status in Haiku’s buildtools repository (which contains the entirety of the gcc and binutils source code, among other things – over 160,000 files) went from around 33 seconds with a cold disk cache, to around 20 seconds; and with a hot disk cache, from around 15 seconds to around 2.5 seconds.

This is still a ways off from Linux (with a similar setup in the same repository, git status there with a hot disk cache takes only 0.3 seconds). Performance on Haiku will likely be measurably faster on builds without KDEBUG enabled, but not by that much. Still, this is clearly a significant improvement over the way things were before now.

↫ Haiku Activity & Contract Report, August 2025

There’s more than this, of course, such as initial support for Intel’s Apollo Lake GPU in the Intel modesetting driver, improvements to USB disk performance, a reduction in power usage when in KDL, and much, much more.