Linuxディストリビューションの歴史と系譜

Linux ディストリビューションとは実際には何か

Linux ディストリビューションの歴史は、ある空白から始まります。Linux カーネルだけでは、人が利用できることは何もありません。カーネルは起動してハードウェアを検出します。そこで停止します。誰かが userland を追加し、ソフトウェアのインストールと更新の方法を決め、何年にもわたって修正を続ける必要があります。ディストリビューションとは、こうした選択の集合であり、その後も支え続ける人々の集まりでもあります。

ディストリビューションは 5 つの要素で構成されます。大半のバイナリが一致していても、次のいずれか 1 つを変えれば、別のディストリビューションになります。

• プロジェクトが選択したバージョンの kernel。そのプロジェクトが追加したパッチとドライバーを含みます。
• userland。C ライブラリ、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 が構成しました。カーネルと GNU（GNU's not Unix）ツールを、メニュー方式のインストーラーとともに 2 枚のフロッピーイメージへ収録しました。これを手作業で行うと 1 日かかるために作られました。

SLS（Softlanding Linux System）は Peter MacDonald により 1992 年にリリースされ、さらに 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 アーカイブです。依存関係の解決機能はありません。新しいパッケージが必要とするライブラリがすでにディスク上にあるかどうかを確認する仕組みもありません。この1つの判断が、その後のすべてを形作りました。ツールが依存関係を解決しないなら、リリースに含めるパッケージ群は構成上、一貫していなければなりません。そのため、リリースは少なく、保守的なものになります。Slackware 15.0 は 14.2 の6年後、2022 年 2 月に登場しました。

この系統は小規模です。SUSE の 1990 年代半ばの初期リリースは Slackware を基に構築されていました。その後、プロジェクトは YaST と、さらに後には RPM パッケージ形式を採用して独自の道を進みました。この最後の点は誤解されがちです。SUSE と openSUSE は RPM パッケージを使用しますが、Red Hat の派生ではありません。形式は広まりましたが、系譜は受け継がれませんでした。

Debian、1993年: ソーシャルコントラクトと3段階のスイート構成

Ian Murdock は、Slackware の3週間後にあたる 1993年8月16日に Debian を発表しました。発表の理由も Slackware と同じでした。名称は、パートナーの Debra と自身の名前を組み合わせたものです。1994年1月には Debian Manifesto が続き、方針が示されました。このディストリビューションは企業ではなく、ボランティアがオープンに保守するというものです。

Debian はその方針を文書化しました。Debian Social Contract と DFSG (Debian free software guidelines) は 1997年7月に採択され、DFSG は 1998年に Open Source Definition の基礎になりました。1つのディストリビューションに何を含めるかを定めるために書かれた文書が、業界全体のライセンス区分を定義することになったのです。これが、sources.list にコンポーネントがある理由でもあります。main にはガイドラインを満たすソフトウェアが含まれ、contrib と non-free には満たさないソフトウェアが含まれます。さらに Debian 12 では non-free-firmware が追加され、無線カードを搭載した laptop でも、必要なファームウェアを探し回らずにインストールできるようになりました。

ツール群ももう1つの継承資産です。dpkg は1つのパッケージをインストールしますが、不足しているものがあると処理を停止し、dpkg: dependency problems prevent configuration of を表示します。1999年の Debian 2.1 でデフォルトになった APT (advanced package tool) は、ほかに取得すべきものと、その順序を判断する層です。すべての Debian 派生ディストリビューションにある apt コマンドは、この仕組みから派生しています。

リリースの仕組みには3つのスイートと1つのルールがあります。メンテナーは unstable にパッケージをアップロードします。unstable のコードネームは恒久的に sid です。リリース対象のアーキテクチャーでビルドでき、新たな release critical bug が発生していなければ、スクリプトが約 5 から 10日後にパッケージを testing へ移行します。その後 testing は freeze され、リリースチームが残った問題を解消し、bug list が十分に短くなると stable がリリースされます。日付で決まるわけではありません。これが Debian stable が古く見えても安定して動作する理由です。freeze の時点でバージョン番号は止まりますが、security fix はそのバージョンへ backport され続けます。

ガバナンスも文書化されており、選挙で選ばれるプロジェクトリーダーと、拘束力のある general resolution があります。2014年、この仕組みによりデフォルトの init system として systemd が選ばれました。これに反対した人々は Devuan を fork し、2017年に最初のリリースを行いました。主な派生ディストリビューションには 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 月に約 340 億ドルで同社の買収を完了しました。そのため、現在ほとんどのエンタープライズソフトウェアが認証対象にしているディストリビューションは、それ以来 IBM の所有です。

