My first day with Haiku — shockingly good!

16 min readJul 9, 2019

TL:DR; Noob seeing Haiku for the first time; finds it shockingly good, especially when compared to the desktops available for Linux.

In the past, I have shared my ideas for (and frustrations with) #LinuxUsability (part 1, part 2, part 3, part 4, part 5, part 6). In this post, I am describing my first impressions with Haiku, an open source desktop operating system for personal computers. Sometimes first impressions can be useful, and since you have first impressions only one time, I am capturing mine here.

The system on which I am writing this article

Maybe they are useful for Haiku developers and/or other interested parties. Not everything may be correct, as I am just describing my (uninformed) first experiences. I’ve also asked the friendly folks in #haiku on irc.freenode.net to give me some hints — and woven those into the article. Thank you, Haiku developers!

What should I say — while not everything is 100% perfect yet, Haiku is already nailing the desktop…

Installation

The Haiku project provides nightly images that can be booted from DVD or USB. I am using a USB 3 stick. I am advised that USB 3 booting may not be working yet, but it seems to work flawless on two Intel-based systems I am testing this with.

Installation consists of downloading the nightly 64-bit image and writing it to a USB stick using Etcher.

Booting works with and without EFI.

I applaud Haiku for providing such an image. Haiku uses its own filesystem, the Be File System, for the boot partition, although it can also deal with FAT32 and NTFS partitions. 600 MB seems to be sufficient for the system, but not for add-on applications. By default, there is a 600 MB Haiku partition with the Be File System and a 3GB FAT32 partition. The FAT32 partition holds /EFI/BOOT/BOOTX64.EFI which means that the system can be booted on EFI systems. Unfortunately, there is no tool that could increase the Haiku partition size. I just hope they would use a different partitioning scheme, since the partition size of the system image is fixed and is so small that you can’t install additional software without running out of space. Alternatively it would be great if add-on packages could be stored on the secondary partition, which is FAT32. This would also have the advantage that one could access those files from non-Haiku systems. (I am told that Linux has been able to read BFS for a long time, and many systems can read and write BFS using FUSE.)

I was advised that if I want a larger partition, I have to install the system to another USB drive. Unfortunately this is more complicated than needed because the Haiku installer does not do partitioning, but points the user to DriveSetup instead, where one has to manually initialize (write a partition table) the drive, add a partition, and format the partition with the Be File System, then come back to the installer. Also, one has to install the boot loader manually using a separate tool. Unfortunately, EFI booting does not work from a USB stick made this way because it is lacking the FAT32 partition and EFI boot files. It would be nice if the installer could do the partitioning automatically, including EFI particularities.

BootManager installs a bootloader onto a disk

Installation itself is remarkably quick, under three minutes(!), as there are “only” 4751 files copied for the whole system. This is because most software lives inside hpkg files, which are somewhat like packages on the Linux desktop, but are never installed, just mounted (somewhat similar to snap packages).

I wonder why there are still many “loose” files (link png files) flying around, couldn’t everything be in hpkg files? I am told that even the kernel is in a hpkg file. (I am told that 4751 files came from the fact that I had launched HaikuDepot which downloaded a lot of resources. Clean installation apparently doesn’t have most of them and will be much faster to install with less than 200 packages. Cool! It is actually a bug that those downloaded files are not ignored at an installation, I am told — yay, the first Haiku bug report I seemingly triggered.)

First boot

The system boots, shows a nice graphical splash screen, but then halts: After booting, my AMD based GPU (Radeon HD 5000/6000/7350/8350 Series) just shows a black screen. I am advised that I need to boot into a failsafe screen mode, which only gives me 1024x768 pixels resolution on a Full HD screen. Possibly I could fiddle in the bootloader to get Full HD. But using another computer with Intel graphics, it works flawlessly.

