¿Por qué los desarrolladores no hacen asistentes de instalación en Linux? [cerrado]

Estoy seguro de que no se trata de pereza o algo así, pero no entiendo por qué los desarrolladores de aplicaciones aunque sobre todo de cara al consumidor no hacen ningún tipo de asistente de instalación donde vaya siguiente-siguiente-acabado. Las mismas aplicaciones suelen tener instaladores para Windows y Mac OS, ¿por qué no Linux?

¿Hay alguna razón técnica para esta tendencia o es solo una convención?

EDITAR (23-09-2014): Esta pregunta no se hizo para iniciar una guerra de llamas entre Windows y Linux. He utilizado los 3 principales sistemas operativos y, aparte de Linux, los otros dos (Windows y Mac OS) tienen instaladores. Todavía no he instalado Oracle, pero sea lo que sea que haya necesitado instalar, nunca vi ningún instalador de GUI para Linux.

Sí, sé que Linux tiene administradores de paquetes, por lo que los desarrolladores no "necesitan" hacer los instaladores. Pero todavía hay una gran cantidad de software que está desactualizado en los administradores de paquetes predeterminados o simplemente no está disponible. Además, ya que Linux se vende como una alternativa a Windows para los usuarios ocasionales (Ubuntu está haciendo grandes esfuerzos en este campo), que tendría mucho más sentido que acaba de dar a los usuarios lo que están familiarizados.

Tomemos, por ejemplo, la creación de una pila LAMP. Esos son todos software de código abierto en los repositorios predeterminados, pero ¿puedes configurar todo de una vez sin un script? Ahora mira el servidor WAMP en Windows. Simplemente ejecuta un instalador e instala múltiples programas de tal manera que funcionen bien entre sí. Luego establece buenos valores predeterminados y otras cosas. Los instaladores pueden hacer eso, los administradores de paquetes no. Sí, puedes encontrar un script para eso en línea, pero ¿dónde? Y cual?

Los instaladores no son una tecnología obsoleta del pasado. Todavía son útiles, y el 95% de los usuarios ya se sienten cómodos con ellos.

Los desarrolladores solo necesitan proporcionar un paquete para una distribución. Cada distribución tiene una forma de instalar este paquete. De esta forma puede estar en un terminal ( apt-get) o mediante una interfaz gráfica, por ejemplo, Ubuntu Software Center.

Lo bueno es que los desarrolladores solo tienen que preocuparse por construir un paquete adecuado; los fabricantes de distribución se encargan del resto, y la instalación de cada paquete tiene el mismo proceso.

Porque no necesitan hacerlo. Las distribuciones de Linux generalmente tienen sistemas de administración de paquetes que funcionan, a diferencia de Windows, donde cada aplicación tiene que volver a implementar la instalación y la actualización una y otra y otra vez.

La mayoría del software de código cerrado, no libre como cerveza en Linux , viene con asistentes de instalación. También lo hace algún software de código cerrado, gratuito como en cerveza, al menos hasta que la mayoría de las distribuciones principales lo recojan. Para el software de código abierto, los administradores de paquetes son una solución claramente superior.

Entonces, ¿qué pasa con las primeras etapas antes de que las principales distribuciones recojan el software de código abierto? ¿Por qué los desarrolladores no crean asistentes de instalación durante esa fase?

En primer lugar, muchos desarrolladores de código abierto simplemente no se preocupan por la distribución. Escriben software para que lo usen ellos mismos, y lo publican en caso de que sea útil para otros, pero ven el empaquetado para su distribución como un problema de otra persona. Si le gusta lo suficiente, alguien asumirá la tarea de incluirlo en su distribución favorita.

Los desarrolladores de código abierto que hacen la atención acerca de la distribución son aún mejor trabajando dentro del sistema gestor de paquetes, porque ahí es donde están sus clientes. Los usuarios de Linux no suelen buscar software en la web. Primero buscan a su administrador de paquetes. De lo contrario, buscan en los repositorios "mantenidos por la comunidad", como los PPA de Ubuntu o el AUR de Arch. Si no está en esos lugares, lo más probable es que su software no se note, y si se nota, es menos probable que sea confiable.

Renunciar a esos canales de distribución existentes es como decidir que los anuncios de superbowl son demasiado caros, por lo que vas a organizar tu propio campeonato de fútbol y anunciar allí. Puede ser menos costoso, pero también es menos efectivo.

