Arch 系ディストリビューションは何を変えているのか、レイヤーごとに見る

CachyOS のサブレディットで「CachyOS と Omarchy のどちらを入れるべきか」と尋ねると、最も評価の高い 2 つの返信はどちらも推薦ではありません。ひとつは「Asking this in related to CachyOS sub…bruh」。もうひとつは、Honda のフォーラムに入って Accord と Camry のどちらを買うべきか聞くようなものだ、と例えています。

どちらの返信も正しく、その理由は姿勢の問題ではなく仕組みの問題です。Arch 系ディストリビューションの違いは、各プロジェクトが素の Arch のどこを変えているかに帰着します。ここで比較するディストリビューションでは、その変更は主に 5 か所に集まります。インストーラー、カーネルとコンパイルターゲット、パッケージリポジトリ、デスクトップシェルと設定、そしてアップデートとロールバックのポリシーです。CachyOS と Omarchy は、最も大きな変更を異なるレイヤーで行っています。

短いバージョン

• ここで比較するディストリビューションでは、意味のある違いは主に 5 つのレイヤーに収まります。インストーラー、カーネルとコンパイルターゲット、パッケージリポジトリ、デスクトップシェルと設定、アップデートとロールバックのポリシーです。
• プロジェクトは 1 つのレイヤーだけを変え、残る 4 つに手を付けないこともできます。だからこそ、2 つのディストリビューションがどちらも「Arch 系」でありながら、ほとんど何も共有していないということが起こります。
• CachyOS はカーネル／コンパイルとリポジトリのレイヤーを大きく変え、インストーラーを整え、デスクトップシェルは押し付けません。シェルはインストール時に自分で選びます。
• Omarchy はデスクトップシェルとアップデートポリシーのレイヤーを大きく変え、独自のパッケージチャンネルを運用し、カーネルやコンパイルターゲットには性能目的の変更を加えていません。
• レイヤーは個別に取り入れられます。CachyOS は既存の Arch 環境に自身のリポジトリを追加する手順を文書化しており、Omarchy 上でその道を試した人もいますが、結果はまちまちです。

この記事が決着をつけないこと

この問いと混同されやすい問いが 3 つあり、それぞれ分類では示せない別種の証拠を必要とします。

• CachyOS が全般的に速いのかどうか。 その問いには独自の証拠基盤と、独自の記事があります。
• 2 つのうちどちらをインストールすべきか。
• 存在するすべての Arch 派生。ここで名前を挙げるのは 5 つで、この 5 レイヤーはこのグループのための比較モデルであり、あらゆる Arch 派生を網羅する分類ではありません。

この比較で追う 5 つのレイヤー

ここで比較する派生では、意味のある違いの大半を 5 つのレイヤーで説明できます。インストーラー、カーネルとコンパイルターゲット、パッケージリポジトリ、デスクトップシェルと設定、アップデートとロールバックのポリシーです。プロジェクトはそのうち 1 つを変え、残る 4 つを Arch が提供するままにしておくことができます。

インストーラーは、何もないマシンから起動済みのシステムに至る道であり、どれだけの選択をユーザーに委ねるかをプロジェクトが決めるレイヤーです。素の Arch は手動インストールの手順を文書化し、ライブ ISO にガイド付きインストーラー archinstall も同梱しています。それでも派生は、その体験を独自のガイド付きデフォルトに置き換えられます。重要なのは、そのインストーラーが代わりに何を決めてしまうかです。ファイルシステム、ブートローダー、暗号化、ドライバー、デスクトップ。デフォルトのひとつひとつが、誰かが取った立場です。

カーネルとコンパイルターゲットのレイヤーは、混同されがちな 3 つの事柄を含みます。どのカーネルビルドを起動するか。パッケージがどの CPU 命令セット向けにコンパイルされているか。どのスケジューラーが、何をいつ実行するかを決めるか。

