Hacker News 의견

요약하면 다음과 같습니다:

• REPLY_FAULT가 연쇄적으로 전파되는지 여부와 그로 인한 취약점에 대한 우려가 제기됨

  • A가 B를 기다리고, B가 C를 기다리는 상황에서 C가 REPLY_FAULT를 하면 A도 함께 종료되는지 확인 필요
  • 만약 그렇다면 전체 시스템이 취약해질 수 있음
  • SEND가 순환 구조라면 의도치 않게 자기 자신을 종료시킬 수도 있음

• REPLY_FAULT는 접근 제어 등 애플리케이션 특화 오류를 정의하고 구현하는 방법을 제공함

  • 이는 시스템이 작고 밀접하며 대부분 시스템 설계자가 애플리케이션을 작성할 때 유용함
  • 그러나 제3자 코드와 연동할 때는 상대방이 언제든 프로세스를 즉시 종료시킬 수 있어 우려됨
  • 세상에는 관리자에게 시달리는 개발자들이 작성한 많은 열악한 드라이버와 백그라운드 프로세스가 존재함

• 한 팀이 모든 코드를 작성하는 시스템에서는 의심스러운 클라이언트를 제거하는 것이 반복 속도를 높일 수 있음

• Hubris는 서버가 클라이언트가 처리할 수 없는 효과를 수행하도록 하는 커널로 볼 수 있음

  • 이는 코드 재사용과 구성을 어렵게 만들지만 실행 모델을 단순화함
  • 정적 임베디드 시스템에서는 올바른 절충안이 될 수 있음

• Hubris와 Humility는 깊이 몰두하고 싶은 기술이지만 시간과 의무의 한계로 어려움

• HTTP에 대한 만우절 RFC로 "당신이 부끄러워해야 합니다"라는 의미의 HTTP 499 상태 코드를 제안함

  • 이는 "뭐야... 그런데 사실 괜찮네" 같은 맥락에 어울림

• 아인슈타인의 명언 "가능한 한 단순하게, 그러나 지나치게 단순하지 않게"를 인용하며 Hubris의 설계가 후자를 위반했다고 지적함

  • 실제 세계의 혼란을 전혀 허용하지 않는 운영 환경에는 관심이 없음

• Humility는 디버거로서 훌륭한 이름임

  • 많은 프로그래머들이 "좋은" 코드는 디버깅이 필요 없다고 가정하고 디버거 사용을 거부함

• Linux에서는 소켓만으로 다른 프로그램을 직접 종료시킬 수는 없지만, root 권한으로 다른 프로세스를 종료시키거나 심지어 재부팅할 수 있음

  • 컨테이너에서는 root 권한이 일반적이라 이런 위험성이 존재함

• "받아들일 때는 관대하고 내보낼 때는 엄격하라"는 기존 네트워크 시스템의 지혜와는 다소 상충됨

  • 그러나 API를 변경하면서 기존 프로그램의 호환성을 유지하려면 받아들일 때 관대해야 할 수밖에 없음