The system seems responsive when running from USB stick. It seems like it is not writing stuff to the USB stick all the time, so I hope I can use it from USB as my main work system. Unlike Linux Live ISOs which feel like they are an afterthought, you seem to get the “real thing” when running Haiku from USB.

At no time the screen flickers, at no time you see kernel messages, at no time the system feels like Xorg is bolted on top of the kernel. In contrast to typical Linux distributions, this feels like the GUI and the kernel are really married together. Great!

No login screen. The system is made for one user. Simple! Exactly what is needed for a personal computer desktop system. Multiple users? Give them multiple USB sticks. They cost under 5 dollars today.

First impressions on the desktop

This thing feels much more “Mac-like” than, say, Linux with Gnome. The command key works exactly as it works on the Mac. Great!

Nothing beats a spatial file manager. Feels like the original Mac!

The file manager is spatial by default (think Macintosh System 1.0). Unfortunately, each file manager window seems to forget its settings (e.g., that it is set to icon view rather than list view). I am told that this is a bug, and think this should be an easy fix. (Reminds me that I need to sign up with the Haiku bug tracker, which unfortunately neither lives on GitHub nor GitLab nor accepts their logins — old school and making it unnecessarily hard to do “drive by” bug reporting.)

Files can have icons themselves. No messing with separate desktop files and icon files. Great! So much better than Linux desktops. Feels so much more straightforward.

Performance

This thing feels snappy, even on low-powered hardware like an Atom netbook. You can feel that it doesn’t have may layers of bloat. Great!

Lunduke says LibreOffice feels faster than on other OSes, I could not test this yet.

Bryan Lunduke: Haiku OS Beta — Visual Tour and Impressions

Command line

There is a Terminal application. Although it is a bit different from a Linux system, I am immediately familiar with it. Turns out it is bash, actually. It greets me with

Welcome to the Haiku shell.In it, you can easily launch applications that are on the $PATH:~> Touchpad~> echo $PATH.:/boot/home/config/non-packaged/bin:/boot/home/config/bin:/boot/system/non-packaged/bin:/bin:/boot/system/apps:/boot/system/preferences

Yay! . is on the $PATH! This means we can just run commands in the current working directory. (Linux people once told me that the world would explode if I ever attempted this.) Nice.

What is cool is that in this terminal, you can press Command-C to copy things, just like in every other application. Not like on Linux desktops where you have to press Ctrl-Shift-C in the terminal unlike everywhere else. Little things like this show just how consistent the whole system is.

On-disk filesystem layout

The partition from which the system is booted is is /boot. Easy!

No more /etc, /usr, /bin… mess. Just /homeand /system. Clean, easy, understandable. Great! (Well, not actually — they are there, but hidden. Why? I am told that they are “fake” directories, i.e. /bin is really just /system/bin. No need to display that in Tracker, but shell scripts use it a lot still. — I think they should get rid of that legacy compatibility stuff, because it just makes things harder to understand.)

packagefs

I mentioned hpkg files above, which are somewhat like packages on the Linux desktop, but are never installed, just mounted (somewhat similar to snap packages). There is a filesystem that does this magic, packagefs. It mounts the hpkg files “over” each other. In fact, the whole /system is created this way.

Unfortunately the mount command does not show what is mounted:

~> mountusage: mount [-ro] [-t fstype] [-p parameter] [device] directory-ro mounts the volume read-only-t specifies the file system to use (defaults to automatic recognition)-p specifies parameters to pass to the file system (-o also accepted)if device is not specified, NULL is passed (for in-memory filesystems)

I am told that there is mountvolume which lists mounted partitions. Unfortunately it does not list the packagefs mount points (mountvolume only shows the ones attached to a “volume” physical disk or disk image).

But this kinda does the trick:

