Я часто задавав собі і іншим це запитання, і я хотів би звернутися до моменту, який я часто бачу перед тим, як перейти до того, чому Linux бачить менше інсталяторів:
Дистрибутиви Linux надають менеджерам пакетів.
Однак я б не сказав, що менеджер пакунків дистрибутива Linux є заміною інсталятора, зокрема, з наступних причин:
Ці менеджери пакунків не стандартизовані в роботі
Менеджер пакунків дещо схожий на те, щоб забезпечити свій бінарний файл і дозволити кінцевому користувачеві вибрати інсталятора. Вони можуть вибрати термінал, або вони можуть вибрати інструмент із більш досконалим графічним інтерфейсом, але це не дозволяє вам контролювати той самий рівень процесу, як у "традиційного" майстра встановлення.
Прикладом того, що я маю на увазі під контролем, є документація. Ви не можете дати своїм кінцевим користувачам такі вказівки, як "Клацніть Далі, і Ви повинні побачити". Ви можете дати вказівки командного рядка для певного інструменту, але тоді ви не тільки покладаєтесь на те, що користувач має цей інструмент, але й втрачаєте більшість переваг майстра встановлення (адже більшість майстрів надають фронт -закінчити прості інструкції з командного рядка та розпочати сценарії).
Це також пов'язане з естетикою. Тепер ви залежно від розподілу своїх кінцевих користувачів, щоб забезпечити інтуїтивно зрозумілий / відповідний інтерфейс. Хоча ви цілком усвідомлюєте цей факт, більш випадковому користувачеві не скаржиться скаржитися, якщо подвійне клацання вашого файлу (інсталятор на їхню думку) відкриває некрасивого менеджера пакунків, нічого не робить, або, що найгірше, відкриває термінал вікно. (Переживання, які я мав з користувачами, та їхня неприязнь до "дозволеного запиту" / "чорно-білого поля" / "Те, що збирається видалити всі їх файли, якщо вони виглядають це смішно", можливо, може заповнити книгу)
Формати пакунків не стандартизовані на різних платформах.
Існують інструменти для конвертації між такими системами, як rpmі deb, але не доцільно сподіватися, що ваш кінцевий користувач перетворить ваші пакунки, якщо ви використовуєте їх у ситуації, коли майстер встановлення буде надано на іншій платформі (тобто натискання та виконання ). Надання сучасних пакетів для додаткового формату пакунків може бути досить прямим, якщо у вас є система рудиментарної збірки, але ви все ще додаєте новий двійковий файл, який потрібно підтримувати.
Це також додавання нових бінарних людей повинні вибирати залежно від їх платформи (це звучить другорядним, але я впевнений, що хтось тут може засвідчити, що потрібно пояснити x86 vs x64 раніше [так, є способи вивести правильну платформу з браузера, але тоді ви потрапляєте в ще складніші та складніші для підтримки процедури])
Менеджери пакетів "приємніші" до програмного забезпечення з відкритим кодом.
Це не говорить про те, що ви не можете ділитися програмним забезпеченням із закритим кодом із системою управління пакетами, але це однозначно можна зробити. Але як тільки ви спробуєте поділитися програмним забезпеченням з близьким кодом на дистрибутивах Linux, ви натрапите на стіну, наскільки це стосується ваших варіантів отримання програмного забезпечення у загальні сховища. Такі речі, як PPA або OpenSUSE Build Service вичерпані, і навіть сховища Canonical Partners не включені за замовчуванням.
Це означає, що якщо ви не надасте власний сховище, ви не можете виконувати багато основних функцій систем управління пакетами, включаючи автоматичні оновлення. На мою думку , це найважливіша вигода на більшості платформ, які використовують ці системи (наприклад, iOS, Android та Windows Store).
І навіть якщо ви надаєте сховище (інше завдання зі змінною тривіальністю), вам все одно потрібно змусити користувачів налаштувати його (це ще один рівень підтримки, інший набір нестандартних підходів та інше відхилення від початкової точки інсталятор)
Тепер, сказавши все це, я все ще не вирішив початкової проблеми, чому інсталятори рідше зустрічаються в Linux, незважаючи на ці фактори (серед інших). Первісне питання задає, чи це технічне, чи засноване на конвенції, і базується на обох частково.
Якщо ви подивитесь на вищезазначені фактори, які я згадував, вони також роблять складнішими для інсталятора, подібного до майстра. Наприклад, чи включить ваш майстер кілька форматів пакунків для встановлення? Як ви поводитесь із зовнішнім виглядом у різних дистрибутивах? Список триває, і одна річ, що пакети дійсно дозволити вам, що нічого з цього не буде ваша турбота ( краще або гірше ), якщо ви надаєте необхідні пакети. І залежно від характеру вашого проекту, ви можете почати користуватися тими більш "спеціалізованими" ресурсами, як подання програм до програмного центру Ubuntu. Це все стосувалося б технічного.
Але аспект, який я особисто вважаю рушійною силою, - це конвенція. (Я сподіваюся, що я похоронив це досить глибоко, щоб люди, які спростували цю іншу відповідь на забуття, перестали читати.)
Я вважаю, що плакат мав точку, але, можливо, це заявив занадто прямо, і насправді не наводив об’єктивних причин для цього. Якщо ви вивчите відмінності, які я зазначив для менеджера пакунків та інсталятора, я не здивуюся, якби ви виявили, що більшість з них майже не мають проблем (можливо, навіть межують з педантичними). Але (вибачте, те, що я сподіваюсь, розглядається як легітимне використання аргументу ad hominem), ми також користувачі на сайті для програмістів. Я вважаю, що дистрибутиви Linux є відмінною альтернативою Windows для випадкових користувачів (очевидно, серед багатьох інших). Забезпечення загальновизначеної процедури, що виконується за допомогою кліків, і всі ці користувачі можуть використовувати насправді, не є ідеальним методом .
Але в той же час я не вважаю, що багато речей в Linux також не є особливо ідеальними для цієї групи. Звичайно, у деяких дистрибутивах є менеджери пакетів на основі графічного інтерфейсу, але це означає, що цим людям потрібно почати розбиратися в тому, як використовувати окремий інструмент, на який не строго орієнтовано встановлення вашої програми (порівняйте це і це з цим ).
Природно, ви можете використовувати графічний інтерфейс, щоб зробити більшість, якими повинен займатися ваш середній випадковий користувач, особливо з певними дистрибутивами (за іронією долі, те, що роблять ці дистрибутиви, не завжди охоплене у спільноті з відкритим кодом (подивіться на скарги на Ubuntu і це "огороджено" сад "]) Але я не думаю, що заперечувати, що конвенції Linux надають перевагу тому, кому зручно користуватися CLI, або, принаймні, не смертельно бояться, що його зовнішній вигляд означає, що вони зробили щось жахливо не так.
Я не кажу, що це те, чого вони прагнуть, але це дійсно те, що я бачу, що ці конвенції роблять. І системи управління пакетами в Linux, схоже, слідують цьому. Зрештою, більшості їх "недоліків" майже не існує, якщо вашому кінцевому користувачеві більше подобається базові концепції.
Про це інсталятори на більшості інших платформ насправді не поширюються, і вони розроблені так, щоб процитувати коментар до питання: "99,99% користувачів [можуть] сліпо натиснути" Продовжити ". Проблема з управлінням пакетом полягає у тому, щоб ці користувачі перешкоджали кнопка "Продовжити", що дає їм знати, що це за кнопка "Продовжити" (я бачив, як користувачі стикаються з інструментами, які говорять, що натисніть кнопку "Ввести" іншим текстом), і дайте їм знати, коли вони натиснули на "узбережжя при натисканні етап "Продовжити".