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.

Haiku terminal running bash

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 /home and /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:

~> mount usage: 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 -h Mount 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:

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.)

is the partition from which the system is booted. Why not ? Or is it ? I am confused. (Explanation: 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)

is where per-user packages are mounted. Why not ? (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 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.