プログラムがコンパイルされた形式で配布されないのはなぜですか？
しかし、彼らは次のような指示を与えます
cd downloaded_program
./configure
make install
これにより、必要なELFと、おそらくいくつかの.soファイルが作成されます。
Windowsアプリのように、ダウンロード用にZipファイルに入れてみませんか？ユーザーがコンパイルする必要がある理由はありますか？
要因を分析しましょう...
分析：
プラットフォームに依存する依存関係：開発者がアプリケーションのいくつかのアーキテクチャ固有のバリアントを作成および維持している環境で発生するいくつかの問題があります。
バリアントごとに異なるソースコードが必要— UNIXベースのオペレーティングシステムが異なると、同じタスクを実装するために異なる関数を使用する場合があります（たとえば、strchr（3）とindex（3）の比較）。同様に、バリアントごとに異なるヘッダーファイルを含める必要がある場合があります（たとえば、string.hとstrings.h）。
バリアントごとに異なるビルド手順が必要—プラットフォームごとにビルド手順は異なります。違いには、コンパイラの場所、コンパイラオプション、ライブラリなどの詳細が含まれる場合があります。
異なるバリアントのビルドは個別に保持する必要があります—単一のソースツリーがあるため、1つのアーキテクチャのオブジェクトモジュールと実行可能ファイルが他のアーキテクチャのオブジェクトモジュールと実行可能ファイルと混同されないように注意する必要があります。たとえば、リンクエディタは、SunOS-4用に構築されたオブジェクトモジュールを使用してIRIX-5実行可能ファイルを作成しようとしてはなりません。
すべてのオペレーティングシステムには独自のリンク管理スキームがあり、必要に応じてELF（実行可能リンク形式）ファイルを準備する必要があります。
コンパイラは、一連の 命令 であるビルドを生成します。アーキテクチャが異なると、命令セットが異なります（ 命令セットアーキテクチャの比較 ）。したがって、コンパイラの出力はアーキテクチャごとに異なります（例：x86、x86-64、ARM、ARM64、IBM Power ISA、PowerPC、Motorolaの6800、MOS T 6502、および- 他にもたくさん ）
[〜＃〜]セキュリティ[〜＃〜]：
- バイナリをダウンロードした場合、それが何をしているかを確認することはできませんが、ソースコードを監査して、システムで自己コンパイルされたバイナリを使用することができます。これにもかかわらず、ユーザーTechmagはコメントで良い点を指摘しました。コードを監査するには、コードを評価するための知識と有能なコーダーが必要であり、安全を保証するものではありません。
[〜＃〜] market [〜＃〜]：このセクションには多くの要素がありますが、再開します：
すべての会社がすべてのプラットフォームに到達することを目指しているわけではありません。それは、市場とプラットフォームの人気、および彼らが販売したいものに依存します。
フリーソフトウェアは、ソフトウェアをできるだけ広く利用できるようにする精神を持っていますが、ソフトウェアがすべてのプラットフォーム用に設計されていることを意味するのではなく、それをサポートするコミュニティーに依存します。
結論：
すべてのソフトウェアがすべてのプラットフォーム用に設計されているわけではありません。すべてのアーキテクチャとプラットフォームにバイナリを提供することは、すべてのプラットフォームでコンパイル、テスト、維持することを意味します。これはより多くの作業であり、場合によっては高すぎるため、ユーザーが独自のプラットフォームでコンパイルすると回避できます。また、ユーザーは自分が何を実行しているかに気づくでしょう。
* nixとotherの両方のようなさまざまなプラットフォームとソフトウェア環境があり、ソフトウェアを実行できる可能性があります。アプリケーション（またはアプリケーションで使用するライブラリ）は、「優れた」ソフトウェアアイテムがサポートするのと同じくらい多くのコンポーネントの組み合わせをサポートする唯一の現実的な方法です。もちろん、GPLなどのライセンスでは、ソースコードが利用可能-であることを必要とするため、ソフトウェアが適切に機能しない場合でも、通常はそれが可能です（ただし、何が間違っているのかを理解するのは難しい場合があります）ユーザーまたは一部のサードパーティが潜入し、作成者が存在しない/存在できない/存在しない場合でも修正するため）そうするために。
ソフトウェアをソースコードとして配布すると、ソフトウェアが主張するとおりに動作し、代わりにまたは同様に不快な動作を行わない独立した検証を作成できます。これは、作成者に対する信頼レベルを下げても、実際にそれを強化します！
まず、あなたの質問は欠陥のある前提に基づいています。プログラムはコンパイルされた形式で配布されます！
他のほとんどのLinuxディストリビューションと同様に、Ubuntuにソフトウェアをインストールする通常の方法は、より一般的にはほとんどのUnixバリアントに、パッケージをインストールすることです。 Ubuntuでは、ソフトウェアセンターまたは他のパッケージマネージャーを開き、使用可能なソフトウェアを参照します。インストールするパッケージを選択すると、バイナリ（パッケージにプログラムが含まれている場合）がダウンロードされ、マシンにインストールされます。
デフォルトでは、パッケージマネージャは、ディストリビューションのメンテナが作成したパッケージを提供します。パッケージのサードパーティのソースを見つけることもできます。 Ubuntuは、サードパーティがパッケージを提供するための標準化された方法として [〜＃〜] ppa [〜＃〜] を提供しています。
コンパイルされた形式で作成者からソフトウェアをダウンロードすることは、最後の手段です。ソフトウェアをパッケージ化するほど人気がない場合、またはパッケージ化されていない最新バージョンが絶対に必要な場合にのみ、これを行う必要があります。ほとんどの人はこれを行う必要はありません。
ソフトウェアが配布用にパッケージ化されていない場合、多くの場合、バイナリ形式ではなくソース形式で配布されます。これがLinuxの世界で頻繁に発生する主な理由は2つありますが、Windowsの世界ではまれです。 1つの理由は、Linux上のオープンソースプログラムの割合がはるかに高いことです。明らかに、プログラムのソースコードが利用できない場合、唯一の配布形式はバイナリです。もう1つの理由は、Linuxの世界がはるかに多様であることです。互換性のないライブラリバージョンのセットごとに異なるバイナリが必要です。これは、多くの場合、各ディストリビューションのバージョンごとに異なるバイナリを意味します。 Windowsは、各パッケージの作成者がプログラムと共に使用するライブラリを配布することでこれを「解決」します（結果：コンピュータは、ライブラリを使用するプログラムごとに1つずつ、各ライブラリの多くのコピーを保存します。ライブラリでバグが修正された場合、各プログラムは、アップデートを出荷する必要があります）、オペレーティングシステムの新しいバージョンを3年ごとにリリースするだけです。 Unixの方がはるかに多様性があり、よりタイムリーなバグ修正の習慣があり、異なるディストリビューション用に異なるバイナリを構築することにより、ライブラリのディストリビューションの問題を解決します。
Linuxは、1つ以上の特定のCPUプラットフォームで実行されます。 ELFファイル（またはその他の種類のraw実行可能ファイル）を配布した場合、一部のバージョンのLinuxはソフトウェアを実行できない可能性があります。ソフトウェアをできるだけ広く利用できるようにするという精神から、ソースコードを使用することをお勧めします。たとえば、LinuxはSparc、Intel、AMD、ARM、およびその他のタイプのプロセッサで動作します。
たとえば、ELFファイルが特にIntelプロセッサをターゲットにしている場合、他のタイプのハードウェアはソフトウェアを実行できませんでした。 ELFはプラットフォームに依存しませんが、ホストするコードはプラットフォームのマシンコードに準拠する必要があります。類似したパッケージ（たとえば、異なるプロセッサをサポートしている場合は_386および_586パッケージ）を含むディストリビューションの数に気づくでしょう。正しい操作を行うには、正しいELFファイルをインストールする必要があります。
同様に、異なる割り込み、リンカーなどを使用するカスタムLinuxバージョンをビルドする場合でも、コードをコンパイルするためのソースコードが必要です。ソースコードにプラットフォーム固有のビルド命令がない場合でも、各プラットフォーム異なるであり、別のシステムからELFを実行しない場合があります。
ソースとしての配布の最初の理由は確かにプラットフォームの多様性でした。 Linuxコミュニティは、その方法と、部分的に政治的な理由から、その方法論を継続しています。
例えばとは異なり。 Windows、Linuxはこれまで、ABI（アプリケーションバイナリインターフェース）を長期間にわたって安定させることを気にしていませんでした。実行可能フォーマット、ライブラリAPI、新しいハードウェアプラットフォームのサポートなどの面で革新を続ける可能性を維持することが、より重要であると考えられています。
商用オペレーティングシステムは、革新性に非常に厳格であるため、長期的なアプリケーション互換性を実現します。新しい機能/ソフトウェアインターフェイスは、常に古いものに追加で追加する必要があります。2つの項目を維持する必要があり、リリース後に何かを変更する場合の価格は非常に高いと考える必要があります。または、OSのソフトウェアを作成している人と一緒に、計画的なアプリケーションの陳腐化の事実を受け入れることができます（これはMSではなく、別のOSベンダーを示唆しています）。
（特定のLinuxディストリビューション以外の）バイナリのみの形式で配布されるソフトウェアの長期安定したプラットフォームを達成することは、Linuxコミュニティの一部の要素にとって望ましくないとさえ考えられます。どちらのプラットフォームも申し分なく使用しているので、それが良いことでも悪いことでもありません。それはそうです。
多くの場合（少なくとも* nixの世界では）、ソースコードはソフトウェアの最もポータブルなバージョンです。ソースがあることで、共有ソフトウェアが、それをサポートする可能性のあるすべてのプラットフォームで機能することが保証されます（多くの場合、POSIX準拠を意味します）。バイナリのリリースは、それらのバイナリがリリースされたプラットフォーム（ソフトウェアとハードウェアの両方）との互換性のみを保証します。
ウィンドウズでは、バイナリーがソフトウェアを共有するための最も便利でポータブルなフォームであることを考慮してください。ソースのコンパイルは通常のWindowsソフトウェア配布モデルの一部ではないため、Microsoftは長年にわたって、バイナリがOSの複数のバージョンで動作することを保証するために多大な努力を重ねてきました。 http://www.joelonsoftware.com/articles/ APIWar.html
ほとんどのLinuxソフトウェアはフリーソフトウェアです。バイナリではなく、いくつかのコンパイル命令を使用してソースコードを配布することにより、コンパイルする前にソースコードを確認または編集することができます。このようにして、プログラムが実際に何をするか、それが有害でないことを非常に確信できます。
私が個人的にプログラムの実行可能ファイルを取得するのが嫌いな主な理由は、最初にソースコードが実際に何をしているのかをチェックしたいからです（ほとんどの場合、他の人のコードを見るのが好きだからです）ほかにもいくつか知っていますまた、悪意のあるコードがないかソースコードをチェックします。
多くの答えは、ほとんどの場合、ソフトウェアあるがコンパイルされた形式で配布されると述べています。私はこの仮定に同意します。それにもかかわらず、ソフトウェアをそのソースによって配布する方が、コンパイルされた形式で配布するよりも優れている場合があります。
それが本当かどうかはわかりませんが、インターネットの最初は想像します。ネットワークの帯域幅が悪かったので、コンパイルされた形式よりもソースによってソフトウェアを配布する方が速い場合があります。コードソースはプレーンテキストのみなので、コンパイルされた形式のソフトウェアよりも小さいことがよくあります。したがって、コードソースを使用してソフトウェアを配布することは、ユーザーがコンパイルできる場合、それを共有するためのより良い方法のようです。
多くの異なるプラットフォームで実行される多くのUNIXシステムがあるという事実は別として、Windowsソフトウェアがこのディストリビューションモーダルから直面する問題を考えてみてください。実際には、Windowsの1つのバージョンと1つのプラットフォーム（PC ）。
PCだけを気にしても、32ビットと64ビットの2つのアーキテクチャがあります。お気づきのように、大部分のWindowsソフトウェアは単に64ビットを無視し、32ビットソフトウェアのみを出荷しているため、64ビットシステムを使用している場合は、最適ではないソフトウェアが残ります。次にライブラリがあります。あるソフトウェアベンダは、適切なライブラリがインストールされていない場合にプログラムを実行しようとすると、奇妙なエラーが発生することを望まないため、プログラムにライブラリを含めるだけです（すでにこのライブラリを持っている場合でも、ダウンロードを大きくします） ）。 2番目のプログラムも同じことを行いますが、ライブラリのバージョンが異なります。最良の場合、プログラムBには下位互換性のある新しいバージョンのライブラリが含まれているため、プログラムBをインストールするとafterプログラムAと動作しますが、逆の順序でインストールすると、古いバージョンのライブラリなので、プログラムBが壊れます。ただし、多くの場合、ライブラリベンダーはnot下位互換性のある変更を行い、ライブラリの名前を変更する必要がないため、2つのプログラムをどの順序でインストールしても、最初のプログラムは壊れます。これは「dll hell」と呼ばれます。
悲しいことに、これを回避するために、ほとんどのWindowsソフトウェアは、すべてのライブラリを共有ディレクトリではなく、独自のプログラムディレクトリで出荷しています。そのため、各プログラムは独自のプライベートライブラリをすべて持ち、互いに共有することはありません。そもそもdllのポイントであり、多くのRAMとディスク領域を使用し、すべての複製ライブラリをダウンロードする時間がかかります。
これがオープンソースソフトウェアがソース形式で公開されている理由であり、OSベンダーは依存関係の問題を整理し、ライブラリをどこにでも複製することなく、実際に必要なプリコンパイル済みバイナリのみをダウンロードするパッケージマネージャーを考案しています。これは、多くの異なるプラットフォームで実行される多くの異なるUNIXシステムがあるという事実にも対処します。