R1/beta6 – Release Notes
Haiku is developed by a small team mostly composed of volunteers, without the use of code or any other materials generated by ‘AI’ in first-party components. If our mission to build an open-source desktop operating system that specifically targets personal computing sounds appealing, consider getting involved!
The sixth beta for Haiku R1 comes just about a week after **Haiku’s 25th anniversary.** We’ve come a long way since the project began a quarter-century ago in 2001. Thank you to everyone who’s supported us thus far, and here’s to another 25 years of Haiku!
This release contains almost two years of the development team’s hard work to improve Haiku’s features and overall stability, and to make more software available for use. Over 530 bugs and enhancement tickets have been resolved for this release.
Please keep in mind that Haiku is beta-quality software, which means it is feature complete but still contains known and unknown bugs. While we are increasingly confident in its stability, we cannot provide assurances against data loss.
For all of this release cycle, waddlesplash was employed as a contractor to work on Haiku. His contract is presently ongoing, supported by the generous donations of readers like you to Haiku, Inc., a 501(c)3 non-profit.
_To download Haiku or learn how to upgrade from the previous release, see “Get Haiku!”. For press inquiries, see “Press contact”._
System requirements
This release is available for x86 32-bit and 64-bit platforms.
#### MINIMUM (32-bit)
- **Processor**: Intel Pentium II; AMD Athlon
- **Memory:** 256MB
- **Monitor:** 800x600
- **Storage:** 2GB#### RECOMMENDED (64-bit)
- **Processor**: Intel Core i3; AMD Phenom II
- **Memory:** 2GB
- **Monitor:** 1366x768
- **Storage:** 16GB
New features
Mozilla Firefox
A few months after the R1/beta5 release, the first working web browsers based on the Mozilla Firefox codebase appeared in the software depots. They were initially quite buggy, and didn’t use official branding. Over the last two years, things have gotten more stable (thanks to work both on the Haiku side and in the port itself), and recently Mozilla gave permission for the official “Firefox” branding to be used. So if anyone asks “Does Firefox run on Haiku?”, you can now say “Yes, it does!”
A variety of other software based on the Firefox codebase is also now available in HaikuDepot, including LibreWolf, Waterfox, Floorp, Icedove (a de-branded version of Thunderbird) and more.
(Note that Firefox and derivatives are only available for x86_64 at the moment. And since Haiku is still beta-quality software, if you encounter any missing features or incomplete functionality compared to Firefox on Linux or other OSes, that’s probably our fault, not Mozilla’s, and any such problems should be reported to HaikuPorts.)
Hardware virtualization for QEMU (on x86_64)
Haiku now supports “NVMM”, the NetBSD Virtual Machine Monitor (which originated on NetBSD, but already had been ported to at least DragonFlyBSD as well before Haiku). This provides support for hardware virtualization to QEMU on most x86_64 systems supporting Intel VT-x or AMD-V. It supports both 32-bit and 64-bit guests, SMP, a wide range of QEMU’s emulated hardware and options, and many different kinds of guest OSes. Just add `-accel nvmm` to your QEMU command line arguments.
(_Note that NVMM acceleration is still somewhat experimental. Please report any problems you encounter on the bug tracker._)
Software ports
The HaikuPorts project continues to maintain a wide variety of software ports to Haiku. There are simply too many new ports to list all of them here (including many KDE and GTK applications), but here’s one of the more notable ones:
Go
There is now a port of the Go programming language compiler and runtime available in the package repositories. Note that this port is a bit out of date (1.26.1), and hasn’t been submitted for inclusion in upstream Go yet; but many features and packages have already been confirmed to work on Haiku, perhaps with a bit of patching (including Hugo, the static site generation tool used for the main Haiku website itself.)
Changes & bug fixes
Hundreds of bugs and other minor issues or enhancement requests were resolved since the previous release, and there are simply too many to try and list them all here. (The monthly activity reports contain a much more complete accounting of the changes.) Practically every area of the system received some amount of attention, and the result is Haiku’s most polished and stable release thus far, though some rough edges remain here and there.
System-wide performance optimizations
There are quite a lot of changes and refactors across most of the system to improve performance in this release. Here are a few of the (rather technical) highlights:
- refactored MIME sniffer buffer management (speeds up MIME sniffing by 5-10x or more)
- faster (and in some cases, better) string hashing routines
- improved locking granularity in many parts of the kernel: memory manager (memory reservations and unreservations), VFS (file descriptor lookups, unused vnode state changes, I/O context root lookups), user timers, and more.
- exclusive-lock avoidance in the FIFO (`pipe()`) implementation, improving throughput from hundreds of MB/s to multiple GB/s
- more arena allocators for scratch buffers (e.g. FIFOs, `packagefs`), avoiding kernel page table changes and invalidations
- skip regular `fork` operations on `vfork` (we don’t support a true `vfork`, but implement the call for compatibility)
- replaced or rewrote many basic library calls with more optimized versions: `memmove`, `strlen`, `strcmp`, `memcmp`, and much more
- re-tuned size classes of the kernel `malloc` (they hadn’t been adjusted since 2007)
- added heuristics for pre-mapping of large files (benefits large applications that are spawned many times, e.g. `gcc`)
- use non-exclusive locks and atomic operations where possible in kernel primitives to send messages to other CPU cores
- directory-entry cache refactored to not need a write-lock when adding entries to the cache, and also to cache string hashes to avoid unnecessary string comparisons
- read-write locking in the disk (inode) block cache (used for filesystem metadata)
The last two items in particular had a dramatic effect on operations that access many files in quick succession, such as `git status`. In one test, after those changes, `git status` in a repository with over 160,000 files went from ~33s to ~20s with a cold disk cache, and from ~15s all the way down to ~2.5s with a hot disk cache!
The cumulative effect of all these optimizations (plus the memory-management changes detailed below) on compile performance can be quite significant. Relatively straightforward compile jobs may be only a bit faster than before (which is around ~40% slower than Linux), but highly involved compile jobs may perform very differently. A full rebuild of HaikuWebKit (same version, same compiler, very similar dependency package set, same buildhost) took 4h53m on R1/beta5, and 2h33m on R1/beta6, a decrease of close to half!
User interface and user experience improvements
In Tracker, Haiku’s file manager, there are a number of operations that behave differently if they (or the corresponding shortcut) is invoked with the “Shift” key pressed. Now, if you press or release that key while a menu’s open, the menu actions that behave differently will change to show what the “shifted” action actually is.
#### Tracker: folder-filtering queries
One of the unique features of BeOS which Haiku has inherited and enhanced is its “database-like” filesystem, with advanced support for extended attributes and filesystem-native indexing of those attributes, allowing arbitrary “queries” to be run against an entire filesystem to rapidly find files matching particular expressions.
Queries themselves search the entire filesystem (as indexes don’t store path information), but sometimes you may want to look at only files in particular directories. To that end, Tracker now allows you to select folders in its “Find” window, and will filter the query’s results to show only files from those folders (or subfolders).
(The command-line `query` tool also gained support for folder-filtering query results.)
#### SoftwareUpdater &`pkgman`: disk cleanup
Haiku packages are really block-compressed filesystem images, which are mounted at every boot into a sort of “union” to build the system’s filesystem. This means that installation and uninstallation is cheap, because it just adds or removes a package from the “union mount”, and so the system can save the old packages in a “previous state” in case you want to roll-back changes (or even boot into a previous state, which you can do directly from the bootloader.)
Previously, such “previous states” were never cleaned up automatically (though there were some third-party tools to manage them), which meant they could just accumulate indefinitely, taking up more and more disk space. Now, SoftwareUpdater automatically deletes older states after some time has passed (though you can disable this in its settings), and the `pkgman` command-line tool notes when there are a lot of older states and suggests running `pkgman cleanup` to remove some of them.
pkgman install/uninstall/full-sync...
[system] Changes applied. Old activation state backed up in "state_2026-08-22_22:38:28" [system] Cleaning up ... [system] Done. [system] 3 old state(s) can be cleaned up. Use "pkgman cleanup" to remove them.
$ pkgman cleanup Clean up 3 old states (166.27 MiB)? [yes/no] (yes) :
#### Screenshot: area select
The built-in “Screenshot” tool (which appears when you press `PrintScreen` on your keyboard) gained the ability to select a specific area of the screen for a screenshot. (It already had support for screenshotting the entire screen or individual windows.)
#### Team monitor: team grouping
“Team monitor”, the tool that appears when you press `Ctrl+Alt+Del`, now groups any non-GUI applications spawned by GUI applications underneath their parent. This makes dealing with multiprocess web browsers (which spawn a lot of subprocesses) or terminals much easier.
It’s now possible to work with disk images directly from DriveSetup, Haiku’s partition manager and editor, through a new “Disk image” menu. You can copy partitions to disk images, write disk images to partitions, and also register disk images with the kernel to be able to work with them as if they were themselves disks (mounting, unmounting, creating or deleting partitions, and more.)
#### app_server: restart handling
app_server, Haiku’s GUI application server (display server, window manager, and drawing server), when restarting after being killed or crashing, can now handle all running applications reconnecting to it and re-establishing all their existing state. This means that app_server crashes no longer require rebooting the system or restarting your desktop to recover from them: instead, in most cases, all running applications will automatically reconnect once the server finishes restarting, and you can continue right where you left off. Most of the time, this will happen in a few seconds or even less.
#### PowerStatus: Improvements on systems with multiple batteries
PowerStatus, the application that displays battery information (and the battery status icon in Deskbar), received a lot of improvements to its operation on systems with multiple batteries, especially when batteries are removed at runtime or charge and discharge at different times or rates.
#### More “dark mode” & HiDPI fixes in many applications
There were a lot of fixes and improvements to make many built-in (first-party) Haiku applications handle “dark mode” and high-DPI setups properly: fixing hardcoded colors, blending, sizes, and more.
#### `launch_roster`: status overview
The command-line tool (`launch_roster`) for interacting with Haiku’s launch and services manager (`launch_daemon`) got a big upgrade, to display the status of all registered jobs and services at a glance in a table format:
$ launch_roster Name Type State Enabled ---------------------------------------------------------- check-daylight-saving-time job stopped yes first-login job stopped yes update-time job stopped yes x-vnd.be-trak service running yes x-vnd.be-tskb service running yes x-vnd.haiku-app_server service running yes x-vnd.haiku-autologin job stopped yes x-vnd.haiku-debug_server service running yes x-vnd.haiku-media_server service running yes x-vnd.haiku-mount_server service running yes x-vnd.haiku-net_server service running yes x-vnd.haiku-notification_server service stopped yes x-vnd.haiku-package_daemon service running yes x-vnd.haiku-power_daemon service running yes x-vnd.haiku-registrar service running yes
System-wide memory management refactors
Besides the system-wide performance optimizations, there were also quite a lot of refactors and overhauls to memory management subsystems across the whole system, some of which contributed to the performance optimizations mentioned in the previous item, but many of which didn’t affect performance much either way (though a number did affect memory usage). Here are some of the highlights:
- optimized data structures in `packagefs`, lowering bookkeeping memory usage by ~20% or more (~15MB on one test system, actual difference depends on the installed files count)
- more efficient and correct memory attribute handling (on x86 & x86_64)
- corrected and more efficient handling of `mprotect`‘ed areas being copied-on-write
- many fixes to booting and running on systems with lots of RAM (128 GB or more)
- avoid per-file node monitors in Tracker, instead watch whole directories or queries (saves kernel memory)
- unified reservation system for both memory and swap
- fixes to incorrect buffer management in the bootloader (saves as much as 100MB or more of after-boot usage)
The combined effect of these changes is that it is now possible once again to at least boot Haiku on 32-bit systems with just 128 MB of RAM (though you may need a “stripped-down” install to make things run smoothly), and even get some work done with it. So long as you don’t need any modern web browsers, that is!
A few changes besides the ones enumerated above deserve special mention and discussion in particular. These are:
#### New userland `malloc`
For a very long time, Haiku used a custom version of the “hoard” memory allocator as its default userland allocator (i.e. the implementation backing `malloc` and related C standard library calls.) This allocator was showing its age, especially when compared against newer allocators (or more recent versions of “hoard” itself) and was due to be replaced for quite some time.
After evaluating various alternatives, we eventually devised an allocator based in large part on OpenBSD’s, but with a number of our own changes (e.g. a global caching layer.) This new allocator provides modest performance improvements over the old “hoard” in most cases, huge performance improvements in a handful of cases that triggered pathological behavior in the old allocator, and has significantly better behavior around releasing unused memory back to the system (which provides large benefits for long-running applications, especially on lower-end hardware where memory can get tight.)
#### Memory area splitting improvements
When an application or library requests a large chunk of memory (e.g. via `mmap`), but then wants to release a smaller chunk in the middle of this bigger one (e.g. via `munmap`), the kernel has to split up the larger area’s bookkeeping data into two areas instead of one. This is actually a somewhat tricky thing to implement, especially if the chunk of memory in question is shared between processes, has per-page protections (as set by `mprotect`), or other special circumstances.
Haiku had a partial implementation for this previously, but our old userland `malloc` didn’t make use of it, so it was only ever exercised by third-party applications that did advanced memory management on their own (or shipped custom `malloc` implementations), which is relatively rare, and so it wasn’t particularly well-tested. The new userland `malloc` uses this functionality very frequently, however (and the new web browser ports also make use of it), and so it was refactored significantly to bring it up to par.
#### Improved behavior on low memory
Haiku does not overcommit most memory (and thus doesn’t have an “OOM killer”): overcommitting is opt-in, per-area/per-memory-region only, and any overages result in potential negative consequences only for the applications that requested overcommitting (and even then, they still have a chance to catch the problem and recover gracefully.) All other memory areas reserve (but don’t allocate, as that would just degrade performance) their memory up-front, and if not enough is available, creation fails with `ENOMEM` or similar standard errors.
But just because the system returns errors, doesn’t mean all parts of the system are prepared to deal with those errors. Since any memory allocation that isn’t backed by already-reserved memory can fail, the kernel and drivers need to tolerate `malloc` (or equivalent routines) returning `ENOMEM` when the system is in a low-memory state, while on other OSes, kernel-level `malloc` is guaranteed not to fail (since, if there’s no other memory available, it’ll just kill some userland application to make it available.)
Failing to handle those errors (or the various other uncommon states that can occur when the system is low on memory) can result in strange system behavior, or even softlocks or crashes. A number of those problems were fixed in the memory-management changes this release cycle, and the system is now much more capable of recovering from critically low memory states than it was previously.
#### `guarded_heap` improvements
In addition to the default kernel and userland `malloc` implementations (which are designed and tuned for general “production” use), Haiku has a number of debug `malloc` implementations built-in to the system. One of these is the `guarded_heap`, a `malloc` implementation that puts every single allocation at the end of its own memory page right next to an unmapped page. This wastes _huge_ amounts of memory and address space, but it is 100% effective at catching non-timing-sensitive buffer overruns (and, with memory reuse disabled, also use-after-frees and double-frees) and without requiring any additional instrumentation (that is, there’s no need to recompile with `-fsanitize` or any other special option.)
The kernel’s `guarded_heap` was completely rewritten during this release cycle, bringing it more up to par feature-wise with the one available in userland. And much like the one available in userland, it can now be activated at runtime (via the bootloader options) instead of requiring a recompile, at least on nightly kernels (release kernels have the option compiled out, for more performance.)
Filesystems improvements
There were a significant number of improvements to Haiku’s filesystem drivers in this release. Some of the highlights of these changes include:
- **FAT**: support for 2TB+ disks, support for disks & filesystems with 4KB sectors, block prefetching for faster mounting
- **NFSv4**: many refactors and bugfixes, asynchronous I/O improvements
- **BFS**: optimized free-block scan, better index selection for queries, avoid unnecessary get/put of identical cached blocks
- **RAMFS** (which backs `/var/shared_memory`&`shm_open`): many fixes, refactors, and improvements, many prompted by the Gecko/Firefox port’s use of shared memory
Besides the filesystem drivers themselves, a number of changes in the general file-data caching system have also been made in this release. The most significant of these is that there is now one file-data write queue for each disk device (instead of only one for the whole system), and these queues keep track of the speed at which modified data is being written back to the underlying device, and the file-data caching system tries to prevent the queues from growing too large.
This means that the problem seen on many Linux systems (at least with the default settings), where large amounts of data may appear to be “copied” very rapidly to a partition on a slow device, but then unmounting or `sync`‘ing takes a very long time (because in reality the data was just added to the kernel’s caches, which is very fast, and not really written out to the slow device), won’t happen in most cases on Haiku: instead, the caching layer will notice the write queue growing faster than it’s getting written out, and prevent further writes from happening until some data is flushed. This means that copies of large amounts of data from fast disks to partitions on slow disks will now run at a rate much closer to the disk’s actual write speed, and the final `sync` should take only a few seconds at most.
Improved hardware compatibility
This release contains many hardware compatibility fixes and improvements, especially for very recent (last ~5 years) x86 systems. Many machines that the previous release did not boot on at all should run R1/beta6 quite smoothly, with most basic hardware supported by built-in drivers.
#### Audio output fixes and improvements
A number of problems leading to audio output being completely or partially broken, especially on lower-end hardware, have been resolved in this release. As part of this work, lazy initialization was also implemented: now, sound output hardware won’t be fully initialized until you actually try to play media for the first time, saving power and CPU cycles.
#### VESA BIOS live-patching
On systems where we don’t have a modesetting-capable driver, we have to use a fallback graphics driver instead: a dumb framebuffer on EFI, and VESA on legacy BIOS systems. VESA supports changing the video mode at runtime, however it only allows choosing modes from a preset list, so most of the time, if you want a custom video mode, it’s unfortunately not possible without a full modesetting driver.
However, on some hardware, it’s actually possible to modify the VESA BIOS directly, to insert custom video modes into the list of presets and then make use of them. Haiku now implements this for select VESA BIOSes where this technique is known to work.
#### More support for USB ethernet & WiFi adapters
Haiku has a source compatibility layer that allows using network drivers from FreeBSD and OpenBSD mostly unmodified. Since the last release, it was enhanced to add support for USB ethernet drivers, and to expand compatibility with USB WiFi adapters. Additionally, the existing drivers were synchronized with upstream FreeBSD and OpenBSD, so a variety of additional hardware is now supported.
Improved POSIX compatibility
Haiku is always looking to see how we can improve our adherence to POSIX and make it easier for developers to port their software. The most recent version of the POSIX standard was published just a few months before our previous release, so a lot of the changes and new features in it are in this release, not our previous one. There are too many changes and additions in this area to individually list, but here are some highlights:
- `O_CLOFORK`
- `MSG_CMSG_CLOEXEC`, `MSG_CMSG_CLOFORK` for sockets
- `SOCK_SEQPACKET`, `MSG_TRUNC`, `MSG_PEEK` for `AF_UNIX` sockets
- `WCOREDUMP`
- `getresuid`, `setresuid`, `getresgid`, `setresgid`
- `pipe3`, `dup2`, `mkostemp`
- `reallocarray`, `memmem`, `qsort_r`
- `posix_devctl`
- `pthread_getcpuclockid`
- `posix_spawn_file_actions_add[f]chdir`
We also implement a number of GNU and/or BSD extensions to the POSIX standards where they are needed or sensible. Here are some highlights of the changes and additions in that area:
- `RTLD_NOLOAD`, `RTLD_GROUP`
- `getloadavg`
- `closefrom`, `closerange`
- `EV_RECEIPT` and Haiku-specific objects (ports, semaphores) for `kqueue`
- custom serial baudrates (via `cfsetispeed`)
- improved compatibility with the FUSE API (for `squashfs` and `exFAT`)
Additionally, all extensions should now be visible by default in the C/C++ headers, unless “standards mode” is requested (by defining `__STRICT_ANSI__` or `_POSIX_C_SOURCE`, which are defined implicitly by the C/C++ compiler when requesting a specific standard version, e.g. `-std=c++11`, instead of the equivalent “GNU” version, e.g. `-std=gnu++11`.)
General stabilization work
A significant amount of time has been poured into work on stabilizing the whole system, with a great many kernel and driver crashes, hangs, corruptions, boot failures, and more tested, tracked down, and fixed over this release’s development cycle. Overall, the system seems to be more stable than ever before.
“Not just yet…”
Unfortunately, not all the development work merged over the last two years has made it into this release, as some of it remains experimental and disabled by default. Here are some of the more interesting features which are still in development:
ARM64
Thanks to the efforts of a variety of different contributors, the ARM64 port now boots all the way to the desktop under virtualization! (One contributor even has an unmerged branch that gets it booting to the desktop on Apple M1 hardware.) There’s still a lot of work to be done, but overall this is very significant progress over the state of the code under R1/beta5.
Multiprocess WebKit
Haiku’s built-in WebPositive still uses the single-process version of the WebKit engine, but there’s been good progress behind the scenes in getting multiprocess mode to work on Haiku. Already the browser engine starts and can display basic websites, but there’s a ways to go before WebPositive itself can be switched over.
New contributors
Since the last release, there is 1 new Haiku developer with commit access: Zardshard, who’s been working on Icon-O-Matic and other first-party Haiku applications. Welcome!
Source code
The source code of Haiku itself can be accessed from the GitHub mirror or via Haiku’s own Git instance. Patches can be contributed via Gerrit.
Reporting issues
There are over 3,900 open tickets on Haiku’s bug tracker and over 16,000 closed items. If you find what you believe to be an issue, please search the bug tracker to see if it has already been reported, and if not, file a new ticket on the bug tracker.
For information about major issues that have been fixed since the release, visit the Release Addendum page.
For more help, take the ‘Quick Tour’ and read the ‘User Guide’, both linked on the Haiku desktop. WebPositive opens by default with our ‘Welcome’ page which provides useful information and many helpful links, as does the Haiku Project’s website.
For support and/or help with anything related to Haiku, feel free to post on our forums, join one of our IRC/Matrix/XMPP rooms, or send a message to one of our mailing lists so our friendly community may assist you.
Press inquiries may be directed to:
- English: waddlesplash `(at)` gmail `(dot)` com
- German: humdinger `(at)` mailbox `(dot)` org