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.
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:
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
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 haiku-os.org 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?
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.
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.
I find this really faszinating, wanted to try, i am just missing something in the setup to compile haiku on linux. Can someone give me a hint, how to set up so that the compile and libs from buildtools is used instead of the system one, also how to set up the includes.
At the jam Step i get:
In file included from ā¦/headers/build/os/BeBuild.h:5,
from ā¦/headers/build/ā¦/os/support/SupportDefs.h:12,
from ā¦/headers/build/os/support/SupportDefs.h:2,
from ā¦/headers/build/ā¦/os/kernel/OS.h:14,
from ā¦/headers/build/os/kernel/OS.h:9,
from ā¦/src/build/libroot/atomic.cpp:5:
ā¦/headers/build/ā¦/os/BeBuild.h:59:9: error: #error Unsupported compiler!
59 | # error Unsupported compiler!
| ^~~~~
