HN Debrief

Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM

  • Open Source
  • Developer Tools
  • Infrastructure
  • AI

Kakehashi is an experimental compatibility layer for running macOS command-line binaries on Linux ARM in userspace. The author says it already runs some real targets, including 7-Zip, curl, and basic Git commands from Xcode tools. The pitch is narrower than full macOS emulation. No VM, no custom kernel module, no root required. The long-term goal is much bigger, though, including Xcode tooling, Homebrew, and eventually Linux-based iOS build workflows.

If you care about Linux-based iOS build pipelines or running macOS-only CLI tooling on ARM servers, watch this closely but treat it as a research prototype, not infrastructure. The near-term signal is less "macOS apps on Linux" and more whether a lightweight userspace compatibility layer can stay usable against Apple's moving ABI and licensing constraints.

Discussion mood

Interested but cautious. People like the idea and see obvious demand, especially for Linux-based iOS builds and macOS-only tooling, but most of the energy went into how hard this will be to maintain and whether the project's LLM-assisted origin weakens any clean-room claim.

Key insights

  1. 01

    Productivity tools are the hard compatibility target

    Running macOS command-line tools sounds simpler than chasing desktop apps or games, but the maintenance profile may be worse. Wine had the commercial gravity of gaming to fund huge compatibility work. Productivity tooling does not get the same concentrated investment, and Apple's interfaces shift often enough that a wide macOS CLI surface can turn into endless breakage repair.

    Do not judge this by one or two demo binaries. The useful metric is whether it can keep a coherent target set working across macOS releases without becoming a full-time porting treadmill.

      Attribution:
    • ZiiS #1
    • frumplestlatz #1
  2. 02

    The real differentiator is smaller than advertised

    The headline distinction from Darling narrowed once commenters corrected the record. Darling also runs in userspace now and dropped its kernel module. That leaves Kakehashi's sharper identity as Rust, Linux ARM focus, and a deliberately lightweight scope around command-line binaries. That is still a real product choice, just not a wholly new architectural category.

    Compare this project against Darling as a specialization strategy, not as a replacement born from a fundamentally different execution model. If you might adopt it, watch where narrow focus produces faster progress and where it just recreates the same compatibility backlog.

      Attribution:
    • 13rac1 #1
    • vlad_kalinkin #1
    • saurik #1
  3. 03

    LLM assistance complicates provenance from day one

    The author openly describes the work as a "light-gray room" effort rather than a strict clean-room implementation. That honesty helps, but it also concedes the core problem. In compatibility projects, legal comfort depends on more than line-by-line originality. It also depends on whether design decisions were independently derived. Once an LLM trained on prior art sits in the loop, that argument gets harder to make, not easier.

    If you are thinking about using LLMs for clone or compatibility work, set provenance rules before code lands. Keep prompts, review trails, and architectural notes, because downstream users and contributors will ask for more than a Git history.

      Attribution:
    • vlad_kalinkin #1
    • rvz #1
    • billyjobob #1

Against the grain

  1. 01

    Just using a copied macOS rootfs misses the point

    A suggestion to avoid reimplementing libraries by requiring a real macOS filesystem sounds tempting, but that mostly collapses back into VM-like execution. For console game decompilation projects the original asset blob is the hard part. For an operating system compatibility layer, the hard part is the runtime behavior and integration boundary, so shipping someone else's rootfs does not remove the core engineering problem.

    Do not assume you can shortcut OS compatibility the way some game preservation projects do. If you need native-feeling execution on Linux, you still have to recreate a lot of semantics, not just mount a borrowed userspace.

      Attribution:
    • derefr #1
    • fl0id #1

In plain english

ABI ↩
Application Binary Interface, the low-level rules that let compiled programs interact with an operating system and its libraries.
Darling ↩
An open source project that aims to run macOS software on Linux by reimplementing needed Apple interfaces.
Homebrew ↩
A popular package manager used to install command-line tools and software on macOS and Linux.
LLM ↩
Large language model, a machine learning system that generates and edits text or code from prompts.
rootfs ↩
Root filesystem, the base directory tree and system files that make up an operating system environment.
userspace ↩
The part of a system where normal applications run, separate from privileged kernel code.
VM ↩
Virtual Machine, software that emulates a complete computer system so another operating system can run inside it.
WINE ↩
Wine Is Not an Emulator, a compatibility layer that lets many Windows programs run on Unix-like systems without a full virtual machine.
Xcode ↩
Apple’s integrated development environment for building macOS and iOS software.

Reference links

Related compatibility projects

  • Darling
    Main prior art mentioned for running macOS software on Linux and the project most often compared with Kakehashi.
  • Darling ARM64 support pull request
    Referenced as evidence that Darling is also working toward ARM64 support, which sharpens the comparison with Kakehashi.