vlad_kalinkin

It's not on the list of goals yet (so far only CLI and a stable basis), but of course if I went to GUI, it would be nice, since I work in Logic Pro :)

By the way, has anyone checked if the utility works on Asahi Linux (or on real non-Mac hardware)?

Wow! Best of luck with your project. It's truly amazing how our ideas mirrored each other perfectly :)

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

Thanks for the question!

Haha, thanks for the comment!

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.

Thanks! What I meant is that Kakehashi doesn't require a custom Linux kernel module (LKM). Kakehashi operates completely without root privileges or kernel-level modifications.

By "proprietary components," I meant that in my prompts, I explicitly forbade the copying or direct implementation of private Apple code. Of course, since LLMs are a bit of a black box, it's hard to be 100% certain about everything it synthesized under the hood, but the clear intent was to stick to public ABI definitions and standard open specs.

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

Thank you very much!

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!

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!

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 remember using an old 2018 Intel MacBook Air with 8GB of RAM about two years ago. That thing was noisy. Every time I tried to compile a larger project or work in Logic, the RAM would fill up and the fans would go full blast. Now I am on an M1 MacBook Pro, also with 8GB. Granted, the RAM is still a bottleneck, but the fan noise is completely gone and the machine always stays at a comfortable temperature.