Ubuntu から Fedora Kinoite へ

どうも、いかそばでございます。

今回は Ubuntu から Fedora Kinoite へ乗り換えてみたので、その経緯や調べた事、感想などを書いていきます。

TL; DR

（なんとなく知りたい人向け）

  • 安定性重視な OS でパッケージマネージャにもその思想が現れている

  • パッケージマネージャでのシステムへの変更は実際に適用するまで保留されるという特性は、
    「やっぱりパッケージをインストールするのはやめる」という場合にもコマンド一つで巻き戻せるので助かる

  • 一般用途で Linux が気になる人や、他のディストリビューションに興味がある人におすすめしたい

発端

ある日 ROCm のアップデートをしたらデスクトップ環境が起動しなくなってしまった。

現象としてはスプラッシュスクリーンから一向に進まないというもの、
きっと多くの Linux ユーザーも体験したことがあるのではないかと思う。

この時点では筆者もなんとかなると思い別の仮想コンソールに入ろうとキーをペチペチしていたが、
しばらくしても仮想コンソールは開けず数分放置してもデスクトップを拝めなかった。

とりあえずインストールメディアを用意しないと何も始まらないけれど、しばらくしょんぼり。

この頃の筆者は他のディストリビューションへの興味が湧いていたので、Fedora Kinoite を選んでみる事にした。

👴｢説明しよう」

説明するべき物が現れると何処からともなく説明しにやって来る博士。　耳の大きさが常人の 1.5 倍ある。

Fedora Kinoite とは

Fedora Kinoite とは Fedora 系のディストリビューションのうち、 Fedora Atomic Desktops というシリーズの一つ。

Fedora Atomic Desktops は Fedora の公式なプロジェクトとしてメンテナンスされていて、
見てくれは普通の Fedora とあんまり変わらない。

Fedora Kinoite はデスクトップ環境に KDE Plasma を利用しているもので、他のバリエーションでは Gnome や Sway などがあったりする。

ここまでは普通のディストリビューションと何ら変わらない説明だけれど Fedora Atomic Desktops というシリーズが持つ特性にとっても興味を惹かれたのだ。

筆者が面白いと思った特徴としては以下のようなものがあるので順番に感じたことを書いていく。

  1. 安定性
  2. サンドボックス性
  3. 開発者向けツール

安定性

まず筆者がひと目見て興味を惹かれた安定性について。

Fedora Atomic Desktops はシステムをなるべく復旧しやすいように作られていて、Fedora Kinoite の HP から一部抜粋すると

システム全体が一度にアップデートされても、問題が発生した場合はアップデートは適用されません。 つまり、何が起こってもコンピューターを動作させることができます。

(閲覧日: 2025/09/23)

ということで、アップデートに失敗してもロールバックできるらしく、環境が壊れることに対してある程度耐性があるらしい。

好きなときに以前のバージョンのシステムにロールバックすることも可能らしく、失敗してもなんとかなるようになっている。

これを実現するために OSTree という仕組みを利用している様で、
パッケージマネージャーは Fedora でお馴染みの dnf ではなく rpm-ostree を使用することになる。

詳しくは後で書くけれど、大まかな説明としては以下の通り

  • システムへの変更は適用されるまで保留
  • 次の起動時に自動で変更を適用
  • 起動中に適用する場合は rpm-ostree apply-live で行う

しかし、設計思想を汲み取るなら再起動を選んだほうが良いものと思われる。

サンドボックス性

次にアプリケーションのサンドボックス性について。

Fedora Atomic Desktops では Flatpak でアプリケーションをインストールすることを推奨している様で、いくつかの利点と注意点がある。

Flatpak は各アプリケーションを軽量なコンテナのような環境に切り離すことで、配布を容易くしたり、アプリケーションの権限を制限することができるらしい。

どのように環境が分割されるかについて 公式ドキュメント からその様子が伺える。

まず、ランタイムという環境によってアプリケーションの依存関係が提供されるらしい。
ホスト環境には依存しない為、どのディストリビューションであっても安定してアプリケーションが動かせる。

アプリケーションはホスト環境から分離されているので、権限としてホームディレクトリや他のパーティションへのアクセスなどを管理できる。

アプリケーションが要求する権限によっては、別のパーティションへのアクセス権限が付与されていない場合もあるので、個別に与える必要があるなど少し面倒な部分もある。

アプリケーションの権限を管理する場合は Flatseal などのツールを使うことで管理することができる。

付与される権限によってはホスト環境に対して十分な影響力を得られるので、アプリケーションに対してむやみに広い権限を与えない方が良さそう。

