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

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

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

EDIT ( 23-09-2014): Этот вопрос не задавали, чтобы начать войну между Windows и Linux. Я использовал все 3 основные операционные системы, и, кроме Linux, у двух других (Windows и Mac OS) есть установщики. Я еще не установил Oracle, но все, что мне нужно для установки, я никогда не видел установщика с графическим интерфейсом для Linux.

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

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

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


63

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

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

Поделиться
Улучшить этот ответ
ответил 21 сентября ’14 в 9:25
  • 15
    +1 … «каждая установка пакета имеет тот же процесс. «- Уве Плонус 21 сен 2014, в 10:03
  • 7
    Что ж, разработчикам просто нужно позаботиться о создании надлежащего пакета для каждого отдельного дистрибутива, который они хотят поддерживать, поэтому им потребуется один или несколько различных RPM, debs, сценариев сборки для портов и т. д. менеджеры великолепны, но пытаться поддерживать все системы в качестве разработчика сложно. Вот почему большинство людей, поддерживающих пакеты для дистрибутивов, на самом деле не являются разработчиками апстрима. — Алан Шутко 21 сен 2014, 14:59
  • 13
    Серьезным недостатком этого подхода являются пакеты быть (в некоторых случаях серьезно) устаревшим. В Windows я могу установить последнюю версию везде, где могу; в Linux мне нужно использовать (установить и понять!) клиент управления версиями для получения исходного кода, а также различные компиляторы или Make /CMake/и т. Д., Чтобы создать его. — marczellm 21 сен 2014 в 20:11
  • 4
    Многие проекты действительно предоставляют последнюю стабильную версию без необходимость контроля версий (если вам не нужна последняя версия development …). Однако вам все равно нужно будет скомпилировать их, потому что невозможно создать двоичный файл, который просто работает из коробки для каждой * nix-подобной ОС (в отличие от Windows, которая является очень стабильной и однородной платформой). К счастью, компиляторы очень легко настроить и установить в Linux по сравнению с Windows. — Rufflewind 21 сен 2014, в 20:19
  • 3
    @ API-Beast полностью отвечает на вопрос. Разработчикам не нужно создавать мастеров, эту громоздкую задачу решают дистрибутивы. — Флориан Маргейн, 22 сен 2014, в 07:31
| показать 11 дополнительных комментариев

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

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


42

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

Поделиться
Улучшите это ответ
ответ дан 21 сен ’14 в 14:03
  • 7
    Тем не менее, большинство нетехнических людей, которых я знаю, предпочли бы загрузить установщик и запустить мастер, а не открывать терминал и вводить команду. Этот менеджер пакетов отлично подходит для нас, гиков, но он действительно беспокоит обычного пользователя ПК, который начал использовать ПК после эры Windows 98. — Арсалан Ахмад 21 сен 2014, в 15:32
  • 44
    @ Arsalan00 Думайте о модели Linux как о AppStore — на самом деле это та же самая модель. Вы можете спросить, почему нет мастеров для Android или iOS. — Maciej Piechotka 21 сен 2014, 15:35
  • 5
    Android и iOS имеют гораздо более строгие ограничения в том, как они работают, и в том, как они позволяют работать приложениям. Linux — полная противоположность этому. Мобильные ОС обеспечивают соблюдение соглашений, Windows, кажется, рекомендует соглашения (папка с программными файлами, реестр и т. Д.), А Linux — это скорее конфигурация, чем соглашения. — Арсалан Ахмад, 21 сен 2014, 15:41
  • 9
    Эээ … если в Windows нет «рабочей системы управления пакетами», то что такое установщик Windows? Я никогда не слышал, чтобы разработчикам приходилось заново реализовывать это, по крайней мере, в последние 10-15 лет. — Aaronaught 21 сен 2014, в 23:42
  • 5
    @Aaronaught И я сбился со счёта количества программ Windows, которые не используют установщик Windows или что-то на его основе, и поэтому ИТ-специалистам излишне сложно их управлять. — Майкл Хэмптон, 21 сен 2014, в 23:56
| показать 11 дополнительных комментариев

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


23

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

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

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

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

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

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

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

Поделиться
Улучшите этот ответ
ответил 21 сен 2014 в 20:07
добавить комментарий |

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

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

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

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

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

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

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


14

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

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

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

