著者 Linuxディストリビューションの歴史と3つの系統
Linuxディストリビューションの多くはSlackware、Debian、Red Hatの3系統に由来します。package managerやVPSイメージが何を引き継いだのか、系譜とともに整理します。
Linux ディストリビューションの実態
Linux ディストリビューションの歴史は、ある空白から始まります。Linux kernel だけでは、人が利用できる機能は何もありません。起動してハードウェアを検出するだけです。その後は停止します。誰かが userland を追加し、ソフトウェアのインストールと更新方法を決め、何年にもわたって修正を続ける必要があります。ディストリビューションとは、こうした選択の集合と、その後も活動を続ける人々の集まりです。
ディストリビューションは、次の5つの要素で構成されます。大部分のバイナリが一致していても、これらの選択が異なれば別のディストリビューションです。
- プロジェクトが選んだバージョンの kernel と、追加したパッチおよびドライバー。1つのリリースで複数を提供する場合もあります。Ubuntu 24.04 LTS は、サーバーに GA (general availability) kernel をデフォルトでインストールし、より新しい HWE (hardware enablement) kernel をオプションとして提供します。
- userland。C library、shell、init system、標準コマンドで構成されます。
- パッケージ形式と、それをインストールするツール。
- リリースポリシー。何を変更できるか、変更頻度、各リリースを修正し続ける期間を定めます。
- 人。パッケージメンテナー、security team、パッケージが壊れたときに対応する担当者です。
kernel は共有される部分です。そのため、2つの Linux ディストリビューションは、どちらも別の Unix より互いに近い関係にあります。これは、サーバープラットフォームとしての Linux と FreeBSD を比較するときに重要です。FreeBSD では、kernel と base userland が1つのプロジェクトによって構築され、まとめてリリースされます。Linux では、これらの要素は別々の upstream から提供されます。ディストリビューションが、それらを整合させる役割を担います。
Linux ディストリビューションの3つの系統の歴史
1993年と1994年に始まった3つのプロジェクトが、Slackware、Debian、Red Hatという系統になりました。現在のVPSコントロールパネルにあるイメージのほとんどは、これらのいずれか、またはその派生です。派生ディストリビューションは、パッケージ形式、ファイル配置、通常はリリースの方針も引き継ぎます。そのため、ブランド表示がなくなっても、Debian派生ディストリビューションはDebianらしく見えます。
独立系ディストリビューションは、どのプロジェクトからもforkしていないため、別に扱う必要があります。Arch、Gentoo、Alpine、NixOS、Voidは、それぞれ独自のパッケージマネージャーと独自のルールを作りました。そのうちArchとAlpineは、デスクトップとは関係のない理由で、最終的にプロバイダーのイメージ一覧にも加わりました。
1992: ファミリー以前のディストリビューション
MCC Interim Linux は 1992 年 2 月に登場しました。Manchester Computing Centre の Owen Le Blanc が構築したものです。メニュー方式のインストーラーを使い、kernel と GNU（GNU's not Unix）のツールを 2 枚のフロッピーイメージに収録しました。これを手作業で行うと 1 日かかっていたため、この仕組みが作られました。
Peter MacDonald が 1992 年にリリースした SLS（Softlanding Linux System）は、さらに機能を追加し、X（X Window System）と TCP/IP ネットワークを搭載しました。distribution という語が現在の意味で使われるようになったのは、SLS がきっかけです。一方で、バグが多く、保守も徐々に滞りました。1993 年、2 人が別々にこの問題を修正しようとしました。1 人は SLS を再構築しました。もう 1 人は、文書化したルールに基づいて最初から作り直しました。
Slackware、1993: 現在もリリースを続ける最古の系統
Patrick Volkerding は、SLS からバグを取り除いて Slackware 1.00 を 1993 年 7 月 16 日にリリースしました。現在も保守されているため、現存する Linux ディストリビューションとしては最古です。
Slackware のパッケージは、内部にインストールスクリプトを含む圧縮 tar アーカイブです。依存関係の解決機能はありません。新しいパッケージが必要とするライブラリが、すでにディスク上にあるかどうかを確認する仕組みもありません。この判断が、その後の設計全体を決めました。ツールが依存関係を解決しないなら、リリースに含めるパッケージ群は、最初から整合していなければなりません。そのため、リリースは少なく、保守的になります。Slackware 15.0 は 14.2 の 6 年後にあたる 2022 年 2 月に登場しました。
この系統は小規模です。1990 年代半ばの SUSE の初期リリースは Slackware を基盤としていました。その後、SUSE は YaST、さらに RPM パッケージ形式を採用して独自の道を進みました。この点は誤解されがちです。SUSE と openSUSE は RPM パッケージを使用しますが、Red Hat の派生製品ではありません。形式は受け継がれましたが、系譜は受け継がれませんでした。
Debian、1993 年: ソーシャル契約と 3 つのスイートによるリリースパイプライン
Ian Murdock は 1993 年 8 月 16 日、Slackware の 1 か月後に Debian を発表しました。発表した理由も同じでした。名前は、パートナーの Debra と本人の名前を組み合わせたものです。Debian Manifesto は 1994 年 1 月に続いて公開され、基本方針を定めました。このディストリビューションは企業ではなく、ボランティアが公開の場で保守するという方針です。
Debian はその方針を文書化しました。Debian Social Contract と DFSG (Debian free software guidelines) は 1997 年 7 月に採択され、DFSG は 1998 年に Open Source Definition の基礎になりました。1 つのディストリビューションに含められるものを定めるために書かれた文書が、業界全体のライセンス分類を定義することになったのです。これが sources.list にコンポーネントがある理由でもあります。main にはガイドラインを満たし、main の外部に何も必要としないソフトウェアが含まれます。contrib にはガイドラインを満たすものの、ビルドまたは実行に main の外部にあるものを必要とするソフトウェアが含まれます。non-free にはガイドラインを満たさないものが含まれます。Debian 12 では non-free-firmware が追加され、無線カードを搭載したラップトップでも、必要なファームウェアを探し回らずにインストールできるようになりました。
もう 1 つの継承物がパッケージ管理ツールです。dpkg は 1 つのパッケージをインストールし、何かが不足していると処理を拒否して dpkg: dependency problems prevent configuration of を表示します。1999 年の Debian 2.1 で標準になった APT (advanced package tool) は、ほかに取得する必要があるものと、その取得順序を解決する層です。すべての Debian 派生ディストリビューションにある apt コマンドは、この仕組みから派生しています。
リリースの仕組みには 3 つのスイートと 1 つのルールがあります。メンテナーは unstable にアップロードします。unstable のコードネームは恒久的に sid です。スクリプトは、アップロードの緊急度に応じて 2、5、または 10 日後に、パッケージを testing へ移行します。ただし、対象のすべてのアーキテクチャーでビルド済みかつ最新であり、testing 版にはないリリースクリティカルバグがなく、testing にすでにあるものを壊さずにインストールできることが条件です。その後 testing はフリーズし、リリースチームが残った問題を解消し、バグ一覧が十分に短くなった時点で stable がリリースされます。日付は基準になりません。Debian stable のバージョンが古く見えても安定して動作するのは、このためです。バージョン番号は通常フリーズ時点で止まり、セキュリティ修正だけがバックポートされます。ただし例外もあります。セキュリティチームは、2026 年 6 月の Tomcat 11 のように、新しい upstream リリースを提供することがあります。
ガバナンスも文書化されています。選挙で選ばれるプロジェクトリーダーと、拘束力のある一般決議があります。2014 年、この仕組みにより systemd が標準の init system に選ばれました。異論を持つ人々は Devuan をフォークし、2017 年に最初のリリースを行いました。Debian はこの切り替えを行った最初のディストリビューションでも最後のディストリビューションでもありませんでした。切り替えが繰り返された理由と、結果的に正しかった反対意見については、systemd が SysV init に取って代わった経緯で説明しています。主な派生ディストリビューションには Ubuntu、Raspberry Pi OS、Proxmox VE、Kali、Linux Mint があります。
Red Hat, 1994: RPM、その後の Fedora と RHEL への分岐
Marc Ewing は 1994 年の Halloween 頃に、最初の Red Hat Linux をリリースしました。Bob Young の会社は 1995 年にこれを買収し、2 人はソフトウェアそのものではなくサポートを販売する、最初の Linux ビジネスを築きました。Red Hat は 1999 年 8 月 11 日に株式を公開しました。IBM は 2019 年 7 月に約 34 billion dollars で同社の買収を完了したため、現在企業向けソフトウェアの認証対象となっているディストリビューションの大半は、それ以来 IBM の所有です。
長く残る技術的な貢献は、Erik Troan と Marc Ewing が 1995 年の Red Hat Linux 2.0 向けに開発した RPM（Red Hat package manager）です。RPM には依存関係が宣言されており、誰でも実行できるビルド手順である spec file から生成されます。後者の性質があったからこそ、Red Hat の企業向け製品を独立して再ビルドすることが、後に可能になりました。
2003 年の Red Hat Linux 9 が、元の系統における最後のリリースでした。同社はこれを 2 つに分けました。2003 年 11 月には高速なコミュニティリリースとして Fedora Core 1 を、2002 年に Advanced Server 2.1 として始まっていた製品は、更新の遅い有償版として RHEL（Red Hat Enterprise Linux）にしました。理由は明確です。新しいバージョンを試す場所と、銀行が 10 年間変更せずに運用するプラットフォームを、1 つの製品で兼ねることはできません。2 つの系統は連動しています。RHEL のメジャーバージョンは Fedora のリリースから分岐し、安定化された後に凍結されます。パッケージツールも同じスケジュールで移行し、2000 年代の yum から、2015 年に Fedora のデフォルトとなった dnf へ移行し、両方の基盤では rpm が使われました。
CentOS が無料の RHEL 再構築版ではなくなった理由
CentOS は 2004 年に、単純な目的で始まりました。Red Hat が公開したソースパッケージから商標を削除し、再構築して、成果物を無償で提供することです。CentOS は 10 年間にわたり、無料で使えるサーバー向けディストリビューションの標準的な選択肢になりました。Red Hat は 2014 年にこのプロジェクトを社内に取り込みました。
2020 年 12 月 8 日、Red Hat は CentOS Linux 8 を 2021 年 12 月 31 日に終了すると発表しました。これは、公開されていた予定より 8 年早い終了です。また、CentOS の名前は CentOS Stream として存続すると発表しました。Stream は再構築版ではありません。RHEL のマイナーリリースが作成される元となるブランチです。そのため、RHEL より後ではなく先行して動作します。数年間維持する予定のマシンでは、先行することは適切ではありません。Red Hat の有料顧客より先に変更を受け取ることになるためです。
2021 年には 2 つの再構築版が登場しました。Rocky Linux は、CentOS の共同創設者である Gregory Kurtzer によって開始されました。AlmaLinux は CloudLinux の資金提供を受けました。2023 年 6 月、Red Hat は一般公開する RHEL のソースを CentOS Stream、顧客ポータル、および UBI (Universal Base Image) コンテナとともに公開するソースイメージに限定しました。Rocky は引き続き、完全に同一の再構築版を目指しました。AlmaLinux は目標を ABI (application binary interface) 互換性に変更しました。これは、RHEL 向けに構築されたソフトウェアが実行できることを意味しますが、バグ一覧が 1 行単位で一致することは保証しません。同年の後半には、Oracle、SUSE、CIQ が OpenELA を設立し、共有ソースを公開しました。2003 年の分岐から 2023 年のソース変更までの経緯と、現在それぞれの再構築版が何を保証しているかについては、Red Hat、CentOS、Rocky、AlmaLinux の詳しい経緯で説明しています。
プロバイダーのイメージ一覧に CentOS と記載されている場合は、その名前が何を指すのかを確認してから構築を始めてください。
cat /etc/os-releaseNAME="CentOS Stream" は RHEL に先行するローリング開発ブランチです。NAME="AlmaLinux" または NAME="Rocky Linux" は、それに追従する再構築版で、10 年間の提供期間があります。
Ubuntu、2004年: カレンダー上の Debian unstable のスナップショット
Ubuntu 4.10 は Mark Shuttleworth の資金提供を受け、2004年10月20日にリリースされました。Debian との関係は、思い入れではなく機械的なものです。各サイクルは、Debian unstable から新しい Ubuntu リリースへパッケージをインポートして始まります。インポートはサイクル途中の Debian Import Freeze まで続き、それ以降は Ubuntu が独自の変更を加えます。Ubuntu の多くのパッケージは、Debian パッケージに差分を加えたものであり、changelog にその内容が記載されています。
もう一つの違いはリリース日程です。Debian は準備が整った時点でリリースします。Ubuntu は4月と10月にリリースし、バージョン番号には日付が使われます。24.04 は2024年4月にリリースされました。4月のリリースは2回ごとに LTS (long term support) となります。プロバイダーが特に断りなく Ubuntu と記載している場合、通常は LTS を指します。サーバーにどちらを使うべきかは、Ubuntu LTS と中間リリースの選択で詳しく扱います。LTS から次の LTS への移行には専用の手順があり、24.04 から 26.04 へのアップグレードで説明しています。
毎年、サーバー管理者が注意すべき点があります。Ubuntu のアーカイブはコンポーネントに分かれています。main は Canonical がサポート期間全体にわたって保守します。universe はコミュニティが保守するため、セキュリティ対応の範囲は異なります。apt install にはその違いが表示されません。次のコマンドで確認できます。
apt-cache policy nginxリポジトリ行が /main で終わっている場合、そのパッケージは Canonical のセキュリティチームが担当しています。/universe で終わっている場合は、コミュニティが担当しています。インターネットに公開するものについては、必ず確認してください。
Arch, 2002: ローリングリリースと部分アップグレードのコスト
Judd Vinet は 2002 年 3 月 11 日に Arch 0.1 をリリースしました。独自に作成したパッケージマネージャー pacman と、通常のシェルスクリプトであるビルドレシピが含まれていました。Arch にはバージョン付きのリリースがありません。インストールメディアは、同じローリングリポジトリの特定時点のスナップショットです。そのため、2019 年にインストールして毎週更新しているマシンも、今日インストールしたマシンも、同じ Arch を実行しています。AUR（Arch user repository）には、ユーザーが提供したビルドレシピが収録されています。これはレビュー済みのパッケージではなくレシピなので、実行する前に PKGBUILD を読むことも作業の一部です。
ローリングリリースには 1 つの障害パターンがあります。しかも、毎回その原因は自分で作ってしまうものです。pacman -Sy foo で単一のパッケージをインストールすると、パッケージデータベースが更新された後、ディスク上のライブラリより新しいライブラリにリンクされた新しいバイナリが 1 つだけインストールされます。その結果、プログラムは次のように失敗します。
error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directoryサポートされている操作は pacman -Syu です。これにより、すべてをまとめて更新します。プロジェクトは、特定のアップグレードの前に手動操作が必要であることを示すニュース項目も掲載しています。これを読まずにアップグレードを実行すると、マシンが起動しなくなることがあります。
そのため、放置する予定のサーバーには Arch は適していません。毎週更新するマシンなら問題ありません。1 年後に 1 回だけ更新するマシンでは、実行を見送っていたすべての手動操作を 1 回の更新で処理することになります。
Alpine: コンテナによって広く知られるようになった小規模ディストリビューション
Alpine は 2005 年頃に Gentoo からフォークされました。LEAF (Linux embedded appliance framework) の影響を受けています。LEAF 自体は Linux Router Project から派生しました。Natanael Copa は、デスクトップではなくアプライアンス向けに Alpine を開発しました。Alpine は一般的な userland の多くを置き換えています。GNU C library の代わりに musl、GNU core utilities の代わりに BusyBox、systemd の代わりに OpenRC を使用し、パッケージマネージャーには apk を使用します。2014 年の Alpine 3.0 は、musl へ移行したリリースです。
コンテナによって Alpine は普及しました。Alpine の base layer は Debian や Ubuntu の base より大幅に小さいため、2016 年以降、一般的な base image になりました。その結果、Alpine を直接インストールしたことがない人も、毎日 Alpine を実行するようになりました。
代償は、musl が glibc ではないことです。この違いにより、一見関係のない問題として現れるバグが発生します。glibc に対してリンクされたバイナリを Alpine で実行すると、すでに存在するファイルを探すよう促すメッセージが表示されます。
sh: ./myapp: not foundプログラム自体は存在します。しかし、ELF interpreter が存在しません。glibc の loader がないためです。もう 1 つの典型的な問題は Python です。manylinux 向けにビルドされた prebuilt wheel は musl にはインストールできません。そのため pip はソースからのコンパイルに切り替わり、compiler がインストールされていない場合に停止します。2021 年に導入された musllinux wheel standard により、その standard の wheel を公開しているプロジェクトではこの問題が解消されました。それ以外のプロジェクトには適用されません。
VPS の host operating system として Alpine を使用すると、インストール容量を小さくでき、更新も高速です。一方で、多くのドキュメントが前提としている手順から外れることになります。systemctl enable を実行するよう指示するガイドは、すべて rc-update add に読み替える必要があります。
不変世代: アトミック更新とイメージベースのサーバー
最新の系統では、パッケージリストではなく更新モデルが変わります。ostree ベースのシステムでは、/usr を読み取り専用に保ちます。更新は完全な新しいファイルシステムツリーとしてダウンロードされ、ステージングされた後、次回の再起動時に切り替えられます。以前のツリーはブートエントリとして残るため、更新に問題があっても、以前のツリーで再起動すれば元に戻せます。
Fedora Silverblue は 2018 年にこの方式をデスクトップへ導入し、Fedora CoreOS は Red Hat が 2018 年に CoreOS を買収した後、2019 年にサーバーへ導入しました。Flatcar Container Linux は、Container Linux が 2020 年に廃止された後も、元の Container Linux を引き継ぎました。openSUSE MicroOS は、btrfs スナップショットと transactional-update によって同じ方式を実現しています。2024 年、Red Hat は bootc を基盤とするイメージベースのモードを RHEL に追加しました。この方式では、オペレーティングシステムがコンテナイメージとして提供され、マシンは新しいタグを指定することで更新されます。Talos Linux はさらに徹底しており、シェルと SSH を完全に排除しています。マシンは API 経由で構成するため、ログイン先がありません。2007 年に初めてリリースされた NixOS は、別の方向から同じ方式に到達しています。システム全体を 1 つの宣言的な設定から構築し、以前の世代もブート可能な状態で保持します。
プロバイダーがこれらをワンクリックイメージとして提供していない可能性は高いです。これらは、管理者が SSH 経由でファイルを編集するのではなく、初回起動時に Ignition または cloud-init で構成することを前提としているためです。多数の同一マシンで運用すると効果を発揮します。これは、複数の Linux サーバーを同時に管理している場合に該当し、各マシンが他のマシンと確実に同じ状態であることが必要になります。
1 つのリリースはどのくらいの期間サポートされますか？
リリースポリシーは、ディストリビューションを利用する期間の大部分に関わる情報で、年数として公開されています。現在のサーバーリリース 5 件について、サポート期間は次のとおりです。
このグラフのデータ
[
{
"distro": "Alpine 3.x",
"standard_years": 2,
"extended_total_years": 2
},
{
"distro": "Debian 13",
"standard_years": 3,
"extended_total_years": 5
},
{
"distro": "Ubuntu 26.04 LTS",
"standard_years": 5,
"extended_total_years": 10
},
{
"distro": "AlmaLinux 10",
"standard_years": 10,
"extended_total_years": 10
},
{
"distro": "RHEL 10",
"standard_years": 10,
"extended_total_years": 14
}
]Alpine は各 3.x ブランチの main リポジトリを 2 年サポートします。community リポジトリは次の安定版リリースまでしかサポートしません。そのため、頻繁に再ビルドするコンテナイメージには、長期間変更せずに運用するホストより適しています。Debian のセキュリティチームは、安定版リリースを約 3 年サポートします。その後、LTS チームが一部のアーキテクチャを選定し、合計でおよそ 5 年までサポートします。Ubuntu LTS では、main のパッケージを 5 年利用できます。Ubuntu Pro サブスクリプションを契約すると 10 年まで延長できます。少数のマシンで個人利用する場合は無料です。Ubuntu Pro の有料 Legacy add on を追加すると、さらに 15 年まで延長できます。RHEL 10 は 10 年のサポートを公開しています。有料の Extended Life Cycle Premium add on を追加すると、最終マイナーリリースについて 14 年まで延長されます。更新可能な Long-Life 条件により、その後もサポートを延長できます。AlmaLinux 10 はサブスクリプションなしで RHEL と同じ 10 年の期間を提供します。これが rebuilds が存在する主な理由です。
Arch にこの表の行がないのは、ローリングリリースのディストリビューションにはサポート対象となるリリースがないためです。Arch で重要なのは、マシンを更新せずに放置できる期間です。この期間は週単位で考えます。
これらの数値の出典
各数値は、2026 年 10 月 10 日に確認した、ベンダーが公開しているポリシーに基づいています。日付を基準に計画する前に、必ず最新情報を確認してください。CentOS のユーザーが 2020 年 12 月に経験したように、ベンダーはポリシーを変更することがあります。
VPS のイメージ一覧がこのようになる理由
プロバイダーは、顧客が名前を指定して求め、ハイパーバイザー上で無人インストールできるイメージを提供します。そのため、ほぼすべての一覧は Ubuntu LTS と Debian stable から始まり、RHEL 向けに認証されたソフトウェアを使うユーザー向けに AlmaLinux または Rocky を加え、Alpine、Arch、Fedora はさらに下に配置します。VPS とは何か、イメージがどのようにディスクへ書き込まれるかを理解すると、この構成が明確になります。プロバイダーは、無人インストールに耐え、一般的な顧客がサーバーを使い続ける期間より長くサポートされるオペレーティングシステムを選んでいるのです。
この選択で決まるのは、パッケージマネージャーだけではありません。3 年後に実行するアップグレードの方式も決まり、方式はディストリビューションの系統によって大きく異なります。Debian と Ubuntu では、稼働中の環境でメジャーアップグレードを実行します。Red Hat 系では、leapp を通じて実行します。Arch にはバージョンがないため、アップグレードもありません。Alpine では /etc/apk/repositories を編集して apk upgrade --available を実行します。また、サードパーティーリポジトリを追加せずにインストールできるソフトウェア、実行中のソフトウェアに CVE (common vulnerabilities and exposures) の登録が発生したときにパッチを提供する主体、将来のソフトウェアが前提とする init システムと C ライブラリも、この選択によって決まります。
もう 1 つ、軽視しやすい影響があります。インターネット上の手順の多くは Debian 系または Red Hat 系を前提としているため、この 2 系統以外を選ぶと、サーバーを使い続ける間ずっと手順を読み替える必要があります。自分がサーバーを変更してもよい頻度にリリースポリシーが合う系統を選び、そのまま使い続けてください。上に載せたパッケージを変更するのは簡単です。その下のディストリビューションを変更するには、サーバーを再構築する必要があります。
FAQ
使用しているサーバーの Linux ディストリビューションファミリーを確認するにはどうすればよいですか？
cat /etc/os-release を実行します。ID フィールドはディストリビューションを示し、ID_LIKE フィールドはそのファミリーを示します。そのため、Ubuntu マシンでは ID_LIKE=debian、AlmaLinux マシンでは ID_LIKE="rhel centos fedora" と表示されます。パッケージマネージャーも判別材料になります。apt と dpkg は Debian ファミリー、dnf と rpm は Red Hat ファミリー、apk は Alpine、pacman は Arch を示します。
CentOS は今でも RHEL の無償版ですか？
いいえ。CentOS Linux 8 は、その名称で最後にリビルドされたバージョンであり、2021 年 12 月 31 日に終了しました。CentOS Linux 7 も 2024 年 6 月 30 日にサポート終了を迎えました。現在も続いている CentOS Stream は、RHEL のマイナーリリースがビルドされるブランチです。そのため、RHEL より後ではなく前に変更が取り込まれます。以前の役割を引き継いだ無償リビルドは AlmaLinux と Rocky Linux で、どちらも 10 年間のサポート期間があります。
Debian stable のバージョン番号が非常に古いのはなぜですか？
バージョン番号はほぼ固定されますが、修正は継続して提供されるためです。Debian では多くのパッケージについて、新しい upstream リリースを取り込むのではなく、リリース済みのバージョンへセキュリティパッチをバックポートします。そのため、2.4.57-2+deb13u1 と表示されるパッケージに、先週公開された修正が含まれていることもあります。upstream バージョンの後に付くサフィックスは Debian のリビジョンであり、apt changelog <package> にその内容が記載されます。バージョン番号だけで Debian サーバーのセキュリティを判断すると、必ず誤った結論になります。
VPS で Arch のような rolling release を実行すべきですか？
定期的に更新できる場合に限ります。rolling distribution では、すべてのマシンが最新のパッケージセットに収束することを前提としています。そのため、pacman -Sy foo で 1 つのパッケージだけを更新すると、ライブラリの不整合や cannot open shared object file のようなエラーが発生します。pacman -Syu を定期的に実行し、実行前に毎回プロジェクトのニュースページを確認すれば、システムは安定します。1 年間放置すると、最初のアップグレードが危険な作業になります。
immutable または atomic なディストリビューションでは、実際に何が変わりますか？
更新を適用するタイミングと、更新を元に戻す方法が変わります。/usr は read only でマウントされ、更新は新しいツリー全体としてステージングされます。再起動時に切り替わり、以前のツリーはロールバック用のブートエントリとして保持されます。これにより、マシンは完全に更新済みか、完全に未更新かのどちらかになり、中途半端な適用状態が発生しません。一方、ファイルを直接編集してソフトウェアをインストールする方法は使えなくなります。そのため、アプリケーションはコンテナまたは layered package に移行します。