Haiku R1/beta6: the little OS gets a bigger foundation

Haiku R1/beta6: the little OS gets a bigger foundation

An old laptop has a way of exposing waste. Open a few programs, copy files from a USB drive, start a build, and suddenly the machine feels as if every task is waiting in line. Haiku has always attracted people who enjoy a different kind of desktop: compact, responsive, and built as one coherent system rather than assembled from unrelated layers.

On August 26, 2026, the Haiku Project released R1/beta6, the first public beta in roughly two years. It arrived about a week after Haiku’s 25th anniversary and includes more than 530 resolved bug and enhancement tickets. A beta is still a pre-final release intended for wider testing, so this is not a promise that every hardware combination will behave perfectly. Still, the release is substantial.

What is new in Haiku R1/beta6, and is it worth trying on old hardware or in a virtual machine? The obvious answer starts with Firefox. The more interesting answer is buried underneath the desktop, in memory allocation, filesystem caching, package management, and recovery from failure.

Firefox gives Haiku a stronger web option

The headline application is Mozilla Firefox with official branding on x86_64, the 64-bit PC architecture used by most modern desktop computers. Firefox and several related browser ports are available through HaikuDepot, Haiku’s graphical software catalog.

That matters because a desktop operating system can feel isolated when its built-in browser falls behind the web. Haiku’s native WebPositive browser and HaikuWebKit remain important parts of the system, but Firefox gives users another engine for sites that depend on newer web standards. The port is currently an x86_64 feature, so a 32-bit Haiku installation should not be treated as an interchangeable version of the same experience.

The software ecosystem also gains a Go compiler and runtime. Go is a programming language designed for practical systems and network software, and having its tools in the package repositories gives developers another way to build native applications instead of working only with precompiled ports.

QEMU can use Haiku as a faster virtual-machine host

Haiku R1/beta6 also adds an experimental NVMM backend for QEMU on x86_64. QEMU is software that can emulate a computer or run another operating system inside a virtual machine. Hardware virtualization lets the processor execute much of that guest system’s work directly instead of making QEMU imitate every instruction in software.

NVMM, short for NetBSD Virtual Machine Monitor, is the low-level interface that connects QEMU to those processor features. On compatible systems with Intel VT-x or AMD-V, the basic QEMU command looks like this:

qemu-system-x86_64 -accel nvmm...

The trailing options would describe the guest image, memory, disks, and other virtual hardware. The important part is -accel nvmm. It signals that QEMU should use hardware-assisted virtualization rather than relying only on software emulation.

This support is still experimental, so a successful boot is the beginning of testing rather than proof that every guest, device, or nested setup will work. Even so, it changes Haiku’s role. The system has long been interesting to run as a guest; beta6 also makes it more useful as a host for experimenting with other operating systems.

The biggest improvements are the ones you may not see

The release contains broad performance work across the kernel, libraries, filesystem code, and applications. A MIME type is a label that tells the system what kind of file it is dealing with, such as an image, audio file, or document. Haiku’s MIME detection, or “sniffing,” was reworked so the system can identify files five to ten times faster in the relevant paths.

Caching received attention too. A cache is a faster copy of recently used information, kept nearby so the system does not need to search the disk or rebuild the same result repeatedly. In one project test involving a repository with more than 160,000 files, git status fell from roughly 15 seconds to about 2.5 seconds with a warm cache. With a cold cache, the result improved from around 33 seconds to 20 seconds.

Those numbers describe specific test conditions, not a universal promise for every computer. They do show where the work is aimed: repeated file access, large source trees, and development tasks that punish inefficient directory and inode handling. A comparable full rebuild of HaikuWebKit dropped from 4 hours 53 minutes on beta5 to 2 hours 33 minutes on beta6 under closely matched conditions.

Memory management also received a serious overhaul. malloc is the user-space memory allocator, the component that hands chunks of RAM to ordinary applications. Haiku replaced its long-used Hoard-derived allocator with a new design based substantially on OpenBSD’s allocator, while adding Haiku-specific caching. The goal is not only faster allocation, but better behavior when programs release memory and when older workloads trigger inefficient allocation patterns.

The release also improves low-memory recovery, memory-area splitting, and package bookkeeping. The notes cover problems on systems with 128 GB or more of RAM, while constrained 32-bit builds can again boot with as little as 128 MB in carefully reduced configurations. That does not make a 128 MB machine suitable for modern web browsing, but it illustrates how much attention went into keeping the operating system economical.

A desktop that recovers instead of giving up

Haiku’s app_server is the system component responsible for drawing windows and coordinating the graphical desktop. In beta6, it can restart after a crash and allow running applications to reconnect and rebuild much of their existing state. A failure in the graphics server no longer has to mean restarting the whole computer.

Several smaller changes improve daily work. Tracker, Haiku’s file manager and desktop, can narrow filesystem queries to a folder and its subfolders. The built-in Screenshot tool can capture a selected area, not only an entire screen or one window. DriveSetup gains better handling for disk images, which are ordinary files treated as virtual disks for testing, installation, or recovery.

Package management becomes more considerate of disk space as well. Haiku keeps package activation states so an installation can roll back to an earlier working set. Beta6 adds cleanup behavior and exposes pkgman cleanup, helping prevent old states from accumulating forever. A rollback state is useful insurance, but it is not a backup of personal files.

Upgrading needs a little care

Moving from beta5 to beta6 is broader than installing an ordinary application update. Haiku uses repositories, which are package servers containing software built for a particular release and processor architecture. Both the Haiku repository and the matching HaikuPorts repository need to point to beta6 before the full synchronization begins.

The upgrade has three conceptual steps:

pkgman add-repo <matching Haiku R1/beta6 repository>
pkgman add-repo <matching HaikuPorts R1/beta6 repository>
pkgman full-sync

The placeholders are deliberate: the exact repository paths and architecture names belong to the release-specific instructions. Run the first two commands, confirm that they succeed, and only then run pkgman full-sync, which performs the actual system transition. Before changing anything, copy important files somewhere outside the Haiku volume and keep bootable installation media nearby.

R1/beta6 feels less like a cosmetic refresh than a foundation release. Firefox broadens the web experience, NVMM gives QEMU a faster experimental path, and the allocator, caches, filesystems, and desktop recovery all address the quiet friction that accumulates over years. Haiku is still a beta operating system, but this is a remarkably mature kind of beta: small on the surface, busy underneath, and much more capable than the version number suggests.