長く残る技術的な貢献は RPM（Red Hat package manager）です。これは Erik Troan と Marc Ewing が 1995 年の Red Hat Linux 2.0 向けに開発しました。RPM には依存関係が宣言されており、誰でも実行できるビルド手順である spec ファイルから生成されます。この 2 つ目の特性があったからこそ、後に 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 向けに構築されたソフトウェアを実行できることを意味しますが、バグ一覧が行単位で一致することまでは保証しません。同年後半、Oracle、SUSE、CIQ は OpenELA を設立し、共有ソースを公開しました。

プロバイダーのイメージ一覧に CentOS と表示されている場合は、その名称がどの CentOS を指すのかを確認してから構築してください。

cat /etc/os-release

NAME="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回に1回が LTS (long term support) です。プロバイダーが修飾子なしで Ubuntu と記載している場合、通常は LTS を指します。サーバーに2種類のどちらを使うべきかは、Ubuntu LTS と interim release の選択で詳しく説明します。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

プログラム自体は存在します。ただし、ELF インタープリターが存在しません。glibc のローダーがないためです。もう1つの典型的な問題は Python です。manylinux 向けにビルドされた事前ビルド wheel は musl にはインストールできません。そのため、pip はソースからのコンパイルに切り替わりますが、コンパイラーがインストールされていない場合は途中で停止します。2021 年に導入された musllinux wheel 標準により、これらの wheel を公開するプロジェクトではこの問題が解消されました。それ以外のプロジェクトには適用されません。

VPS のホスト OS として Alpine を使用すると、インストールサイズを小さくでき、更新も高速です。一方で、多くのドキュメントが前提としている手順とは異なる環境になります。systemctl enable を実行するよう指示するガイドは、すべて rc-update add に読み替える必要があります。

不変世代: アトミック更新とイメージベースのサーバー

最新の系統は、パッケージ一覧ではなく更新モデルを変更します。ostree ベースのシステムでは、/usr が読み取り専用になります。更新では、完全な新しいファイルシステムツリーをダウンロードしてステージングし、次回の再起動時に切り替えます。以前のツリーはブートエントリとして残るため、更新に問題があっても、以前のツリーで再起動すれば元に戻せます。

Fedora Silverblue は 2018 年にこの方式をデスクトップへ導入し、Red Hat が 2018 年に CoreOS を買収した後、Fedora CoreOS は 2019 年にサーバーへ導入しました。Flatcar Container Linux は、2020 年に廃止された元の Container Linux を引き継ぎました。openSUSE MicroOS は、btrfs のスナップショットと transactional-update によって同じ方式を実現します。2024 年には Red Hat が RHEL にイメージベースのモードを追加しました。これは bootc を基盤とし、オペレーティングシステムをコンテナイメージとして提供し、新しいタグを参照するようにしてマシンを更新します。Talos Linux はさらに進み、shell と 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": 13
  }
]

Alpine は各 3.x ブランチを 2 年サポートします。そのため、頻繁に再ビルドするコンテナイメージには、長期間変更しないホストより適しています。Debian では、security team が stable リリースを約 3 年サポートし、その後 LTS team が主要アーキテクチャを引き継ぎ、合計でおよそ 5 年まで対応します。Ubuntu LTS では main のパッケージが 5 年提供され、Ubuntu Pro サブスクリプションにより 10 年まで延長されます。少数のマシンで個人利用する場合は無料です。RHEL 10 のサポート期間は 10 年で、有料の extended life cycle support add-on により 13 年まで延長できます。AlmaLinux 10 は、サブスクリプションなしで RHEL と同じ 10 年の期間を提供します。これが AlmaLinux の再ビルドが存在する主な理由です。

Arch は rolling distribution であり、サポート対象となるリリースがないため、この表には含めていません。Arch で重要なのは、マシンを未更新のままどれだけ長く放置できるかです。この期間は週単位で考えます。

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 のようなローリングリリースを使うべきですか？

定期的に更新できる場合に限ります。ローリングディストリビューションでは、すべてのマシンが現在のパッケージセットへ収束することを前提としています。そのため、pacman -Sy foo で 1 つのパッケージだけを更新すると、ライブラリの不整合が発生し、cannot open shared object file のようなエラーが表示されます。pacman -Syu を定期的に実行し、実行前に毎回プロジェクトのニュースページを確認すれば、システムは安定します。1 年間放置すると、最初のアップグレードがリスクの高い作業になります。

immutable または atomic ディストリビューションでは、実際に何が変わりますか？

更新が適用されるタイミングと、更新を元に戻す方法が変わります。/usr は読み取り専用でマウントされ、更新は完全な新しいツリーとして準備されます。再起動時に切り替えが行われ、以前のツリーはロールバック用のブートエントリとして保持されます。システム全体が更新済みか、まったく更新されていない状態のどちらかになり、更新途中の状態は発生しません。一方、ファイルをその場で編集してソフトウェアをインストールする方法は使えなくなります。そのため、アプリケーションはコンテナまたは layered package に移行します。