Asahi Linux 수석 개발자 Hector Martin, Linux 커널에서 사임

 (lkml.org)
4P by GN⁺ | ★ favorite | 댓글 2개

  • Hector Martin의 패치 메시지

    • Hector Martin은 커널 개발 프로세스와 커뮤니티 관리 접근 방식에 대한 신뢰를 잃었음을 밝힘.
    • Apple/ARM 플랫폼 개발은 다운스트림에서 계속될 예정임.
    • 향후 필요에 따라 서브트리에 대한 패치를 업스트림으로 보낼 수도 있고, 그렇지 않을 수도 있음.
    • 업스트리밍에 도전하고 싶은 사람은 자유롭게 할 수 있음.

  • MAINTAINERS 파일 수정

    • Hector Martin의 이름이 ARM/APPLE MACHINE SUPPORT 섹션에서 제거됨.
    • Sven Peter와 Alyssa Rosenzweig의 정보는 그대로 유지됨.

  • 기타 정보

    • 패치 서명: Hector Martin marcan@marcan.st
    • 마지막 업데이트: 2025년 2월 6일

함께 보면 좋은 글 β

unsure4000   [-]

R4L이 잡음이 참 많은것 같습니다. Torvalds의 리더십이 절실하군요.

답변달기
GN⁺   [-]
Hacker News 의견들

  • 좌절감은 충분히 이해됨
    DMA용 안전한 Rust 추상화를 만들거나 커널 핵심 코드를 맞추는 데 시간을 크게 들였는데, 한 게이트키퍼가 “여러 언어를 원하지 않는다”는 이유로 일괄 차단하면 의욕이 꺾일 수밖에 없음
    Linus가 정말 Rust 통합을 원한다면, 개인 취향으로 거부권을 행사하는 유지관리자에게 맡기지 말고 명확한 정책으로 세워야 함
    그렇지 않으면 기여자는 몇 주나 몇 달을 투자한 뒤 한 사람의 성향만으로 막히는 애매한 상태에 놓이게 됨

    • 처음 Linus가 Rust 드라이버를 실험적으로 장려한 건 맞는 결정이었다고 봄
      새 기술에 장기적으로 약속하기 전에는 실제 경험이 필요했음
      하지만 그 뒤 Rust 드라이버는 꽤 성공적인 것으로 보이고, 이제는 한 커널 유지관리자가 적극적으로 막고 있으니 Linus의 결정이 필요한 시점임
    • Christoph Hellwig는 오래된 하위시스템 유지관리자 중 한 명임
      Rust 개발자 쪽도 더 조심스럽게 행동해야 했고, 누구도 커널 핵심 코드를 깨고 싶어 하지는 않음

  • 몇 년째 말해왔지만, rust4linux 쪽은 업스트림하려고 애쓰는 대신 포크 유지에 힘을 쓰는 편이 나아 보임
    사람과 논쟁하는 시간보다 포팅 시간이 적을 수도 있고, 확실히 더 즐거울 것임
    Rust가 가치를 증명하면 그 포크가 더 나은 운영체제가 되어 배포판들이 하나씩 옮겨갈 것이고, 아니면 C 프로그래머들이 좋은 옛 C로 이겨서 안전성 주장이 현실에서 통하지 않는다는 결론이 날 것임
    rust4linux 리더십이라면 그 주사위를 굴려볼 듯하고, Hector Martin도 다리를 태우는 부분만 빼면 그 방향으로 가는 것처럼 보임

    • Linus와 커뮤니티가 통제하는 Linux가 Google/Samsung/Redhat/Microsoft가 통제하는 Linux로 대체될 때 생길 실제 피해를 과소평가하고 있음
      Linus 트리가 Rust 드라이버를 사실상 거부하고, 업스트림하려는 사람을 계속 괴롭히면 그런 일이 벌어질까 두렵지만 원하지는 않음
    • Hector Martin이 실제로 한 일은 LKML과 Mastodon에서 꽤 화려한 불꽃놀이를 벌인 것에 가까움
      다른 Rust 개발자들을 대표하는 것도 아니고, 적어도 한 명은 공개적으로 동의하지 않았음: https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen...
      포크를 유지하는 편이 더 생산적이었겠지만, 지금까지 그런 일이 벌어진 것도 아니고 앞으로 그럴 거라고 믿을 이유도 없어 보임
    • 포크를 기술적으로 아주 훌륭하게 만들더라도 채택 관점에서는 큰 오르막길을 마주하게 됨
      사람들을 전환시키는 작업량이 엄청날 것이고, Linux 쪽에도 일부 영역에서 Rust를 받아들이려는 의지가 있으니 경쟁하는 쪽이 정말 더 일이 적을지는 회의적임
    • 프로젝트는 순수하게 기술적 장점만으로 살거나 죽지 않음
      역사적으로 그런 예는 너무 많음
    • 커널을 Rust로 공격적으로 다시 쓰겠다는 목표의 포크는 훌륭한 실험이 될 듯함
      거기서 얻은 교훈을 더 주류적인 C/Rust 커널에 적용할 수 있음

  • Marcan이 거칠 수는 있지만, 아래 메시지에서 지적한 것들은 100% 타당함
    Linux 커널이나 비슷한 절차를 쓰는 git에 아주 작고 논리적인 변경이라도 기여해보면, 얼마나 접근하기 어렵고 좌절스럽고 의욕을 꺾는지 눈이 뜨임
    https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...

    • 이메일 스레드를 읽어보면, 목소리가 큰 양쪽 모두 기본적으로 잘못한 부분이 있음
      건설적으로 반대하는 방법이 있는데 DMA 유지관리자는 그렇게 하지 않았고, Rust 유지관리자는 소셜 미디어로 몰려가게 만들면 안 됐음
      R4L이 승인된 이상 C API 변경을 막지 않는 형태의 바인딩은 허용되어야 하고, C API가 Rust를 깨뜨릴 수 있다는 정책이 명확해야 함
      불합리한 유지관리자가 있으면 더 권한 있는 사람이 개입해 반대를 우회할지 유지할지 결정해야 했고, 격한 장광설 전에는 그 방향으로 가는 중이었던 듯함
    • 직접 패치를 보낸 적은 없지만, 한때 Synaptics 드라이버에 트랙패드를 추가하려고 입력 장치 개발자들과 상의한 적이 있음
      다른 트랙패드 추가 업데이트를 준비 중이라 내 것도 넣겠다고 했지만, 5년이 지난 지금도 들어가지 않았음
      반대로 uboot에서 잘못된 업데이트 때문에 emmc, usb, sata 컨트롤러가 망가졌을 때는 dtb 파일 개발자에게 연락했더니 일주일도 안 되어 고쳐졌음
      결국 사람들은 가끔 이상하게 굴고, marcan에게 좋은 일이 있길 바람
    • 몇 번 기여해본 입장에서는 Firefox나 Chromium에 기여하는 것과 비슷하거나 때로는 훨씬 쉬웠음
      물론 매우 시간이 많이 들고 답답하지만, 같은 규모의 프로젝트와 비교하면 반드시 더 심한 건 아님
      임의의 Github 저장소에서 작은 팀이 협업하는 방식이 될 수는 없고, “X 워크플로를 Y로 바꾸자” 같은 단순한 해법으로는 이런 불편이 고쳐지지 않음
    • 현재 드라마와 별개로, 그 정도 위상의 사람이 커널의 끔찍한 절차와 도구를 공개적으로 비판해줘서 반가움
      이메일과 패치 조작용 해킹 더미를 쓰는 방식은 미친 것처럼 보이고, 이해나 기여를 훨씬 어렵게 만듦
      분산형이라고 해서 이런 끔찍한 워크플로가 필수는 아니며, 이메일보다 나은 방법은 분명히 있을 것임
    • 이건 Wikipedia가 아님
      최대한 많은 기여자 확보가 명시된 목표도 아니고, 커널 경험이 꽤 있는 C 프로그래머인 나도 그들이 원하지 않을 거라고 보지만 괜찮음

  • Rust 소동은 Torvalds에게 드문 리더십 실패임
    “절대 안 된다”거나 “좋다, 진행하라”고 명확히 말하는 대신 Rust 문제에서 계속 애매한 태도를 취했고, Linux 커뮤니티의 크고 목소리 큰 일부가 신뢰 위기를 느끼는 상황에서 그 결정은 크게 역효과를 냈음
    R4L은 시범 프로그램으로서 오래전에 졸업하거나 끝났어야 했고, 몇 년간 활발히 개발됐는데도 지위가 불분명함
    Linus가 모두를 같은 방향으로 맞추기보다 부하들이 싸우는 걸 지켜보다가 Martin에게 드라마 책임을 돌린 건 좋지 않은 모습임

    • Martin에 대한 질책은 Rust와 별 상관이 없고 Hector의 행동과 관련됨
      사람들을 공개적으로 겨냥하기 위해 소셜 미디어 캠페인을 위협하는 건 완전히 유해한 행동임
      Rust를 커널 일부에 넣는 것 자체를 모두가 반대하는 건 아니지만, 어느 부분에 어떻게 넣을지가 큰 쟁점이고 Linus는 이런 종류의 불일치에 늘 꽤 손을 떼고 있었음
    • Linux 프로젝트를 성공시킨 거의 유일한 것은 Linus의 강한 리더십이라고 봄
      수년간 비판받았지만, 결국 결과를 내는 건 그 방식이었음
      그런데 이번처럼 Linus가 명확하고 단호하게, 때로는 거칠게 “예”나 “아니오”를 말하지 않으면 커뮤니티는 결정을 내리지 못하는 무능함을 드러냄
      Python에서 GVR이 BDFL에서 물러나기 직전 커뮤니티와 소모적인 싸움을 벌였던 장면이 떠오름
    • 이번 드라마의 원인은 결국 성격 충돌임
      Linus가 기술 로드맵 지시를 내려도 특정 스레드의 승자를 정할 뿐, 성격 문제는 곪아 남음
      Linux에는 소셜 미디어의 관심을 받지 않는 지루한 이메일 스레드에서 기술 문제를 해결하는 편이 가장 나을 수 있음
      함께 일하는 사람들이 원하는 걸 주지 않을 때마다 핵 버튼을 누르려 한다면 혼자 일하러 가는 게 맞고, 그 자체가 나쁜 일은 아님
    • “C++ 사람들을 상대하고 싶지 않으니 C++는 안 된다”는 정책은 Rust 커뮤니티에도 확장해야 함
      Rust 언어의 장점과 별개로, Rust 커뮤니티의 드라마와 설교, 전반적인 우월감은 적어도 C 개발자에게는 꽤 불쾌하게 다가옴
    • Linus가 Martin을 질책했다고 해서 Rust를 절대 우대하지 않을 거라는 뜻으로 읽는 건 너무 나간 해석임
      Linus는 공개적으로 R4L 프로젝트에 여러 번 긍정적이었음

  • 한 개인 유지관리자가 Rust for Linux의 핵심 부분에 거부권을 행사하고 막기 위해 할 수 있는 모든 일을 하겠다고 말할 수 있다면, Linus는 이걸 진짜 프로젝트인 척하면서 다른 사람들 시간을 낭비하는 것임
    기여자들을 그런 환경에 두면 안 됨

    • 일부 하위시스템 유지관리자가 같은 하위시스템이나 상위 유지관리자의 개선 프로젝트를 방해하려고 할 수 있는 모든 일을 하는 건 꽤 어리석음
      Rust 도입이 아직 논의 중이던 때라면 그런 입장이 가능했지만, 이제 Rust는 커널에 받아들여졌음
      이 내분은 장기적으로 커널에 해를 줄 것이고, 매번 이런 논쟁을 볼 때마다 Linux 커널 개발자들이 비합리적으로 적대적이고 함께 일하기 불가능하다는 느낌을 받음
      다만 Linux 유지관리자가 못되게 군다고 소셜 미디어로 드라마를 만드는 것도 마찬가지로 어리석거나 더 나쁨
    • 그는 어차피 거부권을 행사할 수 없었음
      전체 스레드를 읽어보면 유지관리자는 요청에 NACK을 했고, 그 뒤 Greg KH가 들어와 r4l의 일반 정책, 즉 별도 파일과 별도 유지관리자 형태를 재확인했음
      유지관리자의 불만과 무관하게 별도 패치로 Linus에게 직접 병합될 가능성을 은근히 암시한 셈임
      Marcan의 갑작스러운 폭발과 Linus/Greg를 강제로 스레드에 추가한 일은 그 뒤에 일어났고, 다른 rust4linux 개발자들이 상황은 통제되고 있으니 제발 그러지 말라고 요청하는 모습도 보임
    • 유지관리자가 실제로 한 말은 자기 담당 영역의 Rust 코드에 대한 것이었음
      핵심 쟁점은 같은 영역에서 Rust 부분을 맡을 두 번째 유지관리자를 받아들이지 않았다는 데 있어 보임
      Rust 코드 자체에서는 사용 금지보다는 코드 중복이 주된 문제였고, 제안된 코드가 병합되지 않으면 모든 드라이버가 같은 코드를 반복해서 써야 함
    • 문제의 핵심은 사람들이 어떤 것에 동의하길 기대한다는 데 있음
      Linux는 자유 소프트웨어이고, 포크해서 원하는 방식으로 하는 걸 막는 사람은 사실상 없음
      예전에는 그런 일이 자주 있었는데 요즘 사람들은 포크를 두려워하는 듯함
    • 시간을 좀 주면 Linus가 곧 Rust와 관련해 연락할 것임

  • 이 스레드에서 인용함: https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen...
    Simona Vetter와 Dave Airlie의 반응은 꽤 침착하고 핵심을 찌르며, 동시에 치명적으로 보임
    특히 대중을 향한 과시, 몰려오기 유도, 스트리머식 드라마 만들기는 이런 논의에 필요 없고, r4l 팀과 drm 유지관리자 팀이 커널 커뮤니티를 이해하지 못하는 것도 아니라는 지적에 동의함
    그래서 이번에는 marcan 편에 서야 할지 모르겠음

    • Sima도 오늘 아침 일부 발언에서는 너무 멀리 갔음
      https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b0...
      “옳은 쪽에서 유해하게 굴어도 여전히 유해하다”고 말한 직후 @marcan에게 “감당 못하겠으면 꺼져라”는 식으로 말한 건 최소한 눈치가 없었음
      특히 Marcan이 이 일을 처리하는 게 유급 업무가 아니라고 말한 점을 생각하면, 여기서 좋아 보이는 사람은 아무도 없음

  • 내가 맞춰본 바로는 Hector가 누군가, 아마 Hellwig가 Rust 노력을 의도적으로 방해한다고 여겨지는 일을 해서 화가 났고, 그걸 소셜에 올렸음
    Linus는 커널 분쟁에 소셜을 활용한 Hector를 질책했고, Hector는 그만둔 것으로 보임
    분명 부족한 요약일 테니 고쳐줘도 됨

  • Martin은 Asahi에서 열심히 일했지만, 종종 드라마를 찾고 미덕 과시를 하는 것처럼 보임
    이번 건은 Linus 쪽 손을 들어주겠음

    • “미덕 과시”와 “소통”이 요즘은 매우 비슷한 표현처럼 느껴짐
      정확히 어떤 일을 말하는지 몰라 반대하는 건 아니지만, 이제 그 표현이 발언마다 무슨 뜻인지 잘 모르겠음
    • System-D, GNOME 같은 Github 댓글을 읽어보면 Sega 대 Nintendo로 아이들이 말다툼하는 걸 보는 느낌임
      결국 FOSS 개발자들도 다른 사람들과 똑같은 인간이고 같은 결함을 겪음
    • Martin이 Asahi에서 해낸 일이 있는데도 미덕 과시라고 하는 건 서로 반대되는 말처럼 보임
      미덕 과시는 실제 미덕 없이 크게 주장하는 것인데, Hector는 커밋이라는 증거가 있음
      내가 메일링 리스트에 나타나 신념만 떠드는 게 미덕 과시에 가까움

  • Rachel이 자기 블로그 rachelbythebay에서 오픈소스의 바로 이 문제를 다룬 글이 있었던 걸 뚜렷이 기억함
    때로는 유지관리자의 감정에 맞춰 설득하는 뉘앙스가 소프트웨어를 직접 쓰고 개인 포크를 유지하는 것보다 더 큰 일이 됨
    찾았음: Choosing to stay out of the community
    https://rachelbythebay.com/w/2018/10/09/moat/
    https://news.ycombinator.com/item?id=18181409

  • 맥락용 링크: https://news.ycombinator.com/item?id=42926732
    https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...

    • Linus의 질책이 계기가 된 것으로 보임
      다만 Linus가 답장한 이메일을 읽어보면 솔직히 그 질책은 deserved였음
      Hector Martin은 오늘날 가장 똑똑한 해커 중 한 명일 수 있고, geohot과 Playstation 3 해킹을 하던 시절부터 유명했으며 Apple Silicon 취약점도 찾았고 Asahi Linux에서도 훌륭한 일을 했음
      하지만 geohot처럼 다소 유치할 때가 있고, 지금은 소셜 계정도 접근 불가이며 archive.org와 archive.today에도 흔적이 안 보이는 듯해 인상적임
      촉발점은 Apple GPU 드라이버를 Rust로 썼고 커널에 Rust DMA 지원이 필요했다는 점으로 보임
      DMA 유지관리자인 Christoph Hellwig는 Rust를 싫어하고 커널 안의 암처럼 보는 듯하며, Martin이 DMA용 Rust API를 만들도록 돕기를 거부했기 때문에 폭발한 것 같음
      시간이 지나면 서로 화해하거나 누군가 GPU 드라이버를 C로 다시 쓸 가능성이 큼
      최근 정부 분위기에서는 Rust 밀어주기가 예전만큼 크지 않을 것이고, 예를 들어 White House도 메모리 안전 언어의 미래에 관한 문서를 내렸음
      Rust에 들어가던 돈은 줄어들 것이고, 모두를 Rust로 바꾸려는 노력에 반대하는 것이 사회적으로 더 받아들여지게 되고 있음
답변달기