LTSディストリビューションを使用したバニラカーネルの実行

しない限り、リスクはあまりありません非常にディストリビューションで使用されている最新バージョンよりも、それにもかかわらず明確な問題はありません。最大の問題はカーネル - >ユーザースペースにもかかわらずABI安定していると仮定されますが、理論的には限界点に達することができます。 Debian 2.0のコピーを見つけて、その上に3.17カーネルをビルドしてビルドすると（おそらく以前のgcc / libcのためではないでしょう）、それでもうまく機能しても驚くことはありません。

ネイティブCライブラリを含む一部のソフトウェアは、カーネルソースコードのヘッダファイルを使用してコンパイルされます。また、可能バージョンが大きく異なる場合、問題が発生する可能性があります。 Cライブラリが基礎なので、問題があればすぐに気付くことができます。¹ 「ほとんど」とは、3.4と3.16の違いを意味するものではありません。現在のディストリビューションで3.xカーネルを実行したことがある場合は、問題なく3.xカーネルを実行できます。このディストリビューションは、カーネルをアップグレードするときにCライブラリを置き換えません。

簡単に言えば、ディストリビューションでは常にソースバージョンを使用することをお勧めしますが、実際には問題ではありません。ストックカーネルを構築しても何らかの理由で動作しない場合は、設定が間違っています。、ディストリビューションで追加した小さな調整が不足しているわけではありません。私はいつもカスタムカーネルを実行するようです（最初はそうするつもりはなかったにもかかわらず）。そして、数十台のコンピュータで10年以上ストックソースを使用することに関連した問題が発生したことはありません。

^{1. 構成エラーのために単に機能が不足しているカーネルとは異なり、本当に壊れたカーネルを見た唯一のケースは、人為的なツールチェーンを使用して別のプラットフォームでクロスコンパイルされたときでした (つまり、このカーネルを使用しない) マシン) をターゲットライブラリで）。ここで「壊れた」とは、ユーザースペースに関連しています。カーネルは起動して動作しますが、他のデフォルトのユーザースペースツールはログイン後すぐに失敗します。これは必ずしも危険ではありません。この種のエラーは、分割エラーなどのエラーである可能性がほとんど確実です。悪いことは起こらず、あなたがやりたかったことができなかっただけです。コア自体は狂気ではなく、適切に協力しないだけです（良いか悪いかすべてが起こる可能性が低くなります）。}