セキュリティホールが発見された際の対応、バグが見つかった場合の対応について考えてみたい。この観点からディストリを眺めるようになって、少しだけ以前とは見方が変わりました。
誰が、どの段階でセキュリティ等のフィックスをしているか、その点に注目して眺めてみます。
セキュリティ専門家は、よくこんなことを言っています。
「安定していてもセキュリティホールが放置されたものを使うより、多少不安定でもセキュリティ対策がなされたものを使わなければならない」
私はこの考え方に賛成です。
実際に常用OSを選ぶときは、もちろんこれに加えて安定・堅牢なものを選びます。
Sec-１．概念整理
Sec-２．（カテゴリー１）下流側でフィックスするケース
Sec-３．（カテゴリー２）上流側のフィックスを最大限利用するケース
Sec-４．（カテゴリー３）派生ディストリのケース
Sec-５．（カテゴリー４）その他
論点整理とか概念整理ってヤツ。このチャプターの入り口です。
まず使いたい言葉（概念）は上流側とか下流側、あるいは製作側と配布者側って言いましょうか。
ディストリビューションって Linux の独特の言葉です。BSD 系では使いませんでした。かって存在した（て、もう無くなったみたいな言い方だけど・・）UNIX の世界でも使わなかった言葉。日本語だと配布って意味らしい。
なので、ディストリビューションをやってる人達はディストリビューター（分配装置、流通業者とか）でしょうね。
この人達は製作側で作ったソフトを組み合わせて使える状態にして配布します。
カーネルはご存知リーナス氏が率いるグループが作ってる。kernel.org が公開してます。
コマンドやＣライブラリの大半は GNU のものが使われています。ここでは GNU は製作側です。
その他にも Libreoffice postfix apache 等、それぞれ製作者がいて公開しています。
これらを組み合わせ、一つのシステムにして使える状態にした上で配布されているのがディストリです。
こんな感じなので、もとのソフトウェアを作っている人達（GNU、Kernel.org、アパッチファウンデーションとか・・）を上流側または製作側と呼ぶことにします。多分、普通の呼び方です。
また、これらをとりまとめてディストリを配っている側を下流側とか配布者側と呼ぶことにします。これも一般的だと思います。
使う人達、つまり私達は「ユーザ」とか「ユーザ側」って呼んでおきます。
上流側で作られるソフトウェアは適宜、どんどんバージョンアップされたり、セキュリティ上の問題が出たらフィックスされたりしています。そのたびにメジャー番号、マイナー番号、フィックス番号なんかが変わっていきます。
1.1.3 ー＞ 1.2.0 ー＞ 1.2.1 ー＞ 1.2.2 etc etc
ディストリ側も、組み合わせるソフトの変化など諸々の状況のなかで配布物の番号を変えていきます。Debian 10.x とか Debian 11.x とか・・・・
（カテゴリー１）分類の１です。下流側、すなわちディストリ側でセキュリティやバグのフィックスをやる場合。
これは基本的に Debian-stable、Ubuntu 等。固定リリースモデルのイメージ。
イメージは下の図のような具合。
ネットでの情報ですが、Debian は公式メンテナが1000人ほどいるらしい！驚愕の数字です。他に非公式な協力者を合わせると、おそらく軽く数千人規模になると思われます。それだけのパワーがあるから、Debian-stable は非常に高い品質が確保されています。
Ubuntu も力のあるディストリでしっかりできているようです。やはり高品質。
結局のところ、このやり方は力のあるディストリに限定されると思います。
余談ですが、Debian-stable、Ubuntu-LTS、Slackware-stable に限定すると、比較的長くバイナリーコンパチが維持されるようです。多分、同一メジャー番号の間はコンパチビリティが維持されそうです。なので、野良ビルドを多用するには向いています。
上流側では常に改善やバグフィックス、セキュリティ対策をやっています。（程度の差こそあれ・・）
その上流側の成果を極力そのまま利用するやり方。つまり、常に最新のパッケージを入れていくやり方です。
代表選手は Arch と OpenSUSE(tw) でしょう。この２つはこのやり方でうまく行っていると思います。
なお「カテゴリー２は自分たちで更新を作っていない」などと主張しているわけではありません。ものによっては、自らセキュリティパッチを作って流す場合もあるでしょう。
ローリングリリース系は少しずつ絶え間なく変化し続けます。シェアードオブジェクトファイルも変わっていってしまいます。長くバイナリーコンパチを維持するわけでは無いです。このため野良ビルドを多用する使い方には向かないと思います。
カテゴリー１又は２の派生ディストリとしてやっていくやり方。セキュリティやバグフィックスへの対応は、派生元又は上流側がしっかりやっていれば、それを継承・利用するだけで済みます。
極めて要領の良いやりかた。１又は２の良い点を継承することができる。なので、大量のメンテナを抱えていなくても、それなりに良いものが出来そう。
Debian が、派生ディストリの支援を積極的にやるという極めてオープンソースらしい方針です。なので、どうしても Debian の子または孫（Ubuntu 派生）が、世の中に溢れてきます。
最近は Arch の派生も元気があります。
RedHat の派生は聞いたことがありません。クローンはあっても。RedHat は排他性を随分と強めています。
MXとかManjaroとかMintとかPopとかEndeavourとか、Distro 上位には派生ディストリが多く入っています。本家の Debian-stable や Ubuntu や Arch より人気です。
ほんと、要領良い！（けなしてません。褒めてます）
なお、ここで Debian と言っているのは原則として Debian-stable のことです。
その他となっていますが、一番注意すべきカテゴリーです。
それは、カテゴリー１と同じ道を進もうとしていて、進みきれていないディストリ（または進みきれていないと思われるディストリ）のことです。あるいはそれから派生したディストリです。
つまり、やや古めのパッケージを組み合わせてディストリを作っていても、Debian-stable や Ubuntu-LTS のような十分なメンテ（セキュリティフィックスやバグフィックス）ができないと思われるディストリ及びそれから派生したディストリです。
この場合セキュリティホールが見つかっても、大抵の場合次のバージョンアップまで放置されたままになります。Debian や Ubuntu が割合とすばやくパッチ入りの更新を流してくるのとは違います。
次のバージョンアップまで放置ってことは、長いと一年とか一年半くらいそのまま放置されます。
Debian や Ubuntu のような力が無いのに、古めのパッケージで独自に配布物を作っているディストリはセキュリティーやバグフィックスが突然発見されたとき、どう対応していくのでしょうか。これは疑問というより不安という意味です。
私はこのカテゴリのディストリは使わないことにしました。