Почему программы не распространяются в скомпилированном формате?

Но они дают такие инструкции, как

cd downloaded_program
./configure
make install

Это создает необходимый ELF и, возможно, некоторые файлы .so.

Почему бы не поместить их в zip-файл для загрузки, как в приложениях Windows? Есть ли какая-то причина, почему они должны быть скомпилированы пользователем?

Давайте проанализируем факторы ...

Анализ :

ЗАВИСИМОСТЬ ОТ ПЛАТФОРМЫ : Есть некоторые проблемы, которые возникают в среде, где разработчики создают и поддерживают несколько зависящих от архитектуры вариантов приложения:

• Для разных вариантов требуется разный исходный код. Различные операционные системы на основе UNIX могут использовать разные функции для реализации одной и той же задачи (например, strchr (3) и index (3)). Аналогичным образом, может потребоваться включить разные заголовочные файлы для разных вариантов (например, string.h или strings.h).

• Для разных вариантов требуются разные процедуры сборки. Процедуры сборки для разных платформ различны. Различия могут включать такие особенности, как расположение компилятора, параметры компилятора и библиотеки.

• Сборки для разных вариантов должны храниться отдельно. Поскольку существует единственное дерево исходных текстов, необходимо позаботиться о том, чтобы объектные модули и исполняемые файлы для одной архитектуры не путались с таковыми для других архитектур. Например, редактор ссылок не должен пытаться создать исполняемый файл IRIX-5, используя объектный модуль, созданный для SunOS-4.

• Каждая операционная система имеет свою собственную схему управления связыванием и должна подготовить файл ELF (исполняемый и связывающий формат) так, как это необходимо.

• Компилятор сгенерирует сборку, представляющую собой последовательность инструкций , а разные архитектуры означают разные наборы инструкций ( Сравнение архитектур наборов инструкций ). Таким образом, выходные данные компилятора различны для каждой архитектуры (например: x86, x86-64, ARM, ARM64, IBM Power ISA, PowerPC, Motorola 6800, MOS T 6502 и многие другие )

БЕЗОПАСНОСТЬ :

• Если вы загружаете бинарный файл, вы не можете быть уверены, что он делает то, что говорит, но вы можете попытаться проверить исходный код и использовать самостоятельно скомпилированный бинарный файл в вашей системе. Несмотря на это, пользователь Techmag сделал хорошее замечание в своем комментарии: аудит кода требует знающих и компетентных кодеров для оценки кода и не является гарантией безопасности.

РЫНОК : В этом разделе много факторов, но я постараюсь возобновить его:

• Не каждая компания стремится достичь всех платформ, это зависит от рынка, популярности платформ и того, что они хотят продать.

• Свободное программное обеспечение имеет целью сделать программное обеспечение максимально доступным, но это не значит, что программное обеспечение разработано для каждой платформы, оно зависит от сообщества, которое его поддерживает.

Вывод :

Не каждое программное обеспечение предназначено для каждой платформы. Предоставление двоичных файлов для всех архитектур и платформ подразумевает его компиляцию, тестирование и поддержку для всех платформ. Это больше работы, которая иногда просто слишком дорога, и ее можно избежать, если пользователь скомпилирует ее на своей собственной платформе. Также пользователь будет в курсе того, что он выполняет.

Существует такое разнообразие платформ и программных сред, как * nix, так и других , что программное обеспечение может работать на нем, что позволяет вам создать приложение (или библиотеку для использования с приложениями) - единственный реалистичный способ поддержки как многие комбинации этих компонентов, как "хороший" программный элемент. Конечно, лицензии, такие как GPL, требуют, чтобы исходный код был доступен - поэтому, даже если программное обеспечение не работает должным образом, обычно это возможно (хотя может быть сложно понять, что не так и как это исправить) для пользователя или какой-либо третьей стороне, чтобы погрузиться и исправить это, даже если создатель не / не может / больше не существует, чтобы сделать это.

Распространение программного обеспечения в качестве исходного кода также позволяет проводить независимую проверку того, что программное обеспечение делает то, к чему оно претендует, и не делает что-то противное вместо или так же хорошо - что, несмотря на снижение уровня доверия, которое нужно иметь к создателю, фактически повышает его!

Во-первых, ваш вопрос основан на ошибочной предпосылке. Программы будут распределены в скомпилированный формат!

