GitHub의 라이선스 절에 “This project is not derived from Darling.”이라고 명시했으니 Darling을 분명 알고 있음

이 프로젝트가 Darling보다 더 큰 추진력을 얻을지, 아니면 Linux에서 실행하고 싶은 macOS 전용 프로그램 자체가 너무 적을지 궁금함

Wine은 게임 덕분에 큰 지원을 받았지만, 지금도 생산성 앱 호환성은 훨씬 부족한 경우가 많음

Linux ARM에서 macOS CLI 바이너리를 네이티브로 실행하는 실험적 프로젝트를 개발 중임
7-Zip은 8천 개 파일 트리의 다중 스레드 압축 테스트를 통과했으며 현재 Linux 네이티브보다 약 5.2배 느리지만 최적화 계획을 마련했음. curl은 자동화된 Docker 테스트에서 200개 이상의 명령과 옵션을 통과했고, Xcode Tools Git은 init, add, commit이 작동하지만 아직 완전한 안정성을 보장하지는 못함. 건설적인 비판과 아키텍처 아이디어를 받고 싶음

결국 Linux에 이미 존재하는 프로그램이 아닌 바이너리를 대상으로 할 텐데, 어디서부터 시작할 계획인지 궁금함

서로 다른 macOS 대상 버전과 각 버전의 제약까지 지원할 계획인지 궁금함
예를 들어 구형 macOS에서는 /usr/에 쓸 수 있었지만 최신 버전에서는 수작업 없이는 불가능함. 공개된 Darwin 소스를 활용해 비슷한 기능의 CLI 도구도 제공할지, macOS 환경을 전제로 한 /bin/bash 스크립트를 실행하면 uname -o가 Darwin을 반환할지도 궁금함

반대로 macOS에서 Linux 바이너리를 실행하는 프로젝트를 만들고 있음. 활발히 개발되는 비슷한 프로젝트를 찾지 못해 시작했으며, 접근 방식은 매우 유사하지만 Zig로 작성했고 곧 공개할 예정임

오랫동안 원하던 기능이지만 저장소와 문서를 살펴보니 문제 범위가 훨씬 크고 해결책은 아직 초기 단계로 보임. 앞으로 어떻게 발전시킬지 지켜보고 싶음

프로젝트는 멋지지만 Kakehashi라는 이름은 좋지 않다고 느낌. 소프트웨어 엔지니어가 작명에 강한 편은 아니라 해도 지나치게 별로임

이전 프로젝트는 WIE(Wie is Emulator)였고, Cranelift JIT로 macOS에서 PE64 바이너리를 실행하려는 시도였음. WINE을 빗댄 농담이었으며 GitHub 조직 이름에도 남아 있음
이번에는 더 개념적인 이름을 원했음. Kakehashi(掛け橋)는 일본어로 ‘다리’ 또는 ‘중개자’를 뜻하고, 어감과 Asahi Linux와의 조화도 마음에 들었음

Kakehashi는 아시아에 사는 인류 3분의 2에게 충분히 괜찮은 이름임. 다른 문화에도 마음을 열 필요가 있음

이름이 반드시 영어여야 하는 것은 아님

오랫동안 기다려 온 프로젝트임. 충분히 발전한다면 yabridge와 비슷한 계층을 구현해 Linux에서 AU 바이너리를 실행할 수 있기를 바람

실제 사용 목적이 무엇인지 궁금함. 유용해지려면 최종적으로 GUI까지 필요할지, 아니면 CLI만으로도 가치가 있을지 알고 싶음

완전히 재배포 가능한 이미지를 포기하고, 고전 콘솔 게임 디컴파일 프로젝트처럼 빌드할 때 원본 ROM을 요구하는 방식을 택하면 더 쉬워질지 궁금함
처음부터 다시 작성한 라이브러리를 배포하지 않고 실제 macOS 설치에서 복사한 전체 rootfs 안에서 바이너리를 실행하도록 가상화 프레임워크를 설계한다면 난이도가 얼마나 낮아질까 싶음

게임에서 원본 ROM이 필요한 주된 이유는 자산 때문인 것으로 알고 있음. 운영체제에 같은 방식을 적용하면 사실상 가상 머신과 비슷해져 더 느리고 오버헤드도 커짐

이 프로젝트가 정말 클린룸 구현인지, Claude나 개발자가 작성한 코드에 Darling에서 파생된 부분이 없는지 어떻게 확인할 수 있을지 궁금함

개발 과정에서 LLM을 사용했음. AI가 관여할 때 엄격한 의미의 클린룸 설계인지는 논쟁의 여지가 있어 라이트 그레이룸 방식이라고 봄
직접적인 코드 표절은 없음. Kakehashi는 Rust로 처음부터 작성했고 Darling은 C/Objective-C 기반임. Darling은 커널 수준 에뮬레이션을 사용하지만 Kakehashi는 Linux ARM용 경량 사용자 공간 접근에만 집중하는 등 아키텍처도 근본적으로 다름. 프롬프트에는 독점 구성 요소를 사용하지 말라고 명시했으며, 저장소 감사도 환영함

Darling은 다른 언어로 작성돼 LLM이 코드를 그대로 복사했을 가능성은 작아 보임. 하지만 거의 유일한 선행 구현이므로, LLM이 이 문제를 푸는 데 필요한 지식 대부분을 Darling을 읽고 이해해 얻었다고 볼 여지도 있음
인기 오픈소스 프로젝트와 같은 목표를 주되 코드 복사는 금지하고, 그 프로젝트가 축적한 교훈과 실패를 모두 활용하게 하면 어떻게 봐야 할지 흥미로움. LLM 코드가 인간 코드보다 나은 경우도 많아 직접 복사는 오히려 불리할 수 있으며, 인간도 다른 프로젝트에서 영감을 얻지만 일반적으로 표절로 간주되지는 않음