似たようなシステムに Snap などがあるので気になった方は調べてみると暇つぶしになるかも。

開発者向けツール

Fedora Atomic Desktops に同梱されている開発者向けツールについて。

Fedora Atomic Desktops には Toolbx と呼ばれる開発環境を作成するためのコンテナ管理ツールが存在する。

前置きが長くなるけれど先になぜ必要なのかを書いていく。

わざわざコンテナを使わずとも、通常の OS であればコンパイラやランタイムのバージョンを変えるならパスを入れ替えたりすれば満足だったり、
他にも追加のコンパイラが欲しければ apt なりでインストールするかバイナリをダウンロードしたりすると思う。

しかし、安定性 の項目の後半で記したように、
Fedora Atomic Desktops では追加のソフトウェアをインストールするたびに再起動する必要がある。

依存関係を埋める度に毎回再起動していては時間が勿体ないので、
Fedora Atomic Desktops に同梱されている Toolbx の出番がやって来るのだ。ﾔｯﾀﾈ!

これは、ホスト環境とシームレスに連携ができるコンテナを作成することができる代物なのである。
裏では Podman を呼び出しているらしく、sudo を使わなくても良いので楽ちん。

できることは大まかに言うと以下の通り

  • ファイルシステムとシームレスに連携
  • GUI をコンテナ内から動かせる
  • 他のディストリビューションの利用

toolbox create というコマンドでコンテナを作成することができる。

Fedora ならば以下のように

toolbox create

Ubuntu や Arch ならば --distro オプションで指定することができる

toolbox create --distro ubuntu --release 24.04
toolbox create --distro arch

toolbox enter で環境に入ることができる。
コンテナ名やコンテナ ID を指定する必要があり、空欄であれば Fedora のコンテナに入ろうとする。

toolbox enter [CONTAINER]

コンテナ環境に入ると、現在のディレクトリに居る状態になる。
初見だと本当にコンテナに入れたのか気づけないと思う。

他にも arch や ubuntu などのディストリビューションも選択できるので、各環境での開発やデバッグも行える。

Containerfile を書くことでイメージをカスタマイズ することができるらしいので効率的に開発環境を保存しておけそう。

rpm-ostree

Fedora Atomic Desktops では rpm-ostree というパッケージマネージャーを dnf などの代わりに使うことになる。

これは、通常のアプリケーション以外のものをインストールする時に使う想定らしく、
Gimp や Inkscape、Blender などのツールは Flatpak からインストールすると良いらしい。

特性として、システムへの変更を保留して、次回の起動時などに適用するという物があり、
基本的には現在実行中の環境に影響を与えず、次回からの環境で行われている変更を組み立てる感覚で使う。

パッケージのインストール

パッケージのインストールは rpm-ostree install で行える。
これは次回に適用される環境を作っておくもので現在実行中のシステムに対して影響があるものではない事に注意が必要。

git や clang を入れるならこのように書ける。

rpm-ostree install git clang

パッケージのアンインストール

パッケージのアンインストールは rpm-ostree uninstall で行える。
次回に適用される環境として、指定したパッケージが最新の構成から削除されたものを作成し、現在実行中のシステムに対して影響があるものではない事に注意が必要。

git や clang をアンインストールするならこのように書ける。

rpm-ostree uninstall git clang

パッケージの検索

パッケージ検索は rpm-ostree search で行える。

rocm にまつわるものを調べるならこのように書ける。

rpm-ostree search rocm

実行中の環境に対する変更の適用

保留中の変更を今すぐに適用したいという場合は rpm-ostree apply-live から行える。
このコマンドは管理者特権を要求するので sudo で実行する必要がある。

sudo rpm-ostree apply-live

保留中の変更のキャンセル

保留中の変更をキャンセルするのであれば rpm-ostree cleanup が役に立つ。
このコマンドは保留中の変更をキャンセルする以外にもできることがあるらしいけれど今回は割愛。

rpm-ostree cleanup -p
# or
rpm-ostree cleanup --pending

変更のロールバック

適用された変更をロールバックして以前の環境へ戻すなら rpm-ostree rollback が役に立つ。
筆者はまだ使った事がないので他に必要なものがあった場合はあしからず。

rpm-ostree rollback

Linux カーネルパラメーター

Linux のカーネルパラメーターを追加するのであれば rpm-ostree kargs が利用できる。

設定されている引数を表示する場合

rpm-ostree kargs

追加する場合は --append オプションを利用できる。

