Чому програми не поширюються у складеному форматі?

Але вони дають вказівки на кшталт

cd downloaded_program
./configure
make install

Це створює необхідний ELF і, ймовірно, деякі файли .so.

Чому б не розмістити їх всередині zip-файлу для завантаження, як, наприклад, з додатками Windows? Чи є якась причина, чому вони повинні бути складені користувачем?

Проаналізуємо фактори ...

Аналіз :

ВЗАЄМНІ ВІДПОВІДНІ ПЛАТФОРМИ : Існують деякі проблеми, які виникають у середовищі, де розробники створюють та підтримують кілька варіантів програми, що стосуються архітектури:

• Для різних варіантів потрібен різний вихідний код - різні операційні системи на основі UNIX можуть використовувати різні функції для реалізації одного і того ж завдання (наприклад, strchr (3) проти індексу (3)). Так само може бути необхідним включити різні файли заголовків для різних варіантів (наприклад, string.h vs. 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 перерветься. Хоча часто постачальник бібліотеки вносить зміни, які не сумісні з зворотним ходом і не турбуються про зміну назви бібліотеки, тому незалежно від того, в якому порядку ви встановите дві програми, перша буде зламана. Це називається "dll hell".

На жаль, щоб уникнути цього, більшість програмного забезпечення Windows вдалося перевезти всі свої бібліотеки у власний каталог програм замість спільного каталогу, тому кожна програма має всі власні приватні бібліотеки і ніколи не ділиться між собою, що перемагає ціле в першу чергу, ви отримаєте набагато більше оперативного та дискового простору та часу, завантажуючи всі копії бібліотек.

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