あまり知られていない Linux ディストリビューション 5 選

開発者にとって最適な Linux ディストリビューションとは、ツールチェーン、コンテナ、GPU ドライバーを最小限の手間で動作させられるものです。CachyOS、Bazzite、Nobara、Vanilla OS、Chimera Linux は、この 3 点についてそれぞれ異なるトレードオフを選択しています。

「ベストなディストロ」を謳う記事の多くは、実質的にはゲームのベンチマークです。フレームレートは教えてくれても、何気ない平日の朝に npm install や Docker、IDE が問題なく動くかどうかは教えてくれません。

現在ではコンテナがその役割を担うため、手元のノート PC を本番環境に合わせる必要はもうありません。その結果、ホスト OS の選択を左右するのは、ドライバー、アップデートの挙動、ツールのインストール方法の 3 点に絞られます。本記事では、比較的知名度の低い 5 つのディストリビューションを、この 3 つの観点から見ていきます。Omarchy と Garuda Linux については個別の記事があるため、ここでは取り上げません。

CachyOS:パフォーマンスチューニングされた Arch

CachyOS は、Arch をベースとしたローリングリリース型のディストリビューションです。標準の Arch との違いは 2 点あります。1 つは、デフォルトでチューニング済みの EEVDF スケジューラーを使用する CachyOS チューニングカーネルです(BORE などのスケジューラーはオプション)。もう 1 つは、x86-64-v3、x86-64-v4、AMD Zen 4/5 向けにコンパイルされたパッケージリポジトリです。すでに Arch を使い慣れていて、チューニングは任せたいという開発者に向いています。

• パッケージ: Arch リポジトリと AUR を利用できます。珍しい CLI、言語サーバー、ニッチな SDK も、たいていはパッケージ 1 つで導入できます。
• 作業開始までに必要なこと: ランタイムと、Docker または Podman をリポジトリからインストールします。妨げになるものは何もありません。
• NVIDIA: Arch の NVIDIA パッケージと Arch Wiki の NVIDIA ページの内容がそのまま適用できます。
• 業務マシンとして: カーネル、Mesa、ツールチェーンのアップデートが継続的に配信されます。大規模なアップグレードの前には、ニュースを確認することが前提となります。

代償: ローリングリリースならではのメンテナンス負担です。締め切り当日に不具合のあるアップデートが来ても、自分で直すしかありません。

Bazzite:NVIDIA 専用イメージを備えた Fedora Atomic

Bazzite は、読み取り専用の Fedora Atomic イメージをベース OS とするイミュータブルなディストリビューションです。システムは単一のユニットとして更新され、以前のイメージから起動するだけでロールバックできます。つまり、dnf のように開発ツールをグローバルにインストールする使い方はしません。一貫した状態を保つマシンを求め、コンテナ内での作業を厭わない開発者に向いています。

• パッケージ: GUI アプリには Flatpak、ホスト側のソフトウェアには rpm-ostree によるレイヤリング、ツールチェーンにはコンテナを使います。Bazzite には Distrobox が同梱されています。Docker を最初から使いたい場合は、標準イメージではなく Bazzite DX バリアントを選ぶ必要があります。
• 作業開始までに必要なこと: 開発用コンテナを構築します。
• NVIDIA: Bazzite は NVIDIA 専用のイメージを提供しています。ダウンロードページで該当するものを選んでください。
• 業務マシンとして: アップデートはアトミックに適用され、ロールバックも可能です。ただし、ホームディレクトリ、コンテナ、レイヤリングしたパッケージの管理は引き続き自分の責任です。

イミュータブルな Fedora システムでは、rpm-ostree を使ってホストレベルのパッケージをイメージ上にレイヤリングし、再起動後に反映させます。言語ツールチェーンは、ホームディレクトリを共有する Distrobox または Toolbx のコンテナに配置します。

rpm-ostree install zsh          # host layer, applied on next boot
systemctl reboot

distrobox create --name dev --image registry.fedoraproject.org/fedora:latest
distrobox enter dev
sudo dnf install nodejs gcc make   # inside the container only

rpm-ostree rollback             # revert to the previous deployment

dev 内にインストールしたものはホストイメージには含まれず、コンテナを削除すればまとめて消えます。