Поделиться
Улучшить этот ответ
отредактировал 22 сен ’14 в 8:24
ответ дан 21 сен ’14 в 13: 18
  • 3
    удобный — это субъективный термин. ИМО, большинство пользователей компьютеров очень неохотно используют инструменты командной строки, и им было бы проще и удобнее, если бы они могли просто использовать мастер. Даже если на это уйдет больше времени. — Арсалан Ахмад, 21 сен 2014, 15:30
  • 1
    dpkg и APT используются как в Debian, так и в Ubuntu. apt-get , apt-cache и aptitude — это оболочки поверх dpkg . dpkg редко используется напрямую, я могу придумать один вариант использования — это установка пакета из файла .deb . — nyuszika7h 21 сен 2014 в 15:42
  • 16
    @ Arsalan00 обычно есть графический пользовательский интерфейс для менеджеров пакетов, таких как Ubuntu Software Center или yumex. Менеджер пакетов! = Терминал. — Флориан Маргейн, 21 сен 2014, в 15:44
  • @ Arsalan00, если вы используете Ubuntu, просто перейдите на страницу opera.com/download/guide/?os=linux, загрузите Opera для Ubuntu и дважды щелкните загруженный файл. Здесь вообще нет терминала. — oliver 22 сен ’14 в 9:06
добавить комментарий |

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

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

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


13

Я часто задавал себе и другим этот вопрос, и я хотел бы ответить Я часто вспоминаю о том, почему Linux видит меньше установщиков:

В дистрибутивах Linux есть менеджеры пакетов.

Однако я бы не сказал, что диспетчер пакетов дистрибутива Linux является заменой установщика отчасти по следующим причинам:

  • Эти диспетчеры пакетов не стандартизированы в работе

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

    Примером того, что я подразумеваю под контролем, является документация. Вы не можете давать своим конечным пользователям такие инструкции, как «Нажмите Далее, и вы должны увидеть». Вы можете давать инструкции в командной строке для конкретного инструмента, но тогда вы не только полагаетесь на тот факт, что у пользователя есть этот инструмент, но также теряете большую часть преимуществ мастера установки (в конце концов, большинство мастеров предоставляют -end для простых инструкций командной строки и запуска сценариев).

    Это тоже связано с эстетикой. Теперь вы зависите от своего дистрибутива конечных пользователей, чтобы обеспечить интуитивно понятный/подходящий интерфейс. Хотя вы полностью осведомлены об этом факте, для более случайного пользователя вполне разумно жаловаться, если двойной щелчок по вашему файлу (по их мнению, установщик) открывает уродливый менеджер пакетов, вообще ничего не делает, или, что еще хуже, все открывает окно терминала. (Опыт, который у меня был с пользователями, и их отвращение к «подсказке dos»/«черно-белому ящику»/«Вещь, которая удалит все их файлы, если они на это посмеются», вероятно, может заполнить книгу)

  • Форматы пакетов не стандартизированы для разных платформ.

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

    Это также добавление нового двоичного кода, из которого люди должны выбирать в зависимости от их платформы (это звучит второстепенно, но я уверен, что кто-то здесь может засвидетельствовать необходимость объяснения x86 и x64 раньше [да, там — это способы определить правильную платформу из браузера, но тогда вы попадаете в еще более сложные и трудные для поддержки процедуры])

  • Менеджеры пакетов «лучше» для программного обеспечения с открытым исходным кодом.

    Это не означает, что вы не можете совместно использовать программное обеспечение с закрытым исходным кодом с системой управления пакетами, это определенно можно сделать. Но как только вы попытаетесь поделиться программным обеспечением с близким исходным кодом в дистрибутивах Linux, вы столкнетесь с проблемой в том, что касается ваших вариантов размещения вашего программного обеспечения в общих репозиториях. Такие вещи, как PPA или openSUSE Build Service, отсутствуют, и даже репозитории Canonical Partners не включены по умолчанию.

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

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

Теперь, сказав все это, я все еще не решил исходную проблему, почему установщики менее распространены в Linux, несмотря на этих факторов (среди прочих). В исходном вопросе спрашивается, является ли он техническим или основанным на соглашении, и он частично основан на обоих.

Если вы посмотрите на вышеупомянутые факторы, которые я упомянул, они также усложняют работу установщика, подобного мастеру. Например, будет ли ваш мастер включать несколько форматов пакетов для установки? Как вы управляете внешним видом в разных дистрибутивах? Список можно продолжить, и единственное, что пакеты позволяют вам, — это то, что все это не будет вас беспокоить ( к лучшему или к худшему ), пока вы предоставляете нужные пакеты. И в зависимости от характера вашего проекта, вы можете начать пользоваться преимуществами этих более «специализированных» ресурсов, таких как отправка приложений в Центр программного обеспечения Ubuntu. Все это относилось бы к техническим вопросам.

