My progress on Haiku compatibility layer for Linux

Compatibility layers like HyClone rely on remote window protocols to display GUI apps. The same technique is used to display Linux apps on Windows in WSL.

However, app_server currently does not support forwarding just application windows and could only forward full desktops.

As for BeOS applications, this requires a 32-bit HyClone build and a 32-bit Linux environment to test on. HyClone can theoretically run on 32-bit x86 as well (after adding some very little architecture-specific code and probably fixing some hidden bugs that are related to assuming 64-bit pointers) but this has not been tested.

If the community shows more interest in running BeOS r5 apps I might start HyClone development for 32-bit x86.


There are 64 bit x86 Wonderbrush version (and riscv64 one), so it should to possible to run it with HyClone.


Of course, but the important part is “without a full desktop”.

1 Like

Not many flashy features this week, as university break is over.

This week’s focus is on stability. I’ve fixed a few bugs that makes bash fail, prevents launch_daemon from launching on boot, and other things that makes HyClone unstable.

I’ve also added user id emulation support and system watching support. With these new features, launch_daemon can watch and restart any failing system daemons, making HyClone more stable in general.

A visible effect is the increased number of daemons running on HyClone:

As well as the reduced number of zombies visible on the Linux side:

pkgman works normally even after kill package_daemon:


HyClone now supports monitoring directory for events such as file creation and removal. This allows package_daemon to monitor the packages folder and activate/deactivate packages on the fly.

In other words, you can now install/uninstall packages simply by copying/removing packages from /boot/system just like on a normal Haiku installation.

This is the last major obstacle preventing HaikuPorter from running on HyClone. My lie for this month seems to be nearly complete :slight_smile:

It is also amazing to see the source code for various Haiku’s infrastructure to live in hyclone_server, for example KMessage and NotificationService, despite all the fundamental differences between the two environments.


HyClone can now run haikuporter and generate .hpkg files!

This makes HyClone a good tool for generating Haiku packages for CI purposes on Linux-only infrastructure such as GitHub Actions, which is also the original goal of the HyClone project. (Note that since mounting and unmounting packagefs drives is very expensive on HyClone, it is not suitable for serving as a buildmaster (yet)).

These small package files also mark the end of the first chapter of HyClone development. I myself am amazed by how much progress HyClone has made this April, from a fragile environment that can only run a few POSIX-compliant tools to something that can lie to online infrastructure, a handful of Haiku daemons, and a full HaikuPorts build chroot environment.

Thank you for all your support in the past month! The hearts, GitHub stars, and occasional donations all mean a lot to me and encouraged me to keep HyClone running on top of my busy schedule. For the next chapter, I will listen to you - what do you want to do with HyClone? Support for window integration with the host? Support for a faster VFS subsystem and more filesystems like userlandfs and BFS? Support on more OSes like macOS or more architectures like x86 and arm64?


Congrats on the progress @trungnt2910 ! :ok_hand:


Very impressive!

  • GDB/LLDB support

Using the host’s GDB (Linux) on HyClone-emulated Haiku apps, or use gdb on HyClone? The latter is quite impossible as GDB is also broken on Haiku.

Is this even possible?

What I meant was HyClone-emulated Haiku apps, which are nothing but Linux processes.

Debugging these apps work, but the experience is not so good because Linux GDB does not know of symbols of Haiku binaries loaded by HyClone.

This sounds handy!

I’ve successfully built hyclone under Debian testing amd64 using the Ubuntu instructions in the readme but I’ve not tested it yet.


Should it be possible to build this under Debian on the VF2 and use it to build Haiku rv64 packages?

Wouldn’t be better to just use Haiku and build the packages with haikuports?, i mean wouldn’t there be a performance hit using this emulation?

If my x86-64 Haiku vs (Ubuntu) Linux benchmarks from last year are still valid, Linux is approx twice as fast as the Haiku (NewOS) kernel at many CPU intensive tasks like building software and compressing files etc, at least that was the case on the CPU I used for the comparison.

Should it be possible to build this under Debian on the VF2 and use it to build Haiku rv64 packages?

HyClone currently only supports x86_64. It currently has:

  • Some x86_64-specific asm blocks here and there (quite few but they exist).
  • Raw Linux x86_64 syscall numbers (the __NR_* constants).
  • x86_64-specific Haiku constants.

HyClone was designed to be portable so it should not be too much work to port it to another architecture. However, on my TODO list are only x86 (32-bit) and probably arm64 if I can acquire a arm64 laptop after GSoC ends.

Wouldn’t be better to just use Haiku and build the packages with haikuports?, i mean wouldn’t there be a performance hit using this emulation?

There would be quite a huge hit. HyClone in its early stages did not focus on performance and its VFS-related syscalls are very slow. Building packages (a task that uses a lot of these syscalls) on HyClone is not as fast as building on Haiku.

I currently have some ideas to do (yet another) rewrite on the VFS layer to use FUSE instead of emulating my own, but I don’t have any plans to realize that at least in the next few months.

1 Like

It would be better to run regular Haiku for building packages on VisionFive 2. The benefits of using HyClone for building software are using various shared server and continuous integration infrastructure. If hardware is locally available, it should be no problem to run regular Haiku on it.


Is it not possible to use qemu or another RV emulator to build Haiku RV packages on amd64?

Which is the best out of qemu and this

Maybe that can’t be used to run Haiku?

Would a 32 core Xeon running qemu not be able to build Haiku packages faster than a VF2 running Haiku?