私はOpenBSDユーザーです。存在するOpenBSD FAQそれは言う:
OpenBSDは同期を維持するように設計された完全なシステムです。互いに独立してアップグレードできるカーネルとユーティリティではありません。
システムをアップグレードすると、カーネルと基本システムの両方が交換されます。それから行って更新してください。第三者パッケージ。もしソースコードからコンパイル、カーネルを再コンパイルして起動します。次に、メインシステムを再構築し、インストールされたパッケージを再構築します。すべてを最後に再構築してから数週間/月が経過したら、まずスナップショットをインストールしてそこから再構築します（最新のCVSブランチに従う場合）。
同期されていないカーネル、基本システム、および/またはサードパーティのパッケージは問題の潜在的な原因であり、公式メーリングリストから深刻な援助を受ける資格をある程度奪い取ることになります。
私はそれに満足しています。実際、これが私がOpenBSDを使用している理由の1つです。これにより、システムを一貫した単位にし、システムの精神的な概要を簡単に形成することができます。
Linuxではどのような姿ですか？私が知る限り、ほとんどのLinuxにはBSDと同じ意味の「基本システム」がなく、ディストリビューションプロバイダが組み立てたパッケージのコレクションがあります。その後、ローカル管理者はより多くのソフトウェアを追加するので、最初からあったソフトウェアと後で追加されたソフトウェアとの間の境界はせいぜいあいまいになります。
Linuxは（一般的に）カーネルとユーザー空間の組み合わせが強力ではありませんか？ 私が知る限り、カーネルは他のパッケージと同様に更新されたので、これが可能かどうかは少し混乱しています。これに加えて、一部はカスタムカーネル（OpenBSDでは推奨されません）をコンパイルし、ブートメニューにいくつかの異なるカーネルバージョンがリストされています。
Linuxシステムのさまざまなサブシステムが互いに独立して更新されても、互いに機能できることを誰か、または何が保証しますか？
私が尋ねる理由は、このサイトの他のユーザーが要求したからです。私Linuxシステムのカーネルを最新バージョンに置き換えることは「可能」ですか？ OpenBSD側ではそうは言えません。保証するシステムの損傷を防ぐために。
私は上記の「Linux」を「Linuxディストリビューション」、カーネル+ユーティリティの略語として使用します。
答え1
リヌス・トバルズはとても強いユーザー空間回帰を引き起こすカーネルの変更に関するコメント（質問」を参照）Linuxカーネル：ユーザースペースが壊れている「もっと学ぶ）。
ユーザ空間とカーネルの間のインタフェースは、システムコールによって提供されます。最新のカーネルはより多くのシステムコールを持つことができ、変更によって既存のアプリケーションが中断されない限り、既存のシステムコールを変更できます。システムコールインターフェイスにフラグパラメータがある場合、新しいカーネルは新しい機能を公開するために新しいビットフラグを使用することがよくあります。このようにして、カーネルは以前のアプリケーションの以前のバージョンとの互換性を維持します。
ユーザースペースを壊さずに既存のインターフェースを変更できない場合は、拡張機能を提供するために追加のシステムコールが追加されます。だからバージョンは3つになります。dupそして2つのバージョンumountシステムコール。
信頼性の高いユーザースペースを確保するための戦略は、カーネルの更新がユーザースペースアプリケーションにほとんど問題を引き起こさず、通常カーネルをアップグレードした後に問題が発生しない理由です。
ただし、同じAPIの信頼性は保証されません。コアインタフェースおよびその他の実装の詳細。システムファイルシステム（上記/sys）とプロセスファイルシステム（トップ/proc/）低レベルアプリケーションで使用されるランタイム構成、ハードウェア、ネットワーク、プロセスなどのカーネル実装の詳細を公開します。正当な理由から、これらのインタフェースはカーネルバージョン間で互換性のない方法で変更される可能性があります。変更は可能であれば、非互換性を最小限に抑えるよう努め続けます。ルールアプリケーションが問題を引き起こす可能性が最も低い方法でインターフェイスを使用する方法を理解します。低レベルではないアプリケーションでは、これらのインターフェイスを使用しないでください。影響も制限されます。
@petercordes変更が発生したかどうかを表示プロセスファイルシステムまたはシステムファイルシステムディストリビューションのinitスクリプトで使用されているアプリケーションを停止すると、問題が発生する可能性があります。
これは、ディストリビューションがカーネルを更新する方法（長期サポートまたはメインライン）によって多少異なり、ディストリビューションは通常更新されたツールを同時にリリースするため、比較的問題が少なくなります。
スティーブンキットアップグレードされたユーザースペースには最新バージョンのカーネルが必要な場合があります。この場合、システムは以前のカーネルから起動しない可能性があり、リリースノートでは該当する場合はこれについて言及します。
答え2
LinuxカーネルとLinuxディストリビューションのユーザースペース（歴史的にGNUプロジェクトによって開発されたユーザーツールが支配する）は緩く結合されています。これは部分的には設計によるものであり、部分的には必要性によるものです。
カーネルとデフォルトのユーザースペースが一緒に設計され維持されているBSDとは異なり、Linuxカーネルとそのユーザースペースは異なる人々によって開発され維持されています。だから、コミュニティが欲しいとしても、凝集力を維持するのは難しいでしょう。しかし、私はそうではないと思います。
@sebasthはまた、Linuxカーネルプロジェクトの主なポリシーの1つがユーザースペースを壊すことができないことを指摘しました。もちろん、これは緩い結合を強制するもう一つの要因です。
しかし、まだある程度の組み合わせがあります。最新のディストリビューションで実行されないほど古いLinuxカーネル。
答え3
私の理解はLinuxです。はいキー、他のすべては付随的です。一般的には、以下に関連付けられているため、インストールされている（多くの）パッケージとは別にカーネルをアップグレードできます。図書館カーネル自体ではなく。通常、これらの組み合わせはカーネルバージョンとハードウェアドライバ（GPUドライバなど）の間でのみ見られます。 一部ソフトウェアは特定のバージョンのカーネルとのみ互換性がありますが、それはそのプログラムの別の文書で指定する必要があります。
システムに2つのカーネルパッケージスイート（現在使用されているパッケージと以前にインストールされたパッケージ）をインストールするのが一般的です。アップグレード時に新しいバージョンが正しく実行されていることを確認した後、最も古いパッケージを削除すると、安全であることが知られている代替パッケージを引き続き使用できます。たとえば、Red Hat（およびそのような製品）はpackage-cleanup --oldkernels --count 2これを自動的に実行する必要があります。
答え4
ここにあるすべての良い主張に加えて、いくつかの便利な点を追加できます。
私たちはカーネルチームのポリシーを知っており、Linuxディストリビューションとしてカーネルソースコードをできるだけ純粋に保つよう努めています。つまり、脆弱性が発生したり、パッチが必要なときはいつでもカーネルチームに通知し、パッチを助けるように努めますが、最終的な決定はカーネルチームによって行われます。
いくつかのディストリビューションは他のディストリビューションよりも多くのパッチを追加しますが、アイデアはアップストリーム開発者からパッチを維持することです。明らかに、一部のプログラムには特別なカーネル構成、特に仮想化とサードパーティのドライバが必要です。通常、すべては特定のカーネルバージョンまたは少なくとも古すぎないバージョンで動作するように設計されています。したがって、以前のカーネルで実行しようとすると、正しく実行されない可能性があります。
注意すべき追加の要因は、すべてのLinuxディストリビューションには、すべてのソフトウェアがシステムと互換性があることを確認するメンテナンスチームがあることです。これが、ほぼすべてのディストリビューションに安定したバージョンと不安定なバージョンがある理由です。開発者は「不安定な」ソフトウェアを使用し、すべてのソフトウェアがテストされた場合は信頼できるとマークし、その後のみ一般ユーザーがパッケージをアップグレードできるため、要求された人が一般ユーザーである場合、ソフトウェアは90％安全であることを示します。ソフトウェアはよくテストされました。
したがって、誰が誰であるか、コミュニティが何であるか、そして何が共通のアプローチであるべきか、一緒に動作し、システムを損傷しないソフトウェアが必要です。これが、私たちが次のようないくつかの基準に従おうとする理由です。ファイルシステム階層標準。