Но аспект, который я лично считаю движущей силой, — условность. (Надеюсь, я похоронил это достаточно глубоко, чтобы люди, проголосовавшие против другого ответа на забвение, перестали читать …)

Я чувствую, что этот плакат был прав, но мог сказать это слишком прямо , и на самом деле не привели объективных причин для этого. Если вы изучите различия, которые я указал для диспетчера пакетов и установщика, я не удивлюсь, если вы обнаружите, что большинство из них почти не вызывают проблем (возможно, даже граничат с педантичностью).. Но (извините, что, я надеюсь, рассматривается как законное использование аргумента ad hominem), мы также являемся пользователями сайта для программистов. Я считаю, что дистрибутивы Linux являются отличной альтернативой Windows для обычных пользователей (среди прочего, очевидно). Отсутствие общепринятой процедуры «щелкнул и сделал», которую могут использовать все эти пользователи, на самом деле не идеально imo .

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

Естественно, вы можете использовать графический интерфейс для большинства задач обычного обычного пользователя, особенно с некоторыми дистрибутивами (по иронии судьбы то, что делают эти дистрибутивы, не всегда приветствуются в сообществе открытого исходного кода [ посмотрите на жалобы на Ubuntu и его «огороженный сад»]) Но я не думаю, что можно отрицать, что соглашения Linux отдают предпочтение кому-то, кому комфортно с CLI, или, по крайней мере, не смертельно боятся, что внешний вид означает, что они сделали что-то ужасно неправильное.

Я не говорю, что это то, к чему они стремятся, но это действительно то, что я вижу в этих конвенциях. И системы управления пакетами в Linux, похоже, следуют этому. В конце концов, большинство их «недостатков» практически не существует, если ваш конечный пользователь более доволен лежащими в основе концепциями.

Установщиков на большинстве других платформ это не касается, и они разработаны таким образом, чтобы, цитируя комментарий к вопросу, «99,99% пользователей [могут] вслепую нажать« Продолжить ». проблема с управлением пакетами заключается в том, чтобы заставить этих пользователей нажать кнопку «Продолжить», сообщить им, что это за кнопка «Продолжить» (я видел, как пользователи запутались в инструментах, в которых говорилось, что нажмите клавишу ввода с другим текстом), и сообщая им, когда они достигли этого «берега при нажатии кнопки« Продолжить »».

Поделиться
Улучшить этот ответ
отредактировано 22 сентября 2014 г. в 13:00
ответил 21 сен 2014 в 18:45
  • Это отличный ответ, и он объясняет Проблема с точки зрения обычного пользователя. — Арсалан Ахмад, 22 сен. ’14 в 16:59
  • 1
    «Форматы пакетов не стандартизированы для разных платформ.. «- Все LSB-совместимые дистрибутивы (а это большинство из основных) поддерживают формат пакета LSB, который является подмножеством RPM со всеми удаленными функциями, которые не могут быть легко сопоставлены с DEB. Инструменты командной строки, API и ABI для LSB Скорость вращения также стандартизирована. — Йорг В. Миттаг, 22 сен 2014, 18:17
  • @ Jörg W Mittag Я бы вряд ли назвал LSB-соответствие стандартизированным. В Debian «LSB-соответствие» использует инструмент Alien, который я упоминал в моем сообщении (и он ограничен). И снова , мы не сравниваем сценарии установки с пакетами. Это сравнение мастеров установки (которые позволяют даже самым обычным пользователям устанавливать программное обеспечение, даже не видя ужасного черного ящика) с менеджерами пакетов. Требование использования такого инструмента, как Alien, не дает тот же процесс, что и при предоставлении мастера установки. — Селали Адобор, 22 сентября 2014 г., 18:28
  • @AssortedTrailmix: формат пакета LSB — d намеренно разработан для обработки Чужим. А конечному пользователю никогда не нужно взаимодействовать с Alien, об этом позаботится менеджер пакетов LSB в Debian. Кроме того, в LSB явно заботятся мастера установки сборки. Если мастер установки связывается только с библиотеками LSB, то он может работать на всех системах LSB, и он может вызывать диспетчер пакетов LSB, потому что он стандартизирован, и он может устанавливать пакет, потому что он стандартизован, и, в конце концов, вы в итоге получится DEB в базе данных DPKG на Debian и RPM на SuSE. — Йорг В. Миттаг, 22 сен 2014, 18:41
  • Я понимаю это, но думаю, я не понял вашей точки зрения. Разве вы не подтверждаете то, что я сказал? Я хотел сказать, что мастер установки и менеджер пакетов — это не одно и то же. Я не предполагал, что установщик не может использовать диспетчер пакетов. Похоже, вы согласны с моим мнением, но зацикливаетесь на риторическом вопросе: «Например, будет ли ваш мастер включать несколько форматов пакетов для установки?» — Селали Адобор, 22 сен. ’14 в 18:47
