리눅스 ARM에서 macOS CLI 바이너리 실행하는 실험적 프로젝트 Kakehashi 공개
- Kakehashi는 Rust로 작성된 실험적 유저스페이스 레이어로, macOS CLI 바이너리를 리눅스 ARM에서 네이티브처럼 실행하는 것을 목표로 함
- 7-Zip 멀티스레드 압축 테스트는 8000개 파일 트리에서 통과했지만 네이티브 리눅스 실행보다 약 5.2배 느림
- curl은 200개가 넘는 명령어와 옵션이 자동화된 Docker 테스트 스크립트를 통과함
- Xcode Tools의 git은 init, add, commit 같은 기본 명령이 동작하지만 100% 안정성은 아직 보장되지 않음
- 개발자는 개발 과정에서 LLM을 활용했다고 밝혔고, 커널 레벨 에뮬레이션 방식인 Darling 프로젝트와 달리 순수 유저스페이스 접근이라 구조가 다르다고 설명함
Hacker News 의견들
7-Zip 멀티스레드 압축 테스트는 통과했고 네이티브보다 5.2배 느린데 최적화 계획은 이미 세워놓은 상태임. curl은 200개 넘는 명령어랑 옵션이 자동 테스트 통과했고, git은 init/add/commit 같은 기본 명령만 됨. 피드백 좀 부탁함
리눅스에 이미 있는 바이너리 말고 없는 것들 타겟할 계획인지 궁금함. 구버전 macOS는 /usr가 쓰기 가능했는데 최신은 아니잖아, 이런 버전별 차이도 다 구현할 거임?
WINE/Proton이 윈도우에서 성공한 거 보면 macOS 앱도 장기적으론 가능성 있어 보임. Darling 프로젝트 아는지 궁금한데 거기 ARM64 지원 PR도 올라와 있던데 협업 생각 있음?
라이선스 문서에 이미 'Darling에서 파생된 게 아니다'라고 명시해놨더라, 이미 알고 있었던 듯
WINE은 게임 덕분에 지원 많이 받았는데 생산성 앱은 그때도 지금도 지원이 훨씬 약함
yabridge처럼 이 위에 AU 플러그인 돌릴 수 있게 되면 진짜 기대됨, 계속 지켜볼 거임
이거 클린룸 프로젝트 맞음? Claude나 개발자가 짠 코드에 Darling 코드가 섞여 있는 건 아닌지 어떻게 확신함?
Darling은 C/objc라 LLM이 코드를 그대로 베끼진 않았을 거임. 근데 Darling이 유일한 선행 사례니까 LLM이 아는 노하우 자체가 Darling에서 나온 거 아니냐는 논쟁은 할 수 있음
개발자 답변: LLM 쓴 건 맞고 '라이트그레이룸' 방식이라고 부르고 싶음. Kakehashi는 Rust로 처음부터 짰고 Darling은 C/objc 기반에 커널 레벨 에뮬레이션인데 우리는 순수 유저스페이스라 아키텍처 자체가 다름. 프롬프트에서 독점 컴포넌트 쓰지 말라고 명시했음
레포랑 문서 다 봤는데 문제 자체가 크고 아직 초기 단계 같음, 어떻게 풀어나갈지 계속 지켜볼 거임
이미지를 완전 재배포 가능하게 안 만들어도 된다면, 게임 롬처럼 실제 macOS 설치본을 루트파일시스템으로 통째로 가져와서 그 위에서 실행하는 방식이 더 쉽지 않을까?
OS는 게임 에셋이랑 달라서 그렇게 하면 사실상 VM이랑 비슷해지고 오버헤드만 더 커질 것 같음
리눅스 ARM 러너에서 iOS 앱 빌드까지 되면 정말 좋겠음
이거 만드는데 에이전트 시간 얼마나 썼는지 궁금함
README가 AI가 쓴 티 나는데, 뭐 딱히 틀린 내용 있음? 요즘 AI가 쓴 README가 사람이 쓴 것보다 나은 경우도 많은데