~> df -hMount Type Total Free Flags Device
----------------------------------
/boot bfs 600.0 MiB 6.0 KiB QAM-P-W /dev/disk/usb/0/0/0
/boot/system packagefs 4.0 KiB 4.0 KiB QAM-P -
/boot/home/config packagefs 4.0 KiB 4.0 KiB QAM-P -
/no name fat 2.8 MiB 2.3 MiB - M-PRW /dev/disk/usb/0/0/1

We can see that /system and /home/config on the boot partition are packagefs.

People who know me also know that I am a huge proponent of drag-and-drop in the file manager, e.g., using NeXT-style application bundles or AppImages. However, those formats also have disadvantages. Can packagefs combine the best of both worlds?

Well, in my current situation (system partition is full but I want to get applications) it would be neat if I could just download applications somewhere using the browser, and be asked where to save them. Like I could do with an AppImage or Mac .dmg file.

packagefs lives in the kernel, so it is not a FUSE fileystem (although I am told that there is FUSE support in Haiku).

I am told that it may be possible in the future to have additional “packagefs zones” which probably means that I could tell packagefs to store packages e.g., on an additional partition. I would certainly love that! Especially if that partition was removable, so that I could walk to a different machine and have the applications work there, too.

I am told that drag and drop install of packages does work; just drag a file into /system/packages or /home/config/packages, and drag out to uninstall. If you drag in a package that has dependencies which are not installed, the system will pop up a message box asking if you want to install them.

What is unclear to me at first sight is how packagefs handles multiple versions of the same package. What if I want different gcc versions, or different versions of a GUI application? (I hear from a developer “there is nothing in packagefs itself that prevents having multiple packages with the same name activated, but we use libsolv from openSUSE for dependency resolution and it doesn’t allow it, and HaikuPorts is not set up to allow this either” — I know why I like .app bundles, AppDir and AppImage, after all).

Dynamic libraries

Is there the concept of dynamic libraries? Yes. This is what happens when you are double-clicking an application that is missing a shared library:

Can we please have this in @**gnome**, @**kdecommunity**, @**xfceofficial** too?

On Linux, it would just silently do nothing visible.

Let’s see how long it will take Linux land to catch up:

How can I inspect things?

~> ldd
bash: ldd: command not found

We can use instead:

~> objdump -x /bin/bash | grep NEEDED
NEEDED libreadline.so.7
NEEDED libhistory.so.7
NEEDED libncurses.so.6
NEEDED libintl.so.8
NEEDED libroot.so

Although having ldd would be nice, since it shows whether and where those libraries are loaded from.

Where are they actually loaded from?

~> echo $LIBRARY_PATH
%A/lib:/boot/home/config/non-packaged/lib:/boot/home/config/lib:/boot/system/non-packaged/lib:/boot/system/lib

So we can put libraries in lib/ next to the binary, and it will “just work”. How cool is that! Makes it so easy to ship private libraries with an application, without the need to patch rpath or set LD_LIBRARY_PATH like on “Linux”. Great!

There is the dreaded (on Linux) /boot/system/lib/libstdc++.so.6.0.24. What if an application needs a newer one than what happens to be in /boot/system/lib/?

At least there is no “administrator” with a root password, so a mere user could probably just update to the latest version. Or so it looks by default, from the outside. (Actually, “user” is the root user. You can set a password for it with passwd, and then edit sshd config to PermitRootLogin, and then SSH into it. I hear from a developer that by default all apps run as root, but eventually they may want to get around to reworking this… not sure whether I should like this or not.)

Since there are not different Haiku distributions, application developers also don’t have access to versions more recent than what your system has available for download. The result: Less frustration, things “just work”. Great simplification! I like it.

Resources and the Registrar

I notice that applications can have types, and icons, and you don’t have to deal with desktop files and such. I am told that there is a Registar which knows about applications, file types, icons. When a package is installed or a file is marked as executable (using chmod or mimeset), the Registrar is notified. Reminds me of Launch Services on the Mac, exactly what the Linux desktop is missing. Great!

