R1/beta1 – Release Notes

It's been just about a month less than six years since Haiku's last release in November 2012 — too long. As a result of such a long gap between releases, there are a lot more changes in this release than in previous ones, and so this document is weightier than it has been in the past. The notes are mostly organized in order of importance and relevance, not chronologically, and due to the sheer number of changes, thousands of smaller improvements simply aren't recognized here.

Please keep in mind that this is beta-quality software, which means it is feature complete but still contains known and unknown bugs. While we are mostly confident in its stability, we cannot provide assurances against data loss.

To download Haiku, see “Get Haiku!". For press inquiries, see “Press contact".

System requirements

This release sees the addition of official x86_64 images, alongside the existing x86 32-bit ones. Note that these images are incapable of running BeOS (GCC2) applications, but they are as (or, in some cases, more) stable than the 32-bit ones.

MINIMUM (32-bit)

  • Processor: Intel Pentium II; AMD Athlon
  • Memory: 256MB
  • Monitor: 800x600
  • Storage: 3GB


  • Processor: Intel Core i3; AMD Phenom II
  • Memory: 2GB
  • Monitor: 1366x768
  • Storage: 16GB

New features

Package management

HaikuDepot, the GUI package manager
HaikuDepot, the graphical package manager

By far the largest change in this release is the addition of a complete package management system. Finalized and merged during 2013 thanks to a series of contracts funded from donations, Haiku's package management system is unique in a variety of ways. Rather than keeping a database of installed files with a set of tools to manage them, Haiku packages are a special type of compressed filesystem image, which is ‘mounted’ upon installation (and thereafter on each boot) by the packagefs, a kernel component.

This means that the /system/ hierarchy is now read-only, since it is merely an amalgamation of the presently installed packages at the system level (and the same is true for the ~/config/ hierarchy, which contains all the packages installed at the user level), ensuring that the system files themselves are incorruptible.

Since packages are merely “activated”, not installed, this means that the bootloader has been given some capacity to affect them: you can now boot into a previous package state (in case you took a bad update) or even blacklist individual files. (Blacklists can be made permanent through a settings file.)

Blacklisting packages in the bootloader

And of course, since the disk transactions for managing packages are limited to moving them between directories and in and out of the “activated packages” listing file, installations and uninstallations are practically instant. You can thus also manage the installed package set on a non-running Haiku system by mounting its boot disk and then manipulating the /system/packages directory and associated configuration files.

As a result, it is now possible to update the system by running SoftwareUpdater and then rebooting. (For those users who already run package-management-enabled nightlies, you can switch your system repositories from master to r1beta1 to update directly into the beta release.) We intend to maintain the r1beta1 repositories with bugfixes to Haiku itself, and new packages and security updates at HaikuPorts, for the forseeable future.


In addition to HaikuDepot, there is also pkgman, the command-line interface to the package management system. Unlike most other package managers where packages can be installed only by name, e.g. pkgman install rsync, pkgman install sdl2_devel, Haiku packages can also be searched for and installed by provides, e.g. pkgman install cmd:rsync or pkgman install devel:libsdl2, which will locate the most relevant package that provides that, and install it.

Accompanying the package manager is a massively revamped HaikuPorts, which has moved from a organized array of build scripts to a well-oiled full-fledged ports tree, containing a wide array of both native and ported software for Haiku.

A variety of ported software running on Haiku

WebPositive upgrades

Thanks to the generous support of donors, Haiku, Inc. was able to employ a developer to work full-time on enhancing WebKit port and areas of the system relevant to it (which turned out to be nearly everything) for over a year. As a result, the system web browser is much more stable than before, with various under-the-hood changes and a number of notable user-visible ones, such as YouTube now functioning properly:

WebPositive playing Rick Astley

WebKit is a pretty hefty piece of software, and as a result working on bringing it up to speed meant also fixing a large number of bugs in Haiku itself that it exposed, such as broken stack alignment, various kernel panics in the network stack, bad edge-case handling in app_server's rendering core, missing support for extended transforms and gradients, broken picture-clipping support, missing POSIX functionality, media codec issues, GCC upgrades … the list goes on.

For better or for worse, HaikuWebKit now also uses our own network protocol layer, which means that it now supports Gopher.

Completely rewritten network preflet

The old network preflet was showing its age, especially following the addition of WiFi drivers some years ago. It has now been replaced with a completely new preflet, designed from the ground-up for ease of use and longevity.

new Network Prefs

In addition to the (now-streamlined) interface configuration screens, the preflet is also now able to manage the network services on the machine, such as OpenSSH and ftpd. It uses a plugin-based API, so third-party network services (VPNs, web servers, …) can integrate with it.

User interface cleanup & live color updates

There were a lot of miscellaneous cleanups to various parts of the user interface since the last release.

Mail and Tracker, displaying some sample data.

Mail and Tracker both received significant internal cleanup of their UI code, and as a result now sport Haiku-style toolbars and font-size awareness, among other applications. This makes future work to add proper DPI scaling (or, even further, right-to-left layouts)

In addition, the way most applications interact with system color settings has changed significantly. Instead of requesting a specific system color and then manipulating it, most applications now instruct their controls to adopt certain colors based on the system color set directly. This means that changing the colors in the Appearance preflet changes them across the system, live: