Відповіді:
Все програмне забезпечення - це програми , які також називаються вихідними пакетами . Таким чином , всі вихідні пакети , повинні бути побудовані першим, щоб працювати на вашій системі.
Ці бінарні пакети є один, які вже будує з джерела хто - то з загальними функціями і параметрами, в програмному забезпеченні , так що велика кількість користувачів може встановити і використовувати його.
Бінарні пакети прості в установці .
Але можуть бути не всі параметри з висхідного пакету.
Тож для установки з вихідного коду вам потрібно створити вихідний код самостійно. Це означає, що вам потрібно подбати про залежності самостійно. Також вам потрібно знати про всі особливості пакету, щоб ви могли його скласти відповідно.
Переваги установки з джерела:
Коротше кажучи, встановлення з джерела дає вам велику можливість налаштування, водночас це вимагає великих зусиль, тоді як установка з двійкового файлу простіша, але ви не зможете налаштувати за своїм бажанням.
Оновлення : додавання аргументу, пов’язаного із безпекою, у коментарі нижче. Так, це правда, що при установці з двійкового файлу ви не маєте цілісності вихідного коду. Але тоді це залежить від того, звідки ви отримали двійковий файл. Є багато надійних джерел, з яких ви можете отримати бінарні дані будь-якого нового проекту, єдиний мінус - це час . Може знадобитися певний час, щоб двійкові дані оновлень або навіть новий проект з'явилися в наших надійних сховищах.
І перш за все, щодо безпеки програмного забезпечення, я хотів би висвітлити цю веселу сторінку в лабораторіях, що надаються Джо в коментарях нижче.
Вихідний файл містить оригінальний код, написаний розробником будь-якою мовою, яку він обрав (C, C ++, Python тощо), і є загальним. Він не характерний для будь-якого дистрибутива і в багатьох випадках для будь-якої операційної системи.
Пакет (RPM або DEB, наприклад) - це двійковий виконуваний файл (або інтерпретований сценарій тощо), попередньо підготовлений для вашого конкретного дистрибутива. Завдання підготовки джерела до компіляції (додавання будь-яких необхідних патчів тощо), власне компіляція, створення конфігураційних файлів для дистрибутива, створення сценаріїв перед і після встановлення тощо виконує для вас сервіс, що підтримує пакет.
Іншими словами, усі роботи з ослами були зроблені для вас в пакеті, тоді як вам потрібно буде зробити це самостійно, якщо ви вирішите встановити з джерела.
Набагато простіше використовувати пакет майже у всіх випадках, як:
Однак іноді упакована версія - це стара версія, а ще гірше, не існує упакованої версії; в такому випадку ваш єдиний варіант - скласти себе. Якщо це зробити, вам потрібно врахувати наступне:
devпакети - їх може бути багато.Якщо ви готові докласти додаткових зусиль, то компіляція з джерела може принести вам переваги:
Зауважте, що хоча попередньо вбудовані пакети дистрибутивів надають бінарні виконувані файли, які готові встановити та запустити (RPM та DEB - приклади), інші дистрибутиви надають пакети, які просто автоматизують процес збирання.
ebuildsПриклад цього - Gentoo - це в основному інструкції керівнику пакунків, що описують, як скласти та встановити виконуваний файл. Це має багато переваг традиційних менеджерів пакетів (автоматичні оновлення, видалення тощо), але все ж дозволяє користувачеві оптимізувати процес компіляції під свій смак.
Arch Linux має систему упаковки, де основні пакети є двійковими, тоді як багато додаткових пакетів збираються в системі за допомогою PKGBUILDфайлів.
Окрім інших відповідей, я хотів би додати щось:
Якщо ви вирішили скласти програму самостійно, вам потрібно подумати, що компіляція - це не те, що ви робите лише один раз. Ймовірно, вам потрібно буде підписатися на розсилку розсилки розробок програм, які ви вирішили скласти і бути в курсі нових версій і, особливо, оновлень безпеки.
Щоразу, коли додаток оновлюється, вам доведеться перекопіювати нову версію, тому пам’ятайте, що вам доведеться витрачати частину свого часу щотижня.
Якщо ви не можете собі цього дозволити, краще дозволити технічному обслуговувачу пакунків виконувати цю роботу за вас.
Побудова з джерела дозволяє вказати архітектуру саме вашої машини. Нові процесори мають додаткові інструкції, які компілятори розуміють, знижуючи трохи продуктивності. Пакети попереднього збирання зазвичай розраховують на найбільш архаїчний процесор, який все ще використовується.
Це в основному важливо для критично важливих проектів додатків, які дуже активно використовують процесор, наприклад, інструменти біоінформатичного конвеєра, наприклад, або інструменти геофізичного моделювання. Таке програмне забезпечення працює в дуже контрольованому середовищі, не має власного контролю доступу, тому рідко є помилки безпеки настільки нагальні, що їх потрібно виправити за кілька днів або годин. Майже ніколи його не потрібно працювати на іншій машині з спочатку невідомою архітектурою.
Так, я знаю, що комп'ютери зараз дуже-дуже швидкі, і будь-які зусилля чи дії, які ви вживаєте, дуже дуже дорогі, але на третій день сидіти і чекати, коли ваша програма завершиться (саме про цю ситуацію я говорю) такі правди почати виглядати сумнівно.
По-іншому, такі програми, як веб-переглядачі тощо, слід краще використовувати з репозитарію технічного обслуговування (а не з деяких завантажених попередньо вбудованих пакетів), оскільки дуже важливо постійно оновлювати їх.
Один із способів отримати найкраще з обох світів (сучасне програмне забезпечення, проста установка / видалення, включення більшості налаштувань і адаптацій дистрибуції, можна оптимізувати для місцевих потреб), при цьому витрати (повинні бути в курсі самих себе, стежте за помилками) і виправлення в останню хвилину, слідкуйте за розробкою, ви самостійно щодо виправлень помилок та несумісності між версіями) не можна пом'якшити (багато), це створити власні пакунки, починаючи з вихідних пакетів з вашого розповсюдження. Так, це більше роботи, ніж просто побудова та встановлення.