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!
Well, of course, most of all I would like to achieve full-fledged support for Xcode Tools (including building iOS applications) and the macOS version of Homebrew. But, of course, there is still a lot of work ahead to get to this point. Thank you!
That's true. But if we can achieve support for the current stable version, it will be much easier to add new features later or rework the ones that were replaced (unless Apple changes everything on purpose :)
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?
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
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?
Thanks for the comment! You guessed it, I did use LLMs during development. While the strict definition of a "clean room" design can be debatable when AI is involved, I'd consider this a "light-gray room" approach. There is no direct code plagiarism here: Kakehashi is written from scratch in Rust, whereas Darling is built on C/objc. Furthermore, the architecture is fundamentally different—Darling relies on kernel-level emulation, while Kakehashi is purely focused on a lightweight userspace approach for Linux ARM. In my prompts, I explicitly restricted the use of proprietary components. Ultimately, the codebase speaks for itself, and I welcome everyone to audit the repository! Thanks again!
Darling is written in a different language so I don't think the LLM would copy paste code from it directly. But it is the main (only?) prior art, so it could be argued that everything the LLM knows about how to do this came because it read and understood Darling, i.e. if Darling didn't exist it may still be able to do this but it would have to figure it out from first principles.
Not saying it happened here, but it's an interesting thought experiment: what if you order an LLm to achieve the same goal as a popular open source project, using all the lessons learned and pitfalls faced by that project, but not to copy the code. Indeed, LLM code is now often better than human code, so direct code copying would be a disadvantage. Humans are certainly inspired by other projects like this all the time and it isn't considered plagiarism.
> Darling is written in a different language so I don't think the LLM would copy paste code from it directly.
Just because it is written in a different language does not mean that it is a clean room implementation. The logic from Darling might as well have been lifted and then rewritten by a human or an LLM agent.
> Indeed, LLM code is now often better than human code, so direct code copying would be a disadvantage.
Is that why coding agents such as Claude Code and Codex have so many bugs in them? This is entirely dependent on the language chosen with the humans behind the decision to review and accept some of the changes.
> Humans are certainly inspired by other projects like this all the time and it isn't considered plagiarism.
Humans (researchers) also appropriately credit the work that inspires them, especially in experiments and research.
Interesting project! A long term vision for MacOS applications is feasible given the success of WINE/Proton with Windows applications.
Are 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?
In their "License" section on Github, they write "This project is not derived from Darling." - so they clearly are familiar with it.
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!
I assume you eventually plan to target binaries that don't already exist on Linux? Where do you think you'll start?
Well, of course, most of all I would like to achieve full-fledged support for Xcode Tools (including building iOS applications) and the macOS version of Homebrew. But, of course, there is still a lot of work ahead to get to this point. Thank you!
And it’s an endlessly moving target, look at how many apps break every major release (and use it to justify regular, expensive paid upgrades)
That's true. But if we can achieve support for the current stable version, it will be much easier to add new features later or rework the ones that were replaced (unless Apple changes everything on purpose :)
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?
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
Thank you very much!
Would be nice to be able to build iOS apps on Linux ARM runners
this is something I've been waiting for a long time. I will be watching this with great interest.
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.
Quite the interesting work! Although I don't use macOS binaries, I can see this is promising.
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?
Otherwise great project.
Thanks for the comment! You guessed it, I did use LLMs during development. While the strict definition of a "clean room" design can be debatable when AI is involved, I'd consider this a "light-gray room" approach. There is no direct code plagiarism here: Kakehashi is written from scratch in Rust, whereas Darling is built on C/objc. Furthermore, the architecture is fundamentally different—Darling relies on kernel-level emulation, while Kakehashi is purely focused on a lightweight userspace approach for Linux ARM. In my prompts, I explicitly restricted the use of proprietary components. Ultimately, the codebase speaks for itself, and I welcome everyone to audit the repository! Thanks again!
FWIW Darling runs in userspace too.
What do you mean by "proprietary components"?
Darling is written in a different language so I don't think the LLM would copy paste code from it directly. But it is the main (only?) prior art, so it could be argued that everything the LLM knows about how to do this came because it read and understood Darling, i.e. if Darling didn't exist it may still be able to do this but it would have to figure it out from first principles.
Not saying it happened here, but it's an interesting thought experiment: what if you order an LLm to achieve the same goal as a popular open source project, using all the lessons learned and pitfalls faced by that project, but not to copy the code. Indeed, LLM code is now often better than human code, so direct code copying would be a disadvantage. Humans are certainly inspired by other projects like this all the time and it isn't considered plagiarism.
> Darling is written in a different language so I don't think the LLM would copy paste code from it directly.
Just because it is written in a different language does not mean that it is a clean room implementation. The logic from Darling might as well have been lifted and then rewritten by a human or an LLM agent.
> Indeed, LLM code is now often better than human code, so direct code copying would be a disadvantage.
Is that why coding agents such as Claude Code and Codex have so many bugs in them? This is entirely dependent on the language chosen with the humans behind the decision to review and accept some of the changes.
> Humans are certainly inspired by other projects like this all the time and it isn't considered plagiarism.
Humans (researchers) also appropriately credit the work that inspires them, especially in experiments and research.
> Indeed, LLM code is now often better than human code
lol. Find better humans.
it depends on your prompting. LLMs can generate beautiful code, or absolute slop.