非常に簡単に言えば、*nix の歴史の大部分において、他に選択肢はありませんでした。プログラムはソース tarball として配布され、それらを使用する唯一の方法は、ソースからコンパイルすることでした。したがって、それはメンタリティというよりも必要悪です。
とは言うものの、ハードウェア用に特別にコンパイルされるため、自分でコンパイルする非常に正当な理由があります。有効にするオプションと無効にするオプションを選択できるため、微調整された実行可能ファイルを好きなように仕上げることができます。 .ただし、これは明らかに専門家のユーザーにとってのみ意味のあることであり、動作中のマシンでメールを読んでもらいたいだけの人にとっては意味がありません.
現在、Linux の世界では、主要なディストリビューションはすべて、何年も前にこれから離れています。 Gentoo のようにこれを行うのが好きな人向けに特別に設計されたディストリビューションを使用していない限り、最近では自分で何かをコンパイルする必要はほとんどありません。ただし、ほとんどのディストリビューションでは、平均的なユーザーは何もコンパイルする必要はありません。これは、ディストリビューションのリポジトリに必要なもののほとんどすべてが存在し、コンパイルされているためです。
つまり、あなたが言うこの CIY の考え方は、本質的に消えてしまったのです。 UNIX の世界ではまだ生きていて、活躍しているかもしれません。私はそこでの経験がありませんが、Linux では、まともなリポジトリを備えた人気のあるディストリビューションを使用している場合、自分で何かをコンパイルする必要はほとんどありません。
エンド ユーザー、ディストリビューション メンテナー、コード サプライヤー/開発者/プロジェクト グループなど、その考え方にはいくつかの原因があり、そのすべてが完全に有効です。
オープンソースの側面
フリー ソフトウェアを使用していることを知って楽しんでいて、ソースからコンパイルすることを選択してそれを検証する人もいます。これは、Linux From Scratch project/howto/guide/book などの出番です。
最適化とオプションの側面
特定の CPU アーキテクチャ向けに特定の最適化を行ってコンパイルしたいですか?おそらく、必要な特定の機能を有効または無効にするためのコンパイル時オプション (またはそれを作成するためのパッチ) があります。この例としては、postfix にパッチを適用してクォータを管理できるようにしたり、Gentoo などのディストリビューションを使用して systemd を使用しないことを選択したり、ogg/theora/vorbis/whatever をサポートし、ライセンスの問題のために mp3 をサポートしないことを選択したりすることが考えられます。
CPU アーキテクチャの側面
あなたの職場では、ハイエンドの非 x86/amd64 マシンを使用していますか?必要な/必要なパッケージは、CPU アーキテクチャ用に事前にコンパイルされていない可能性があります。実行しているディストリビューションはなおさらです。確かに、この種のハードウェアを実行しているほとんどの場所は、IBM などからのサポートも受けており、勝手にインストールやコンパイルを行うことはありません。しかし、余剰セールで手に入れたり、PPC プロセッサを搭載した古い iMac を掘り出したりしたらどうでしょうか?
配信の側面
ディストリビューションの「ファミリ」 - つまり、Debian と Ubuntu、Mint など、および RedHat と CentOS、Whitebox、Fedora など - はすべて異なるパッケージ形式を使用します。また、各バージョンには異なるライブラリ バージョンなどが付属しています。単純な単一ファイルのシェル スクリプトでさえ、適切な Debian .deb ファイルを設定するには時間と労力がかかります。かゆみをかき消すためにソフトウェアを作成し、それを無料にして gitlab や自分の Web サーバーなどに投稿したい場合は、ソースの一般的な .tar.gz ファイルをビルドの手順と共に投稿しますか? Debian の 2 つのバージョン (安定版とテスト版、場合によっては旧安定版)、RPM としての Redhat と Fedora の複数のバージョン、Slackware 用の TGZ、Gentoo 用の ebuild プロファイルなどのバージョンをパッケージ化します。
@terdon が言うように、最近ではコンパイルの必要性はかなり少なくなりました。特にホーム ユーザーにとってはそうです。
以前、Unix の世界では、ソースのコンパイルに大きく依存していました。たとえば、Solaris、AIX、Ultrix、Digital Ultrix、および HP/UX システムを管理していたため、ベンダーによって保守されなくなったり、実装されたりすることがありました。の一般的なサービスは、Linux を含む他の Unix で一般的に使用されていたものよりもはるかに遅れていました。
現在でも、リポジトリにないあいまいまたは時代遅れのソフトウェアを取得するか、互換性のあるバイナリがないパッケージのより最近のバージョンを使用するか、または追加の機能を追加したい、またはまれに、パッチまたはモジュールを作成できる場合。
また、OS でサポートされなくなったフレームワークを持つ Debian や新しいバージョンの Debian に移植するためにシステムを再設計する際には、手作業でソフトウェアをコンパイルする必要がありました。
たとえば、以前は、プロトコルに対する Windows の変更をサポートするため、またはテレコムの世界でプロビジョニングするための特定のパッチをサポートするために、DHCP デーモンを手動でコンパイルする必要がありました。
Debian に (重大な) バグがあり、通常、対応する Debian/Ubuntu の .debs が存在しない一連の安定したバージョンがあったため、dev git リポジトリから自分でコンパイルした FreeRadius バージョンの debs をローカル リポジトリに保持しています。
言うまでもなく、自分で書いたものを実行/コンパイルしなければならないこともしばしばあります.
現在、依存関係をインストールすることは以前ほど難しくありません。一部のソフトウェアでは、一部の一般的な Linux ディストリビューション用に、コンパイルする依存関係に名前を付けるルール ファイルをカスタマイズし、依存関係のリストが組み込まれたパッケージ ファイルを作成するという重い作業を行っています。このようなパッケージをローカル リポジトリからインストールすることは、公式リポジトリから同じパッケージをインストールすることと大差ありません。