Обычный способ установки программного обеспечения в Ubuntu, как и в большинстве других дистрибутивов Linux, и, в более общем случае, в большинстве вариантов Unix, - это установка пакета. В Ubuntu вы открываете центр программного обеспечения или другой менеджер пакетов и просматриваете доступное программное обеспечение. Когда вы выбираете пакет для установки, двоичные файлы (если пакет содержит программу) загружаются и устанавливаются на ваш компьютер.

По умолчанию менеджер пакетов предлагает вам пакеты, созданные сопровождающими дистрибутива. Вы также можете найти сторонние источники пакетов; Ubuntu предлагает PPA как стандартизированный способ предоставления пакетов третьим лицам.

Загрузка программного обеспечения от автора в скомпилированном виде является последним средством. Это нужно делать только в том случае, если программное обеспечение недостаточно популярно для упаковки или если вам абсолютно необходима последняя версия, которая еще не была упакована. Большинству людей никогда не нужно этого делать.

Когда программное обеспечение не упаковано для распространения, оно часто распространяется в исходной, а не в двоичной форме. Есть две основные причины, почему это часто случается в мире Linux, но редко в мире Windows. Одна из причин заключается в том, что доля программ с открытым исходным кодом в Linux намного выше. Очевидно, что если исходный код программы недоступен, единственной формой распространения является двоичный файл. Другая причина в том, что мир Linux гораздо более разнообразен. Для каждого набора несовместимых версий библиотеки требуются разные двоичные файлы, что часто означает разные двоичные файлы для каждой версии каждого дистрибутива. Windows «решает» это, заставляя каждого автора пакета распространять библиотеки, которые они используют, вместе с программой (следствие: ваш компьютер хранит множество копий каждой библиотеки, по одной на программу, которая ее использует; если в библиотеке исправлена ​​ошибка, каждая программа, которая его использует, должна поставлять обновление) и выпускать новую версию операционной системы только каждые три года или около того. Unix обладает гораздо большим разнообразием и гораздо более своевременными привычками исправления ошибок, а также решает проблемы распространения библиотек, создавая различные двоичные файлы для разных дистрибутивов.

Linux работает не только на одной конкретной платформе процессора. Если вы распространяете файлы ELF (или любой другой вид необработанного исполняемого файла), есть вероятность, что некоторые версии Linux не смогут запустить программное обеспечение. В духе обеспечения максимально широкого доступа к программному обеспечению использование исходного кода является предпочтительным. Например, Linux работает на процессорах Sparc, Intel, AMD, ARM и других типов.

Если файл ELF предназначен, например, специально для процессоров Intel, то другие типы оборудования не смогут запустить программное обеспечение. ELF не зависит от платформы, но код, который он размещает, должен соответствовать машинному коду платформы. Вы заметите, что во многих дистрибутивах есть похожие пакеты (например, пакеты _386 и _586, когда он поддерживает разные процессоры) - вам нужно установить правильный файл ELF, чтобы получить правильную работу.

Точно так же, если я решу создать собственную версию Linux, которая использует различные прерывания, линкеры и т. Д., Мне все еще нужен исходный код для компиляции кода. Даже если исходный код не содержит инструкций по сборке для конкретной платформы, каждая платформа отличается и может не запускать ELF из другой системы.

Первоначальной причиной распространения как источника, безусловно, было разнообразие платформ; Сообщество Linux продолжило эту методологию как по этим, так и по новым, частично политическим причинам.

В отличие, например, от Windows, Linux исторически никогда не заботился о том, чтобы поддерживать какой-либо ABI (двоичный интерфейс приложения) стабильным в течение длительных периодов времени - возможность более инновационного подхода к таким аспектам, как исполняемые форматы, библиотечные API и поддержка новых аппаратных платформ, считалась / считается более важный.

Коммерческие операционные системы достигают долгосрочной совместимости приложений, будучи очень дисциплинированными в отношении инноваций; В дополнение к старому всегда необходимо добавлять новый интерфейс функции / программного обеспечения, требующий обслуживания двух вещей, и цена изменения чего-либо после выпуска должна считаться очень высокой. В качестве альтернативы вы можете принять факт запланированного устаревания приложений вместе с любым, кто пишет программное обеспечение для вашей ОС (это не намеки на MS, а на другого поставщика ОС).

Достижение долгосрочной стабильной платформы для программного обеспечения, распространяемого только в двоичной форме (за пределами данного дистрибутива Linux), было бы даже нежелательным для некоторых элементов сообщества Linux. Как непримиримый пользователь обеих платформ, я не говорю, хорошо это или плохо; это так, как есть.