コンパイルターゲットとは、パッケージがビルドされたマイクロアーキテクチャレベルのことです。x86-64 はあらゆる x86-64 プロセッサが対応するベースラインです。x86-64-v3 は AVX、AVX2、BMI1、BMI2、FMA などの機能を追加し、x86-64-v4 は v3 の上に AVX-512 の要件を加えます。どちらかのレベル向けにビルドされたパッケージは、必要な機能セットを持たないプロセッサでは起動しません。スケジューラーは、実行可能なタスクのどれが次にプロセッサを得るかを決め、スケジューラーごとにスループットと対話的な応答性の重み付けが異なります。派生はこの 3 つすべてを変えることも、1 つだけ、あるいは何も変えないこともできます。

パッケージリポジトリのレイヤーは出所の問題です。誰がビルドしたパッケージを受け取るのか、それがどれだけ新しいのか、届くチャンネルを誰が管理しているのか。素の Arch は core、extra、multilib からバイナリを取得し、その横に自分でコンパイルするビルドレシピとして AUR があります。派生は独自リポジトリを上に重ねることも、Arch のリポジトリの前に意図的な遅延を置くことも、その両方をすることもできます。

デスクトップシェルと設定のレイヤーは、画面に何が表示され、どう配置されるかであり、ここで語彙につまずく人が多いのです。KDE Plasma や GNOME のようなデスクトップ環境は完全なパッケージです。ウィンドウ管理、パネル、ファイルマネージャー、設定、アプリケーション。i3 のようなタイル型ウィンドウマネージャーや Hyprland のようなタイル型 Wayland コンポジターは、完全なデスクトップ一式を提供せずにウィンドウ配置を担い、バー、ランチャー、通知、ロック画面を別々の部品として残します。派生はシェルを押し付けることも、メニューで選ばせることも、何も立場を取らないこともできます。

アップデートとロールバックのレイヤーは、システムがどう前進し、まずい場所に進んでしまったときにどう戻るかを扱います。素の Arch ではどちらも自分の責任です。自分が決めたタイミングで pacman -Syu を実行し、復旧はパッケージキャッシュか自分で組んだスナップショットの仕組みで行います。派生はそのコマンドをラップすることも、ゲートを設けることも、そのままにすることもでき、スナップショットが安価になるようにファイルシステムを配置して復旧をデフォルトにすることもできます。Btrfs のサブボリューム構成が買ってくれるのはそれです。スナップショットは 1 つのサブボリュームのある時点のコピーで、ブートローダーと統合すれば、派生はそれらのスナップショットを復旧の選択肢として提示できます。

CachyOS が変えているもの

CachyOS はカーネルとコンパイルターゲットのレイヤーとパッケージリポジトリのレイヤーを大きく変え、インストーラーを整え、デスクトップシェルは押し付けません。独自のカーネルビルドを提供し、Arch のパッケージをより新しい CPU 機能レベル向けに再コンパイルし、画面に何を表示するかはインストールする人に委ねています。

インストーラーではデスクトップ、ファイルシステム、カーネルに加えてパッケージとブートマネージャーを選べ、ハードウェア検出ツールが見つけたものに合わせてドライバーをインストールします。 プロジェクトの主張はインストーラーの中ではなく、その下にあります。

デフォルトの linux-cachyos カーネルは Clang ThinLTO と AutoFDO プロファイリングでビルドされ、このファミリーは BORE、EEVDF、BMQ を選択可能なスケジューラーとして提供しています。 それとは別に、新しいカーネルをビルドせずにユーザー空間から BPF スケジューラーを読み込むためのフレームワークである sched-ext にも対応しています。 この 2 つは別物です。sched-ext は実行時にスケジューラーを差し替えるもので、先ほどのリストの 4 番目の項目ではありません。

CachyOS はさらに Arch のパッケージを x86-64-v3、x86-64-v4、Zen4+ 向けに再コンパイルしており、wiki ではベースラインに対して x86-64-v3 で 5% から 20% の向上を主張しています。 これは CachyOS 自身の成果に対する CachyOS 自身の数字であり、独立した測定ではありません。再ビルドされたパッケージは、Arch の core、extra、multilib を置き換えるのではなく、その上に重ねられた CachyOS のリポジトリにあります。置き換えではなく重ねることで出所が読み取れる状態が保たれ、どのパッケージについても、どのチャンネルがビルドしたかを言えます。

デスクトップシェルは CachyOS が押し付けないレイヤーです。環境は自分で選びますが、いくつかの選択肢には CachyOS が保守する設定や dotfiles が付属します。 オンラインインストーラーは KDE Plasma、GNOME、Hyprland、Niri、Sway、Xfce を含む 17 以上の環境を提供し、選択はユーザーに委ねられます。 CachyOS Hello と Kernel Manager はシステム管理ユーティリティであって、シェルではありません。

CachyOS は独自のアップデートラッパーを必須にしていません。直接の pacman -Syu は文書化された手順として残っており、Shelly、Octopi、オフラインアップデートといった任意のツールもあります。Btrfs にインストールすると、CachyOS は個別のサブボリュームを配置し、復旧用スナップショットに Snapper を使います。対応するブートローダー構成では、それらのスナップショットを復旧用に提示できます。

読む

CachyOSは本当に速いのか？ パフォーマンス向上の本当の出どころ

Omarchy が変えているもの

Omarchy はデスクトップシェルのレイヤーとアップデートポリシーのレイヤーを大きく変え、独自のパッケージチャンネルを提供し、カーネルやコンパイルターゲットには性能目的の変更を加えていません。固定のデスクトップを 1 つインストールし、pacman をユーザーに任せる代わりにアップデートコマンドを自ら引き受けます。

Omarchy は独自の ISO からインストールし、ディスク全体か、別の OS の隣の空き領域に入れられ、デフォルトでディスクを暗号化します。 インストーラーはデスクトップについて何も尋ねません。答えは 1 つしかないからです。

カーネルとコンパイルターゲットのレイヤーはほぼ手付かずです。 Omarchy 自身のマニュアルは、これを Hyprland と Quickshell を中心に構築された Arch 系ディストリビューションと説明しており、インストーラー、アップデート、dotfiles、CLI の各ページを通して、カスタムカーネルもコンパイルターゲットもスケジューラー選択も文書化していません。 通常のハードウェアでは、Omarchy はシステムの他の部分と同じく Arch のミラーから届く素の Arch のカーネルパッケージを実行します。 マニュアルが文書化している唯一のカーネル差し替えはハードウェア対応のためのものです。T2 チップ搭載の Intel Mac では、インストーラーがパッチ済みの linux-t2 カーネルをセットアップします。

リポジトリのレイヤーは確かに変えていますが、CachyOS とは別の軸です。 Omarchy は独自の Package Repository から通常の pacman パッケージとしてインストールされ、デフォルトの stable チャンネルは最新から 1 か月遅れの Arch ミラーを追従するため、非互換は先に上流で表面化します。 他の 3 つのチャンネル（RC、edge、dev）は、その緩衝を新しさと引き換えにします。

Hyprland と Quickshell はセットで入り、外すことはできません。Hyprland はタイル型 Wayland コンポジターで、Quickshell はバー、ランチャー、メニュー、通知、ロック画面を組み立てるための構築キットです。だからこそ Omarchy はテーマを配布するのではなく、1 回のリリースでシェル全体を差し替えられます。この分離により、Omarchy はプロジェクトが定義した再現可能なベースラインを持ちつつ、ユーザー独自の上書きは別に保てます。 設定は 2 つに分かれます。ユーザーの dotfiles は ~/.config に、プロジェクトのデフォルトは /usr/share/omarchy にあり、後者はパッケージが所有し、アップデート時に上書きされます。 アップデートを生き延びさせたいものはすべて、この分離のユーザー側に置くべきです。

