Hacker News 의견

• Nix에 대한 호감을 느끼려고 여러 번 시도했지만, 이제는 포기해야 할 때라고 생각함.

  • Nix를 사용하는 두 시스템이 있지만, 건드리는 것이 두려움.
  • 이론적으로 Nix는 멱등성(idempotent)과 결정론적(deterministic)이지만, 모든 의존성 부분을 정확히 이해하지 않으면 이상한 결과와 도움이 되지 않는 오류를 마주칠 수 있음.
  • 문서화가 매우 형편없으며, 튜토리얼은 일부만 도움이 됨.
  • Docker의 강점은 혼돈 자체에 있으며, 쉘과 패키지 관리자에 대한 기본적인 이해만으로도 거의 모든 것을 쉽게 구축할 수 있음.

• Nix와 NixOS는 GitHub 이전의 git과 비슷한 상태에 있음.

  • 기본 아이디어는 현재의 SVN, Docker보다 더 심각한 컴퓨터 과학에 기반을 두고 있음.
  • flox의 출시로 상황이 바뀌었을 수 있으며, flox는 사용하기 쉬움.
  • flakes와 nix-command 없이는 Nix가 의미가 없으며, 이들은 실험적이고 기본적으로 비활성화되어 있음.
  • Nix/NixOS 또는 유사한 것이 Docker를 동일한 상태로 만들 것이지만, GitHub 순간이 오기 전까지는 그렇지 않을 것임.

• Darwin에서 Docker 이미지를 빌드하는 데 2-3일을 보냈고, 이 기사는 나를 조롱하는 것 같음.

  • Nix는 원하는 것을 달성하기에 최고의 도구이지만, 때때로 영혼을 말리는 어두운 구석이 있음.

• 공유 Docker 레이어가 유용한 이유에 대한 설명이 블로그 포스트에 누락됨.

  • 캐싱 때문에 유용함. 더 많은 이미지가 동일한 레이어를 공유할수록 캐싱이 더 잘 됨.
  • Nix는 이미 해시를 통해 의존성을 저장하므로 레이어는 항상 동일한 버전과 구성으로 동일함.

• Java 애플리케이션을 위한 Docker 이미지를 Nix로 빌드하는 경험은 그리 즐겁지 않았음.

  • gradle2nix가 폐지된 후, Gradle 기반 Java 애플리케이션을 위한 Docker 이미지를 빌드하는 명확한 대체 방법이 없음.

• 이미 Nix를 채택한 경우에 유용하며, Nix나 Guix와 같은 더 선언적인 패키지 관리 솔루션이 대중화되기를 바람.

  • Docker를 사용하면서 점진적으로 Nix를 채택하고 싶다면, Dockerfile을 유지하면서 Nix 구성을 빌드하는 대안적 접근 방식이 있음.

• 플랫폼 엔지니어로서 Nix를 좋아하고 싶지만, 모두에게 쉽지 않음.

  • 예를 들어, devbox add python@3.11과 같이 패키지를 추가하는 것을 선호함.

• Nix는 대부분의 라이브러리에 대해 상당한 패키징 노력이 필요할 정도로 업스트림과 호환되지 않음.

  • 복잡한 C 또는 C++ 라이브러리의 경우 Nix를 위해 모든 것을 래핑하는 것이 상당한 작업 부분이 됨.

• 최근에 CI 베이스 이미지를 Nix로 빌드하려고 시도했지만, 이미지가 너무 컸고 링킹 문제로 인해 일부 작업이 제대로 작동하지 않았음.

  • 다중 아키텍처 이미지를 빌드하려면 실제로 다른 아키텍처로 실행하려고 하며, 이는 qemu를 사용한 하드웨어 가상화만 지원함.

• Dagger를 사용하고 있으며, Docker의 창시자들에 의한 두 번째 시도로 대부분의 문제를 해결함.

  • 이미 사용하고 있는 언어로 파이프라인을 작성할 수 있으며, 레이어 그래프와 고급 캐싱과 같은 BuildKit의 고급 기능을 활용할 수 있음.