En cuanto a la personalización de la configuración, para un software como un servidor web que tradicionalmente es más fácil de manejar con un archivo de configuración, lo que hace que la configuración sea más fácil de compartir, realizar copias de seguridad y restaurar.

Para un software cliente como un navegador web, es mucho mejor crear un asistente de configuración que aparezca la primera vez que un nuevo usuario ejecuta el software, en lugar de hacerlo en el momento de la instalación. La razón principal es que Linux es un sistema operativo multiusuario, por lo que debe personalizarlo por usuario de todos modos. Esto también hace que sea más fácil volver a ejecutar el asistente de configuración más tarde, por cualquier razón, sin tener que mantener el programa de instalación para reinstalar todo el software. Este tipo de asistente es bastante común en el software de Linux.

Las distribuciones de Linux (también, creo, como Unices con sabor a BSD) tienen una interfaz fácil de usar para la instalación del programa, a través de los llamados gestores de paquetes (o gestión de puertos en el caso de BSD): pacman para Arch, dpkg para Debian / Ubuntu , y así.

Este administrador de paquetes proporciona una manera de instalar programas mediante archivos de configuración uniformes. Una vez que el programa que necesita está empaquetado de acuerdo con el administrador de paquetes de su distribución, simplemente puede ejecutar su comando de instalación sobre el paquete seleccionado (con personalizaciones ocasionales específicas del usuario, aunque a menudo ninguna) y el administrador hace el resto.

Los administradores de paquetes suelen ser más fáciles de usar que los procesos de instalación de programas específicos de Windows, solo por la forma uniforme en que los programas se empaquetan para la instalación. Por lo general, también le permiten consultar la base de datos del administrador de paquetes para el programa que está buscando, ver sus dependencias.
También admiten la actualización centralizada de los paquetes.

A menudo me he hecho a mí mismo y a otros esta pregunta, y me gustaría abordar un punto que a menudo veo mencionado antes de llegar a por qué Linux ve menos instaladores:

Las distribuciones de Linux proporcionan administradores de paquetes.

Sin embargo, no diría que el administrador de paquetes de una distribución de Linux es un reemplazo de un instalador por, en parte, las siguientes razones:

• Estos gestores de paquetes no están estandarizados en operación

  Un administrador de paquetes es un poco como proporcionar su binario y dejar que el usuario final elija el instalador. Pueden elegir el terminal, o pueden elegir una herramienta con una GUI más avanzada, pero no le brinda el mismo control de nivel del proceso que con un asistente de instalación "tradicional".

  Un ejemplo de lo que quiero decir con control es la documentación. No puede dar instrucciones a sus usuarios finales como "Haga clic en Siguiente y debería ver". Puede dar instrucciones de línea de comandos para una herramienta específica, pero no solo confía en el hecho de que el usuario tiene esa herramienta, sino que también pierde la mayoría de los beneficios de un asistente de instalación (después de todo, la mayoría de los asistentes proporcionan un frente -final para instrucciones de línea de comandos simples y guiones de inicio).

  Esto también se vincula con la estética. Ahora depende de la distribución de los usuarios finales para proporcionar una interfaz intuitiva / adecuada. Si bien es plenamente consciente de este hecho, no es irracional que un usuario más informal se queje si al hacer doble clic en su archivo (en su opinión, el instalador) abre un administrador de paquetes feo, no hace nada en absoluto, o lo peor de todo es que abre un terminal ventana. (Las experiencias que he tenido con los usuarios y su aversión al "dos prompt" / "cuadro blanco y negro" / "Cosa que va a eliminar todos sus archivos si lo ven divertido" probablemente podría llenar un libro)

• Los formatos de paquete no están estandarizados en todas las plataformas.

  Hay herramientas para convertir entre sistemas como rpmy deb, pero no es razonable esperar que su usuario final convierta sus paquetes si los está utilizando en una situación en la que se proporcionaría un asistente de instalación en otra plataforma (es decir, clics y listo). ) Proporcionar paquetes actualizados para un formato de paquete adicional puede ser bastante sencillo si tiene un sistema de compilación rudimentario, pero aún está agregando un nuevo binario que necesita soporte.

  Eso también agrega un nuevo binario que las personas tienen que elegir dependiendo de su plataforma (suena menor, pero estoy seguro de que alguien aquí puede dar fe de tener que explicar x86 vs x64 antes [sí, hay formas de deducir la plataforma correcta del navegador, pero luego te estás metiendo en procedimientos aún más complicados y difíciles de soportar])

