ハクソク

世界を動かす技術を、日本語で。

Guixを試してみた：Nixユーザーの印象

2025年7月15日原文(tazj.in)

概要

  • Nixユーザー が初めて Guix を試した体験記
  • GuixとNixのアーキテクチャ的違い や使い勝手の印象
  • non-freeファームウェア 問題と「nonguix」活用の現実
  • ドキュメントやパフォーマンス、initシステム の比較
  • Guixの Lisp環境 や一貫性への評価と今後の課題

Guixを試してみた：Nixerの印象

  • 長年 Nix を利用し、大規模プロジェクトやNix言語インタプリタの開発経験を持つ筆者の視点
  • Emacsユーザー でLispに親しみあり。Schemeはやや経験が浅いものの好意的
  • 今回初めて Guix を実際に使用し、UncharteviceノートPC（Zhaoxin x86_64互換CPU）でniriデスクトップ構築を目指す試み
  • 目的：NixとGuixの違いを体感し、興味深い点を記録
  • 結果：完全な環境構築は未達。多くの発見あり、今後も挑戦予定

GuixとNixの共通点・相違点

  • GuixとNix は低レベルのパッケージ管理基盤（Nix Guix Store、derivation等）を共有
  • ただし、 GuixはNixのSchemeラッパーではなく独立したエコシステム として進化
  • 「NixをLisp構文で書くもの」と考えるのは誤り。両者の設計思想や実装が大きく異なる

non-freeファームウェア問題とnonguix

  • GuixはGNUプロジェクト であり、ソフトウェアの自由を重視。プロプライエタリなファームウェアを推奨せず、同梱もしない
  • 多くの現代ハードウェアで動作させるには「 nonguix」を利用し、非自由なバイナリを追加する必要
  • 筆者も Wi-Fi利用のためnonguix導入。技術的な影響も即座に発生

アーキテクチャ上の違い

  • Nixの構造
    • [nix-daemon] <-> [Nix CLI] <- [Nix code]
    • nixpkgs の複数コミット混在や柔軟な構成が可能
    • CLIとパッケージセットが独立し、バージョン切替も容易
  • Guixの構造
    • [guix-daemon] <-> [guix CLI + profile] <- [Guix user code]
    • パッケージ/サービスはSchemeモジュールの階層構造 で管理
    • guix pull でCLI自体を再構築し、バージョン切替は必ず2段階（guix再構築→設定再構築）
    • バージョン切替や初期セットアップが遅く、キャッシュ破壊が起きやすい
  • Emacsパッケージ管理の違い
    • Guixでは グローバルなprofileインストール が主流
    • Nixの emacs.withPackages のような隔離的環境構築が見当たらず、実験的なパッケージ導入が難しい印象

ドキュメントとオンボーディング

  • Guixコミュニティ は明確な思想と集中した文化を持つ
  • ドキュメントはNixより遥かに優秀。構造化され、Schemeコードとしても詳細に記述
  • ただし、 Schemeの習得が前提 となるため、初心者向けとは言い難い
  • nonguix問題 によるインストール手順の情報不足も障壁
  • 結論： ドキュメントは自信のあるユーザーには有効だが、初心者の障壁は依然高い

パフォーマンス

  • GuixはNixより遅い。特に低スペックCPU（例：Zhaoxin KX-6640MA）では顕著
  • guix pull だけで30～50分要し、その後の設定評価やビルドも時間がかかる
  • Nixでは同等の作業が5～10分で済む
  • 安定運用状態になると改善するとの話もあるが、到達までが大変
  • ビルドサーバー（TVLのnevsky）でGuixをビルド→ノートPCへ転送 を試みるも、guix copyのHTTP転送が機能せず断念
  • GuileインタプリタのJITや評価モデルの違い によるものか、パフォーマンス向上の余地あり

Shepherd（initシステム） vs. systemd

  • Guixはsystemdを採用せず、Shepherd（Scheme製init）を利用
  • 筆者はsystemdに否定的で、Shepherdの採用を歓迎
  • Shepherdは シンプルかつドキュメントが充実。今後さらに検証予定

