NixOS

NixOS は、Nixパッケージマネージャーをベースとした自由かつオープンソースのLinuxディストリビューションである。NixOS はシステムの更新をアトミックに行い、宣言的に環境構築を行えるシステムにより高い再現性と移植性を担保している。

NixOSはNixパッケージマネージャーを通じてNixPkgsを主とした複数のパッケージリポジトリを利用できる。パッケージ構成および設定は特別に設計された遅延評価を行う関数型プログラミング言語であるNix言語を通じて定義される。

歴史 Nixは2003年、エルコ・ドルストラ（Eelco Dolstra）率いる研究プロジェクトとして立ち上げられた。信頼性の高いデプロイ手段の探求を目的としたこの研究の成果は、ドルストラの博士論文 The Purely Functional Software Deployment Model にまとめられ、宣言的かつ純粋関数的に扱う、全く新しいソフトウェア構成へのアプローチを提示した。ユトレヒト大学のエルコ・フィッセルにより監修されたDolstraの研究は、Nixの理論的基礎を築いた。

2006年、アルミン・ヘメル（Armjin Hemel）はNixの思想をLinuxディストリビューションに統合する試みを行い、NixOSのプロトタイプ実装が同氏の修士論文の一部として初めて公開された。

2015年、純粋関数的なソフトウェアデプロイモデルを実装するプロジェクトの支援、ならびにNixOSとそのエコシステムの開発への継続的な支援を提供する目的で、NixOS Foundation がオランダにて設立された。

Wikiの沿革コミュニティによる最初の NixOS wiki は2010年から2011年頃に立ち上げられた。ドキュメントの一元化および共同での知見の共有を目標としていたが、wikiの維持に対するコミュニティの関心が薄れていくにつれ、古く不正確な情報が多くを占めるようになった。

2015年11月、ロク・ガルバス(Rok Galbas)は彼のトーク番組である Make Nix Friendlier for Beginners にてwikiの退廃した現状を指摘し、コミュニティに大きな議論の波を引き起こした。この時多くの開発者がNixパッケージマネージャーのドキュメントサイトとの統合を主張したが、ついにこの対応が取られることはなかった。

2016年中旬、モデレーション不足によってwikiはスパムボットで溢れかえった状態となり、同年8月に編集のロックダウンが行われた。ロックダウン解除を議論するため GitHub に issue が2017年2月に開かれたが、論争は解決に至らないまま終了した。最終的に、2017年5月にてwikiは恒久的に運用停止することとなり、Archive.org に内容がアーカイブとして公開された。

Wikiの不在を埋めるため、Jörg Thalheim (Mic92) が2017年4月にnixos-users GitHub Wikiを立ち上げた。GitHub wiki プラットフォームの編集・加筆を迅速に行える特性によりコミュニティの参入は容易になったが、検索機能や目次といった基本的な機能に欠けていたことがユーザー体験の低下につながり、代替としてMediaWikiベースのwikiがTristan Helmich (fadenb) によって立ち上げられた。nixos-users GitHub WikiのコンテンツはFelix Richter (makefu)によりMediaWiki側へと移行された。

2024年1月、新しく公式wikiを樹立するための運動が開始され、2026年現在使われているWikiが発足した。この「復活」は、「NixOSユーザーのために正確かつ統一されたされたドキュメントを維持する」というコミュニティの意志の表れとされた。

バージョン履歴 NameDateNixOS 13.10 "Aardvark"NixOS 14.04 "Baboon"NixOS 14.12 "Caterpillar"NixOS 15.09 "Dingo"NixOS 16.03 "Emu"NixOS 16.09 "Flounder"NixOS 17.03 "Gorilla"NixOS 17.09 "Hummingbird"NixOS 18.03 "Impala"NixOS 18.09 "Jellyfish"NixOS 19.03 "Koi"NixOS 19.09 "Loris"NixOS 20.03 "Markhor"NixOS 20.09 "Nightingale"NixOS 21.05 "Okapi"NixOS 21.11 "Porcupine"NixOS 22.05 "Quokka"NixOS 22.11 "Raccoon"NixOS 23.05 "Stoat"NixOS 23.11 "Tapir"NixOS 24.05 "Uakari"NixOS 24.11 "Vicuna"NixOS 25.05 "Warbler" NixOS は一年に二回、それぞれ5月末と11月末に安定版のリリースを行っている。

機能サムネイル|NixOSのグラフィカルインストーラー

宣言的な構成 NixOSでは、カーネルからアプリケーション、システムパッケージ、設定ファイルに至るまで、Nix言語で書かれた記述に基づいてNixパッケージマネージャーによって管理される。新しい構成の反映は古いバージョンの上書きを伴わない。

NixOSのシステムは、グローバルな設定ファイル（通常/etc/nixosに存在する）に、望む機能を記述することで構成できる。例として、下記はSSHデーモンを実行するミニマルなマシンの設定である。{ boot.loader.grub.device = "/dev/sda"; fileSystems."/".device = "/dev/sda1"; services.sshd.enable = true; }設定ファイルを変更した後、nixos-rebuildコマンドを使用してシステム構成を（設定ファイルに基づいて）更新できる。コマンドの実行はパッケージのダウンロードとインストール、追加の設定ファイルの生成など、新しい構成を反映するために必要なすべての操作を自動的に行う。

