Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–40 of 80 posts

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

#31

Post by 13rac1 »

vlad_kalinkin wrote: post #17
rvz wrote: post #8

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-leve…

FWIW Darling runs in userspace too.

What do you mean by "proprietary components"?

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

#32

Post by vlad_kalinkin »

13rac1 wrote: post #31
vlad_kalinkin wrote: post #17

Earlier quoted context omitted.

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-leve…

FWIW Darling runs in userspace too. What do you mean by "proprietary components"?

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.

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

#35

Post by sterlind »

nxc18 wrote: post #30
billyjobob wrote: post #13

Earlier quoted context omitted.

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…

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

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

#36

Post by derefr »

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?

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

#39

Post by fl0id »

derefr wrote: post #36

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 , b…

with games, afaik that is mostly necessary for assets. For an OS, this would basically like a VM and is slower/more overhead.

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

#40

Post by ZiiS »

13rac1 wrote: post #5

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?

Wine got a lot of support from games, even today productivity apps are often much less supported.
Post reply on HN