どうしてdevenvが必要なのか、シェルと何が得られるのかを教えてもらえる？{ pkgs }: pkgs.mkShell { nativeBuildInputs = with pkgs; [ # ビルドツール cmake ninja gnumake pkg-config ]; buildInputs = with pkgs; [ # java jdk8 # コンパイラ gcc clang llvmPackages.libcxx # ライブラリ capstone icu openssl_3 libusb1 libftdi zlib # スクリプト (python3.withPackages (ps: with ps; [ requests pyelftools ])) ]; # capstoneのヘッダーはinclude/capstone/にあるけどblutterはinclude/を期待してる shellHook = '' export CPATH="${pkgs.capstone}/include/capstone:$CPATH" export CPLUS_INCLUDE_PATH="${pkgs.capstone}/include/capstone:$CPLUS_INCLUDE_PATH" ''; }

うーん。home-managerとはどう違うの？

version pinningがdevenv.shやNix全般でどう機能するのか、正直よくわからないんだよね。自分のリポジトリに.tool-versionsファイルを置けば、そこで作業してるみんながasdfを使って同じバージョンのツールをインストールできる。これは低テクで完璧じゃないけど（Nixの全機能の代わりにはならないけど）、それなりに機能するんだ。devenv.shのページの例は、ツールやパッケージを特定のバージョンに固定することを示してないみたい。Nixの熱心なファンたちは、これがXY問題だと思ってて、個々のツールやパッケージを任意のバージョンに固定する必要はないって言うけど、俺はそういうことをしたい、哲学的には間違ってるかもしれないけどね。

いや、そういう人気ソフトの最新バージョンをnixpkgsに熱心に提出するオタクがいるよ。あとはflatpakを使うことを勧めてくるかも。

いい質問だね。今のところ、ちょっとNixの魅力にハマってる。NixOSのLinuxマシンを持ってて、Macにはnix-darwinを入れてる。NixでBrewをインストールして、BrewでChromeみたいなアプリのカスクを管理してるんだけど、これって自動でアップデートされるよね。だから、「flake.lock」は君が言ったアプリにはあんまり正確じゃないかも。

他のディストロとあんまり変わらないよ。自動アップデートの仕組みって、root権限やシステムパッケージマネージャーが使えないから、$HOMEに新しいバージョンをインストールするしかないんだ。アップデートがインストールされたら、システムパッケージはそれにトランポリンみたいになる。Discordを試したけど、最初の起動時にいくつかのアップデートをダウンロードするみたいだけど、バージョンはシステムのやつ（0.0.127、最新は0.0.129）に固定されてる。だから、多分アップデートしないか、しようとして失敗してるんだと思う。

Discordとか、こういうソフトウェアは実は2層のアップデートがあるんだよね。ウェブページのアップデート（基本的にはホームディレクトリにJSを書き込むこと）にはNixOSは何も防げないし、ホストプログラム（つまりElectron）のアップデートはNixOSが無効にしてる。Jetbrains ToolboxはRustupみたいなツールとはちょっと違うカテゴリーで、自分自身のパッケージマネージャーだから。ToolboxでIDEを管理してるなら、そのIDEのバージョンは「Nixの外」にあって、Nixに管理されてないんだ。自分のFHS環境にパッケージされてるだけで、Nix上にあることは全く知らないってわけ。とはいえ、Toolbox自体のアップデートはパッケージマネージャーを通じて行う必要があるよ。最後に、なんでLinuxでDocker Desktopを使うの？ WindowsやMacでは理解できるけど、Dockerは本質的にLinuxに結びついてるから、Windows/MacのアプリはVMを動かしてポートマッピングやファイルシステムのマウントをしてることを抽象化してるんだよね。でもLinuxでは、俺はいつも直接ホストにDockerをインストールしてるだけなんだ。

個人のデスクトップ環境では、最新のnixifiedオプションがないときは普通にインストールしてる。いくつかのものについては、GitHubでスケジュールされたGitHubアクションを使ってアプリのアップデートをチェックするnixモジュールを作ったりして、新しいハッシュを生成してリリースにタグ付けしてる。Claude CodeやCursorのためにそれをやったことがあって、これで自分のnix設定から彼らの設定ファイルを管理できる機会にもなった。

CIにおけるNixはすごく良い組み合わせだと思う。ATprotoのことはあまり気にしてないけど、TangledはNixを使ってCIシステムを構築してて、それがすごく魅力的だなって感じる。GitHub ActionsのCIキャッシングは本当にひどいから、Forgejoがその方向に行ったのはちょっと残念だった。

ChatGPTは、ちゃんと動くコードをまとめるのが得意だよね。最初の試みではうまくいかないけど、3回目にはだいたい成功する。

俺たちの多くはNixOSやnixを使ってるけど、ドキュメントを読んだこともなければ、自分でnixを書いたこともないんだ。それはClaude Codeの仕事だね。

NixOSのウィキが2つあるのも困るよね。nixos.wikiとwiki.nixos.org。wiki.nixos.orgはnixos.wikiが古くて非公式だって主張してる。でも両方とも更新されてるみたいで、どっちがSEOで勝つかはNixOSの質問をググるたびに運任せだよ。

そうだね、昔は同意してたけど、気づいたのは、俺はソフトウェアエンジニアで、大規模なプロジェクトでソースコードを唯一のドキュメントとして使うことに慣れてるってこと。NixOSの素晴らしいところは、nixpkgsをクローンして、他のドキュメントが不十分なソフトウェアと同じように扱えるところなんだ。

NixOSで自分のNixOS設定から安く派生した隔離されたコンテナを実行するための良いプロジェクトを聞いたことある？それが欲しいんだ。基本的に、すべての非標準アプリを自分の小さな世界にインストールできるコンピュータが欲しい。「あれ、面白いな。このシステムには俺だけがインストールされてるみたいだ」と思わせるような。要するに、インターネットから完全に未確認のコードをローカルマシンで実行できて、最悪でも自分のコンテナを壊すだけだって分かるのが理想なんだ。NixOSは、その未来に向かう一つの道だと思う。

そうだね、俺はもう20年近くUnix系のものを使ってる（ほとんどがLinuxで、4年ほどmacOSにハマってたこともある）。最初にArchやUbuntu、Mint、OpenSUSEを使ったときはそれなりに好きだったけど、NixOSを実際に試したら、明らかに正しいと感じて、これがデフォルトじゃないことが気になり始めた。nix-shellで一時的にものをインストールできるのはゲームチェンジャーだし、configuration.nixを見れば自分のコンピュータに何がインストールされているかをすぐに確認できるのがすごくいい。「アンインストール」するのは「configuration.nixから削除して再ビルドする」だけ。ビルドごとに自動的にスナップショットが作成されるから、Archで設定をいじるよりもずっと「大胆」になれる。ビデオカードやWi-Fiドライバーをいじるのが怖かったんだ。何かを壊してしまったら、元に戻す方法が分からなくて、再インストールしなきゃいけなくなるかもしれないから。そんなことはあまりなかったけど、ブートパラメータやカーネルモジュールをいじるのがちょっと怖かった。NixOSの自動スナップショットのおかげで、下位レベルのものをいじるのがずっと簡単（そして楽しい）になった。もし何かを壊してしまっても、最悪のシナリオは再起動して古い世代を選ぶだけだから。これって思ったより大きなことなんだ。例えば、今のノートパソコンでは、USBデバイスが30秒以上使われないと「ウェイクアップ」しなきゃいけないという変な癖があって、最初の3、4語が入力されないことがあった。調べた結果、解決策はカーネルパラメータに「usbcore.autosuspend=-1」を追加することだと分かった。それをやったらうまくいった。もしArchやUbuntuを使ってたら、たぶんそのまま我慢してたと思う。カーネルパラメータを編集するのが怖くて、壊すリスクがあったから。NixOSが大好きだ。離れたいとは思わないし、少なくともこのモデルを放棄したいとは思わない。GNU Guix Systemに切り替えようかとも考えたけど、Nix言語よりLispの方が好きだから、FSF公認のディストリビューションは実際にコンピュータを使う人には本当に面倒なんだ。

Nixはすべての面で優れてる。デスクトップでNixOSを使った経験から言うと、95%は素晴らしくて、5%は非常に辛い。NixOSでつまずくことがあったら、何をしようとしているのかをもっと広く深く理解する必要があるかもね。一般的なLinux OSは形を整えるのが簡単だけど、NixOSは最初からすべての複雑さを支払うことになるんだ。

NixOSユーザーとして3年、Claudeユーザーとして1年以上の俺としては、君の言う通り理想的なフィットだと思う。例えば、Claudeがdconf設定を通じてGNOMEを設定できるのが本当に嬉しい。宣言的にその設定を調整するには、異なる領域の知識やどこを掘り下げるかを知っておく必要がある。でもClaudeはそれを知ってる。でも、常に動いているAIのための環境を設定しようとして、高レベルの抽象化（樹状のflake-partsなど）に従って自分の設定をリファクタリングさせようとすると、全く無知で、成功せずに即興でやってしまう。Nixが人間にとって難しいことは、AIにとっても難しいんだ。型のないラムダが暗黙のファイル外コンテキストで解決されるから、NixOSモジュール、home-managerモジュール、nix-darwinモジュール、flake-partsモジュールなど、どれを見ているのかを知っておく必要がある。それらのモジュールは、親スコープで何がインポートされているかについての仮定をすることがある。だから、プロジェクトのためにかなり広範なコンテキストを提供する必要があると思う。どう構造を持たせたいかを詳しく説明する必要がある。エコシステムはかなり断片化されていて、人々は良いパターンについて完全には合意していないから、AIは良いパターンが何かを知ることができないんだ。はっきりさせておくけど、広範なコンテキストを提供するのは絶対に価値があると思うし、より良いNixベースのプロジェクトテンプレートやNixベースのデプロイメントテンプレートを作るのが本当に楽しいし成功してる。Nixユーザーによって作られた安定した、よく作られたプロジェクトの量は驚くべきものだよ。

確かにその通りだね。自分のflake設定がもっと良くできるって分かってたけど、面倒でやらなかった。今年の初めにClaudeに頼んだら、すべてが改善されたし、ずっと気になってた小さなバグも直った。これをやる自信は、まさに君が言ったことから来てるんだ。もし全てが壊れたら、ただロールバックすればいいから。

時々、Nixのことを考えるときにLLMを使うのもいいけど、Nix言語に慣れてないと、結構やらかしちゃうことがあるんだよね。とはいえ、最近は開発用のフレークが必要なとき、リポジトリにLLMを向けるだけで、必要なものをほとんど理解してくれるから助かってる。Nixは残念ながら、暗闇の中を手探りで進むのに向いてるところがあるんだよね（REPLのことは知ってるけど）。

不変のOSなら、どれでもこの目標を達成できるんじゃない？

Nixを使う前にAIがもっと良くなるのを待ってたんだ。なんか難しそうで、Arch Linuxみたいだったし、時間が取れるか心配だったから。準備として、開発環境を完全にDockerスクリプトに移行して、ネットから動くスニペットをコピー＆ペーストできるようにしたんだ。NixとAIは相性抜群で、これからAIによって安くて使いやすい良いソフトウェアがたくさん出てくると思う。

最近、面倒な設定の問題をいくつか解決したんだけど、（正直言って複雑な）NixOSとHMの設定ファイルの中から見つけるのが面倒だったから、Claudeに頼んで見つけてもらったんだ。Claudeには、始めたけど時間がなくて完全には実装できなかった新しい構造に設定の一部を移す作業をやってもらった。提供した例に基づいて、Claudeにいくつかの異なるWMやDEのテスト環境をセットアップさせたんだ。で、今は自分が望むようにすべてが設定できたから、システムを維持するために特に何もしなくてもいいんだ。たまに更新するくらい（不安定版だから手動でやってるけど）。Claudeを私の.configディレクトリに放り込んで、aptやdnf（など）にアクセスさせて、NixOSじゃない環境をセットアップさせることはできるかな？多分できるし、そこそこうまくいくと思うけど、NixOSを信頼するほどには信じられないかな。

AIがなかったら、どうやってdotfilesを設定してたかわからない。nixの構文はちょっと難しいけど、ロールバック機能があるから、自信を持ってシステムを変更できるんだ。主な問題は、非FHSファイルシステムで、アプリケーションやエージェントが一般的に期待してるものとは違うところかな。

すべてのマシン、ローカルとクラウドにClaude Codeトークンを入れたんだ。マシンはほぼ自動で修正されるようになった。特にNixOSでは、基本的なインストールが終わると、Nixのclaude-codeパッケージが入るから、その後は楽だよ。数週間前にOpenClawが出たから、古いPCを引っ張り出してNixOSをインストールして、Claude Codeを追加したら、ClaudeがOpenClawをインストールしてくれた。Claude、OpenClawのセキュリティ状況について教えて。 「実行権限機能をオンにして危険なコマンドを無効にしますか？」って言って、Claudeがそれをやって、実際に無効になってるかテストしてくれる。私のTelegramボットが混乱してる：「ごめんなさい、そのコマンドを実行するシェル/execがありません。数分前にどうやって実行したの？」

ここでは唯一のゲームだよ。おいおい、LLMもGuixにはかなり良いよ。

すごいよ。自分がパッケージ化するのに何週間もかかるような、超難しいパッケージをたくさんパッケージ化してきたんだ（中には試して失敗したものもある）。NixOSを日常的に使って6年になるから、ディストロにはそんなに新しくないよ。stdenvや言語ビルダーをいじるのも簡単だし、欲しいソフトウェアは、数時間の間にclaude/codexが無監視で回してくれるだけで手に入る。めっちゃいいね！確実に過小評価されてる。

完全に気持ちがわかるよ、そういう理由で離れたんだね。もしまた挑戦したいと思ったら、 > 「フレーク」があるけど、正直あんまり理解できなかったんだ。Nixはフレークを使い始めるまではピンと来なかった。周りには子供じみた内部ドラマがたくさんあって、だからこそ実験的なものとしてマークされていて公式の推奨にはなってないんだ。公式の推奨に従うと、Nixはもっと厳しいことになるよ。フレークの方がずっと直感的なんだ。Determinate Systemsのインストーラーはデフォルトでそれを有効にしていて、彼らのドキュメントは幸せな道に沿ったものだよ（FlakeHubは除いて、まだそれは理解できてない）。基本的なレベルでは、フレークを使うことで、/etc/nixos/nixos.nix（またはそれに類似したもの）を/etcからgitリポジトリに移せるんだ。古いスタイルのnixでもできるかもしれないけど、試す前にフレークを見つけたんだ。以前は/etc/nixでgitを使おうとしたけど、奇妙な所有権の問題でgitが崩壊してた。つまり、nix isoでブートした後に、次のコマンドを実行することで、マシンをインストールして完全に設定できるってことだよ：nixos-install --flake https://github.com/.../repo.git。自分のシステム設定は/home/$user/$cloneで管理してる。/homeに関してはhome-managerがあって、また、そこに導かれることはないんだ（チュートリアルはnix profiles/nix-envの方に押し進めるから）。home-managerは、システム設定がシステムのためにすることを、ホームディレクトリのためにやってくれるし、多くのプログラムモジュールがあるよ。ホームレベルのsystemdユニットも宣言できるしね。 > 手動で編集した/etcファイル。これらのファイルにはenvironment.etcを使えるよ[1]。systemd.tmpfilesは/etc以外のものにも使える。home-managerには.config、.local、.cacheのための同等のものがあるよ。[2]。

それから「フレーク」があるけど、正直あんまり理解できなかった。フレークは2つのことをするんだ：1. あるNixコードベースの入力と出力の宣言。2. この入力ソースのバージョンを固定すること。依存関係の固定は、言語特有のパッケージマネージャーでよく見られるpackage.json/package.lockなどに似てるよ。