うん、この分野のプロジェクトはもっとコミュニケーションを取るべきだね。アトミックディストロは、再起動時にアップデートがアトミックに入れ替わるものだよ。イミュータブルディストロとも呼ばれてる。唯一「システム」パーティションだけがイミュータブル。人気なのはSteamOSで、その次がFedoraのバリアント（SilverblueやKinoite）や派生版（Bazzite）かな。日常使いにはまだ制限があって、ちょっと粗いところもあるけどね。

「アトミックでトランザクショナルなLinux」って何？ Linuxディストロは、パッケージごとじゃなくてフルシステムスナップショットで更新されるもので、Androidに似てる。大きな違いは、ほとんどの/が読み取り専用でマウントされてて、配布されたアップデートだけで変更されるから、あなたもディストロチームも何が動いてるか正確に把握できること。 代替案の利点は？ 常にサポートされた構成で動いてるから、よりコントロールと安定性がある。何か問題が起きたときに、以前のアップデートに簡単にロールバックできる。もしマシン間で同期させたいなら、何が動いてるか常に把握できるのが便利（サーバー環境では特に）。 他に似たようなプロジェクトは？ KalpaはAeonOSの「兄弟」プロジェクトで、アトミックなOpenSUSEだけどGnomeが使われてる（他にもいろいろ変更があるけど）。FedoraのアトミックラインにはKinoiteやSilverblue（それぞれKDEとGnome）があって、U-Blue、Bazzite、SteamOSなどもある。今のところ、主要なディストロラインはほとんどアトミックバリアントを持ってると思う。 このプロジェクトの特別なモチベーションは？ Kalpaは、AeonOSのKDEの代替を提供するために作られた。元々はAeonOSだけで、OpenSUSE MicroOS（OpenSUSE Tumbleweedのアトミック版）にGNOMEがインストールされてた。だけどAeonはMicroOSから大きく逸脱して、もうそれを上流として使ってないと思う。AeonOSはKDEのサポートも拒否したから、Kalpaが生まれたんだ。Kalpaは今でもMicroOSを上流として使ってるけど、これを変える予定があるかは分からない。 最も重要なのは、なんでこれを使いたいと思うべきなの？ 個人のノートパソコンで使ってる理由は、ローリングディストロの利点（最新のパッケージ）を享受しつつ、安定性の心配がないから。アップデートはバックグラウンドで自動的に適用されるし、再起動すれば常に動いてるシステムが使えるって分かってるからね。

Aboutページに埋もれてるけど、違う用語を使ってるね。彼らはコピーを見直す必要があると思う。 > 自動アップデート：アップデートは実行中のシステムには触れず、再起動時にのみ適用される。 > レジリエント：アップデートの原子的な性質のおかげで、何か問題が起きた場合、システムは自動的に最後の正常な状態にロールバックする。

でも「原子的でトランザクショナルなLinux」って何？ それは、ユーザーデータの「持続性」を追加した、グレードアップされたLive CDみたいなもんだよ。アップデートはシステムのインストールを置き換えることで行われる（通常の操作中は読み取り専用、まるでLive CDみたいにね）し、再起動することで、運用中にシームレスなアップデートを可能にするA+Bメカニズムもあって、新しいインストールが失敗した場合はロールバックもできる。これは、システム管理における現代的な「家畜ではなくペット」のアプローチなんだ。すべてのシステムは、よく定義された（「原子的な」）Live CDの相当物を実行していて、部分的なアップデートや実行中のシステムでの編集の予測不可能な結果ではないんだよね。

マッキーボードのショートカットが使えるLinuxディストリビューションってある？筋肉記憶がある人が両方使いやすいように。

毎日Kalpaを使ってて、家族のPCにもインストールしたよ。長い間リサーチしてKalpaにたどり着いたから、この新しいディストロの技術についてざっくりまとめてみるね。

用語

1. イミュータブル: コアOS（/usrディレクトリ）は変更を許可しないことで「クリーン」な状態を保つ。

• パッケージのインストールや削除を控える。
• ほとんどのユーザーが同じOSと同じパッケージバージョンを使ってるから、テスト済み。
• システムアップグレードは完全に新しいイミュータブルコピー。