アップデートポリシーは Omarchy の立場が最も鮮明なところです。omarchy update コマンドは、保留中のマイグレーションとパッケージアップデートを 1 回の操作で実行し、その前にスナップショットを取ります。ロールバックは、そのスナップショットをブートローダーで選ぶことを意味します。 代わりに pacman -Syu に手を伸ばすとガードに当たります。Omarchy はシステムの直接アップグレードを止め、独自コマンドへ誘導しますが、マニュアルによれば、ガードは 1 回のトランザクションに限って回避する方法を教えてくれます。 要点は結合です。マイグレーションはパッケージアップデートと一緒に移動します。

読む

Omarchyが同じ理由で称賛され、嫌われる理由

比較スレッドが決して収束しない理由

CachyOS と Omarchy は同じレイヤーのいくつかに触れていますが、最も強い変更を置く場所が異なります。CachyOS はカーネル、コンパイルターゲット、パッケージビルドに集中し、Omarchy はデスクトップシェルとアップデートのワークフローに集中しています。「どちらが良いか」は、これらの別々の問いを 1 つに潰してしまいます。

両者はインストーラー、リポジトリ、復旧のレイヤーで重なりますが、同じやり方ではありません。CachyOS のリポジトリは Arch のパッケージがどうビルドされるかを変え、Omarchy のリポジトリはいつ届くかを変えます。CachyOS は直接の pacman アップデートを使える状態にしてその周りにスナップショットを加え、Omarchy はパッケージアップデート、マイグレーション、スナップショットを独自のアップデートコマンドの背後で結合します。

あの CachyOS スレッドの上位 2 つの返信は、まさにこれを圧縮していました。正しい診断を、その背後にある 5 つのレイヤー抜きで伝えていたのです。

レイヤーは混ぜられる

5 つのレイヤーは互いに排他ではなく、個別に取り入れられます。 CachyOS は自身のリポジトリを Arch 環境に追加する手順と、再び取り除く手順を文書化して公開しています。 Omarchy は Arch 環境なので、同じ手順で CachyOS の最適化リポジトリをその上に持ち込めます。

実際にそうしている人がいます。 r/linux_gaming のスレッドで、あるコメント投稿者は率直にこう述べました。「There's nothing stopping you from installing the cachyos kernel and repositories on omarchy.」 この組み合わせ用のインストールスクリプトを公開し、Hacker News に投稿した人もいます。

原理上の独立性は、実際の信頼性と同じではありません。 両者間の移行に関する r/omarchy のスレッドでは、あるコメント投稿者が「All of the install scripts and such to do this are currently not working for many people」と報告し、手動で介入しても動かなかったと述べています。 これは 1 つのスレッドの 1 人の報告ですが、備えておく価値のある種類のトラブルです。

2 つ目の限界は、この組み合わせにどれほどの価値があるかです。 公開されている性能比較では、ゲームの平均 FPS にほとんど差がなく、CachyOS のカーネル、スケジューラー、コンパイルターゲットによるより広い効果は、自動的なものではなくワークロード次第のままです。

CachyOS のカーネル作業とコンパイルターゲットがより広範に、どのクラスのワークロードで意味のある効果を生むのかは、この記事が決着をつける証拠基盤とは別の証拠基盤に依存します。

EndeavourOS と Manjaro は同じレイヤーのどこに位置するか

EndeavourOS と Manjaro も同じ 5 つのレイヤーに独自の組み合わせで収まります。だからこのモデルは 2 プロジェクトの比較以上の価値があるのです。EndeavourOS が最も変えているのはインストーラーのレイヤーですが、initramfs の生成に Dracut を使い、EndeavourOS 固有のツールとパッケージ用に小さなリポジトリも維持しています。Manjaro が最も変えているのはリポジトリのレイヤーで、インストーラーはいくらか、コンパイルターゲットのレイヤーはまったく変えていません。

EndeavourOS は自らを軽量でターミナル中心の Arch システムと説明しており、加えているのはガイド付きインストーラー、厳選された少数のパッケージ群（Firefox、Yay、FirewallD、Pipewire）、そして GPU と VM のドライバー用の独自ツールです。 カスタムカーネルなし、Arch の一般リポジトリの CPU 向け再ビルドなし、デスクトップの押し付けなし。ここで挙げた派生の中では、依然として最も素の Arch に近い存在です。

