NixOSは、新しいタイプのソフトウェアビルドツールを搭載したディストリビューションです。インストールして動作させることはできますが、奇妙なことに、それが本質ではありません。
これは従来のLinuxディストリビューションではないため、従来のディストリビューションレビューでもありません。「聞かなければ理解できない」という発言は、最も腹立たしいものの一つであることは承知しています。NixとNixOSを部外者として理解しようとするのも、まさにそれに似ています。ウェブサイトやWikiで語られている利点やメリット、あるいはLinux.comのような初期の記事でさえ、どちらかといえば理論的なものです。Nixコミュニティが重要視している点と、一般的なデスクトップOSユーザーが重要視する点の間には、ほとんど重なりがなく、その溝を埋めるのは困難です。
Reg FOSSデスクでは、コンテナ化パッケージングの記事に続くLinuxソフトウェアパッケージング特集の第2弾以来、NixOSを試してみようと考えていました。そして、ついに好機が訪れたので、ダウンロードしてインストールしてみました。そして、いくつか大きな注意点はあるものの、ちゃんと動作することを確認しました。しかし、奇妙なことに、それが本題ではないかもしれません。
NixOSライブインストールメディアにはGNOMEとKDE Plasmaのフレーバーがありますが、好みのデスクトップをインストールできます。
NixOSは、Nixパッケージングシステムで構築されたLinuxディストリビューションです。今月初めに、OSの新バージョンであるNixOS 22.11「Raccoon」がリリースされました。x86-64およびAArch64コンピューターをサポートし、そのパッケージはこれらのアーキテクチャで動作する他のLinuxディストリビューションやmacOSでも使用できます。
ここで重要な点の一つは、Nixのパッケージングシステムこそが重要であり、NixOS自体はほぼ概念実証に過ぎないということです。ウェブサイトに記載されている上位3つの利点、すなわち再現可能なビルド、宣言的な設定、そして信頼性の高いインストールは、パッケージングシステムの特性であり、ディストリビューション自体の特性ではありません。インストールの容易さ、ユーザーフレンドリーさ、ハードウェアサポートといった、一般的なLinuxディストリビューションに求められる要素は全く考慮されていません。
これにより、レビュー担当者が関心を持つ質問が当てはまらないため、レビューが少し難しくなります。では、それらの質問を排除しましょう。これは Linux OS です。Linux が動作する環境では動作しますが、Linux が動作しない環境では動作しません。他の Linux でできることはできますが、Linux でできないことはできません。必要なデスクトップを選択すれば、そのデスクトップで動作します。このリリースには、GNOME、KDE Plasma、Xfce、Pantheon、Cinnamon、MATE、Enlightenment、および LXQt が含まれています。プロジェクトでは、64 ビット Arm および x86 用に GNOME および KDE Plasma が事前構成されたダウンロード イメージと、GUI のない最小限のインストール イメージが提供されています。GNOME イメージを試したところ、問題なく GNOME が起動し、そこから Xfce システムをインストールして完璧に動作しました。
問題の一因は、非常に活発なサブレディットから判断すると、Nixコミュニティが関心を持つ問題は、多くのディストリビューションが抱える問題とは異なるということです。これは特異なことではありません。例えば、Gentooユーザーは、コンパイラフラグやコード最適化設定など、ほとんどのユーザーがほとんど意識していないような問題に強い関心を持っています。
Nixは、ソフトウェアセットを再現性のある形で定義し、構築することを目的としています。設定ファイルを作成すると、Nixツールがそれをどのようにビルドするかを計算し、実行します。その結果は毎回全く同じになります。つまり、ビルドは再現可能です。NixOSプロジェクトは、Software Freedom Conservancyが支援するReproducible Builds組織に所属しています。
ここでの核心となる問題は、同じソースコードを取得し、同じ設定でビルドすれば、全く同じ結果が得られることを保証することです。Gentooとは異なり、ほとんどのLinuxディストリビューションはバイナリをベースにしています。つまり、ソフトウェアをビルドし、ユーザーがインストールするのです。Ubuntuは唯一無二の存在であり、その様々なリミックスは、ほとんどの場合、それらのバイナリを組み合わせてインストール可能なインストールメディアを作成しています。Ubuntuを使うことを選択するということは、Canonicalを信頼することを選択するということです。これは、Canonicalの創設者が当時大きな論争を巻き起こした有名なブログ記事「We Have Root」で意味していたことです。
Rocky や Alma Linux などの RHEL のリビルドのような他のディストリビューションの場合は状況が異なり、再現可能なビルドが重要です。このようなディストリビューションを使用している場合は、おそらく高価な有料のアップストリームとの互換性が保証されているため、RockyLinux のバイナリが RHEL のバイナリと本当に同一であることが気にされます。そうすれば、特定の特殊なハードウェアなど、RHEL で動作するものは、AlmaLinux や Rocky Linux でも動作することを確信できます。これにより、互換性の問題はある程度意味をなさなくなります。特定のモデルやサーバー構成と互換性があるかどうかは気にしません。そのサーバーが RHEL との互換性が認定されている場合、他のディストリビューションが RHEL と互換性があることが気にされます。なぜなら、それはそのサーバーと互換性があることを意味するからです。
言い換えれば、Google ChromeをGoogleからダウンロードするということは、Googleを信頼する必要があるということです。なぜなら、Chromeを自分でビルドすることはできないからです。結果として、オープンソースのChromiumブラウザを選択した場合、公開ソースコードからChromiumのバイナリをビルドするための特定の設定ファイルセットが必要になるかもしれません。そして、全く同じ結果が得られるという確信が持てます。つまり、仮の例を挙げると、世界中のすべてのサイトがそれぞれ独自のコピーをビルドできるようになり、一箇所でビルドしてそれを各ブランチに配布する必要がなくなります。Chromiumには約3500万行のコードがあるため、これは大変な作業です。文字通りにも比喩的にも、多くの変数が存在するのです。
もちろん、特定のバージョンのChromiumの特定のビルドは、Linuxディストリビューション全体の中では比較的小さな部分にすぎません。OS全体の構築ははるかに複雑です。ブラウザ、ブラウザをビルドするためのすべてのツール、18種類の構成プログラミング言語でコードをビルドするためのすべてのツール、そして結果の実行に必要な様々なライブラリ、そしてビルドツールの実行に必要なライブラリなどが必要です。
非常に複雑です。VMwareのSaltStackやRed HatのAnsibleのようなツールが存在する理由の一つは、マシンのインストールと設定を自動化するためです。設定ファイルを作成し、ソフトウェアを特定のマシンに指定するだけで、ツールがインストールと設定を自動的に行います。筆者は10年近く前にRed Hatで短期間勤務しており、個人用ラップトップのセットアッププロセスを自動化するために独自のAnsible「プレイブック」を保守している、過去および現在のRed Hat社員を個人的に知っています。
- TORブラウザ12がアルバニア語、ウクライナ語をサポートしてリリース
- MacOS9.app: エミュレーションと統合の傑作
- 最も古いLinuxデスクトップであるXfceの最新バージョンがXubuntuビルドで公開されました
- Linuxカーネルのフロッピー処理における長年のバグを修正
Nixは、この問題の解決をソフトウェア構築スタックのさらに下層へと進めます。ある組織が様々なツールチェーンを用いてバイナリを構築・パッケージ化し、その後、他のツールがそのソフトウェアをインストール・設定するといった作業ではなく、Nixツールを使えば、最終的な結果が何であるかを、同じくNixと呼ばれるカスタムプログラミング言語で指定するだけで、Nixツールが自動的にそれを実現します。もし最終結果が期待通りでなかったり、正しく動作しなかったりした場合、Nixは変更をロールバックし、すべてを元に戻してOS全体を元の状態に戻すことができます。
これはDNFやAPTといった従来のパッケージマネージャでは不可能な機能であり、SUSEファミリーのディストリビューションではBtrfsスナップショットを使用して同等の機能を提供しています。この次世代機能こそが、SUSEがMicroOSベースのAdaptable Linux Platformに事業を賭けている理由です。Fedoraプロジェクトも同じファイルシステムを使用していますが、スナップショット機能は全く使用していません。そのため、SilverblueとKinoiteという別のエディションが用意されており、これらのエディションではRed HatのOStreeツールを使ってイメージベースのデプロイメントを行っています。
Nixはファイルシステムを利用してこれを実現しますが、これはUnixらしからぬやり方です。SUSEファミリーでは、Linuxディレクトリツリーで様々なスナップショットを直接確認することはできません。Btrfsツールを使ってのみ確認できるのです。NixOSでは、OS全体がNixによって構築・管理されているため、従来のディレクトリもいくつか存在しますが、その内容は期待通りではありません。スクリーンショットに示すように、1つの統合ディレクトリが存在し/bin、そこには1つのファイル（ を提供するためのシンボリックリンク）のみが含まれていますsh。
NixOSの/binディレクトリは驚くほど空っぽです。そこにあるのはBashシェルを提供するためのシンボリックリンクだけです。
/binUnixのファイルシステムレイアウトに精通していて、から知識を得ている人にとって/usr/local/bin、NixOSは衝撃的な存在となるでしょう。 というパッケージ管理コマンドがありnix-env、これを使ってソフトウェアをインストールできますが、面白いことに、特定のパッケージを探すには、Nix wikiの提案によるとsearch.nixos.orgで検索するように書かれています。
すぐに使えるLinuxマシンを思い浮かべた時、特定のツールセット、例えば特定のバージョン、そしてそれらを開くための入力方法など、具体的なイメージが容易に思い浮かぶなら、NixOSは最適です。必要なパッケージを設定ファイルで指定する方法を学べば、NixOSが自動的にそれを実行し、最新の状態に保ちます。ただし、特定のパスにパッケージがあるという考えは捨ててください。実際にはそうではありません。パッケージは直下の非常に長いフォルダに配置され/nix/store/、OSに管理させる必要があります。
自分に合ったデスクトップがまだ分からず、いろいろ試して、学習して、プログラムを追加したり、試してみたり、削除したりしたいと考えているなら、NixOSはほぼ間違いなく不向きです。また、Unixマシン上での配置を完璧に把握している方にも、NixOSは不向きです。
しかし、すでに確かな知識があり、かつそれを手放して新しい方法を学ぶ意欲があるなら、大きな可能性を秘めていると言えます。とはいえ、ツールの成熟度に大きく左右されます。これまでの経験がまったくない状態から始めて、GNOME ISO を入手し、Virtualbox にインストールし、Xfce デスクトップを選択すると、大きな問題なく完全に機能するインストールが実現しました。デフォルトのインストールでは、デスクトップ、Firefox、および期待される基本的なアクセサリが提供されました。LibreOffice の追加は、次のように入力するだけでnix-env -iA nixos.libreoffice、数秒後にはバージョン 7.3.7 がインストールされ、動作しました。ただし、Xfce のアプリケーション メニューに表示されるようにするには、再起動する必要がありました。LibreOffice では 6GB 未満のディスク容量を使用し、Xfce ではアイドル時に約 350MB の RAM を使用しました。
ある意味、NixOSはDevOpsのアプローチを自分のコンピュータに取り入れることを意味します。どこに何があるのか、依存関係はどうなのか、インストールに必要なコマンドは何なのかなど、心配する必要はありません。必要なものをリストアップし、Nixに任せれば、あとはOSが何をどこに保存するのか、どこから来たのか、コンパイルが必要かどうかなど、すべて任せられます。
わずか2、3年前のNixOSに関するレポートと比較すると、インストールと動作は非常に簡単でした。これは、ツールが順調に成熟し、ある程度の完成度に達していることを示していますが、初めて使用する私たちにとっては、比較対象となる基準が全くありません。これは従来のディストリビューション、いや、従来のUnixとは全く異なりますが、問題なく動作し、その魅力は理解できます。
先入観を捨てて一からやり直せる立場にあるなら、NixOSは非常に魅力的に見えます。現在のOSを維持する必要がある場合は、Nixパッケージマネージャを既存のディストリビューションのサブフォルダに配置すれば、そのツリー内で動作します。個々のLinuxマシンを頻繁に入れ替える立場にあり、必要なツールが揃っていて動作することよりも、それを実現するのにかかる時間の方が重要であれば、NixOSは検討する価値があります。®
