둘 다 패키지, 또는 배포판일때는 시스템의 재현성을 보장해주는 함수형 패키지 매니저인건 똑같고 매우 유사함. 예전에는 의존성 꼬이는 거 해결해주는 게 주 목적인 것처럼 서술하는 게 많았는데 요즘은 좀 없어진 듯.

guix와 비교했을 때 nix의 가장 큰 강점은 사용자 많다는 거임. 패키지 수만 비교해도 nix는 보니까 8만 넘긴 거 같은데 guix는 16000 정도더라.

언어는 nix는 nix expression language, 빌드할 때는 shell, guix는 guile scheme 쓰는데 이 정도는 취향 문제인 거 같아.

다만 guix는 gnu 프로젝트라 부자유 소프트웨어 안 들어감.  마이크로코드나 펌웨어 때문에 일반 커널 필요하거나 nonguix 채널 넣어야 됨.

guix 장점
1.graft
보안 패치나 엄청 중요한 패치 같은 건 전부 일일이 다시 빌드할 필요 없이 graft로 인풋만 바꿀 수 있음.

2.gexp
빌드할 때 쉘 스크립트 쓰는 nix와 달리 guix는 g-exp라는 빌드용 s-exp를 써서 해커 조상님들이 남겨주신 우아하면서도 강력한 괄호들을 더 많이 쓸 수 있음

3. hurd 쓸 수 있음
쓰는 새끼가 있을 진 모르겠지만
언제 어디서나 당당하게 GNU/Linux가 아니라
GNU 운영체제라고 말할 수 있음.

4.emacs
nix가 하스켈과 연관이 많다면 guix는 그게 emacs인 거 같아. emacs 패키지가 많고 패키징하기도 쉬워.
패키지들 명시되어있는 manifest 파일 만들면 어디서든 재현 가능한 개발환경 구축 쌉가능.

5.부트스트랩
내가 옮겼던 이유인데, 부트스트랩은 재현성과 함께면 인풋을 완전히 관리할 수 있게 되고, 신뢰할 수 있으면서도 다양한 기계에서 검증 가능한 아웃풋을 만들 수 있기 때문에 특히 hpc 분야에서 중요함.
대표적으로는 비트코인이 ci에 부트스트랩 때문에 guix를 사용하고 있고, 유네스코에서 하는 소프트웨어 헤리티지, 그 외에도 각종 hpc에 guix가 꽤 쓰이고 있음.
소프트웨어 자유에도 중요해서 그런지 guix 쪽이 부트스트랩에 공을 많이 들이더라.


몇 가지 예를 들자면 러스트 같은 경우에는 nix는 그냥 바이너리받아서 그걸로 다시 빌드할 때 guix는 cpp로 쓰인 mrustc로 rustc 1.19.0 빌드하고 그걸로 1.19.0 다시 빌드하고 거기서 1.0씩 기차처럼 빌드함.

java도 nix는 러스트랑 상황이 비슷할텐데 guix는 cpp로 쓰인 jikes라는 컴파일러로 classpath라는 자바 라이브러리 예전 버전 빌드하고 그걸로 jamvm이라는 jvm의 예전 버전 빌드해서 그걸로 jdk만들고 그걸로 ant - ecj 에 이어서 엄청 길게 빌드하더라.

하스켈은 hugs나 nhc98로 하스켈 98에서 시작하려고 하던데 잘 안 되는 듯.

gcc는 gnu mes라는 부트스트랩용 툴체인으로 시작해서 c만으로 빌드 가능한게 4.7이였나 그거 빌드해서 다시 그걸로 최신 버전 빌드함.
지금 바이너리 시드가 아마 150MB 정도 되는 걸로 기억해.

6.
누가 만든건지 모르겠는 애니짤