Hi HN,
I started developing an experimental project with the goal of running macOS CLI binaries natively on Linux ARM machines.
As of now, we have working prototypes for:
- 7-Zip: Passes multi-threaded compression tests on an 8k-file tree. Currently ~5.2x slower than native Linux execution, but I already mapped out a clear optimization plan to cut this gap down.
- curl: Over 200 commands and options successfully pass our automated Docker test script.
- Xcode Tools Git: Basic version control commands (init, add, commit) are up and running, though 100% stability is not yet guaranteed.
I would be highly grateful for your constructive criticism, architectural ideas, and feedback!
Thank you!
How can we tell that this is truly a clean room project and that there is no code from either (Claude or yourself) that is derived from the Darling project?
This is something i have been looking for long time, however i have gone through repository and docs and the problem is bigger and solution still seems to be early, I am curious how you gonna take further, will be watching it
If you didn't care about having a fully-redistributable image, but were okay with doing things more like modern old-console-game decompilation projects do (where compiling the project requires the original game ROM as an input), would a project like this be more trivial?
I.e. how hard would it be, comparatively, to design a virtualization framework that doesn't actually ship with any ground-up-rewritten libraries, but instead just expects to execute the binary in question in the context of a full rootfs copied over from a "real" macOS install?
Based on the commit history, it took about 6 days of active development.
As for the AI assistant, I used Grok 4.5 in Build (Medium, no sub-agents, just standard chats and Plan Mode). I can't track the exact hours, but I spent several full days hyper-focused on this. Naturally, I hit the weekly usage limits all the time and had to sit around waiting for the cooldowns (like now :).
Really cool project, but honest question though: why do people tend to name these projects so horribly? I know software engineers aren’t actually known for their creative acuity when it comes to naming, but damn, Kakehashi is just bad.
My previous project had a more traditional name: WIE (Wie is Emulator), which was an attempt to run PE64 binaries on macOS via Cranelift JIT. It was an ironic joke nod to WINE (and it still survives in the GitHub organization name).
For this one, I wanted something more conceptual. Kakehashi (掛け橋) means "bridge" or "go-between" in Japanese. Plus, I just really liked how it sounds and harmonizes with Asahi Linux.
Interesting, I've been building the inverse of this project, to enable running Linux binaries on macOS, as that's not something I've seen in an active project. It works an a very similar way but it's in Zig.
I'd really need to marry this with qemu and osxcross, the ability to cross compile from x86_64-linux to darwin. So far I could only test apple compilation, but not runtime yet.
32 comments
[ 0.21 ms ] story [ 9.6 ms ] threadAre you familiar with the Darling project? https://github.com/darlinghq/darling There's an open PR for ARM64 support https://github.com/darlinghq/darling/pull/1753 Could you combine efforts or do your goals differ too much?
If this ever gets far enough I would love to see something similar to yabridge implemented on top of this and be able to run AU binaries on linux.
Otherwise great project.
I.e. how hard would it be, comparatively, to design a virtualization framework that doesn't actually ship with any ground-up-rewritten libraries, but instead just expects to execute the binary in question in the context of a full rootfs copied over from a "real" macOS install?
As for the AI assistant, I used Grok 4.5 in Build (Medium, no sub-agents, just standard chats and Plan Mode). I can't track the exact hours, but I spent several full days hyper-focused on this. Naturally, I hit the weekly usage limits all the time and had to sit around waiting for the cooldowns (like now :).
Thanks for the question!
My previous project had a more traditional name: WIE (Wie is Emulator), which was an attempt to run PE64 binaries on macOS via Cranelift JIT. It was an ironic joke nod to WINE (and it still survives in the GitHub organization name).
For this one, I wanted something more conceptual. Kakehashi (掛け橋) means "bridge" or "go-between" in Japanese. Plus, I just really liked how it sounds and harmonizes with Asahi Linux.
Open up your mind and learn other cultures.
I'll post it soon!