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 calling convention and data representation rules used when compiled code interacts at runtime.
Darling ↩
An open source project that aims to run macOS software on Linux by reimplementing needed Apple interfaces.
Homebrew ↩
A popular package manager for macOS and Linux that lets users install software from the command line.
LLM ↩
Large Language Model, a machine learning model trained to generate and analyze human-like text.
rootfs ↩
Root filesystem, the base directory tree and files that make up an operating system image.
userspace ↩
The part of a system where normal applications run, separate from privileged kernel code.
VM ↩
Virtual machine, a simplified software-defined computer that runs programs in its own instruction set.
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, the main software developers use to build apps for iPhone, iPad, and Mac.

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.