добавить комментарий |

Я часто задавал себе и другим этот вопрос, и я хотел бы затронуть вопрос, который часто поднимался до того, как Чтобы понять, почему Linux видит меньше установщиков:

В дистрибутивах Linux есть менеджеры пакетов.

Однако я бы не сказал, что диспетчер пакетов дистрибутива Linux является заменой установщика отчасти по следующим причинам:

  • Эти диспетчеры пакетов не стандартизированы в работе

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

    Примером того, что я подразумеваю под контролем, является документация. Вы не можете давать своим конечным пользователям такие инструкции, как «Нажмите Далее, и вы должны увидеть». Вы можете давать инструкции в командной строке для конкретного инструмента, но тогда вы не только полагаетесь на тот факт, что у пользователя есть этот инструмент, но также теряете большую часть преимуществ мастера установки (в конце концов, большинство мастеров предоставляют -end для простых инструкций командной строки и запуска сценариев).

    Это тоже связано с эстетикой. Теперь вы зависите от своего дистрибутива конечных пользователей, чтобы обеспечить интуитивно понятный/подходящий интерфейс. Хотя вы полностью осведомлены об этом факте, для более случайного пользователя вполне разумно жаловаться, если двойной щелчок по вашему файлу (по их мнению, установщик) открывает уродливый менеджер пакетов, вообще ничего не делает, или, что еще хуже, все открывает окно терминала. (Опыт, который у меня был с пользователями, и их отвращение к «подсказке dos»/«черно-белому ящику»/«То, что удалит все их файлы, если они на это посмеются», вероятно, может заполнить книгу) p>

  • Форматы пакетов не стандартизированы для разных платформ.

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

    Это также добавление нового двоичного кода, из которого люди должны выбирать в зависимости от их платформы (это звучит второстепенно, но я уверен, что кто-то здесь может засвидетельствовать необходимость объяснения x86 и x64 раньше [да, там — это способы определить правильную платформу из браузера, но тогда вы попадаете в еще более сложные и трудные для поддержки процедуры])

  • Менеджеры пакетов «лучше» для программного обеспечения с открытым исходным кодом.

    Это не означает, что вы не можете совместно использовать программное обеспечение с закрытым исходным кодом с системой управления пакетами, это определенно можно сделать. Но как только вы попытаетесь поделиться программным обеспечением с близким исходным кодом в дистрибутивах Linux, вы столкнетесь с проблемой в том, что касается ваших вариантов размещения вашего программного обеспечения в общих репозиториях. Такие вещи, как PPA или openSUSE Build Service, отсутствуют, и даже репозитории Canonical Partners не включены по умолчанию.

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

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

Теперь, сказав все это, я все еще не решил исходную проблему, почему установщики менее распространены в Linux, несмотря на этих факторов (среди прочих). В исходном вопросе спрашивается, является ли он техническим или основанным на соглашении, и он частично основан на обоих.

Если вы посмотрите на вышеупомянутые факторы, которые я упомянул, они также усложняют работу установщика, подобного мастеру. Например, будет ли ваш мастер включать несколько форматов пакетов для установки? Как вы управляете внешним видом в разных дистрибутивах? Список можно продолжить, и единственное, что пакеты позволяют вам, — это то, что все это не будет вас беспокоить ( к лучшему или к худшему ), пока вы предоставляете нужные пакеты. И в зависимости от характера вашего проекта, вы можете начать пользоваться преимуществами этих более «специализированных» ресурсов, таких как отправка приложений в Центр программного обеспечения Ubuntu. Все это относилось бы к техническим вопросам.

Но аспект, который я лично считаю движущей силой, — условность. (Надеюсь, я похоронил это достаточно глубоко, чтобы люди, проголосовавшие против другого ответа на забвение, перестали читать …)

