著者 Linuxディストリビューションの歴史と3つの系統
Linuxディストリビューションの多くはSlackware、Debian、Red Hatの3系統に由来します。package managerやVPSイメージが何を引き継いだのか、系譜とともに整理します。
Linux ディストリビューションとは実際には何か
Linux ディストリビューションの歴史は、ある欠落から始まります。Linux kernel だけでは、人が利用できることは何もありません。kernel は起動してハードウェアを検出します。その後、停止します。誰かが userland を追加し、ソフトウェアのインストールと更新方法を決め、何年にもわたって修正を続ける必要があります。ディストリビューションとは、こうした選択の集合であり、その後も維持に関わり続ける人々の集団でもあります。
ディストリビューションは5つの要素で構成されます。そのうち1つでも変われば、ほとんどのバイナリが一致していても、別のディストリビューションになります。
- プロジェクトが選定したバージョンの kernel。プロジェクトが追加したパッチとドライバーを含みます。
- userland。C library、shell、init system、標準コマンドで構成されます。
- package format と、それをインストールするツール。
- release policy。変更できる内容、変更頻度、各リリースを修正する期間を定めます。
- 人々。package maintainer、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 日に Debian を発表しました。Slackware の 3 週間後であり、理由も同じでした。名称は、パートナーの Debra と自身の名前を組み合わせたものです。Debian Manifesto は 1994 年 1 月に続き、条件を定めました。このディストリビューションは企業ではなく、ボランティアによってオープンに保守されます。
Debian はその条件を文書化しました。Debian Social Contract と DFSG (Debian free software guidelines) は 1997 年 7 月に採択され、DFSG は 1998 年に Open Source Definition の基盤になりました。1 つのディストリビューションに何を含めるかを定めるために書かれた文書が、業界全体のライセンス分類を定義することになりました。これが、sources.list に components がある理由でもあります。main にはガイドラインを満たすソフトウェアが含まれ、contrib と non-free には満たさないソフトウェアが含まれます。また Debian 12 では non-free-firmware が追加され、無線カードを搭載したノート PC でも手探りでファイルを探さずにインストールできるようになりました。
もう 1 つの継承物がツール群です。dpkg は 1 つのパッケージをインストールし、不足しているものがあると停止して dpkg: dependency problems prevent configuration of を表示します。APT (advanced package tool) は 1999 年の Debian 2.1 でデフォルトになり、追加で取得すべきパッケージとその順序を解決する層です。すべての Debian 派生ディストリビューションにある apt コマンドは、この仕組みから派生しています。
リリースの仕組みには 3 つの suite と 1 つのルールがあります。メンテナーは unstable にアップロードします。unstable のコードネームは恒久的に sid です。リリース対象のアーキテクチャーでビルドでき、新たな release critical bug が発生しなければ、スクリプトが約 5 から 10 日後にパッケージを testing へ移行します。その後 testing は freeze され、release team が残った問題を解消し、バグ一覧が十分に短くなると stable がリリースされます。日付は基準になりません。これが、Debian stable が古く見えて安定して動作する理由です。freeze 時点でバージョン番号は固定されますが、security fix は引き続きそれらのバージョンへ backport されます。
ガバナンスも文書化されており、選挙で選ばれる project leader と、拘束力のある general resolution があります。2014 年、この仕組みによって systemd がデフォルトの init system に選ばれました。異議を唱えた人々は Devuan を fork し、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 は CentOS Stream と顧客ポータル以外での RHEL ソースの公開を停止しました。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 年頃、LEAF（Linux embedded appliance framework）のフォークとして始まりました。LEAF 自体は Linux Router Project から派生したものです。Natanael Copa は、デスクトップではなくアプライアンス向けに Alpine を開発しました。Alpine は一般的なユーザーランドの多くを置き換えています。GNU C library の代わりに musl、GNU core utilities の代わりに BusyBox、systemd の代わりに OpenRC を使用し、パッケージマネージャーには apk を採用しています。2014 年の Alpine 3.0 で musl へ移行しました。
コンテナによって Alpine は普及しました。Alpine のベースレイヤーは Debian や Ubuntu のベースより大幅に小さいため、2016 年以降、一般的なベースイメージになりました。そのため、Alpine を直接インストールしたことがない人も、毎日のように Alpine を実行するようになりました。
代償として、musl は glibc ではありません。この違いにより、一見無関係に見えるバグが発生します。glibc にリンクされたバイナリを Alpine で実行すると、すでに存在するファイルを探すよう促すメッセージが表示されて失敗します。
sh: ./myapp: not foundプログラム自体は存在します。ただし、glibc のローダーが存在しないため、ELF インタープリターがありません。Python でも同様の問題がよく発生します。manylinux 向けにビルドされた事前ビルド wheel は musl にはインストールできません。そのため pip はソースからのコンパイルに切り替えますが、コンパイラーがインストールされていないと停止します。2021 年に導入された musllinux wheel 標準により、その標準に対応する wheel を公開しているプロジェクトではこの問題が解消されました。それ以外のプロジェクトには適用されません。
VPS のホスト OS として 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 件について、サポート期間は次のとおりです。
The data behind this chart
[
{
"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": 13
}
]Alpine は各 3.x ブランチを 2 年サポートします。そのため、頻繁に再ビルドするコンテナイメージには、長期間変更しないホストより適しています。Debian のセキュリティチームは stable リリースを約 3 年サポートし、その後 LTS チームが主要なアーキテクチャを対象に、合計でおよそ 5 年までサポートします。Ubuntu LTS では main のパッケージを 5 年利用でき、Ubuntu Pro サブスクリプションを契約すると 10 年まで延長されます。少数のマシンで個人利用する場合は無料です。RHEL 10 のサポート期間は 10 年で、有料の extended life cycle support add on により 13 年まで延長できます。AlmaLinux 10 は、サブスクリプションなしで 10 年という RHEL と同じ期間を提供します。これが AlmaLinux の再ビルドが存在する主な理由です。
Arch にこの表の行がないのは、ローリングリリースのディストリビューションにはサポート対象となるリリースがないためです。Arch で重要なのは、マシンを更新せずに放置できる期間です。この期間は週単位で考えます。
これらの数値の出典
各数値は、ベンダーが公開している独自のポリシーを 2026 年 8 月に確認したものです。特定の日付を前提に計画する場合は、事前に再確認してください。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 は、その名称で最後に再構築されたバージョンであり、31 December 2021 に終了しました。CentOS Linux 7 は 30 June 2024 にサポート終了を迎えました。現在も存続している 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 は読み取り専用でマウントされ、更新は新しい完全なツリーとして準備されます。切り替えは再起動時に行われ、以前のツリーはロールバック用のブートエントリとして保持されます。これにより、マシンは完全に更新された状態か、まったく更新されていない状態のどちらかになり、中途半端な状態を避けられます。一方、ファイルを直接編集してソフトウェアをインストールする方法は使えなくなります。そのため、アプリケーションはコンテナまたはレイヤー化されたパッケージに移します。