2. アトミック/トランザクショナル: データベースのアトミック性に似ていて、一連の操作がトランザクションにまとめられる（アトミック＝分割不可の単位）、成功するか完全に失敗するかのどちらか。システムアップグレードも同じで、部分的なパッケージ更新はない。 注意: Kalpaは特に、SUSEのマイクロOS技術「トランザクショナルアップデート」を使ってる。 https://documentation.suse.com/sles/15-SP7/html/SLES-all/cha...

アトミックスタイル

イミュータブルディストロの主流モデルは4つ:

1. 宣言的設定: システムの設定をすべて設定ファイルに記述。例: パッケージバージョン、ネットワーク設定、ユーザーアカウントなど。例: NixOS、BlendOS
2. OSTreeベース: クラウド/コンテナ（OCI）技術を使って既存のレイヤーに重ねる。例: Fedoraのアトミックスピン、VanillaOS、EndlessOS。Fedora CoreOSがベースレイヤーで、アトミックスピンはデスクトップパッケージを重ねる。例: Gnome/KDEなど。
3. Btrfsスナップショットベース: アップグレード前にルートパーティションのBtrfsスナップショットを取ることで、アップグレードが失敗した場合にブートできる。例: SUSEマイクロOSファミリー（Kalpaもここに属する）、ChimeraOS
4. systemd-mkosiベース: mkosiを使ってOSのファイルシステム全体をディレクトリに「キュレーション」し、イミュータブルなディスクイメージとしてデプロイ。例: KDE Linux 注意: systemd-mkosiはsystemdのメンテナーのビジョンで、ここで言及されている。 https://0pointer.net/blog/fitting-everything-together.html この理想を達成するために開発中のシステム機能がたくさんある。これらのディストロのほとんど（Btrfsベースを除く）は、単にA/Bルートシステムを使用している。 2つのルートパーティション/イメージを維持し、アップグレードを「他の」パーティションに入れて、それをライブとしてマークし、現在のパーティションをバックアップとしてマークする。新しいパーティションへのブートが失敗した場合、バックアップパーティションにブートして次のアップグレードを待つ。システムパッケージマネージャの使用を許可しないため、ユーザーレベルでパッケージ管理を行うことになる。GUIアプリにはFlatpakを使う。その他のユーティリティには、通常Homebrewや言語特有のツール（Cargo、pip/npmなど）を選ぶ。

Distroboxという魔法のツール

これはユーザースペースでコンテナを実行し、できるだけシステムに統合しようとする。多くのソフトウェア開発にはシステムレベルのサービスやシェルアクセス、依存関係のインストールが必要。ホストではそれができないから、コンテナを作ってそこで開発を行う。もし汚れすぎたら、削除して新しいのを作ればいい。個人的には、開発にはArchコンテナを使ってる。最新のパッケージが揃ってて、便利なAURもあるから。VSCode（Flatpakから）は公式のリモート拡張を使ってコンテナに接続できる。メディアサーバもその中で動かしてる。必要なシステムパッケージやコマンドラインユーティリティもインストールできる（例: コーデック、ollamaなど）。

他のディストロよりKalpaを選ぶ理由

• SUSEが知られる素晴らしいKDEの仕上げ
• Btrfs技術は成熟していて、SUSEで何年も使われてきた。アトミックシステムはとても理解しやすく、ブートメニューで好きなスナップショットを選ぶだけ。
• イミュータブルでも、システムのカスタマイズ（例: ドライバー、カーネルモジュール、ファイアウォールのインストールなど）が簡単。
• トランザクショナルアップデートシェルに入るだけで、新しいミュータブルスナップショットを作成し、そこにchrootする。
• シェル内で好きなコマンドを実行。例: パッケージのインストール/削除、サービスの有効化など。
• シェルを終了すると、トランザクションが成功/完了としてマークされ、次回のブート用にスナップショットがライブとして設定される。
• デフォルトでミニマル。
• アップデートは早くて小さい。Tumbleweedリポジトリからの定期的なローリングリリースアップデートだから。 問題点もある:
• 単一のメンテイナー
• Fedoraベースのアトミックスピンなどの代替と比べて人気が少ない。
• Tumbleweedベースなので、小さなアップデートがたくさん（ほぼ毎日）。Fedoraベースは、例えば、週次/隔週のアップデート。
• まだアルファ段階（でも一度セットアップすれば、非常に安定してる）。
• イミュータブルはまだ新しい概念で、Flatpakはまだ粗い部分がある。バグが予想される。ミュータブル/従来のディストロは、ずっと「その方法」で使われてきたから、使いやすい。