Manjaro の位置づけは、段階的な安定性というアプローチです。 パッケージは Arch のリポジトリを直接追従するのではなく、Manjaro 独自のリポジトリ内で unstable、testing、stable のブランチを経て流れます。だから Manjaro のパッケージが同名の Arch パッケージより古いことがあるのです。 インストーラーでは公式の Plasma、GNOME、Xfce エディションに加え、コミュニティ版の Cinnamon、i3、Sway ビルドからデスクトップを選べます。

カーネルツールも備えており、その区別が重要です。 Manjaro Settings Manager はカーネルを追加・削除でき、別のビルド済みカーネルバージョンを実行できます。 パッケージ化されたカーネルバージョンから選ぶことは、より新しい CPU 命令セット向けにパッケージを再ビルドすることと同じ操作ではありません。どちらもカーネルとコンパイルターゲットのレイヤーに属してはいますが。

このブランチモデルこそ、Manjaro を固定リリースの世界から分けているものでもあります。 Ubuntu と対比した Manjaro のローリングモデルは、Arch ファミリーの外で問われた同じリポジトリとアップデートポリシーの問いです。 同じ整理は、そのファミリーの外でも通用します。 Ubuntu は Debian から派生し、リリースの周期、パッケージングの方針、デフォルトのデスクトップで Debian と異なります。

新しい派生のトップページを見れば、たいていこれらのレイヤーのどれに触れているか、そしてこの 5 レイヤーモデルの外で何かを変えているかが分かります。

よくある質問

Omarchy は本物のディストリビューションか、それとも単なる dotfiles か？

5 レイヤーのテストでは、Omarchy は dotfiles の集まり以上のものです。独自の ISO インストーラー、4 つのリリースチャンネルを持つ独自のパッケージリポジトリ、そして pacman -Syu の代わりとなる独自のアップデートツールを備えています。カーネルやコンパイルターゲットには性能目的の変更を加えておらず、マニュアルが文書化している唯一のカーネル差し替えは T2 チップ搭載 Intel Mac 向けのハードウェア対応パッチです。その下のシステムはそれ以外は素の Arch です。それを合わせて「ディストリビューション」と呼べるかどうかは、ラベルをめぐる議論です。

CachyOS のカーネルとリポジトリを Omarchy で使えるか？

技術的には可能です。CachyOS は既存の Arch 環境へのリポジトリ追加を文書化しており、Omarchy は内部で Arch のパッケージを使っています。ただし互換性が保証されるわけではありません。Omarchy の遅延したパッケージチャンネルとアップデートワークフローがもう 1 つの可動部品を加えますし、r/omarchy のあるコメント投稿者は、便利スクリプトが多くの人で失敗していると報告しています。手動での介入に備えてください。

CachyOS はデスクトップ環境を押し付けてくるのか？

いいえ。CachyOS はデスクトップの選択をユーザーに委ねます。オンラインインストーラーは、KDE Plasma のような完全な環境から Hyprland や Niri のようなタイル型 Wayland コンポジターまで 17 以上の選択肢を並べ、選択はインストール中に行います。Kernel Manager など CachyOS が保守するツールは、選んだどのデスクトップでも動作します。

x86-64-v3 とは何を意味するのか？

x86-64-v3 は、ベースラインの x86-64 より上位の CPU マイクロアーキテクチャ機能レベルです。AVX、AVX2、BMI1、BMI2、FMA などの要件が加わるため、v3 専用にビルドされたソフトウェアには、その機能セットに対応した CPU が必要です。v3 向けにコンパイルされたパッケージはそれらの機能を使え、備えていないプロセッサでは起動しません。CachyOS は Arch のパッケージを x86-64-v3 と x86-64-v4 向けに再ビルドし、v3 で 5% から 20% の向上を主張していますが、これはプロジェクト自身の数字です。