不変Linuxシステム入門

 (dataswamp.org)
3 ポイント 投稿者 GN⁺ 2023-09-19 | 1件のコメント | WhatsAppで共有
  • 不変Linuxディストリビューションは、アップグレードを実行中のシステムではない場所で準備し、次回の起動時に適用することで、失敗時に元へ戻せる運用方式を提供する
  • 「不変」という名前とは異なり、システムの多くの領域は依然として変更可能であり、実際の共通点は トランザクション更新 とロールバックに近い
  • NixOS・Guix は宣言的構成と読み取り専用ストアを中核に据え、OSTree 系・MicroOS・Vanilla OS はそれぞれ /usr、btrfs スナップショット、A/B ルートパーティションでアプローチしている
  • 利点は、パッケージ変更中でもシステムを安定して保ち、問題を巻き戻せることだが、再起動の必要性・構成管理ツールとの衝突・変更追跡の難しさは残っている
  • 新しさはスナップショット自体よりも、ライブではない環境に変更を適用し、ブートローダーやユーザーツールに統合して扱いやすくした点にある

「不変」という名前の実際の範囲

  • 不変性は本来 変化しないオブジェクト を意味するが、オペレーティングシステムに適用すると定義はすぐに曖昧になる
  • Linux LIVE-CD は毎回同じプログラムで起動し、ディスクメディアが読み取り専用である点では不変に見えるが、実行中にはファイルやディレクトリを作成したり、パッケージをインストールしたりできる
  • 現在、不変 Linux ディストリビューションと呼ぶには、おおむね次の3つの条件が必要になる
    • システムアップグレードを ライブシステム 上で直接実行しない
    • パッケージ変更を 次回の起動時 に適用する
    • 以前の状態へ ロールバック できる
  • 実装ごとに追加機能は異なるが、この3点が現在の「不変」ディストリビューションの最小条件に近い

実装ごとの違い

  • NixOS / Guix

    • NixOS と Guix は同系統の実装に依存しており、Nix は 2003 年に初登場し、Guix パッケージマネージャーは 2010 年代初頭に Nix からフォークされ、100% 自由ソフトウェアを目指している
    • この2つのシステムは従来の Unix 系システムと大きく異なり、不変性 を中核原理としている
    • すべてのパッケージとビルド済みファイルは、パッケージマネージャーだけが使える特別な読み取り専用ディレクトリに一意の項目として保存される
    • オペレーティングシステム自体がパッケージマネージャーの生成物であり、ユーザーは望むシステム状態を 宣言的構成 として記述する
    • 構成には、ユーザー、シェル、インストール済みパッケージ、実行サービスと設定、マウントするパーティションやオプションなどが含まれる
    • モジュールがデフォルト値を提供するため、ユーザー作成時に UID、GID、シェル、ホームディレクトリをすべて手動指定する必要はない
    • /etc/fstab や /bin/sh のようなファイルも読み取り専用で、変更するにはパッケージマネージャーを経由する必要がある
    • 構成の切り替えはシンボリックリンクの変更に近いため即時に可能で、起動時に以前の構成を選んでロールバックできる
    • 特殊なストアディレクトリを除く /home、/etc、/var などは変更可能で、システムシンボリックリンクを別のものに置き換えることはできても、元のソースは変更できない
    • NixOS は優れた実装と評価されているが、既存システムとあまりに異なるため、利点があるにもかかわらず採用率は低い

  • Endless OS

    • Endless OS は一般ユーザー向けに公開された初期の不変 OS であり、インターネットや電力網のカバレッジが低い国でも使える堅牢なシステムを目標としている
    • Debian ベースだが、OSTree で不変性を実現している
    • OSTree は中核システムイメージを管理し、その上にパッケージのようなレイヤーを追加しつつ、次回起動用の新しいシステムイメージを準備できる
    • パッケージ変更は次回の起動で使われる新しいシステムバージョンに適用され、起動時に以前のバージョンへ戻せる
    • パーティションは概ね書き込み可能だが、OSTree が扱うパッケージ領域である /usr は読み取り専用でマウントされる
    • /etc にはロールバックがない
    • ユーザー向けアプリケーションは Flatpak でインストールし、新しいパッケージを入れるたびに再起動が必要になる状況を減らしている
    • 改変された GNOME デスクトップはスマートフォンのメニューのように見え、非技術系ユーザーに親しみやすい形を目指している
    • DevOps ツールの導入は実用的とは言いにくいが、不可能ではない

  • Fedora Silverblue

    • Fedora Silverblue は、Fedora / CentOS / RHEL を不変化しようとしていた Project Atomic の流れをくむ後継系にある
    • OSTree 上に RPM パッケージ変更を適用する rpm-OSTree を使用する
    • システムは、リリースごとの単一の中核イメージと、その上に追加されるパッケージレイヤーで構成される
    • インストール済みパッケージレイヤーを一覧でき、パッケージを削除するとスタック全体を再生成するため、削除後に残骸が残らない
    • この再生成プロセスは非常に遅い
    • パッケージをインストールしても現在起動中のシステムには適用されないため、基本的に再起動が必要であり、起動時に以前のシステムバージョンを選択できる
    • rpm-OSTree は、次回起動向けの変更を tmpfs オーバーレイとしてライブシステムに一時マージする機能を提供する
    • マウントポリシーは /etc、/root、/var を除いて読み取り専用で、ホームディレクトリはデフォルトで /var/home にあるため期待とずれることがある
    • /etc は rpm-OSTree が管理しないためロールバックされない
    • /usr/local は /var 内のディレクトリへ向かうシンボリックリンクなので、RPM ファイルなしでもユーザー変更を注入しやすい
    • パッケージインストールが遅く、再起動が必要なため、Flatpak や toolbox の利用が推奨される
    • toolbox は root 権限なしの Fedora コンテナを作成し、開発ライブラリやツールをターミナルから使えるようにする

  • OpenSUSE MicroOS / Aeon

    • OpenSUSE MicroOS は rolling-release の OpenSUSE Tumbleweed の不変スピンで、独自実装を使用している
    • /home、/var など一部のディレクトリを除くシステム全体が btrfs スナップショット 上にある
    • システム変更が必要になると、現在のスナップショットを新しいスナップショットへ複製し、変更を新スナップショットに適用して次回起動に使う
    • OSTree ベースのシステムと異なり、/etc もスナップショットの一部であるためロールバック可能である
    • 新しいスナップショット内でシェルを使い、ファイルシステム上の任意のファイルを変更できるため、ドライバ問題の解決用ファイル注入のような作業に有用である
    • ただし、このような変更は追跡されないため、システムが「純粋な」状態かどうかを保証しにくい
    • 変更は transactional-update コマンドで実行し、パッケージの追加・削除や、新しいスナップショット内でシェルを開いて任意の変更を行える
    • /etc はスナップショットに含まれるが常に読み取り可能なので、ライブ状態で /etc を変更した後に新しいスナップショットを作ると、その変更は即座に継承される
    • 基本アプローチは、更新後に毎日再起動する計画を前提とする方式であり、rolling-release のため毎日更新があり、再起動前は新しいパッケージの利点を得られない
    • 自動再起動は無効化できる
    • Silverblue のようにライブシステムへ変更を適用する機能は現在実験的で、まだ利用できない
    • 代わりに、distrobox により複数ディストリビューションの root 権限なしコンテナを使ってユーザーツールをインストールする方法が推奨される

  • Vanilla OS

    • Vanilla OS は Ubuntu ベースで、近く Debian ベースへ移行予定の新しい不変系システムである
    • 不変性は ABroot で実装されている
    • ABroot はルートパーティション A、ルートパーティション B、そして /home や /var のような永続データ用パーティションを持つ
    • 起動と変更の流れは次のとおり
      • 最初の起動は A で行われ、A は読み取り専用でマウントされる
      • 新しいパッケージや /etc ファイル変更のようなシステム変更は B に適用され、tmpfs オーバーレイによるライブ適用も可能である
      • 再起動後は B から起動し、成功すると ABroot が A と B の差分をスキャンして B の変更を A に適用する
      • 新しい変更がないとき、A と B は常に同一である
    • 欠点は、新バージョンへ起動する前までしかロールバックできない点である
    • 新バージョンで起動すると、変更が以前の起動パーティションにも適用され、もはやロールバックできない
    • この方式は、失敗したアップグレードやライブで試した変更を元に戻す用途に主に有効である
    • Vanilla OS は apx パッケージマネージャーを提供する
    • apx は distrobox 作者が作ったツールで、root でないユーザーが Arch Linux、Fedora、Ubuntu、Nix など複数ディストリビューションのパッケージをインストールし、ローカルインストールのように統合できるようにする
    • Vanilla OS、ABroot、apx はまだ若く、粗い部分がある

  • Alpine Linux with LBU

    • Alpine Linux は lbu コマンドで不変性に近い構成を作ることができる
    • Alpine インストーラーを基本起動システムとして使い、「保存済み設定」tarball を作成して起動時に自動適用する
    • 起動のたびにディレクトリが再展開され、パッケージが再インストールされ、すべてはライブメモリ上で完全に書き込み可能である
    • 常にクリーンな状態から始め、その上に変更を適用し、変更をロールバックしてやり直すことができる
    • 先に定義した不変性は完全には満たしておらず、変更が基本システムの上に適用されるためである
    • システム全体がメモリ上にあり、保存・復元対象を自分で管理する必要があるため、高い理解が求められ、アーカイブが大きくなることもある
    • ドキュメントも不足している

