Я часто задавал себе и другим этот вопрос, и я хотел бы затронуть вопрос, который я часто поднимаю, прежде чем понять, почему Linux видит меньше установщиков:
В дистрибутивах Linux есть менеджеры пакетов.
Однако я бы не сказал, что менеджер пакетов дистрибутива Linux является заменой установщика, отчасти по следующим причинам:
Эти менеджеры пакетов не стандартизированы в работе
Менеджер пакетов похож на то, как предоставить ваш двоичный файл и позволить конечному пользователю выбрать установщик. Они могут выбрать терминал или инструмент с более продвинутым графическим интерфейсом, но он не дает вам такого же уровня управления процессом, как при «традиционном» мастере установки.
Примером того, что я подразумеваю под контролем, является документация. Вы не можете дать инструкции для конечного пользователя, такие как «Нажмите Далее, и вы должны увидеть». Вы можете дать инструкции командной строки для конкретного инструмента, но тогда вы не только полагаетесь на тот факт, что у пользователя есть этот инструмент, но также теряете большинство преимуществ мастера установки (в конце концов, большинство мастеров предоставляют конец для простых инструкций командной строки и запуска сценариев).
Это также связано с эстетикой. Теперь вы зависите от дистрибутива конечного пользователя, чтобы обеспечить интуитивно понятный / подходящий интерфейс. Несмотря на то, что вы полностью осведомлены об этом факте, для обычного пользователя не является необоснованным жаловаться, если двойной щелчок по вашему файлу (по их мнению, установщик) открывает уродливый менеджер пакетов, ничего не делает или, что хуже всего, открывает терминал окно. (Мой опыт общения с пользователями и их неприятие «DOS-приглашения» / «Чёрно-белого ящика» / «То, что удалит все их файлы, если они посмеются над этим забавно», возможно, заполнило бы книгу)
Форматы пакетов не стандартизированы для разных платформ.
Существуют инструменты для конвертирования между системами, такими как rpmи deb, но не стоит ожидать, что ваш конечный пользователь будет конвертировать ваши пакеты, если вы используете их в ситуации, когда мастер установки будет установлен на другой платформе (т.е. клики и готово) ). Предоставление современных пакетов для дополнительного формата пакета может быть довольно простым, если у вас есть элементарная система сборки, но вы все еще добавляете новый двоичный файл, который необходимо поддерживать.
Это также добавление нового бинарного файла, который люди должны выбирать в зависимости от их платформы (это звучит незначительно, но я уверен, что кто-то здесь может засвидетельствовать необходимость объяснить x86 против x64 до того, как [да, есть способы сделать вывод о правильной платформе из браузер, но затем вы получаете еще более сложные и трудные для поддержки процедуры])
Менеджеры пакетов "лучше" для программного обеспечения с открытым исходным кодом.
Это не значит, что вы не можете делиться программным обеспечением с закрытыми исходными кодами с системой управления пакетами, это определенно можно сделать. Но как только вы пытаетесь поделиться программным обеспечением с закрытым исходным кодом в дистрибутивах Linux, вы сталкиваетесь со стеной в том, что касается ваших вариантов размещения вашего программного обеспечения в общих репозиториях. Такие вещи, как PPA или openSUSE Build Service, отсутствуют, и даже репозитории Canonical Partners не включены по умолчанию.
Это означает, что если вы не предоставите свой собственный репозиторий, вы не сможете использовать многие основные функции систем управления пакетами, включая автоматические обновления. На мой взгляд , это самое важное преимущество для большинства платформ, которые используют эти системы (например, iOS, Android и Windows Store).
И даже если вы предоставляете репозиторий (еще одно задание переменной тривиальности), вам все равно нужно заставить пользователей его настроить (это еще один уровень поддержки, еще один набор нестандартных подходов и другое отклонение от первоначальной точки установщик)
Сказав все это, я все еще не обратился к исходной проблеме, почему установщики менее распространены в Linux, несмотря на эти факторы (среди прочих). Оригинальный вопрос спрашивает, является ли он техническим или основанным на соглашении, и основывается ли он на обоих аспектах.
Если вы посмотрите на вышеупомянутые факторы, которые я упомянул, они также усложняют процесс установки, подобный мастеру. Например, будет ли ваш мастер включать несколько форматов пакетов для установки? Как вы справляетесь с внешним видом дистрибутивов? Список продолжается, и одна вещь, что пакеты действительно позволить вам, что ничего из этого не будет ваша забота ( лучше или хуже ), если вы предоставляете необходимые пакеты. И в зависимости от характера вашего проекта, вы можете начать использовать преимущества этих более "специализированных" ресурсов, таких как отправка приложений в Ubuntu Software Center. Это все относится к технической.
Но аспект, который я лично считаю движущей силой - конвенция. (Я надеюсь, что я похоронил это настолько глубоко, что люди, которые отвергли этот другой ответ забвению, перестали читать ..)
Я чувствую, что у этого плаката был смысл, но, возможно, он сказал это слишком прямо, и на самом деле не представил объективных причин для этого. Если вы посмотрите на различия, которые я указал для менеджера пакетов и установщика, я не удивлюсь, если вы обнаружите, что большинство из них почти не имеют проблем (возможно, даже граничат с педантичным). Но (извините за то, что я надеюсь, рассматривается как законное использование аргумента ad hominem), мы также пользователи сайта для программистов. Я вижу, что дистрибутивы Linux выдвигаются как отличная альтернатива Windows для обычных пользователей (очевидно, среди прочего). Отсутствие обычно определенной процедуры « нажми и сделай», которую могут использовать все эти пользователи, на самом деле не идеальный вариант .
Но в то же время я не считаю, что многие вещи в Linux особенно идеальны для этой группы. Конечно, в некоторых дистрибутивах есть менеджеры пакетов на основе графического интерфейса, но это означает, что эти люди должны начать изучать, как использовать отдельный инструмент, поскольку он не сфокусирован исключительно на установке вашей программы (сравните это и это с этим ).
Естественно, вы можете использовать GUI для выполнения большинства задач, которые необходимы обычному обычному пользователю, особенно с определенными дистрибутивами (по иронии судьбы то, что делают эти дистрибутивы, не всегда воспринимается в сообществе открытого исходного кода [посмотрите на жалобы на Ubuntu и его «окружение» garden "]) Но я не думаю, что можно отрицать, что соглашения Linux предпочитают кого-то, кто чувствует себя комфортно с CLI, или, по крайней мере, не смертельно боится, что его внешний вид означает, что они сделали что-то ужасно неправильное.
Я не говорю, что это то, к чему они стремятся, но на самом деле это то, что я вижу в этих конвенциях. И системы управления пакетами в Linux, похоже, следуют этому. В конце концов, большинство их «недостатков» почти не существует, если ваш конечный пользователь более доволен основными концепциями.
Установщики на большинстве других платформ на самом деле не подвержены этому влиянию и предназначены для того, чтобы процитировать комментарий к вопросу: «99,99% пользователей [могут] слепо нажать« Продолжить ». Проблема с управлением пакетами заключается в том, чтобы заставить этих пользователей кнопка «Продолжить», позволяющая им узнать, что это за кнопка «Продолжить» (я видел, что пользователи были сбиты с толку инструментами, которые нажимают ввод с другим текстом), и позволяющая им знать, когда они достигли этого «края при нажатии «Продолжить» кнопку «этап».