Bazzite の読み取り専用ベースでは、これまでの習慣が通用しなくなります。普段は sudo とテキストエディターで問題を解決し、ファイルのパーミッションや所有権も熟知している方もいるでしょう。しかし Fedora Atomic では、/usr は読み取り専用です。/etc は書き込み可能なままですが、新しいイメージが適用されるたびに、OSTree が変更内容をマージします。落とし穴はもう 1 つあります。Flatpak でパッケージされた IDE はサンドボックス内で動作します。そのため、明示的に設定しない限り、コンテナ内やホスト上のコンパイラーを認識できない場合があります。

代償: ツールをインストールするたびに、ホスト、コンテナ、Flatpak のどこに置くべきかを最初に判断する必要があります。

Nobara:粗削りな部分を磨き上げた Fedora

Nobara は、ごく普通の書き込み可能な Fedora に、メディアコーデック、NVIDIA ドライバー、ゲーミング向けのカーネルパッチを追加したものです。Fedora のドキュメントや dnf の使い方は、ほとんどがそのまま通用します。GloriousEggroll 氏がメンテナンスしており、インストールのたびにコーデックやドライバーを設定することにうんざりしている Fedora ユーザーに向いています。

• パッケージ: dnf、Flatpak、Fedora エコシステムに加え、Nobara 独自のリポジトリを利用できます。
• 作業開始までに必要なこと: ほとんどありません。Fedora と同様に、ランタイムとコンテナエンジンをインストールするだけです。
• NVIDIA: プリインストール済みです。Fedora の初回起動時に最もよくある手間が解消されます。
• 業務マシンとして: ミュータブル(書き換え可能)なシステムです。何でも編集できる反面、何でも壊せてしまいます。

代償: Fedora よりも小規模なプロジェクトです。問題が起きた際は、アップストリームに加えて、Nobara 独自のパッチも調査対象になります。

Vanilla OS:イミュータブルかつコンテナファースト

Vanilla OS は、ベースシステムをイミュータブルに保ち、ソフトウェアのインストールをコンテナ側で行う設計です。コンパイラーをインストールする際は、どのリポジトリから入手するかではなく、どのコンテナに置くかを決めるところから始まります。1 台のマシンで複数のディストリビューションのパッケージを日常的に必要とする開発者に向いています。

• パッケージ: ホストは ABRoot によって管理されます。ABRoot は各アップデートを 2 つ目のルートパーティションに適用し、次回の再起動時にそちらへ切り替えます。Apx は、他のディストリビューションをベースにしたコンテナを管理し、それらのパッケージマネージャーをホストから利用できるようにします。GUI アプリは Flatpak でカバーします。
• 作業開始までに必要なこと: ツールチェーンの系統ごとに Apx コンテナを作成します。
• NVIDIA: お使いのハードウェアへの対応状況は、プロジェクトのドキュメントを確認してください。
• 業務マシンとして: Bazzite と同様、イミュータブルならではのトレードオフがあります。ただし、rpm-ostree ではなく Vanilla 独自のツールを通じて扱うことになります。

代償: Vanilla 固有のツール群を覚える必要があります。Fedora Atomic や Arch のドキュメントが 1 対 1 で当てはまるわけではありません。

Chimera Linux:正真正銘の異端児

Chimera Linux は、可能な限り GNU を排除した、独立系のローリングリリース型ディストリビューションです。glibc の代わりに musl、GNU coreutils の代わりに FreeBSD のコアツールを採用し、システムツールチェーンには LLVM/Clang、init には dinit を使用しています。パッケージは apk-tools で提供されます。システムプログラマーや、移植性(ポータビリティ)を検証したい人に向いています。

• パッケージ: apk リポジトリを使用します。Arch や Fedora のパッケージングを前提とするソフトウェアには、コンテナが必要です。
• 作業開始までに必要なこと: 使用するランタイムが musl 上で動作するかを確認します。
• NVIDIA: NVIDIA のサポート状況は、プロジェクトのドキュメントで確認してください。
• 業務マシンとして: BSD 系のツールはフラグ(オプション)の仕様が異なるため、GNU coreutils を前提に書かれたシェルスクリプトが想定外の動作をすることがあります。

Chimera Linux のような musl ベースのディストリビューションでも、自分で書いたコードのビルドや実行は問題なく行えます。問題になるのは、glibc にリンクされたビルド済みバイナリです。glibc 向けビルドしか公開していないベンダー製 CLI やパッケージは、互換レイヤーや glibc コンテナなしでは動作しない可能性があります。

