Почему разработчики не делают мастеров установки на Linux? [закрыто]

Я уверен, что дело не в лени или чем-то в этом роде, но я не понимаю, почему разработчики приложений, в основном ориентированных на потребителя, не делают никакого мастера установки, чтобы перейти к следующему-следующему этапу. У одних и тех же приложений обычно есть установщики для Windows и Mac OS, так почему бы не Linux?

Есть ли техническая причина для этой тенденции или это просто соглашение?

РЕДАКТИРОВАТЬ (23-09-2014): Этот вопрос не был задан для начала войны пламени Windows против Linux. Я использовал все 3 основные операционные системы, и кроме двух других (Windows и Mac OS) есть установщики. Я еще не установил Oracle, но что бы мне ни понадобилось для установки, я никогда не видел никакого установщика GUI для Linux.

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

Взять, к примеру, настройку стека LAMP. Это все программное обеспечение с открытым исходным кодом в репозиториях по умолчанию, но можете ли вы настроить все за один раз без сценария? Теперь посмотрим на сервер WAMP в Windows. Вы просто запускаете установщик, и он устанавливает несколько программ таким образом, чтобы они хорошо работали друг с другом. Затем он устанавливает хорошие значения по умолчанию и прочее. Установщики могут сделать это, а менеджеры пакетов - нет. Да, вы можете найти сценарий для этого онлайн, но где? А какой?

Установщики - это не устаревшая технология из прошлого. Они все еще полезны, и 95% пользователей уже довольны ими.

Разработчики просто должны предоставить пакет для распространения. В каждом дистрибутиве есть способ установить этот пакет. Этот способ может быть в терминале ( apt-get) или через графический интерфейс, например, Ubuntu Software Center.

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

Потому что им не нужно. В дистрибутивах Linux обычно есть работающие системы управления пакетами, в отличие от Windows, где каждое приложение должно переустанавливать установку и обновление снова и снова, снова и снова.

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

Так что на ранних стадиях, прежде чем программное обеспечение с открытым исходным кодом будет подхвачено основными дистрибутивами? Почему разработчики не создают мастеров установки на этом этапе?

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

Разработчики с открытым исходным кодом , которые делают заботу о распределении еще лучше работать в системе менеджера пакетов, потому что там их клиенты. Пользователи Linux обычно не ищут в Интернете программное обеспечение. Сначала они ищут своего менеджера пакетов. В противном случае они ищут «поддерживаемые сообществом» репозитории, такие как PPA в Ubuntu или Arch AUR. Если вы не в этих местах, скорее всего, ваше программное обеспечение не будет замечено, а если оно будет замечено, оно вряд ли будет доверенным.

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

Что касается настройки конфигурации, то для программного обеспечения, такого как веб-сервер, традиционно проще обращаться с файлом конфигурации, что облегчает обмен, резервное копирование и восстановление конфигурации.

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

Дистрибутивы Linux (также, как я думаю, как BSD-версии) имеют удобный интерфейс для установки программы через так называемые менеджеры пакетов (или управление портами в случае BSD): pacman для Arch, dpkg для Debian / Ubuntu , и так далее.

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

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

Я часто задавал себе и другим этот вопрос, и я хотел бы затронуть вопрос, который я часто поднимаю, прежде чем понять, почему 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% пользователей [могут] слепо нажать« Продолжить ». Проблема с управлением пакетами заключается в том, чтобы заставить этих пользователей кнопка «Продолжить», позволяющая им узнать, что это за кнопка «Продолжить» (я видел, что пользователи были сбиты с толку инструментами, которые нажимают ввод с другим текстом), и позволяющая им знать, когда они достигли этого «края при нажатии «Продолжить» кнопку «этап».

По большому счету это оба. Модель дистрибуции Linux ближе к AppStore / Play Store, чем к традиционной Windows / Mac OS X - и даже эта платформа движется от того, что я слышал.

Соглашение состоит в том, что это проще. Большинство аргументов для AppStore / Play Store применимы и к Linux:

• Автоматические обновления. Обновление 20 программ отдельно для Windows разрушительно и неэффективно. Пользователь должен щелкнуть через обновления Java / Flash / Adobe / ... при загрузке.
• Одиночный, доверенный, репозиторий. Вы проверяете, загружаете ли вы через безопасное соединение? Или вы не загрузили обновление Reader с сайта get.adobe.com.hackers.example.com/setup.exe? Даже если вы делаете большинство пользователей, особенно не опытных пользователей, не делайте этого . Вместо этого вы идете в центр программного обеспечения или аналогичную программу в Linux и получаете доверенную копию.

Кроме того, существуют следующие преимущества, которые могут не относиться к AppStore / Play Store:

• Не у каждого Linux есть GUI - думаю, http-сервер - но большинство дистрибутивов поддерживает такую ​​конфигурацию. Хорошо. Не всем это нужно, но рано или поздно кто-то захочет использовать его по любой причине.
• ABI библиотек в разных дистрибутивах могут отличаться. Не вдаваясь в подробности установки инсталлятора, вы возложите ответственность за работу программы на вас, а не на людей, обслуживающих пакет в репозитории.
• Связано с предыдущим - нужно как-то управлять зависимостями. Связывание считается неподходящим по какой-либо причине - в таком случае вам нужно убедиться, что вы обновили библиотеку до версии без ошибок - например, вы не включили openssl 1.0.1f в свой комплект. Практика показывает, что люди включают в себя устаревшие библиотеки с известными уязвимостями безопасности.

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

Учитывая, что в мире Linux терминал стоит на первом месте, а графический интерфейс является необязательным, становится очевидным, почему им не хватает настоящих мастеров установки.

Windows, с другой стороны, очень ориентирована на пользователя. Большинство файлов MSI могут быть легко развернуты без присмотра, точно так же, как и установка Windows без присмотра (насколько легко / сложно заставить WAIK работать - это другой вопрос). Это также означает, что куча приложений для Windows не основана на MSI и не поддерживает сценарии. Например, среди приложений масштаба предприятия продукты Adobe довольно сложны в установке по сценарию.

Целевая аудитория другая. Unix и Unix-подобные системы обычно использовались профессиональными программистами, системными администраторами, инженерами и серьезными любителями, которые настраивали каждую систему под свои нужды. Любые «мастера установки» ограничивают свой выбор, а не предоставляют доступ ко всем необходимым переменным. И те, что сейчас там, до сих пор делают.

Windows не нацелена на профессионалов подобным образом и, следовательно, имеет более универсальные установщики, ориентированные на «пользователей», которые хотят только установить объект. Linux собирает больше таких типов пользователей, которые, вероятно, оценят такую ​​вещь, но, возможно, большинство дистрибутивов все еще имеют в виду профессионала.