Haiku R1/beta6 Ships After Nearly Two Years of Platform Work

Haiku released R1/beta6 on August 26, 2026, almost two years after R1/beta5 and about one week after the project’s 25th anniversary. The official notes count more than 530 resolved bug and enhancement tickets. Images remain available for 32-bit x86 and x86-64 systems.

The release is still explicitly beta-quality. Haiku describes R1 as feature complete but warns that known and unknown bugs remain and that it cannot promise protection from data loss. Beta6 is a broad integration release, not a declaration that the operating system has reached R1 final.

Firefox becomes a supported name on x86-64

Ports based on Mozilla’s Firefox codebase had begun appearing after beta5. During this cycle the port and Haiku-side support matured enough that Mozilla permitted use of the official Firefox branding. Firefox, LibreWolf, Waterfox, Floorp, and Icedove are available through the package ecosystem, though Firefox-derived applications are currently limited to x86-64.

That availability is important because WebPositive and HaikuWebKit have long carried the burden of the platform’s native browser experience. A working current Firefox codebase expands site compatibility while Haiku developers continue improving native components. The release notes also make the support boundary clear: Haiku-specific missing features should be reported to HaikuPorts rather than assumed to be Mozilla defects.

NVMM gives QEMU hardware acceleration

On x86-64, Haiku now includes a port of NetBSD’s NVMM virtual machine monitor. QEMU can use it on many Intel VT-x and AMD-V systems by adding:

qemu-system-x86_64 -accel nvmm ...

NVMM supports 32-bit and 64-bit guests, SMP, and a range of QEMU devices and options. Haiku labels the acceleration experimental, so a successful guest boot is the beginning of validation rather than the end. Nested virtualization, firmware quirks, and specific QEMU devices can expose untested paths.

The direction is notable: Haiku has often been run as a guest, while beta6 also makes it a more capable host for hardware-assisted virtual machines.

Performance work reaches the whole system

Beta6 includes changes across the kernel, filesystem paths, runtime loader, libraries, packagefs, and applications. The release notes call out finer locking in memory management and VFS code, faster string and memory routines, improved FIFO throughput, directory-cache changes, and reduced page-table work for temporary kernel buffers.

Haiku measured a repository with more than 160,000 files: warm-cache git status time dropped from about 15 seconds to roughly 2.5 seconds after directory-entry and inode-cache work. A comparable HaikuWebKit rebuild fell from 4 hours 53 minutes on beta5 to 2 hours 33 minutes on beta6. These are project measurements for specific systems, not universal benchmarks, but they identify the workloads the changes targeted.

A new userland allocator, based substantially on OpenBSD’s design with Haiku-specific caching, replaces the old Hoard-derived allocator. The goal includes better release of unused memory in long-running programs as well as improvement in workloads that triggered pathological behavior before.

The desktop recovers and cleans up more state

app_server can now restart after a crash and allow running applications to reconnect and reconstruct existing GUI state. That changes a display-server failure from a likely desktop restart or reboot into a recovery that can complete within seconds in many cases.

SoftwareUpdater now deletes old package activation states according to its settings, and pkgman warns when many old states have accumulated. The new pkgman cleanup command exposes removal directly. Previous states remain a powerful rollback mechanism; beta6 adds lifecycle management so they do not consume disk indefinitely.

Tracker can filter query results by folders, its menus update when modifier keys change, Screenshot adds area selection, Team Monitor groups helper processes beneath GUI applications, and DriveSetup can register and manipulate disk images. HiDPI and dark-mode corrections continue across first-party applications.

Hardware and memory work continue below the UI

The cycle includes memory-area splitting fixes, a unified memory and swap reservation system, better behavior on systems with 128 GB or more RAM, and lower packagefs bookkeeping cost. The 32-bit build can again boot in extremely constrained 128 MB configurations, although the official recommended environment is larger and modern browsers are not realistic there.

Graphics, USB, audio, networking, storage, bootloader, and device-support changes fill much of the release notes. That breadth is why an upgrade should begin with verified installation media and a backup, especially on hardware that depends on a particular beta5 workaround.

Upgrade as a recoverable package transaction

Existing installations can move to beta6 through the package system, but a release transition is broader than an ordinary update. Repository branches for both Haiku and HaikuPorts must point to the matching beta6 architecture, and pkgman full-sync may need to replace or remove packages rather than only install higher versions. Read the release-specific commands from Haiku’s own download page instead of copying an old mirror URL from a forum post.

Before changing repositories, save important data outside the Haiku volume, record pkgman list-repos, and keep a bootable image whose published checksum you verified. Package activation states provide a valuable rollback path, but they are not a substitute for a backup when filesystem or bootloader work is involved.

After the full synchronization and reboot, confirm the reported Haiku revision and architecture, refresh HaikuDepot, launch the applications that matter, and test networking, audio, graphics, suspend, and every storage controller on that machine. For a 32-bit installation, verify that the required applications still publish compatible packages; the new Firefox-family ports described for beta6 are an x86-64 feature.

If the upgrade does not boot, select the previous package state from the boot loader before attempting repairs. Preserve the failed state and create a report with hardware identifiers, source release, target architecture, repository list, and exact package transaction. A clean reinstall may restore the machine, but it destroys the evidence that can make the upgrade path better for the next user.

R1/beta6 is best read as a platform release: a modern browser port, host virtualization, allocator replacement, broad locking and cache work, and better recovery behavior all arrived together. The remaining beta label is equally important. Users gain a much more capable Haiku, while testers still need reproducible bug reports and recoverable data.

Related:

Sources: