ハクソク

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

NixOSを愛する理由

2026年3月23日原文(birkey.co)

概要

  • NixOS の魅力はLinux自体よりも Nixパッケージマネージャ にある点
  • システム全体を 宣言的・再現可能 に構築・管理できる特長
  • 環境の 実験や変更が安全かつ可逆的 である利点
  • 異なるOS間でも一貫したツール管理 が可能
  • LLM時代の 柔軟な開発・デプロイ環境 としての有用性

NixOSの魅力はNixパッケージマネージャにあり

  • NixOS は単なるLinuxディストリビューションではなく、 決定論的かつ再現可能な関数型パッケージ管理 の思想の産物
  • Nix DSL でシステム全体を定義し、構成を一元管理可能
  • システムの ロールバック や 段階的な変更 が容易
  • 他のOSが徐々に「状態の山」と化すのに対し、NixOSは 宣言的な構成管理 が可能
  • 新しいPCを購入しても、 単一のソースからシステムを再構築 できる安心感

宣言的な設定と一元管理の利点

  • パッケージや設定、キーマッピングなどを 一箇所で宣言的に管理
  • 例：GNOME拡張機能やキーボード設定をNix DSLで記述
    • GNOME拡張機能の導入・設定
    • キーボードごとのキー割り当て変更
  • 手作業のセットアップやスクリプトの断片化 を回避

安定性とアップグレードの容易さ

  • 長期的な安定性 と 半年ごとの予測可能なリリースサイクル
  • 自動アップデート や 安全なアップグレード が可能
  • unstableチャンネル で新しいソフトウェアの試用も容易

実験のしやすさと安全性

  • パッケージの試用やisolated shell（nix shell/nix develop） による安全な実験環境
  • 依存関係やビルド手順も宣言的に管理 でき、システム汚染を防止
  • 異なるOS（macOS、Linux、FreeBSD） でもNixパッケージマネージャを利用可能
  • 開発ツールや依存管理の一貫性を保つことができる

LLM時代の開発環境との親和性

  • ツールやランタイムのバージョン管理 が簡単
  • コーディングエージェントが必要なツールを nix shell/develop で即時導入・隔離実行可能
  • 例：Rust開発環境をNixで即時用意し、 ベースシステムを一切汚さず にビルド完了
  • flake.nix で依存関係を固定し、 再現性のあるアーティファクト としてコミット可能

デプロイとCI/CDにおけるNixの利点

  • Dockerよりも決定論的なデプロイ が可能
  • dockerTools.buildLayeredImage で小型かつ再現性の高いDockerイメージを構築
  • CIパイプラインやデプロイアーティファクト も同じ思想で管理
  • 一貫したソフトウェア管理モデル で、ツールや習慣の断片化を防止

NixOSが体現する理想のシステム像

  • 宣言的・再現可能・可逆的・安定的 なシステム運用
  • 実験の安全性 と アップグレードの容易さ
  • LLM時代の高速なツール変化 にも柔軟に対応
  • 「NixOSが好き」というより「Nixの思想が好き」 という本質
  • 日常的な開発・運用における理想的な表現 としてのNixOS

Hackerたちの意見

Nixをシステム全体で使ったことはないけど、記事に書いてある理由でhttps://devenv.sh/を使うのは楽しいよ。ローカルコンテナより開発がずっと楽だしね。

└

どうして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問題だと思ってて、個々のツールやパッケージを任意のバージョンに固定する必要はないって言うけど、俺はそういうことをしたい、哲学的には間違ってるかもしれないけどね。

Nixの経験はないんだけど、パッケージマネージャーの外で自分でアップデートプロセスを持つソフトウェアはどう扱うの？具体的にはDiscordやSlack、Docker Desktop、Jetbrains Toolboxとか。こういうソフトは使わないのがNixの流儀なの？

└

いや、そういう人気ソフトの最新バージョンを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設定から彼らの設定ファイルを管理できる機会にもなった。

NixOSの一番好きなところは、毎回CIで再ビルドしなくてもいい、決定論的にキャッシュされたパッケージが持てるところだね。Nixで開発環境を設定するのも簡単だし。

└

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

Hacker Newsで議論の続きを見る