ついに Atomic Linux デスクトップを試してみました – システムが壊れるのを恐れなくなりました

私はいつもの方法で Linux デスクトップを壊してしまいました。 2018 年のフォーラムのコメントの一部が自信に満ちているように聞こえたので、ランダムな PPA をインストールしました。役に立たないと思われるパッケージを削除しましたが、そのパッケージがテープと先祖の祈りとともにログイン画面を保持していることに気づきました。それだけでなく、私は真夜中にアップグレードし、システムが黒い画面で戻るのを見て、それからこれを「学習」しているふりをしました（コピエ！）。

これらの問題を解決することで Linux について多くのことを学びましたが、実際にやりたかった作業の時間が奪われてしまうこともありました。それが私をアトミックデスクトップへと駆り立てた理由です。私が Fedora Silverblue を選択したのは、Fedora Silverblue がこのアイデアの最もよく知られた実装の 1 つになったからです (また、Fedora が私の毎日のドライバーであるためでもあります)。しばらく使ってみると、Linux マシンの保守方法に関して根本的なことが変わることに気づきました。

システムはプロジェクトではなくリリースのように動作します

アップデートによりシステムイメージ全体が置き換えられます

ほとんどの Linux ディストリビューションは、オペレーティング システムを一度に 1 つのパッケージずつビルドします。アップデートごとに個々の RPM または DEB パッケージが変更され、インストールするすべてのパッケージがライブ システムの別の部分になります。このモデルは何十年も機能し続けていますが、すべてのマシンはゆっくりと独自の個性を発展させています。サードパーティのリポジトリを追加したり、別のカーネルをインストールしたり、ライブラリを置き換えたり、別のアプリケーションが依存するパッケージを削除したりすると、インストールがクリーン インストールから離れ始めます。

Fedora Silverblue は別の道を歩みます。数千のパッケージを個別に更新する通常のディストリビューションとは異なり、Silverblue は単一のイメージとして OS を構築します。イメージは、OSTree のファイルシステムと Fedora の RPM パッケージを組み合わせた rpm-ostree で管理されます。

アップデートが到着すると、rpm-ostree は現在のデプロイメントとともに新しいデプロイメントを準備します。実行中のシステムでは何も変わりません。実際、アトミック アップデートを使用する Fedora Silverblue などの Linux ディストリビューションでは、ほとんどのシステム パーティションは変更できません。これは、安定性を確保し、将来エラーが発生した場合にロールバックできるようにするためです。

rpm-ostree を使用してソフトウェアをインストールするプロセスは、Git リポジトリにコミットするのと似ており、変更を追跡できます。システムが更新されるたびに、rpm-ostree は新しい展開に必要な変更されたコンテンツのみをダウンロードし、システムに階層化されたパッケージを再適用します。新しいデプロイメントは再起動後にアクティブになりますが、以前のデプロイメントはブート メニューで使用可能なままです。この展開モデルにより、システムのバージョン履歴が得られます。デプロイメントで問題が発生した場合、ロールバックとは、数十のパッケージを手動で修復しようとするのではなく、単に以前のデプロイメントを起動することを意味します。

ソフトウェアはさまざまな場所に属します

コンテナとフラットパックでホストをクリーンに保つ

Silverblue は、ソフトウェアを整理する別の方法を推奨しています。デスクトップ アプリケーションは通常、Flatpak を通じて提供されます。ブラウザ、メディア プレーヤー、エディタ、コミュニケーション ツールは、デスクトップと適切に統合しながら、ホストから分離されたままになります。

開発ツールはコンテナに移動します。 Toolbox は、通常のシェルとほぼ同じように感じられる Fedora コンテナを作成します。 GCC、Python、Node.js、Go、Rust、Docker、Ansible、または Kubernetes ツールは、ホスト オペレーティング システムに追加せずにインストールできます。

あるプロジェクトは Python 3.14 を必要とし、別のプロジェクトは Python 3.13 に依存しているとします。ホスト上で両方を満たすことを試みるのではなく、各プロジェクトは独自の Toolbox コンテナー内に存在できます。

同じ考え方がデータベース、言語ランタイム、SDK、ビルドの依存関係にも当てはまります。数か月にわたる実験の後にコンテナーが乱雑になった場合、コンテナーを削除するには数秒かかります。別のものを作成するには、コマンドを 1 つだけ必要とします。このアプローチでは、インストールするソフトウェアのほとんどがシステムに触れることがないため、システムを大幅に小さく保つことができます。

実験からの回復が容易になりました

ロールバックはワークフローの一部のように感じられます

すべての Linux ユーザーは、最終的には好奇心が勝つポイントに達します。 COPR リポジトリをテストしたい場合や、新しい Mesa ドライバーが必要な場合があります。おそらく、あまりテストされていないパッケージを重ねたいと思うかもしれません。これらの実験は Linux エクスペリエンスの一部です。従来のディストリビューションでは、これらの変更はすぐにライブ システムの一部となり、悲しいことに、後で変更を削除してもマシンが必ずしも以前の状態に復元されるわけではありません。

Silverblue は、これらの状況を別の方法で処理します。 rpm-ostree のアップグレードによりハードウェアにリグレッションが発生したとします。フォーラムを検索したり、パッケージをダウングレードしたり、インストールを再構築したりする代わりに、以前の展開を起動して作業を続けることができます。

rpm-ostree レイヤ化を使用してホスト パッケージをインストールする場合も、同じ原則が適用されます。これらの変更は展開の一部となるため、実行中のファイルシステムを直接変更する必要はありません。別のデプロイメントがすでに存在することを知ると、実験の快適さが変わります。リカバリが簡単なので、新しいソフトウェアのテストがはるかに簡単になります。

実験を好む人のために作られたデスクトップ

Fedora Silverblue はすべての Linux ユーザーに適しているわけではありません。ワークフローがシステム パッケージを毎日変更することに依存している場合は、Fedora Workstation の方が適している可能性があります。多くの開発者、愛好家、Linux 愛好家にとって、Atomic モデルは、従来のパッケージ管理では特にうまく対処できなかった問題を解決します。

Silverblue を使用してから数週間後、システムの修復に費やす時間が減り、ソフトウェアのテスト、プロジェクトの構築、以前なら後回しにしていたアイデアの試行に多くの時間を費やすことができるようになりました。それだけでも、Atomic ディストリビューションに切り替える価値がありました。