利点と運用上の制約

  • 利点

    • 問題が発生したら 変更をロールバック できる
    • トランザクション更新は、パッケージ変更中でもシステムが正しく動作する助けになる

  • 欠点

    • Ansible、Salt、Puppet のような 構成管理ツール との統合が非常に悪い
    • パッケージ変更の適用方式を理解するよう更新されていても、通常のシステムのように管理しようとすると大半は壁に突き当たる
    • 変更後に再起動が必要なのは煩わしいが、NixOS と Guix では変更のたびに再起動する必要はない
    • OSTree ベースのシステムは柔軟性に欠ける
      • たとえば、サウンドのために ALSA ディレクトリへ追加ファイルが必要なネットブックでは、そのファイルを配布するパッケージを作らなければ追加できない
    • ロールバックは ブラインドロールバック に近く、各システムバージョンにどんな変更があったのか把握しにくい
    • ルートファイルシステムにディレクトリが必要な Nix/Guix のようなプログラムや、パッケージ化されていないソフトウェアのシステム全体へのインストールが難しい場合がある

不変システムに関する事実と誤解

  • 不変性は厳密に言えば嘘に近く、システムの多くの部分は依然として変更可能である
  • 不変が ステートレス (stateless) を意味するわけではない
  • NixOS と Guix は安定したパッケージマネージャーでシステム全体を追跡でき、ソースにバージョン管理システムを使えるため、最初から正しい哲学を備えた実装と評価されている
  • 不変性はしばしばセキュリティ上の利点と結び付けられるが、root 権限を得た攻撃者はライブシステムを操作でき、/boot パーティションにも手を加えられる
  • 次回起動用のバックドア設置を防ぐものではない
  • 不変性には 規律と保守 が必要である
    • バージョン管理を意識する必要がある
    • apx、distrobox、devbox のような追加プログラムはシステムとは別に更新しなければならない
    • NixOS と Guix ではこの部分が統合されている

実際に新しくなった部分

  • 不変オペレーティングシステムはオープンソースシステムコミュニティで注目されているが、同じ言葉の下に複数の実装とユースケースが混在している
  • 「不変」という名前はユーザーに特定の期待を抱かせるが、実際にはオペレーティングシステム向けの トランザクション更新 に近い
  • トランザクション更新自体は新しい概念ではない
    • Solaris と ZFS では起動時にシステムスナップショットを選択できた
    • FreeBSD も約 10 年前に類似機能を実装していたようだ
    • 一般的な Linux ディストリビューションでも btrfs スナップショットを使えば起動時にスナップショットを選べる
  • 本当に新しい点は、トランザクション変更を ライブではない環境 に適用し、それをブートローダーへ統合し、ユーザーが容易に扱えるツールを提供したことである
  • さらに読むものとして、Colin Walters の “Immutable” → reprovisionable, anti-hysteresis が勧められている