以下は systemd-tpm2-generator に対して TPM2 synchronization point をブート時に挿入しないようにする設定。
TPM2 に対応していない環境にとって嬉しいことがあるらしいけれど詳細を知らないため割愛。

rpm-ostree kargs --append "systemd.tpm2_wait=false"

エディタで編集する場合は --editor オプションを利用できる。　デフォルトでは nano が立ち上がる。

rpm-ostree kargs --editor

OSTree

Fedora Atomic Desktops の堅牢性を支える物の一つに OSTree というものがある。

OSTree とは Linux ベースの OS 向けのバージョン管理システムで、変更ごとの環境を効率的に管理できる。

OSTree の README によれば、Git のようにチェックサムとファイルの本体を紐づけた Content-Addressable Storage でファイルの実体を管理しているらしい。

そして、実体に対してハードリンクを行い環境を作るという仕組みであるらしい。　そのため、Docker の OverlayFS のようにベースとなるファイルは不変である。

直接的な変更はできない代わりに効率的にアップデートごとの変更を保存することができ、巻き戻しも容易いという事だろう。

筆者はトラブルシュートが大の苦手なのでとってもありがたいのである。

日本語入力

日本語入力について。

筆者の環境だけなのかどうかはわからないけれど日本語入力は入っていない様なので Flatpak から Fcitx 5 と mozc をインストールすることにした。

flatpak install flathub org.fcitx.Fcitx5
flatpak install flathub org.fcitx.Fcitx5.Addon.Mozc

Discover からは mozc について検索してもインストール候補が出てこなかったのでコマンドラインからインストールするのが良さそう。

今のところ問題なく使用出来ている。

感想

Fedora Kinoite を使い始めてからまだ 1 周間も経っていないにこの様な記事を書いてしまった。
それだけ Fedora Kinoite が魅力的に感じたからでもあるけれど、実際の感想としては不十分だろう。

実際に使ってみた感想としては rpm-ostree 自体は実行中のシステムにもソフトウェアをインストールできるので、煩わしさはあまり感じないで済みそうだった。

ただ、起動が遅いと感じた。　フォーラムでも似たような報告はあるけれど人によって解決方法が違うので一部の PC では起動が遅いという事かもしれない。

それでも筆者は一度起動した場合、ほとんどシャットダウンすることはないので普段の用途では特に気になることはなさそうだった。

ROCm のインストールは rpm-ostree のリポジトリから提供されているものを使った為、今回では 6.3 系のバージョンをインストールできた。
今のところ特に問題なく GPU での計算が出来ている様なので、LLM だったり GPGPU で遊ぶ場合も大丈夫そうだ。

今のところアプリケーションのほとんどは Flatpak からインストールして、コンパイラなどはバイナリをダウンロードして利用することにしている。
Nix などを覚えていればもっと小回りが効くかもしれないなと思ったので、適当なタイミングで調べても良いかもしれない。

筆者自身、ディストリビューションの深いところまでは干渉しない使い方をしていたので普段の用途には問題はなさそうと感じた。
Helix も問題なく使えて、Deno も動いているので記事の執筆もちゃんと行えている。

Toolbx はネーミングについて最初はタイポだと思ったのだけれどそうではないらしいと知って衝撃を受けた。

Toolbx 自体は WSL みたいにシームレスにホスト環境と連携できる点がとても気に入ったので今後使うかもしれない。
Toolbx のコンテナはホスト環境の IME での入力も完璧にできるのでとってもハッピー。

ただ、venv のようにプロンプトに現在の環境が Toolbx のコンテナであるとの表示は出ないのでちょっとヤヤコシイ。
今後設定方法を知ったら記事にしたい。

やっぱりデスクトップ環境は KDE Plasma が一番好きなので Fedora Kinoite があって助かった。

RedHat 系の Linux を触る口実が出来てよかった。

おわりに

全体的に Fedora Kinoite について調べると Fedora Atomic Desktops というシリーズの思想がなんとなくわかってきた。

似た事が実現できるようなディストリビューションは Nix OS や、Chrome OS が思いつく。
後者は一応 Gentoo ベースらしいのだが Linux と呼ぶには堅牢すぎるので引き合いに出すとややこしくはある。

調べてみるとこのようなディストリビューションは Reddit の一部のスレッドでは Atomic distro や Immutable Linux distribution などと呼ばれている様だ。

Linux を初めて使う方や、他のディストリビューションが気になる方は Fedora Atomic Desktops も視野に入れてはどうだろうか。

またこんど！

最終更新：