Binary files can have resources like icons embedded into them, hence you don’t need to manage separate icon and desktop files. Just like in Macintosh System 1. Cool!

Application types, supported document types, built-in resources, and version information

The Tracker (the file manager) automatically marks binaries as executable. Exactly what I have wanted the Linux desktop to do for over a decade. This whole thing makes so much sense to me.

How cool is that! Life can be so easy.

It is so much more elegant and Mac-like than the XDG stuff on Linux. Or this…

Linux application (ELF) without the executable bit set. Source: https://medium.com/@probonopd/make-it-simple-linux-desktop-usability-part-6-1c03de7c00a9

GNOME even had removed the very capability to launch executables from the file manager altogether, but backpaddled after an uproar in the community.

I am told that applications are not using hardcoded paths like/usr/bin, /usr/share(as is common on the “Linux” desktop), but are using find_paths() API. This should make them relocatable in the filesystem. I applaud that! On Linux, this is “complicated” as well.

What I find surprising

/boot is the partition from which the system is booted. Why not /? Or is it /Haiku? I am confused. (Explanation: /boot is indeed always the partition the system is booted from. It displays on the desktop as “Haiku” because that is its name. Think of / as roughly the equivalent of Mac System 1 desktop. It’s the root of the filesystem hierarchy, but does not exist on any disk.)
/home/config is where per-user packages are mounted. Why not /home? (the explanation given to me by a developer was that they didn’t want to “litter” the home directory, but I still find “config” counter-intuitive a name given that it contains a bin/ subdirectory… so it’s clearly not just for configuration)
What license is stuff under? The about screen of the WebPositive browser, for example, does not even give a hint. The “About this system” box says that the code unique to Haiku is MIT licensed. Great! (I am told that WebPositive is shipped with the OS so under the same license, it uses WebKit which is under a 2 clause BSD for the most part.)

What does not work as expected

Overall I am impressed with the level of hardware support. On my Atom netbook, even WLAN works out of the box. Some things don’t work yet.

Cannot work on Macintosh hardware, neither with EFI nor with BIOS emulation (“Windows”). Selecting the icon in the Mac boot screen just freezes the system. I am told that this is a known issue and it can boot using rEFIt, but that’s too complicated for me to set up right now
Graphics acceleration. This one seems like the biggie. Not on AMD Radeon (I just got a black screen there) but also seemingly not on Intel (video in the WebPositive isn’t accelerated but H.264 is handled purely in software… really surprising given BeOS’ original focus on video. A developer says “video in Web+ is a slow hack, to be precise” — sounds like they are on it)
No sound? A developer tells me that “Audio drivers are still hit and miss. Someone needs to give the HDA driver the same care I just gave the USB3 driver. For now, warm reboots from other OSes usually suffice to get audio”… I trust that this will be fixed at some point in time
No media keys. To control volume and brightness. (The framework is already here: see the Shortcuts app — bind any shortcut you like to any function globally you like. It just doesn’t know about media keys yet. Volunteers?)
Two-finger scrolling on the touchpad. Does not work out of the box. There is a Touchpad settings panel, but it says “No touchpad found, the settings will have no effect.” (It is an ELAN Input Device, ACPI ETD050A, known issue)
There is an application that is supposed to read files from digital cameras and Android phones, but I could not get it to work with my phone in both MTP and PTP modes. It would be nice if those were mounted just like other partitions in the system
Closing the lid of my notebook. Just seems to do nothing (I am told that Haiku does not support ACPI suspend yet; the infrastructure is there but it is not wired up and driver reinitialization is missing)
I cannot create a bugtracker account because the WebPositive browser does not let me solve the captcha

Applications

The whole point of a desktop OS is to run applications. I was fearful that there would be no real-world applications for Haiku. Luckily, I was wrong, and there is hope that the situation may improve as more users come to use Haiku.

Scribus (desktop publishing) is available. A rather complex Qt-based application. So is QtCreator (IDE).