関連記事

1件のコメント

 
GN⁺ 2023-09-19
Hacker News の意見

  • Silverblue がリストに入っているのはうれしいが、Fedora CoreOS が抜けているのは残念
    FCOS は本番環境で使いやすい OS で、CoreOS の買収以降かなり進化しており、Nix に比べて学びやすく使いやすい一方で、不変性も保てる、ちょうどよい中間地点のように見える
    FCOS 開発陣が追加した CoreOS Layering は、Dockerfile でシステム状態を定義すると FCOS がその状態へリベースし、サーバー設定は再起動するだけで済むという強力な機能
    次のプロジェクトで VM が必要なら、一度試してみる価値がある。Linux ワークステーション上でローカルに Butane ファイルを作りやすくする Python ベースの CLI ツール Bupy も作ったし、CoreOS Layering で Paperless NGX を動かす例もある
    https://github.com/quickvm/bupy
    https://github.com/quickvm/fcos-layer-paperless-ngx
    https://coreos.github.io/rpm-ostree/container/
    https://github.com/coreos/enhancements/blob/main/os/coreos-l...
    https://github.com/coreos/layering-examples

    • CoreOS 系の別プロジェクトである Flatcar についても考えを聞いてみたい
      ベアメタル環境でこうしたプロジェクトをどう使うべきかが一番難しかった。VM イメージを作るのは素晴らしいが、実際には既存ドライブにインストールしたり、その下に ZFS プールを置いてインストールしたかったりすることが多い
    • CoreOS Layering は本当に便利そう。今は Raspberry Pi 数台と x86_64 サーバーで openSUSE MicroOS を使っていて、MicroOS を選んだ理由の一つは Raspberry Pi へのインストールがかなり簡単だったから
      CoreOS を Raspberry Pi にインストールするのはどれくらい難しいのか気になる。ネット上の一部のインストールガイドはかなり複雑に見える

  • こうした不変システムの紹介でいつも抜けているもう一つの軸は、イメージベースのアプローチ
    https://universal-blue.org/ で自分よりはるかに熟練した人たちと一緒に作業しているが、Fedora Silverblue の基本版と複数のデスクトップエディションの上に OCI コンテナイメージをビルドしている
    このイメージは rpm-ostree で起動、正確にはリベースでき、階層化よりも堅牢にシステムを拡張する方法で、同じ変更を誰でも簡単に継承したり活用したりできる。自分でイメージを作るのも非常に簡単
    VanillaOS と SUSE も似たことをしているようだが、私たちは OS プロジェクトではなく Fedora の downstream にすぎない。Fedora の正式サポートも進行中で、すでに動作している範囲だけでも、Nvidia ドライバーの提供のような作業には、経験上もっとも堅牢で簡単な方法の一つ

    • 少し違う話だが、2009年ごろに Windows リモートデスクトップホストを動かす大きなハイパーバイザーを見て衝撃を受けた。たぶん Citrix だったと思う
      VM はイメージから起動し、イメージと差分ディスクがすべて RAM 上にあった。ユーザープロファイルはハードディスク上にあったが、25人用のデスクトップホストがリモートログインを受け付けられる状態になるまで、約4秒で起動した
      パッチ適用が最も苦にならない Windows システムだった
    • Fedora Silverblue も イメージベース ではないのかと思って混乱している
      基本インストールでは階層化を使わず、追加の RPM パッケージをインストールしたいときだけ階層化が入るのだと思っていた
    • UBlue は GitHub Actions でイメージを定期的に再ビルドして、パッケージ更新を反映しているようだ。費用は誰が払っているのか気になる
      イメージも GitHub から提供されるのか、GitHub が外部転送量に課金するのか、多くのユーザーが同じイメージをダウンロードしようとしたらどうなるのかも気になる

  • 不変システムよりも、事前構成済みシステムにより関心がある
    ここでは NixOS と Home Manager が目立つが、設定方法が本当にひどい。設定全体をソース管理に入れ、現在のシステム状態がその設定と同じだと分かるようにしたいし、それ以外の変更は再起動時に消えてほしい。再起動前に変わった内容は強調表示されるとよい
    Silverblue のようなものを少し試した限りでは、基本システムは構成できるが、Firefox のようなアプリケーションを追加し始めると Flatpak を使うことになり、必要な Flatpak 全体のインストールとその設定まで一緒に宣言する方法がよく分からない
    Flatpak を一括インストールし、残りは dotfile で処理する方法はありそう
    https://universal-blue.org/tinker/mindset/#resist-the-urge-t...

    • 「再起動時にそれ以外は消える」ことを望むなら、Impermanence を試したことがあるのか気になる
      https://nixos.wiki/wiki/Impermanence
    • Silverblue で nix パッケージマネージャー を使ったことがあるのか気になる
      https://julianhofer.eu/blog/01-silverblue-nix/
      こうすれば、ひどいという点に同意している Nix の設定部分を最小限に抑える助けになる

  • Flatpak と不変アプローチ全般で遭遇した問題は、開発者がサポートしていない方法では修正できないという点
    例えば decsync でカレンダーを同期しているが、知る限り Evolution Flatpak に decsync プラグインを追加するのは不可能
    こうした不変システムが、開発者がサポートできない、またはサポートしないユースケースのために、カスタムのオーバーレイファイルシステムを積み重ねることを第一級の機能としてサポートするまでは、人々は可変システムを使い続けるだろう

    • NixOS は、まさにこの種の制御権をいくつもの方法で提供している
      nixpkgs の一部パッケージと、NixOS および Home Manager モジュールの大半は、プラグインや追加パッケージなどを設定できる多くのオプションを公開している
      Nix は、カスタムパッケージや既存パッケージのバリエーションを追加する overlay と override も提供しており、パッケージの一部を差し替えることもできる。それでも足りなければ、コードに直接パッチを入れたり、upstream リポジトリの fork からビルドしたりもできる
      実際、これは Nix で最も気に入っている点の一つだ。「このパッケージをビルドするとき、この依存関係を自分のバージョンに置き換えろ」と言うのが簡単なので、オープンソースにより頻繁に貢献するようになった
    • 「Evolution Flatpak に decsync プラグインを追加する」ようなことは、Linux GUI ソフトウェアではごく一般的
      この領域の外では、ほとんどのソフトウェアが必要な機能を含めて提供している。例えば Solidworks は任意依存関係をダウンロードしろと言ってきたことはないが、FreeCAD は CAD/CAM/シミュレーション/レンダリングの流れで次の段階に進むたびに、文字どおり15分ごとに何かを要求してきた
      https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv... も参考になる
      要点は、「全員が使う20%」は決して同じではないということ。過去10年で、機能の20%だけを実装した「ライト」なワープロを出そうとした会社を何十社も聞いたが、記者がレビューを書いている途中で文字数カウント機能を探し、それが「誰も使わない80%」に入っていたため、結局「軽いプログラムは良く、肥大化は悪いが、このろくでもないものは文字数を数えられないので使えない」と書くことになる、という話は PC と同じくらい古い
    • カスタムのオーバーレイファイルシステムを第一級の機能として積み重ねるくらいなら、単に 可変システムを使えばいいのではと思う
      10年前、誰もが NoSQL に飛びついたあと、すぐに各プロジェクト内でスキーマを再発明していた様子を思い出す
    • Flatpak アプリケーションにもプラグインを追加でき、そのようなプラグインは 拡張パッケージとして作ればよい
      OBS がその例。Flathub には com.obsproject.Studio.Plugin.* 形式の OBS プラグインがいくつもある

  • 定義はこうするのがよさそうだ。パッケージをいくつインストールしたとしても、将来のどの時点でどの順序で削除しても、最初からインストールしていなかった場合と 同等の状態になるべき
    この定義では一部のディストリビューションは除外されるだろうが、この概念で重要なのはまさにその性質だと思う

    • ユーザー向けシステムでは、その性質は事実上不可能だというのが要点に見える
      ワープロやテキストエディタを削除するとき、作成したすべてのファイルも一緒に消えてほしいだろうか。ブラウザを削除したら、ダウンロードしたファイルもすべて消えるべきだろうか。そうでないなら、どのファイルがプログラムによって自動生成されたもので、どのファイルがユーザーがそのプログラムで作成したものなのかを信頼性高く区別する方法はない
      インストール中に生成されたものは簡単に削除できるが、その後のすべての変更までは不可能
      DNS 実装を切り替えたあと、後でデフォルトの DNS サーバーを変更した状況も考えられる。provider を削除して以前の実装に戻るとき、以前のサーバーにも戻すのか、それとも新しいサーバー設定は維持するのかを選ぶ必要がある。個人的には provider だけを変えて、新しいサーバーは維持したい
      複数のマシンで共有するディレクトリも難しくする。/home/${USER} を NFS や Samba マウントにして複数のワークステーションで同じファイルを使っている場合、あるプログラムが XDG 設定ディレクトリにファイルを作成し、1台のワークステーションでそのプログラムを削除するとき、全マシンのファイルも削除すべきなのだろうか。すべてのデバイスが同一であるべきなのか、ホームディレクトリだけが同一であればよいのかを、単一システムのパッケージマネージャーが知る方法はない
    • その性質をどの程度深く適用したいかが問題
      一意表現データ構造と 履歴独立データ構造を調べてみるとよい
      ブロックデバイス、例えば SSD が履歴と無関係にブロックを割り当てるよう、特別に注意する必要があるだろう
    • それは 再現可能性と呼ばれる性質で、同じ設定が常に同じシステム状態を作り出すという意味
    • その定義は気に入った
      パッケージ集合が束を成し、どの部分集合のパッケージに到達したとしても、経路に関係なく状態は一つだけだ、と言うこともできそうだ

  • Fedora Silverblueをリリース時から使ってきたが、これは間違いなく未来だと思う
    みんな ostree を使うべきだと思う

    • Silverblueは個人用コンピューターには十分に柔軟ではないと感じた
      自分のLinuxの使い方が少し行き当たりばったりなのかもしれないが、/usr や /bin のようなフォルダーに書き込み権限がないことに、2週間に一度くらいイライラさせられた
      たとえばUbuntuユーザーが書いたスクリプトが、Ubuntu式の名前と場所にあるライブラリを探していて、Fedoraではそのライブラリに別の名前を使っている場合があった。こういうとき自分の本能としては、Ubuntu名のシンボリックリンクを作って、Fedora RPMが管理するライブラリを指すようにすることだ
      しかし実際には、動かすためにスクリプトをフォークし、ローカルでビルドできるようにし、両方のライブラリ名を探すように直し、ローカルテストを回し、upstreamにPRを送る……といったことをしなければならなかった。普段ならシェル1行で済むことが、90分の作業になる
    • 1年使っているが本当に良い。Red Hatは自分たちが何を手にしているのか分かっているのだろうか。Silverblueだけでなく、Fedora 自体もそうだ
      Quoraの回答で、Windows OSの開発予算を給与ベースで約180億ドルと見積もっているのを読んだ。Red HatがFedoraに20億ドルを投資してデスクトップOS界のFirefoxにすると想像してみると、Microsoft相手に10%のシェアを取るだけでも非常に大きい
      数千のオープンソースパッケージの上で、これほど少ないリソースでここまで来ている。その資金は、こうしたプロジェクトを存続させ、開発中に支援するために使える。Red Hatの社員はすでにその多くのプロジェクトに関わっている
    • ostreeのアイデアは気に入っているが、ざっと見た限りでは、一般ユーザーや中級ユーザーにとってDockerほど親切には見えなかった。Dockerは個人ユーザーでも半日あれば学べる
      「Debianディストリビューションをostreeスナップショットとして配布する」という地点までどうやって到達するのかが明確ではなかった
      これは専門のシステム管理者やシステムビルダーだけのために設計されたものなのか気になる
    • Nix を使ったことがあるなら、比較がどうなのか気になる
      Silverblueは使ったことがないが、Nixも未来のように感じる
    • 今サーバーではUbuntuを使っていて、リポジトリにostreeがあるのは見たが、まだ試せていない
      可能なら現在のシステムのままバージョン管理を始めてみたい。それが難しすぎる、あるいは不可能なら、いつかサーバーをSilverblueへ移すつもりだ。ostreeのアイデアは本当に気に入っている

  • この夏は Tinycore にハマった
    数日前ここで話していたQubes、Tails、Whonixの根底にある「1つのOSに1つの機能」というセキュリティ哲学を補完するのにちょうどいい
    非常に軽量なので、メールサーバー用VMを1つ、データベース用VMを1つ、ファイアウォール/ルーター用VMを1つ、それぞれ数秒で立ち上げられる
    Tinycore自体がイミュータブルなので、vdiskに「パッケージ」と設定を入れて読み取り専用としてマークすれば終わりだ。Virshスクリプト1つが「サービス」の開始と終了を処理し、各サービスはTinycoreインスタンスになる
    面白いし、今のところ堅牢だが、まだ誰かの本番環境に入れるかどうかは確信がない

    • TinyCoreはこうしたイミュータブルLinuxの紹介ではいつも抜け落ちる。かなり昔から存在し、設計も優れている
      実装には惜しい点があり、人々にあまり知られていない理由を説明してくれる企業スポンサーもおそらくいない
      他のイミュータブルLinuxディストリビューションと違って、堅牢でシンプル だ

  • Fedora Sericeaが出てからずっと使っている。基本的にはFedora Silverblueだが、Gnome-wmの代わりに Sway-wm を使う
    実際かなり使い物になり、rpm-ostree install コマンドのたびに毎回再起動する必要もない。rpm-ostree live-apply がsystemdベースのオーバーレイで処理してくれる

    • この2週間 Fedora Workstation を使っているが、Linuxを20年ぶりに使ってみた立場から言うと、体験はものすごく良くなっている
      まだWindowsで再起動する必要はなかった。今後6か月間もこの状態が続くなら、Linuxへ完全に移行してWindowsパーティションを消すつもりだ
    • それでも新しいカーネルを実際に適用するには再起動が必要ではないのか？ それともkexecのようなものでカーネルが切り替わるのか気になる

  • 「イミュータビリティは嘘で、システムの多くの部分は可変だ。ただ、この系統を別の言葉でどう説明すべきかは分からない。トランザクション的な何か？」という話について、Nixの場合は 再現可能性 により重点があるように聞こえる
    Nixの設定ファイルを別のコンピューターに置けば、/home くらいを除いて同じシステムが得られるはず、という意味に見える
    ほかのものは、既存ツールが提供していたスナップショットとロールバック機能を、別の実装で提供する方向に近いように見える

    • 「イミュータブル」という言葉をここに付けるのは妙だ
      ライブシステム上でシステムアップグレードをせず、パッケージ変更は次回起動時に適用され、変更をロールバックできるという意味なら、データベースのような アトミックトランザクション に近い。ただしコミットするためにシステムを落とさなければならないというのは少し大げさだ
      Microsoftは数年前にファイルシステムにアトミックトランザクションを入れたが、ファイルシステムのトランザクションはあまり使われなかった
      インストールシステムはすべての変更をまとめてコミットし、インストール中に問題が起きたら何もコミットせず以前の状態へロールバックできるとよい。理論上はトランザクションファイルシステムで可能だろうが、実際にはファイルシステム以外の状態があまりにも多く絡んでいそうだ

  • サーバー側にはAmazonの Bottlerocket OS がある
    アップグレードにA/Bパーティションを使い、基本システム以外はすべてコンテナで動かすというアイデアだ
    起動時のユーザー定義設定にはboot containerを使い、長時間稼働するサービスにはhost-containerを使うか、KubernetesではDaemonSetを使う方式だ
    https://github.com/bottlerocket-os/bottlerocket