• Los administradores de paquetes son "mejores" para el software de código abierto.

  Esto no significa que no pueda compartir software de código cerrado con un sistema de administración de paquetes, definitivamente se puede hacer. Pero una vez que intenta compartir software de código cerrado en distribuciones de Linux, se encuentra con un muro en lo que respecta a sus opciones para llevar su software a repositorios comunes. Cosas como PPA o el servicio de compilación de openSUSE están fuera, e incluso los repositorios de Canonical Partners no están habilitados de forma predeterminada.

  Eso significa que, a menos que proporcione su propio repositorio, no puede tener muchas de las características principales de los sistemas de administración de paquetes, incluidas las actualizaciones automáticas. En mi opinión , este es el beneficio más importante en la mayoría de las plataformas que usan estos sistemas (por ejemplo, iOS, Android y Windows Store).

  E incluso si proporciona un repositorio (otro trabajo de trivialidad variable), aún necesita que los usuarios lo configuren (que es otra capa de soporte, otro conjunto de enfoques no estándar y otra desviación del punto original del instalador)

Ahora, habiendo dicho todo eso, todavía no he abordado el problema original, por qué los instaladores son menos comunes en Linux a pesar de estos factores (entre otros). La pregunta original pregunta si es técnica o si se basa en convenciones, y se basa en ambas en parte.

Si observa los factores anteriores que he mencionado, también hacen que las cosas sean más complejas para un instalador "similar a un asistente". Por ejemplo, ¿su asistente incluiría múltiples formatos de paquete para instalar? ¿Cómo maneja la apariencia en las distribuciones? La lista es interminable, y una cosa que los paquetes que no se ofrecen es que nada de esto va a ser su preocupación ( para bien o para mal ), siempre que proporcione los paquetes adecuados. Y dependiendo de la naturaleza de su proyecto, puede comenzar a aprovechar esos recursos más "especializados", como el envío de aplicaciones al Centro de software de Ubuntu. Todo esto estaría relacionado con lo técnico.

Pero el aspecto que personalmente considero que es la fuerza impulsora es la convención. (Espero haber enterrado esto lo suficientemente profundo como para que las personas que rechazaron esa otra respuesta al olvido hayan dejado de leer ...)

Siento que el póster tenía un punto, pero podría haberlo dicho sin rodeos, y en realidad no proporcionó razones objetivas para ese punto. Si examina las diferencias que establecí para un administrador de paquetes y un instalador, no me sorprendería si descubriera que la mayoría de ellos son casi sin problemas (tal vez incluso limítrofe con pedante). Pero (disculpe lo que espero que se vea como un uso legítimo de un argumento hominem publicitario) también somos usuarios en el sitio para programadores. Veo las distribuciones de Linux impulsadas como una excelente alternativa de Windows para usuarios ocasionales (entre muchas otras cosas, obviamente). Si no se proporciona un procedimiento de clics-y-hace comúnmente definido que todos estos usuarios pueden utilizar realmente no es ideal imo .

Pero al mismo tiempo, tampoco creo que muchas cosas en Linux sean especialmente ideales para ese grupo. Claro que algunas distribuciones tienen administradores de paquetes basados ​​en GUI, pero eso significa que estas personas tienen que comenzar a buscar cómo usar una herramienta separada, en eso no está estrictamente enfocado en la instalación de su programa (compare esto y esto con esto ).