アトミックで信頼性の高いアップデート Nix言語の純粋関数的な特性により、システムの状態にかかわらず、同じ設定ファイルの評価は常に同じ結果をもたらす。

NixOSはシステム構成の管理にトランザクション的なアプローチを採用しており、アップグレードなどの構成変更をアトミックに行う。例として、システム構成の更新が停電などによって中断されたとしても、システムは変更する前、もしくは完全に更新された状態を一貫に保つ。

ロールバックシステム更新の結果が望ましいものではなかった場合、nixos-rebuild switch --rollbackコマンドを利用して古いバージョンの構成にロールバックできる。すべてのシステム構成のバージョンはブート時のメニューに表示され、例えば新しい構成バージョンのシステムが起動できない場合、古い構成バージョンに切り替えて起動することができる。

システム構成の再現性 NixOSの宣言的な構成方法により、システム設定を容易に別のマシンで再現することができる。設定ファイルを別のマシンにコピーし、更新コマンドを実行するだけで、（ユーザーデータなどNixパッケージマネージャによって管理されていない部分を除いて）全く同じシステム構成（カーネル、アプリケーション、システムサービスなどを含む）を再現できる。

ソースコードビルドとバイナリキャッシュの併用 NixOSにおけるパッケージのインストールは、ソースからパッケージをビルドする手順の記述を評価することで行われる。この設計はユーザーによる柔軟なカスタマイズを容易にするが、記述を更新するごとにパッケージを再ビルドする必要が生じ、多量の時間がかかってしまう。そこで、リモートパッケージリポジトリにあらかじめ全パッケージのビルド結果をキャッシュし、パッケージのインストール時に利用可能なビルド結果がある場合、それを直接ダウンロードして利用できる方法が導入されている。ビルド設定の変更、または--option substitute false をインストール時の引数として指定した場合、パッケージはソースからビルドされる。これらの措置により、Nixはソースベースの柔軟性とバイナリベースの効率性を両立しているといえる。

一貫性 Nixパッケージマネージャーは、実行中のシステムがシステムの論理と一致していることを保証する。言い換えれば、パッケージの操作が行われた際、関連するすべてのパッケージも再ビルドされる。例えばカーネルを変更したとすると、関連するカーネルモジュールがすべて再ビルドされる。同様に、ライブラリがアップグレードされると、そのライブラリに（静的にリンクされているパッケージをも含めて）関連する全てのパッケージが、新しいバージョンのライブラリを使うように再ビルドされる。

ユーザー間におけるパッケージ管理 NixOSでは、個別のユーザーがパッケージをインストールするのに特権を必要としない。全システム共通のプロファイル以外に、ユーザー別にそれぞれ独自のプロファイルが割り当てられているため、たとえ同じパッケージの違うバージョンを複数のユーザーがインストールしていたとしても、これらのパッケージは共存できる。複数のユーザーが同じバージョンの同パッケージをインストールしようとすると、パッケージのダウンロードおよびビルドは一回だけ行われる。

Nixはこの操作が安全であることを保証している。なぜなら、システム設定によって明示的に信頼されたユーザーだけが derivationの生成結果を制御できるビルドパラメーター（ビルドサンドボックスに不純物を追加したり、信頼されていないSubstituterー追加のNixストアーを利用するなど）の使用を許可されているからである。そのようなパラメーターが含まれていない場合、ユーザーはビルドにシステムより信頼されたsubstituter、もしくは暗黙的に信用されるローカルのサンドボックス化されたビルド環境のみ使用できる。

実装 NixOSはパッケージ管理にNix (パッケージ管理システム)を利用している。すべてのパッケージは独立した状態でNixストアに保存される。

インストールされたパッケージは、ビルド過程に入力されたすべての情報に基づいて一意なハッシュ値を与えられる。ビルド手順を変更すると異なるハッシュ値が生成され、異なったパッケージとしてNixストアにインストールされる。この仕組みは設定ファイルの管理にも使用され、設定の更新が過去の設定履歴を上書きしないための措置として導入されている。

この特異なパッケージ管理方法により、NixOSのディレクトリ設計は Filesystem Hierarchy Standard に準拠していない。唯一の例外は、/bin/shがNixストアにインストールされたbashへのシンボリックリンクとして存在していることである（例：/nix/store/s/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/）。システムワイドの設定ファイルを保持する/etcディレクトリは存在こそするが、その内容のほとんどは/nix/storeに存在するビルド生成物へのシンボリックリンクである（例：/nix/store/s2sjbl85xnrc18rl4fhn56irkxqxyk4p-sshd_config）。これは、複数のバージョンのパッケージが共存できるように、/binのようなグローバルディレクトリを回避したためである。

反響 2015年にDistroWatch WeeklyでNixOS 15.09をレビューしたジェシー・スミス（Jesse Smith）はこう書いている：

2022年に書かれたFull Circle紙の NixOS 21.11 "Porcupine"レビュー記事はこう結んでいる：

The Register のリーアム・プルーヴン（Liam Proven）による NixOS 22.11「Raccoon」のレビュー：

DistroWatch のジェシー・スミスによるNixOS 23.11 「Tapir 」のレビュー：

NixOS

Źródło i licencja