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".