スクリーンショットすら用意してないのには本当に驚いた。スクリーンショットがあると、いろんなディストロやデスクトップ環境を試してみたくなるんだよね。

どの部分が「ただ動かない」ってこと？

これ知ってるかもしれないけど、残念ながら、Archを長い間使わずに放置してからアップデートすると、正常にデスクトップが起動できなくなることがあるんだよね。[EDIT] あと、Kalpaのインストールでたくさん問題があったんだけど、ChatGPTを使って全部解決できたよ。

変更点を理解しようとしてたんだけど、前はWSLでTumbleweedしか使ったことがなかったんだ。デスクトップ環境はプリインストールされてるの？それとも「自分で持ち込む」感じ？（そうじゃないなら、Kalpaが持ってる大きな利点みたいだね？）

「ちょっとした不便があるから、99.92%がベースと同じ新しいディストリビューションを作ろう！」

KalpaはMicroOSをベースにした不変のディストロで、デスクトップ環境はKDEだよ。MicroOSとその派生版は全部Tumbleweedをベースにしてる。MicroOSはコンテナワークロード用に使われることを想定してたんだ。AeonはGNOMEデスクトップを持っていて、KalpaはKDEデスクトップを持ってる。彼らはTumbleweedとは違った方向にフォーカスしてるから、より意見がはっきりしたディストロになってる。一方で、Tumbleweedは誰にでも合うようにしたローリングディストロなんだよね。

初心者向けに言うと、これは人気のBazziteと同じUniversalBlueプロジェクトの一つ。ゲームではなく、一般的なコンピューティングユースケースに焦点を当ててる。

イミュータブルなオペレーティングシステムは、より高い安定性をもたらすという考え。パーティションは（理論的には）インストールされたすべてのコンピュータでディストリビューションが期待する通りで、ユーザーの変更が何かを壊す可能性を制限する。ユーザーにとっての利点は、間違ったスクリプトを実行して自分を傷つけるのがずっと難しくなること。

私にとってのポイントはセキュリティではなく、メンテナンス。システムアップグレードがうまくいかなかったときは、ほとんどが部分的なアップデートで、それはもう起こらない。コンテナで作業するのは開発者としては簡単だった。ただ、問題を移動させてるだけだと思うけど、コンテナを最新の状態に保つのは難しい。distrobox assembleは少し役立つけど。

アトミックロールバックはサーバーにとって結構重要だよね。いろんなサーバーを管理してると、パッチを当てるたびに重要なものが壊れちゃうことがよくある。俺がシステム管理者だった頃、Windowsのアップデートで2ヶ月ごとにサーバーが壊れたり、Redhatは6ヶ月ごとに壊れたりしてた。サーバーを動作状態に戻して、後で修正できるのは便利だったな。

flatpaksが嫌いで、低レベルのベアメタルアプローチを好む フラットパックはバブルラップでサンドボックス化されてるから、俺はそれでもベアメタルだと思うよ。それに、フラットパックは特に重くもないし、kde/gnome/freedesktopランタイムに依存するだけなら、普通のバイナリより大きくなる必要はない。昔はディストロ経由でアプリをインストールするのが好きだったけど、今はアプリをサンドボックス化するフラットパックの使い方が好きになった。フラットパックを削除すると、そのアプリの設定やキャッシュファイルも確実に消えるからね（保持する選択をしない限り）。アトミックディストロを試したいなら、いろんなアプローチがあるよ。例えば、GnomeOSはパッケージベースじゃないし、OpenSUSEはbtrfsスナップショットを使ってる。Fedora Atomicは今はrpm-ostreeを使ってるよ。

Kalpaをインストールする時に手動でパーティショニングをした。スワップパーティションを追加して、その容量をRAM + 2GBに設定したら、ハイバネートが動作した。ハイバネートはスリープよりも優れていると思う。何もしていない時にコンピュータが電力を使う必要はないじゃん？もしデスクトップがハイバネートを使わずにフル再起動前の状態を回復できるなら、スリープは必要ないよね？