Я чувствую, что этот плакат был прав, но мог сказать это слишком прямо , и на самом деле не привели объективных причин для этого. Если вы изучите различия, которые я указал для диспетчера пакетов и установщика, я не удивлюсь, если вы обнаружите, что большинство из них почти не представляют проблем (возможно, даже граничат с педантичностью). Но (извините, что, я надеюсь, рассматривается как законное использование аргумента ad hominem), мы также являемся пользователями сайта для программистов. Я считаю, что дистрибутивы Linux являются отличной альтернативой Windows для обычных пользователей (среди прочего, очевидно). Отсутствие общепринятой процедуры «щелкнул и сделал», которую могут использовать все эти пользователи, на самом деле не идеально imo .

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

Естественно, вы можете использовать графический интерфейс для большинства задач обычного обычного пользователя, особенно с некоторыми дистрибутивами (по иронии судьбы то, что делают эти дистрибутивы, не всегда приветствуются в сообществе открытого исходного кода [ посмотрите на жалобы на Ubuntu и его «огороженный сад»]) Но я не думаю, что можно отрицать, что соглашения Linux отдают предпочтение кому-то, кому комфортно с CLI, или, по крайней мере, не смертельно боятся, что внешний вид означает, что они сделали что-то ужасно неправильное.

Я не говорю, что это то, к чему они стремятся, но это действительно то, что я вижу в этих конвенциях. И системы управления пакетами в Linux, похоже, следуют этому. В конце концов, большинство их «недостатков» практически не существует, если ваш конечный пользователь более доволен лежащими в основе концепциями.

Установщиков на большинстве других платформ это не касается, и они разработаны таким образом, чтобы процитировать комментарий к вопросу: «99,99% пользователей [могут] вслепую нажать« Продолжить ». проблема с управлением пакетами заключается в том, чтобы заставить этих пользователей нажать кнопку «Продолжить», сообщить им, что это за кнопка «Продолжить» (я видел, как пользователи запутались в инструментах, в которых говорилось, что нажмите клавишу ввода с другим текстом), и сообщая им, когда они достигли этого «берега при нажатии кнопки« Продолжить »».


9

По большому счету, и то, и другое.Модель распространения 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 есть графический интерфейс — подумайте о http-сервере — но большинство дистрибутивов поддерживает такую ​​конфигурацию. Хорошо. Не всем он нужен, но рано или поздно кто-то захочет его использовать по какой-либо причине.
  • ABI библиотек в разных дистрибутивах могут отличаться. Если не вдаваться в подробности, наличие установщика возложит ответственность за работающую программу на вас, а не на людей, поддерживающих пакет в репозитории.
  • Связано с предыдущим — вам нужно как-то управлять зависимостями. Объединение считается неправильным по какой-то причине — в таком случае вам необходимо убедиться, что вы обновили библиотеку до версии без ошибок — например, вы не включили openssl 1.0.1f в свой пакет. Практика показывает, что люди действительно включают устаревшие библиотеки с известными уязвимостями безопасности.
Поделиться
Улучшить этот ответ
ответил 21 сен ’14 в 15:52
  • 5
    +1 «Обновление 20 программ отдельно в Windows является разрушительным и неэффективным.» — IQAndreas 22 сен. : 20
  • Я бы сказать, что называть диалоги разрушительными или неэффективными — это немного. Если программа имеет плохо спроектированную систему обновлений, которая досаждает пользователям, как только они входят в систему, и не предоставляет возможность тихих обновлений, это в основном ошибка этой программы. При этом я не нахожу много программ, выполняющих это (большинство из них — это программы, не имеющие традиционной процедуры запуска), и конечный результат, возможно, более управляем, чем одно приглашение с перечислением каждого единственная вещь , которую нужно обновить. — Селали Адобор, 22 сен 2014, в 10:41
  • И «единый надежный репозиторий» несколько вводит в заблуждение. Это действительно только частично применимо, если вы пишете программное обеспечение, которое может там оказаться. Проприетарное программное обеспечение нелегко попасть в хорошо поддерживаемые репозитории по умолчанию для распространенных дистрибутивов Linux. Даже репозиторий для канонических партнеров на Ubuntu (вход в который нетривиален) по умолчанию отключен и многими считается небезопасным, поскольку риски безопасности в размещенном там программном обеспечении остаются без исправлений гораздо дольше, чем то же программное обеспечение на основе другие способы обновления. — Селали Адобор 22 сен 2014, в 10:58
добавить комментарий |

