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

32

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

cd downloaded_program
./configure
make install

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

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

Китти
источник
18
Вот как распространяется исходный код . вы пометили это Ubuntu - вы пробовали aptматериал?
mikeserv
11
Ubuntu: 40.000 наиболее распространенных программ: $ sudo apt-get install [name]. Более редкое программное обеспечение: некоторые должны быть собраны из исходного кода с помощью {cmake .. && make, ./configure && make, waf, scons и т. Д. ~ 10 опций сборки}.
Кнуд Ларсен
6
У вас есть три версии Windows © и ~ 100 версий "Linux OS". Невозможно поддерживать и хранить более (40000) наиболее распространенных программ.
Кнуд Ларсен
35
этот вопрос просто неправильный. большая часть программного обеспечения распространяется в двоичном формате, как правило , в .rpmили .debили .tgzпакетах. Источник также распространяется для тех, кто хочет скомпилировать его самостоятельно, изучить или модифицировать, или упаковать его в один или несколько дистрибутивов. Никто не использует .zipдля распространения двоичных файлов в Linux, потому что .zip-файлы не поддерживают важную информацию, такую ​​как пользователь, группа и разрешения для файлов, которые они содержат.
cas
2
Мне еще нужно собрать любую Linux-программу, которую я хотел запустить. Исполняемые файлы всегда были доступны ... до сих пор.
user2338816

Ответы:

34

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

Анализ :

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

  • Для разных вариантов требуется разный исходный код. Различные операционные системы на основе 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 сделал хорошее замечание в своем комментарии: аудит кода требует знающих и компетентных кодеров для оценки кода и не является гарантией безопасности.

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

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

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

Вывод :

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

Факундо Виктор
источник
1
Я думаю, что этот ответ был бы улучшен, если бы он был немного более четким о различиях моделей процессоров - и как ~ 10 лет назад каждый вариант Unix в основном имел свои собственные. Linux не был таким распространенным влиянием, как сегодня.
Sobrique
@Sobrique: Или даже упомянуть о различиях моделей процессоров как таковых - 10 лет назад было более двух типов, которые мы имеем сегодня, и Linux работал почти на всех из них (я сам запускал Linux на PowerPC). Это все еще частично актуально сегодня с x86, AMD64 (иначе известный как x86-64) и ARM. MIPS до сих пор довольно популярен среди людей, которые могут производить свои собственные чипы, потому что к настоящему моменту он совершенно не защищен патентом.
Slebetman
Извините за задержку! Спасибо вам обоим! Я добавил несколько ссылок на архитектуры процессоров, а также добавил ссылку на список сравнения. Я не хочу, чтобы ответ был таким большим. Но да, это очень актуально!
Факундо Виктор
1
Комментарий безопасности подразумевает, что читатель / установщик знает, как читать и понимать код. Учитывая, что уязвимость от снарядов выжила десятилетиями, не будучи замеченной, я бы с уважением предположил, что это несколько ложное убеждение. Он позволяет компетентным и компетентным кодировщикам оценивать код, да, но это не столько реальное средство защиты, сколько рекламируется. Это может на самом деле иметь противоположный эффект. В наши дни хакеры, финансируемые государством и организованной преступностью, скорее всего, вносят код для всего поместья библиотек / проектов с открытым исходным кодом в надежде посадить очередное открытие "
Шеллшок"
Вы правы! Я изменил ответ для отражения этого. Я старался не терять акцента на основной цели ответа. Спасибо Techmag!
Факундо Виктор
10

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

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

SlySven
источник
8

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

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

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

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

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

Жиль "ТАК - перестань быть злым"
источник
5

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

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

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

phyrfox
источник
Именно поэтому вы, вероятно, будете запускать 32-битный Firefox точно так же, как и многие другие программы в «64-битной» операционной системе Windows, тогда как 64-битная Linux обычно запускает 64-битное приложение.
mchid
5

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

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

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

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

rackandboneman
источник
4

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

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

zje
источник
5
Windows также зависит от базовой архитектуры. Приложения Windows с поддержкой ARM не работают на обычных ноутбуках / настольных компьютерах и т. Д. Это основная причина, по которой Linux имеет гораздо лучшую аппаратную поддержку - потому что код написан для компиляции на любой платформе, которая имеет нормальную реализацию Linux, в то время как Windows зависит от известных типов присутствующего оборудования.
phyrfox
Если вы собираете Windows / x86, то вы покрываете 95% бинарной совместимости. Это очень хорошо. В то время как Linux / x86 становится все более распространенным, мы пришли из мира, где у вас было множество громких имен с их собственной специальной архитектурой процессора и вариантом Unix - который не был двоично-совместимым.
Sobrique
@Sobrique Откуда ты взял этот показатель 95%? В прошлый раз, когда я смотрел, было 4 процессора ARM на каждый 1 x86. Это было несколько лет назад, до того, как все начали использовать смартфоны с процессорами ARM. Так что, если предположить, что нет других процессоров, то это 20%.
Ctrl-Alt-Delor
3

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

Rapti
источник
0

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

xempes
источник
0

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

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

Nairolf21
источник
0

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

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

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

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

psusi
источник