I wonder whether anyone would write a native Be application for Haiku as of today, using native tools (do they exist), or whether just using QtCreator is the way to go (will also make the resulting applications easier to port cross-platform). I hear from Haiku developers that “definitely” they prefer Haiku-API native apps. I wonder whether this is really the way to go, since I have always been skeptical that “real world” apps get written for anything but cross-platform (all “real-world” production apps I use are cross-platform, in fact).

WxWindows applications are also available.

I hear that Gtk+ is not really available, and is also not fun to work with. While I tend to agree, it’s sad that this means there will be no GIMP on Haiku anytime soon (or so I imagine). But hey, there is Krita!

What I think is needed is an easy and straightforward way to build applications on Travis CI and GitLab CI for Haiku, kinda like this.

Where is it headed?

Is this stuck to BeOS UX concepts or will it move on? I think that in order to stay attractive, it needs to carefully adapt new UX schemes while still staying true to its foundations.

For example,

Can it stay lean and mean, without 1,001 configuration options that make “Linux” so “complicated”?
Will it get an arrow mouse cursor rather than the strange hand?
May it get a Dock? (I am told that there is LaunchBox, kinda a Dock of sorts shipped with Haiku, but there is also LnLauncher which looks more like a Dock. The original BeOS apparently did have a Dock already back in 1998, with that exact name!)
May it get a global menu bar? (Apparently no, because JLG thinks it is no more beneficial.)
May it get snappy windows? (I am told that I should try out “Stack & Tile” by holding down the Windows key while dragging windows around — this is hardly discoverable and, worse, seems to do nothing for me, though.)
May it get animations, e.g., when windows are opened or maximized?
May it get drop shadows behind windows?
May it get theming,e g., to make it a bit more Aqua? (Yes: the infrastructure and tools like HaikuThemeManager are available already, but someone has to make nicely looking themes. If it is documented, I might even give it a try… someone points me to https://xref.plausible.coop/source/xref/haiku/headers/os/interface/ControlLook.h but that is way over my head right now)

These are all fine lines to walk because the system should not not lose its unique personality.

Conclusion

Haiku is a true eye-opener for me. It shows how a desktop can “just work”. In many aspects this system is exactly addressing what has been driving me crazy on the “Linux” desktop for well over a decade, as someone originally coming from the Mac and looking for the same level of elegance and simplicity.

Sure, there are still some rough edges. But surprisingly much “just works”, including hardware such as WLAN or printers. First and foremost, though, this system has concepts in place for the desktop which sorely have been missing from the “Linux” desktop.

Having one full-stack system (rather than a kernel and various competing userland stacks on top) makes the whole thing simpler and more consistent.

Having just one system rather than different distribution further reduces complexity.

Having the system designed for exactly one desktop user reduces complexity even further.

The result: A very straightforward, elegant, and in many ways minimalistic but polished system that feels like it is made for “mere mortals” rather than for UNIX system administrators. I can only hope that as this thing becomes more popular (which is inevitable), complexity will not creep in everywhere.

I have written about #LinuxUsability in the past (part 1, part 2, part 3, part 4, part 5, part 6), and I am happy to say that Haiku solves many of the issues raised there. It also solves many of the platform issues that have been plaguing the Linux desktop for a long time.

After just one day of playing with it, I already know that I’d love to use this desktop as my daily driver and am already thinking about how I can best contribute.

Try it out for yourself today! The Haiku project provides nightly images that can be booted from DVD or USB. Installation consists of downloading the nightly 64-bit image and writing it to a USB stick using Etcher.

This article is part of a series:

probono is the founder and lead developer of the AppImage project, the founder of the PureDarwin project, and a contributor to various open source projects. Screenshots were made on a Haiku system booted from USB stick. Grateful acknowledgment is made to the developers in #haiku on irc.freenode.net, particularly mr. waddlesplash, @PulkoMandy, and @diver.