ハクソク

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

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

314日前原文(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を覚えたくらい、全然違うから。

└

Nix-the-languageは、今まで触れた中で最悪のプログラミング言語だよ。Nix-the-languageは、Javascriptのサブセットで、組み込みの怠惰さとちょっと違った構文を持ってる。2025年のプログラムに対する、まさに標準的でメインストリームな考え方だね。それにしても、Nix-the-languageはフロントエンド開発で見られる同じような欠陥も抱えてる。

└

Nix-the-languageは、今まで触れた中で最悪のプログラミング言語だよ。俺も同じ気持ち。マルチライン文字列や文字列補間は本当にいいんだけど、残念ながら、いじられてるテキストの多くはbashで、元々見た目が悪いから、結果的にダブルで見た目が悪くなるんだよね。関数型の部分はまあまあだけど、表現言語として、主に宣言的に使われるから、Nixで何が起こってるのか全然わからないことが多い。コードを読んでも評価を理解するのはすごく遠い感じ。callPackage... これは言語でクールだと思ってたけど、実際にその混乱の深さを体験してみると、全然違った。残りの構文には「なんで？」って思うところが多くて、他の言語に対して独自のことをするから、リズムに乗りにくいんだよね。問題の本質は、実際の内容にあると思う。クロスコンパイルのスライディングウィンドウのやつ... 何度も勉強したけど、実際に何かやらなきゃならないとなると、すぐにLLMに行くことになる。コンパイラにはターゲットがあるからね。

└

正直言って、nixとschemeを見た時点で読むのをやめた。もしschemeプラスnixで、整理されてたら続けたかもしれないけど。

guixを試すのをためらってる一番の理由は、私の知る限り、macOSのサポートがないからなんだよね。

└

その通り、GuixはLinuxとHurdだけだね。

└

まだ早いけど、「macOS Subsystem for Guix」プロジェクトがあるよ: https://superkamiguru.org/projects/msg.html

両方とも好きだな。面白いし、かなり似てる。どちらもコーナーケースがあるのがちょっと面倒。基本的なこと、例えばグラフィックカードのフォールバックがうまくいかないのがイライラする。これはDebianが10年前に解決した問題で、Intel/NVIDIA/AMDに関係なく設定なしでできるはずなのに。正しいドライバーやファームウェアがなくても、VESAやfbdevにフォールバックするのは当たり前だと思う。今ほどブラックスクリーンが多かったことはないよ。Windowsの方が、ドライバーをインストールする間に基本的な解像度を提供するのがうまい。もしかしたら、WaylandやNVIDIAのオープンドライバーの導入で、Linuxエコシステムがこうなってしまったのかも。伝統的なパッケージ管理の逆を行っていて、1つのパッケージを更新したいときに、システム全体の更新がデフォルトで行われるのも問題。これがバグを増やして、安定したシステムの頻繁な更新につながる。改善するためには、2つのチャンネルを追加して、nixos-stable v24とnixos-latest v25と名付けるといい。ほとんどのシステムを1つバージョン下げることで安定性が大きく向上する。もちろん、組み込まれたGrubブートビルドの選択肢は、動作するシステムに戻すのに便利でいいね。Guixがクローズドソースを別プロジェクトの懸念として分けているのも好きだ。でも、どちらもオープンソースだけで簡単にインストールできるか、プロプライエタリを含めるかは同じくらい簡単だよ。

└

どちらもオープンソースだけで簡単にインストールできるか、プロプライエタリを含めるかは同じくらい簡単だよ。 最近本当に劇的に変わったわけじゃないなら、それは違うと思うよ。ほら、ここに公式マニュアルページがある。そこには、メインのnixpkgsリポジトリにある非自由パッケージの使用を有効にする方法が詳しく書かれている。 https://nixos.org/manual/nixpkgs/stable/#sec-allow-unfree そして、こちらがguixの同等物で、完全に別のリポジトリで管理されていて、公式チャンネルでは話したり文書化したり言及したりできないものだ。 https://gitlab.com/nonguix/nonguix これらは同じではないよ。

└

伝統的なパッケージ管理の逆で、1つのパッケージを更新したいときに、デフォルトで全システムのアップデートが行われるってこと？それって、まさにArchのやり方じゃないの？（部分的なアップデートはサポートされてないし）

Guix SDは、非systemd管理を強制している限り、流行ることはないと思う。Shepherdを試す気もないし。systemdで十分だし、もう勝ってるよ。 > 「インターネットを使うためにnonguixを使わなきゃいけなかったんだけど、それがすぐに技術的な影響をもたらした。」 これがGuixに興味を持っている主な理由だね。 - 知名度のある良い言語（lisp）を使っている - 確か、再現性が高い（導出に使われる内容がハッシュに影響する） - 完全なソースブートストラップがある もしかしたら、UXを改善することに集中している誰かが、これを新しく作る必要があるかもね。

└

systemdを導入しても、書くシステム宣言ファイルには違いがないと思う。Lispyな方法でサービスを宣言することになるし。内部でsystemdサービスに変換されるかどうかって、重要なのかな？

└

systemdに慣れた後、ちょっと試しにguixを使ってみることにした。ユーザーの視点から見ると、あんまり気にしなくていいんだよね。複雑なサービスでも結構シンプルだし、特に何か違うことをしてるわけでもない。もちろん、Linuxのユーザーランドがどんどんsystemdに依存していくのは問題になるだろうね。私の一番の不満は、コンピュータにインストールするのがもっと簡単になればいいのにってこと。あるコンピュータではnonguixがないと起動できないけど、それをやるのが本当に嫌なんだ。というのも、nonguixからのシステムインストールは後で色々壊れやすいから。

└

Waylandを試す気もないな。Xorgはもう勝ってるし、多くの人がsystemdの肥大化を避けるのがプラスだって言うだろうね。shepherdとsystemdのエンドユーザーインターフェースはすごく似てるし、宣言型ディストロに移行することはあまり心配しなくていいと思うよ。

実は、Niri「スクロール可能なタイル型Waylandコンポジタ」にもっと興味があるんだ。無限の横ストリップを持つデスクトップ/ウィンドウのパラダイムが有効だなんて考えたこともなかった。欲しいかどうかはわからないけど、かなりユニークだよね。 https://github.com/YaLTeR/niri?tab=readme-ov-file

└

2ヶ月前にwmii（古いsucklessタイルWM）からniriに切り替えたんだけど、sway/i3よりもずっと満足してるよ。試してみて！

└

GnomeプラグインのPaperWMに似てるの？

└

スクロール可能なタイル配置が最高だね。特に、横に二つの広いモニターがあるときは。

└

昔、i3でそんなことやってたな。meta+tabで次のワークスペースに移動して、同じベースのウィンドウを動かすためのコンボも作ってた。でも、結局CompizやKWinでやってたことと同じだって気づいて、戻っちゃった（笑）

└

「無限のストリップ」と考えるより、「各ワークスペースがストリップに配置されている」と考えた方がいいよ。私のワークスペースは大体2〜5カラムあって、ウルトラワイドモニターでは2〜3個が同時に収まる感じ。[1] ウィンドウサイズを調整する時間をさらに減らしたタイルウィンドウマネージャーって感じかな。[1]: 開いてるブラウザウィンドウの狂気については話さないことにしよう。それは96GBのRAMが許す限り、ほぼ無限に近いから。