Во многих случаях (по крайней мере, в мире * nix) исходный код является наиболее переносимой версией программного обеспечения. Наличие источника гарантирует, что совместно используемое программное обеспечение будет работать на любой платформе, которая может его поддерживать (что во многих случаях означает просто POSIX-совместимость). Выпуск двоичных файлов гарантирует только совместимость с платформами (как программными, так и аппаратными), для которых выпущены эти двоичные файлы.

Учтите, что в Windows двоичные файлы являются наиболее удобной и переносимой формой для совместного использования программного обеспечения. Поскольку компиляция исходного кода не является частью обычной модели распространения программного обеспечения для Windows, Microsoft за долгие годы приложила немало усилий, чтобы обеспечить работу двоичных файлов в разных версиях своих ОС: http://www.joelonsoftware.com/articles/APIWar.html

Большая часть программного обеспечения Linux является свободным программным обеспечением. Распространяя исходный код с некоторыми инструкциями по компиляции, а не с двоичными файлами, у вас есть возможность просмотреть или даже отредактировать исходный код перед его компиляцией. Таким образом, вы можете быть абсолютно уверены, что программа на самом деле делает и что она не вредна.

Основная причина, по которой мне не нравится просто получать исполняемый файл программы, заключается в том, что мне нравится сначала проверять, что на самом деле делает исходный код (в основном потому, что мне просто нравится смотреть на код других), но я знаю несколько других которые также проверяют исходный код на наличие вредоносного кода.

Много ответов сказали , что в большинстве случаев, программное обеспечение будут распределены в скомпилированный формат. Я согласен с этим предположением. Тем не менее, я вижу случай, когда распространять программное обеспечение по его источнику лучше, чем распространять его в скомпилированном формате.

Я не уверен, что это правда, но я предполагаю, что в начале Интернета, поскольку сеть работала плохо, иногда было проще распространять программное обеспечение по источнику, чем в скомпилированном формате. Поскольку источники кода представляют собой только простой текст, он часто меньше программного обеспечения в скомпилированном формате. Таким образом, распространение программного обеспечения с исходным кодом представляется лучшим способом его распространения при условии, что пользователи могут его скомпилировать.

Помимо того, что существует множество систем Unix, работающих на разных платформах, просто рассмотрим проблемы, с которыми сталкивается программное обеспечение Windows из-за этого модального дистрибутива, даже если им действительно нужно беспокоиться только об одной версии Windows и одной платформе (ПК). ).

Даже при наличии только ПК, есть две архитектуры: 32-битная и 64-битная. Если вы заметили, подавляющее большинство программного обеспечения для Windows просто игнорирует 64-битную версию и поставляет только 32-битную версию, оставляя вам неоптимальное программное обеспечение, если у вас 64-битная система. Тогда есть библиотеки. Один поставщик программного обеспечения не хочет, чтобы вы пытались запустить странную ошибку, пытаясь запустить их программу, если у вас не установлена ​​необходимая библиотека, поэтому они просто включают библиотеку в свою программу (что делает загрузку больше, даже если у вас уже есть эта библиотека). ). Вторая программа делает то же самое, но с другой версией библиотеки. В лучшем случае программа B содержит более новую версию библиотеки с обратной совместимостью, поэтому, если вы устанавливаете программу B послепрограмма A, все работает, но установка их в обратном порядке оставляет вас со старой версией библиотеки, и поэтому программа B ломается. Однако часто поставщик библиотеки вносит изменения, не совместимые с предыдущими версиями, и не меняет название библиотеки, поэтому независимо от того, в каком порядке вы устанавливаете две программы, первая ломается. Это называется "длл ад".

К сожалению, чтобы избежать этого, большинство программ для Windows прибегают к отправке всех своих библиотек в свои собственные программные каталоги, а не в общие каталоги, поэтому у каждой программы есть все свои частные библиотеки, и они никогда не будут делиться друг с другом, что наносит ущерб всей Во-первых, вы можете использовать гораздо больше оперативной памяти и места на диске, а также время загрузки всех дубликатов библиотек.

Вот почему программное обеспечение с открытым исходным кодом публикуется в исходной форме, и поставщики ОС придумали менеджеры пакетов, которые решают проблемы с зависимостями и загружают только те скомпилированные двоичные файлы, которые вам действительно нужны, без дублирования библиотек повсюду. Это также связано с тем фактом, что существует множество различных систем Unix, работающих на разных платформах.