Naturalmente, puede usar la GUI para hacer la mayoría que su usuario casual promedio debe hacer, especialmente con ciertas distribuciones (irónicamente, las cosas que están haciendo esas distribuciones no siempre se incluyen en la comunidad de código abierto [mire las quejas sobre Ubuntu y está "amurallado" jardín "]) Pero no creo que sea negable que las convenciones de Linux favorezcan a alguien que se sienta cómodo con una CLI, o que al menos no tenga un miedo mortal de que su apariencia signifique que hizo algo terriblemente mal.

No estoy diciendo que esto es a lo que aspiran, pero realmente es lo que veo que hacen esas convenciones. Y los sistemas de gestión de paquetes en Linux parecen estar siguiendo eso. Después de todo, la mayoría de sus "inconvenientes" son casi inexistentes si su usuario final se siente más cómodo con los conceptos subyacentes.

Los instaladores en la mayoría de las otras plataformas no se ven realmente afectados por eso, y están diseñados para citar un comentario sobre la pregunta, "99.99% de los usuarios [pueden] hacer clic ciegamente en" Continuar ". El problema con la administración de paquetes es hacer que esos usuarios un botón "Continuar", que les permite saber qué es ese botón "Continuar" (he visto que los usuarios se tropezaron con herramientas que decían presionar enter con otro texto) y les hacían saber cuando tocaban esa "costa al hacer clic" la etapa del botón "Continuar".

A grandes extensiones es a la vez. El modelo de distribución de Linux está más cerca de AppStore / Play Store que el tradicional Windows / Mac OS X one, e incluso esas plataformas se están moviendo allí por lo que he escuchado.

La convención es que es más simple. La mayoría de los argumentos para AppStore / Play Store también se aplican a Linux:

• Actualizaciones automáticas. Tener 20 programas actualizados por separado en Windows es disruptivo e ineficiente. El usuario necesita hacer clic a través de las actualizaciones Java / Flash / Adobe / ... en el arranque.
• Único, confiable, repositorio. ¿Compruebas si descargas a través de una conexión segura? ¿O no ha descargado desde una actualización de Reader desde get.adobe.com.hackers.example.com/setup.exe? Incluso si lo hace la mayoría de los usuarios, especialmente los usuarios avanzados, no lo haga . En su lugar, vaya al centro de software o un programa similar en Linux y obtenga una copia confiable.

Además, existen los siguientes beneficios, que pueden no aplicarse a AppStore / Play Store:

• No todos los Linux tienen GUI, piense en el servidor http, pero la mayoría de las distribuciones admiten dicha configuración. Okay. No todos necesitan uno, pero tarde o temprano alguien querrá usarlo por cualquier razón.
• Las ABI de las bibliotecas en varias distribuciones pueden diferir. No entrar en detalles al tener un instalador pondría la responsabilidad del programa trabajando en usted en lugar de que las personas mantengan un paquete en el repositorio.
• Conectado con el anterior: debe administrar las dependencias de alguna manera. La agrupación se considera inadecuada por una razón: en tal caso, debe asegurarse de haber actualizado la biblioteca a la versión sin errores, por ejemplo, no incluyó openssl 1.0.1f en su paquete. La práctica muestra que las personas incluyen bibliotecas obsoletas con vulnerabilidades de seguridad conocidas.

Por lo general, la instalación no necesita interacción con un usuario (la mayoría de los apt-getpaquetes, por ejemplo), o puede ser programada. Esto hace que sea muy fácil automatizar para implementar un software en muchas máquinas. En lugar de hacer cosas a través del asistente, usted hace esas mismas cosas a través de secuencias de comandos o mediante archivos de configuración.

Dado que en el mundo de Linux, el terminal es lo primero, y la GUI es opcional, resulta obvio por qué carecen de asistentes de instalación reales.

Windows, por otro lado, está muy orientado al usuario. La mayoría de los archivos MSI pueden implementarse fácilmente de manera desatendida, de la misma manera que la instalación de Windows puede ser desatendida (lo fácil / difícil es hacer que WAIK funcione es un tema diferente). Esto también significa que un montón de aplicaciones para Windows no están basadas en MSI y no son programables. Entre las aplicaciones a escala empresarial, los productos de Adobe, por ejemplo, son conocidos por ser bastante difíciles de instalar de manera programada.

El público objetivo es diferente. Los sistemas Unix, y similares a Unix, solían ser utilizados por programadores profesionales, administradores de sistemas, ingenieros y aficionados serios que personalizaban cada sistema según sus necesidades. Cualquier "asistente de instalación" solo limitaría sus opciones en lugar de dar acceso a todas las variables que necesitan. Y los que están ahora afuera todavía lo hacen.

Windows no está dirigido a los profesionales de la misma manera y, por lo tanto, tiene instaladores de propósito más general orientados a "usuarios" que solo desean instalarlo. Linux está obteniendo más de estos tipos de usuarios que probablemente apreciarían tal cosa pero, posiblemente, la mayoría de las distribuciones todavía tienen en mente al profesional.