代償: エコシステムが glibc を前提としている点です。世の中で配布されているバイナリの大半は、glibc 向けにビルドされています。

開発者に最適な Linux ディストリビューションはどれか?

• AUR を日常的に使い、ローリングアップデートも気にならないなら、 CachyOS がチューニング済みの Arch を提供してくれます。
• 状態が変化しない OS を求め、コンテナでの開発に抵抗がないなら、 Bazzite のイメージモデルと Distrobox がニーズを満たします。
• すでに Fedora に慣れていて、NVIDIA とコーデックの問題さえ片付けばよいなら、 Nobara でこれまでの習慣をそのまま活かせます。
• 1 台のマシンで複数ディストリビューションのパッケージを日常的に必要とするなら、 Vanilla OS が各ツールチェーンを専用の Apx コンテナに分離してくれます。
• 移植性を検証するための型破りなシステムが欲しいなら、 Chimera がコードに潜む glibc や GNU への依存をすべて浮き彫りにしてくれます。

どれを選んでも、本番環境でコードが動作する基盤は変わりません。この選択で決まるのは、ツールチェーンをどのようにマシンへ導入するか、アップデートがどのように適用されるか、そしてエディターを開く前にどれだけドライバー関連の作業が必要か、という点です。自分の状況に合うものを選んだら、そのディストリビューションを空きパーティションにインストールし、本格的に移行する前に、現在のプロジェクト環境をそこで再構築してみてください。

よくある質問

Bazzite や Fedora Atomic で rpm-ostree install を実行するたびに再起動が必要ですか?

いいえ、パッケージを追加するだけなら不要です。デフォルトでは rpm-ostree のすべての操作はオフラインで行われ、次回起動時に反映されます。ただし、rpm-ostree install --apply-live(短縮形は -A)を使うと、新たにレイヤリングしたパッケージを実行中のシステムに即座に適用できます。ライブ適用が使えるのは、他に保留中の変更がない状態でパッケージを追加する場合のみです。パッケージの削除には引き続き再起動が必要です。また、rpm-ostree apply-live --reset を実行すると、起動時のツリーに戻せます。

x86-64-v3 に対応していない古い CPU でも CachyOS は動作しますか?

はい、動作します。CachyOS は x86-64-v3、x86-64-v4、Zen 4/5 向けのビルドに加えて、汎用の x86-64 リポジトリも提供しています。セットアップ時には、インストーラーとリポジトリスクリプトがプロセッサーの対応状況を判別し、最適なリポジトリ階層を自動で選択します。AVX2 非対応の CPU には汎用パッケージが使われるため、ローリングリリースの Arch ベースや CachyOS のツール群はそのまま利用できます。お使いの CPU が対応しているレベルは、/lib/ld-linux-x86-64.so.2 --help を実行すると確認できます。

開発用コンテナとして、Distrobox と Toolbx にはどのような違いがありますか?

どちらも、ホストとホームディレクトリを共有する長期利用向けのコンテナを作成します。Toolbx は Podman 上でのみ動作し、Fedora 系のイメージで最もよく機能します。一方の Distrobox は Podman または Docker をラップし、どちらもない場合は独自の Lilipod マネージャーにフォールバックします。また、ほぼあらゆるディストリビューションのイメージを実行できます。Fedora Atomic 上で Fedora コンテナを使うだけなら Toolbx で十分です。.deb 形式でしか提供されていないベンダー製ツールを使う場合など、Arch、Ubuntu、Alpine のユーザーランドが必要なときは Distrobox が適しています。

Flatpak 版の VS Code から、Distrobox 内やホストにインストールしたコンパイラーを使えますか?

デフォルトでは使えません。Flathub で配布されている VS Code パッケージはサンドボックス内で動作し、ホストにインストールされた SDK にはアクセスできません。そのため、Distrobox コンテナ内のツールチェーンや、rpm-ostree でレイヤリングしたツールチェーンは認識されません。パッケージの説明には、3 つの回避策が記載されています。flatpak-spawn --host または host-spawn を介してホストのコマンドを実行する方法、統合ターミナルでホストのシェルを使うよう設定する方法、そして Go SDK や .NET SDK などの Freedesktop SDK 拡張機能をサンドボックス内にインストールする方法です。