Сильно расширяет и то, и другое. Модель распространения 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 есть графический интерфейс — подумайте о http-сервере — но большинство дистрибутивов поддерживает такую ​​конфигурацию. Хорошо. Не всем он нужен, но рано или поздно кто-то захочет его использовать по какой-либо причине.
  • ABI библиотек в разных дистрибутивах могут отличаться. Если не вдаваться в подробности, то наличие установщика возложит ответственность за работающую программу на вас, а не на людей, поддерживающих пакет в репозитории.
  • Связано с предыдущим — вам нужно как-то управлять зависимостями. Объединение считается неправильным по какой-то причине — в таком случае вам необходимо убедиться, что вы обновили библиотеку до версии без ошибок — например, вы не включили openssl 1.0.1f в свой пакет. Практика показывает, что люди действительно включают устаревшие библиотеки с известными уязвимостями безопасности.

6

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

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

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

Поделиться
Улучшить этот ответ
отредактировано 21 сентября ’14 в 11:58
ответил 21 сен 2014 в 08:47
  • 1
    Эту проблему легко решить. Многие установщики Windows имеют параметр «тихо» и предварительно заполнены хорошими значениями по умолчанию, так что пользователю не нужно делать ничего, кроме нажатия кнопки «Далее». — Арсалан Ахмад 21 сен 2014, в 8:52
  • 5
    Ненавижу нажимать далее только потому, что разработчики не смогли сделать это более простым способом. — Сильвиу Бурча, 21 сен. ’14 в 9:23
  • @ Arsalan00: «пользователь не должен делать ничего кроме …» нарушает автоматизацию. Если пользователю нужно сделать что-нибудь , это нельзя автоматизировать. В идеале вы должны иметь возможность включить машину и позволить ей загрузиться через PXE, установить ОС, а затем установить и настроить все необходимое, без какого-либо взаимодействия с пользователем. В Linux вы можете это сделать (кроме, может быть, нескольких приложений, но я пока с ними не сталкивался). — Арсений Мурзенко 21 сен 2014, в 12:01
  • 1
    @MainMa ваше правка действительно попадает в точку. Если разработчики хотят, они могут сделать свои установщики скриптовыми или тихими. Но система мастеров действительно помогает начинающему пользователю познакомиться с тем, о чем идет речь, а мастера информируют пользователя, как не могут менеджеры пакетов. Кроме того, установка в автономном режиме — это то, что является важной необходимостью для многих людей. — Арсалан Ахмад, 21 сен 2014, 15:35
  • 2
    @ Arsalan00 обычно менеджеры пакетов могут задавать вопросы, если им это действительно нужно. Автономная установка возможна с помощью менеджеров пакетов, просто сначала загрузите пакет, как и при загрузке и установке файла. И, наконец, он более удобный, большинство начинающих пользователей не должны заботиться о том, «где вы хотите установить это» и т. Д., Он должен «просто работать». — iveqy 21 сен 2014, в 15:44
| показать 2 дополнительных комментария

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

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

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


-1

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

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

Поделиться
Улучшите это ответ
ответ дан 21 сен ’14 в 16: 14
  • 4
Мастер установки позволяет вам настраивать больше, чем менеджер пакетов, который обычно используется в Linux. — iveqy 21 сен 2014, в 13:35
  • @iveqy Любой текстовый файл конфигурации даст вам гораздо больше возможностей, чем любой «мастер» установки. Если бы такие волшебники могли работать лучше, они бы существовали, но их нет. — Роб 21 сен. ’14 в 15:03
  • 4
    это правда, но редактирование текстовых файлов конфигурации не является частью процесса установки большинства менеджеров пакетов. Типичные вопросы в процессе установки Windows: «куда вы хотите это поместить?», Менеджер пакетов уже решает это в среде Linux и «какие компоненты этой программы вы хотите установить», и это уже было решено сопровождающий пакета в случае менеджеров пакетов. Вы можете видеть, что менеджер пакетов более удобен для пользователя, поскольку он используется для Android и iphone (магазин приложений и Google Play). — iveqy 21 сен 2014, в 15:41
  • @iveqy Я только что понял, что мы не по теме. Это не имеет ничего общего с тем, что я сказал изначально, и то, что вы до сих пор не видите таких волшебников, является еще одним доказательством того, что я сказал. — Роб 22 сен ’14 в 2:38
  • добавить комментарий |

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

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

    Оцените статью
    Botgadget.ru
    Добавить комментарий