回答:
私の考えでは、独自のLinuxカーネルをコンパイルすることで本当に得られる唯一の利点は次のとおりです。
独自のLinuxカーネルをコンパイルする方法を学びます。
速度/メモリ/ xxxを増やすために必要なことではありません。それがあなたがあなたの開発であなたがいると感じる段階であるならば、それはする価値のあることです。この「オープンソース」の全体が何であるか、カーネルのさまざまな部分がどのように、どのようなものであるかについてより深く理解したい場合は、試してみてください。起動時間を3秒短縮するだけの場合は、どういう意味ですか... ssdを購入してください。もし興味があり、学びたいなら、あなた自身のカーネルをコンパイルすることは素晴らしいアイデアであり、おそらくそれから多くを得るでしょう。
そうは言っても、独自のカーネルをコンパイルすることが適切な場合、いくつかの特定の理由があります（他の回答で数人が指摘しているように）。一般的に、これらは特定の結果のためにあなたが持っている特定のニーズから生じます。例えば：
問題は、すべてがすでにあるべき方法で動作しているときに、独自のカーネルをコンパイルすることには本質的な利点があると考えていることにあり、私はそうは思わない。必要のないものを無効にし、調整可能なものを微調整するために無数の時間を費やすことができますが、実際には、Linuxカーネルはほとんどのユーザーの状況に対して（ディストリビューションによって）十分に調整されています。
ほとんどのユーザーは、独自のカーネルをコンパイルする必要はありません。ディストリビューションがこの作業を行っています。通常、ディストリビューションには、ディストリビューションの動作の特定の部分、デバイスドライバーのバックポート、新しい未リリースバージョンのカーネルまたはユーザーが開発した機能のいずれかと統合するためのパッチのセットが含まれます。
独自のカーネルをコンパイルする場合、いくつかのオプションがあり、公式のLinus Torvaldsカーネルをコンパイルできます。これには、ディストリビューションによって追加されたパッチまたはカスタマイズ（良いまたは悪い）は含まれません。ディストリビューション再構築ツールを使用して、独自のカーネルを構築します。
カーネルを再構築する理由は次のとおりです。
多くの開発者は、特別なデバイスドライバーを必要とする、または不要な機能を削除したい組み込みシステムまたはセットトップボックス用のカーネルのカスタムバージョンを作成するためにも使用します。
bisectバグが導入された場所を見つけるためにingを追加する必要があります...
カーネルを自分でコンパイルすると、コンピューターに関連する部分のみを含めることができます。これにより、特にブート時に、コンピューターのサイズが小さくなり、潜在的に高速になります。汎用カーネルには、できるだけ多くのハードウェアのサポートを含める必要があります。起動時にコンピューターに接続されているハードウェアを検出し、適切なモジュールをロードしますが、すべてを実行するには時間がかかり、コードをカーネルに直接ベイクするのではなく、動的モジュールをロードする必要があります。コンピューターにCPUが1つしかない場合にカーネルが400種類のCPUをサポートする必要はありません。また、Bluetoothマウスを持たない場合はそれをサポートすることもできます。
ここで受け入れられた答えは、「速度/メモリ/ xxxを増やすために必要なことではない」とは信じられません。
これは完全に間違っています。カーネルを定期的にカスタムビルドして、不要なコードを削除するとともに、主にハードウェアに関連するパフォーマンス強化コードを含めます。たとえば、いくつかの古いハードウェアを実行し、このビルトインを備えたいくつかの古いMoBoでHPT36xチップセットサポートなどのめったに有効にされていないカーネルドライバーを有効にすることで、パフォーマンスの向上を引き出すことができます。
別の例として、SlackwareでのBIG SMPがデフォルトであり、たとえば、Dell 2800では、かなりのフットプリントを消費してGFSD（カーネルモジュールとしてではない）などを実行します。必要ありません。同様に、NFSDやその他のキャッチオールで、すべてのメンタリティを満足させることができます。Linuxをボックスに入れて実行しようとしている場合は問題ありませんが、「速度/メモリ/ xxx何でも」を気にする場合は、これらが重要で動作します。
私のプロダクションボックスはすべてカスタムカーネルです。Dellシリーズ（2800、2850、2900など）ハードウェアなどの一般的なハードウェアを使用している場合、カーネルの.configファイルを各ボックスにコピーし、カーネルをコンパイルしてインストールするだけです。
独自のカーネルをコンパイルすることでメリットが得られる状況を次に示します。
モジュールのロードを無効にしたカーネルは、より安全です。これには、モジュールとしてコンパイルするのではなく、必要なことがわかっているモジュールを選択し、カーネルの一部として含める必要があります。
/ dev / kmemのサポートを無効にするか、適切なコンパイラオプションでサポートを無効にすることは、セキュリティにとって良いことです。現在、ほとんどのディストリビューションがこれをデフォルトで実行していると思います。
可能であればinitrdを使用しないことを好みます。起動するハードウェアに合わせてカーネルをカスタマイズすると、initrdが不要になります。
カーネルの新しいバージョンに必要な機能が搭載されている場合もありますが、今日では非常にまれです。Debianを初めて使い始めたときは、2.4カーネルを使用していましたが、udevサポートには2.6カーネルが必要でした。
不要なネットワークプロトコル/オプションを無効にすると、TCP / IPのパフォーマンスが向上します。
不要なオプションを無効にすると、カーネルのメモリフットプリントが低下します。これは、低RAM環境で重要です。256MB RAMシステムをルーターとして使用している場合、これが役立ちます。
/ devにあるすべての「tty」デバイスが、通常シリアルまたはssh経由でのみログインするシステムでは迷惑です。
独自のカーネルをコンパイルすることで、既存のドライバーにPCI / USBデバイスIDを提供するなど、新しいデバイスが動作する可能性のある単純なものであるかどうかにかかわらず、カーネル開発プロセスに参加できます。カーネル開発。
また、ハードウェアで開発カーネルをテストし、リグレッションに気付いた場合にフィードバックを提供することもできます。これは、ハードウェアの珍しい部分がある場合に、特にあなたや他の人に役立ちます。ディストリビューションカーネルを待つ場合、問題レポートからの修正が新しいディストリビューションカーネルリリースにフィルターされるまでに時間がかかる場合があります。
また、個人的には、自分のカーネルをコンパイルして、所有しているハードウェアのみのサポートを含めるようにしています。ディストリビューションカーネルを実行しての出力を見ると、lsmod(8)持っていないハードウェア用にロードされた多くのモジュールが表示されます。これにより、モジュールリスト、/ proc、/ sys、およびログが汚染され、何かを検索しているときにノイズの中に隠れてしまう可能性があります。また、これらのモジュールが診断しようとしている問題に寄与していないことを100％確信することもできません。
2番目のgabe。の回答（コメントが長すぎるため、回答として投稿しています）。
高度に特殊化された目的（組み込みマシン、厳密なセキュリティプロファイリングなど）を持たない限り、自分のカーネルをコンパイルすることは、それがどのように行われるかを確認する以外に実用的な利点はないと思います。オプションを系統的にレビューすることにより、システムがどのように相互作用してシステムを構築するかを確認することは、システムがどのように機能するかを理解する素晴らしい方法です。達成しようとしているタスクの目的を持たないように見えるコンポーネントを削除しようとすると、驚くべきことがわかります。
ただし、ウサギの穴を飛び降りるのは間違いなく爽快です。あなたが考えていたよりも多くの夜と週末を吸い戻すでしょう！
このスレッドは古くなっていますが、質問がされたときと同じように今日でも有効です！
答えは次のとおりです。ニーズと要件に応じて、選択したLinuxカーネルをコンパイルします。
多くのシナリオが有効です：
あなたはエンジニアであり、システムのパフォーマンスとセキュリティの要件/要求を満たすためにビルドを必要とし、指定された基準を満たすために再コンパイルします。
あなたは普通のユーザーであり、できる限り長く使い続けたい古いシステムを持っている場合、コンポーネントを追加/削除するために再コンパイルして古いシステムを最適化したままにします。
あなたは、最新の最速のハードウェアを使用している通常のユーザーであり、十分なメモリ/ RAMを搭載しています。再コンパイルする必要はありませんが、システムについてもう少し学習することに興味があるなら、まだできます。
MicrosoftやMacの日常ユーザーのようになりたいだけで、再コンパイルせずに、上流のディストリビューションからの更新をそのまま使用します。
シナリオを継続してください:-)
Mac / Windowsユーザーとは異なり、Linuxが提供するのは選択肢です。簡単にするか、要件に合わせてシステムを最適化するかの選択。
ほとんどの用途では、汎用カーネルは事実上すべてのハードウェアに適しています。また、通常、ディストリビューション固有のパッチが含まれているため、独自のカーネルをコンパイルすると問題が発生する可能性があります。
独自のカーネルをコンパイルする理由は次のとおりです。
ソースベースのディストリビューションを使用していなかった場合、カーネルをコンパイルしませんでした。
カスタムカーネルをコンパイルするこの理由に誰も言及していないことに驚いています。
別のC / c ++コンパイラを使用するためです。GCCは、Linuxカーネルのコンパイルに適しています。しかし、非常に優れたコンパイラーがあります！GCCの最適化は、IntelのC / C ++コンパイラに少し遅れています。また、Intelは、パフォーマンスプリミティブライブラリとvtuneツールを提供しています。どちらも、高性能のLinuxカーネルを作成するために不可欠です。これまでのところ、GCCとG ++でしか取得できません。実際には、結果はコンパイラによって制限されます。そのため、Intelコンパイラとパフォーマンスライブラリを使用します。1.5GBのダウンロードでは少し大きめですが、優れたコンパイラに何が含まれているかが少しわかります。
インテルのC / C ++コンパイラは、非営利目的で無料で使用できます。しかし、IntelのWebサイトを検索する非商用ライセンスのIntel c ++コンパイラダウンロードページをGoogleで検索する方が簡単です。私は通常、GCC / G ++を使用しません。そして、プログラマーである必要はありません。環境を設定し、makeファイルの2行を変更してIntelのコンパイラを指すようにします。
その後、あなたはいくつかの深刻な速度を得ることができます！
What are the pros and cons of compiling your own kernel?Cons = not not easy、多くの状況では付加価値がないことを尋ねる方が良いでしょう。長所=セキュリティ、パフォーマンス、あなたが何をしているのかを知っている場合、たとえば、Linuxを使用してハードウェアの一部を動作させ、ネットワークおよびグラフィック機能を備えたNASデバイス。