# Haiku Beta 6 Nearly Halved a Five-Hour Build. I'm Still Using a Spare Disk. **Summary:** Haiku R1/beta6 nearly halves a HaikuWebKit rebuild and adds Firefox, hardware-accelerated QEMU, and broader hardware support. I think that makes it a compelling spare-machine OS, while its own data-loss warning keeps it off a primary system. - Canonical: https://markhuang.ai/news/haiku-beta6-five-hour-build-spare-disk - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-08-30 - Section: News - Tags: Haiku OS, Operating Systems, Open Source, Alternative Operating Systems, Retro Computing - Source: [Haiku Project](https://www.haiku-os.org/news/2026-08-26_haiku_r1_beta6) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![An older desktop computer running beside a separate modern workstation, with colorful feather-like light flowing from its screen](https://cdn.markhuang.ai/news/haiku-beta6-five-hour-build-spare-disk/hero.webp) *Haiku Beta 6 makes old hardware inviting again. I would still give it a test disk, not the disk that holds my only copy of anything.* [Haiku R1/beta6 arrived on August 26, 2026](https://www.haiku-os.org/news/2026-08-26_haiku_r1_beta6), almost two years after beta5. The short announcement understates the work behind it: the [official release notes](https://www.haiku-os.org/get-haiku/r1beta6/release-notes/) count more than 530 resolved bug and enhancement tickets, plus Firefox, hardware-accelerated QEMU on most x86\_64 systems with Intel VT-x or AMD-V, and a broad sweep of performance and hardware fixes. My read is simple. This is the first Haiku release in a while that makes me want to rescue an old PC just to see how pleasant it can be. It does not make me want to entrust that PC with my main working environment. The performance gains are concrete, but the project still calls the release beta-quality and says it cannot assure users against data loss. That warning sets the boundary. ## The speed claim has receipts The number that caught me was not the ticket count. On the same build host, a full HaikuWebKit rebuild fell from 4 hours 53 minutes on beta5 to 2 hours 33 minutes on beta6. A separate test of `git status` in a repository with more than 160,000 files dropped from about 15 seconds to 2.5 seconds with a hot disk cache. Those are source-reported tests, not a promise that every workload is twice as fast. The notes say straightforward compiles may improve only a little and put Haiku at roughly 40% behind Linux for compile performance. A Haiku developer offered more context in the [Lobsters discussion](https://lobste.rs/s/lt9i0j/haiku_r1_beta6_released): the system can approach parity on some workloads, but its stronger distinction is low input latency and a responsive interface rather than raw computation. I like that distinction because it gives Haiku a reason to exist beyond nostalgia. A personal computer can feel good even when it loses a throughput benchmark. Beta 6 also replaces its aging user-space memory allocator with one based largely on OpenBSD's, improves filesystem caching and locking, and cuts several fixed memory costs. The project says a stripped-down 32-bit installation can once again boot with 128 MB of RAM, though its published minimum remains 256 MB and modern Firefox is x86\_64 only. ## Firefox changes what the machine is for A quick desktop is charming until the browser becomes the slow, incompatible room where most work happens. Beta 6 does not solve the modern web, but it changes the proposition. Firefox now appears under its official branding, alongside ports derived from the same codebase. The release notes are careful here too: missing features or incomplete behavior compared with Firefox elsewhere should be reported to HaikuPorts, not Mozilla. Go is now in the package repositories as well, although the notes label the port as version 1.26.1, a bit out of date, and not yet submitted upstream. These additions benefit two groups immediately: curious users who need a viable browser, and developers who want to see whether Haiku can support real work instead of a guided tour around the desktop. Public reaction reflects that shift. In the [Haiku subreddit discussion](https://www.reddit.com/r/haikuOS/comments/1vz0g3b/haiku_r1beta6_has_been_released/), one commenter singled out Go as the feature that could make actual work possible. Another reported that beta6 felt less stable than beta5 on an older Dell laptop. Neither anecdote settles the release. Together, they are a useful reminder that a wider software catalog and dependable hardware support are different tests. ## A virtual machine has its own trap Trying Haiku in a VM sounds like the safest answer, and it mostly is. There is one sharp edge worth knowing before blaming the OS for an unbootable install. In the [OSNews discussion](https://www.osnews.com/story/145885/haiku-r1-beta6-released/), a Haiku developer confirmed that the `virtio_block` driver was disabled after intermittent disk corruption and kernel panics. `virtio_scsi` remains supported, but some virtualization interfaces choose `virtio_block` when the user selects a generic VirtIO disk. That caveat did not make the official release notes. It should affect the test plan. I would use a backed-up spare machine or verify the VM's virtual disk controller before installation. I would also avoid treating the new NVMM support as finished infrastructure. Haiku calls its QEMU acceleration experimental even though it supports 32-bit and 64-bit guests, multiple virtual CPUs, and many guest operating systems. > **Info:** > > My boundary is boring on purpose: use a disk you can erase, keep another copy of anything important, and confirm the VM is not using `virtio_block`. Beta 6 is interesting enough to install, but the release notes do not ask for production trust. ## The beta label is doing honest work Haiku has spent 25 years pursuing a specific kind of personal computer: fast, coherent, and built around its own ideas instead of assembling another Linux distribution. Beta 6 moves that project forward in ways a user can notice. Older package states can now be cleaned up, the screenshot tool can capture a selected area, newer x86 hardware gets more support, and a crashed `app_server` can usually restart while applications reconnect. Still, this is not the release where the beta label becomes ceremonial. ARM64 can reach the desktop under virtualization but is not part of the supported release images. WebPositive's multiprocess WebKit work remains unfinished. The tracker lists more than 3,900 open tickets, and the project's own warning about known and unknown bugs is unusually direct. That honesty makes the decision easier, not harder. I would install Haiku R1/beta6 for the same reason I would restore a well-designed old tool: not because it can replace every modern default, but because its priorities are still legible when I use it. Put it on hardware that has been waiting for a purpose. Give it a separate disk and a fair test. If it earns a larger role later, that should come from what survives daily use, not from turning an impressive release note into a guarantee the developers never made.