まとめと今後

  • 現状： GuixはノートPC上で動作するが、GUI未導入・ハードウェア設定も未完
  • nixos-generate-config相当の自動設定ツールがなく、手動で設定推測が必要
  • チャネル管理の失敗で再度guix pullが必要 となり、さらなる時間消費
  • Lisp環境やエコシステムの一貫性は魅力
  • GuixがNixにないものを提供できるかは未定。まずは NixOS相当のデスクトップ環境構築と反復作業の効率化 が目標
  • 今後も継続的に挑戦予定

Hackerたちの意見

読みやすいね。NixとGuixの両方に詳しいユーザーによる比較投稿がもっと必要だと思う。ほとんどの議論にはバイアスが見られるし。Guixの欠点は、インフラが整ってないことと、Guixエコシステムに取り組むボランティアが少ないことかな。それが解決されれば、Guixは飛躍的に改善すると思う。

└

Guixは最近SavannahからCodebergに移ったんだけど、これがインフラやボランティアの数に関する問題を改善する助けになるといいな。

└

主要な欠点は記事に書いてあるけど、更新がめちゃくちゃ遅いんだよね。30分もかかるなんて、ちょっとありえない。誰もそんなの使わないよ。

└

比較投稿がもっと必要だ この記事はGUIX システム とNixOSの比較に焦点を当ててるけど、GUIXとNIXを別のLinuxディストリビューション（例えばDebian）で使うパッケージマネージャーとして比較したら、もっと面白いと思う。そうすれば、ブートに必要なバイナリブロブの複雑さを気にしなくて済むから、GUIXの方が良い結果になるかもしれないね。

└

nixからguixへのパッケージの自動化って可能かな？多くのnixパッケージ（例えばpython）は自動的に処理されてると思う。もしguixがあの巨大なパッケージリポジトリを利用できれば、本当に助かると思う。

私も似たような経験がある。古いノートパソコンでguix pullを何回か実行した後、プロジェクトを棚上げしちゃった。distccクラスターを作るまで手をつけなかったけど（結局作らなかった）。

フレークがナンセンスな理由 うわ、もっと聞きたいな。私はフレークが好きだけど、論争の的だって知ってるし、理由をあまり聞いたことがないんだよね。

└

フレークが好きだよ…フレークを使ってる。君もフレークが好きなら…使い続けて！あとは政治の話だね。

└
  • flakesは大きなリポジトリではパフォーマンスが悪い。これがlazy-treesで変わるかもしれないけど、それを待って2年以上経ってる。 - flakeの入力は遅延取得されない。 - flakesは、任意の値で入力をオーバーライドできないという点で、ちょっと制約がある。特に特別に設定されたnixpkgsオブジェクトを渡したい場合には重要だよ。実際には、非自明なユースケースでは、flakesは解決しようとしている問題を解決できてないことが多い。ほとんどのflakesは、これらの高度なユースケースのためにlib関数を公開してるけど、非-flakesで得られるものとほぼ同じだよ。
└

変な方法で評価されるんだよね。例えば、入力を宣言する時にrecキーワードが使えない。

└

Flakesは、伝統的なNixワークフローとの互換性を壊す並行エコシステムを作るため、主に物議を醸している。コアの再現性の問題を解決することなく、追加の複雑さを導入し、限られたコミュニティの意見で開発されたにもかかわらず、Nixの動作方法に根本的な変化をもたらすものだから。

とても興味深い記事だね。長いことNixを使ってるけど、Guixを試してみたいと思いつつ、なかなか時間が取れなかった。全体的に素晴らしい投稿だよ。 > ただ、Guixのドキュメントがオンボーディングをスムーズにするかは正直わからない。だってSchemeを知ってないといけないから、Nixよりも複雑な言語なんだよね。笑えないくらいダメだよ。Nixという言語は、私が今まで関わった中で最悪のプログラミング言語だ。大学の授業で1日でSchemeを覚えたくらい、全然違うから。

Hacker Newsで議論の続きを見る