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

Estoy seguro de que no se trata de la pereza ni nada por el estilo, pero no entiendo por qué los desarrolladores de las aplicaciones que se enfrentan principalmente a los consumidores no realizan ningún tipo de asistente de instalación al que irá el próximo próximo día que termine. 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 solicitó para iniciar una guerra de llamas entre Windows y Linux. He usado los 3 sistemas operativos principales y, aparte de Linux, los otros dos (Windows y Mac OS) tienen instaladores. Todavía no he instalado Oracle, pero lo que sea que haya necesitado para 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" para hacer los instaladores. Pero todavía hay una gran cantidad de software que está obsoleto en los administradores de paquetes predeterminados o simplemente no está disponible. Además, dado que Linux se vende como una alternativa a Windows para usuarios ocasionales (Ubuntu se está esforzando mucho en este dominio), tendría mucho más sentido darles a los usuarios lo que les es familiar.

Tomemos, por ejemplo, la configuración de una pila LAMP. Todos estos son software de código abierto en los repositorios predeterminados, pero ¿puedes configurar todo de una sola vez sin un script? Ahora mira el servidor WAMP en Windows. Simplemente ejecuta un instalador e instala varios programas de manera que funcionen bien entre ellos. Luego establece buenos valores predeterminados y esas cosas. Los instaladores pueden hacer eso, los administradores de paquetes no lo hacen. Sí, puedes encontrar un script para eso en línea, pero ¿dónde? ¿Y cuál?

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

32
@ Arsalan00 Te estás perdiendo un punto importante. Normalmente hay una GUI para los gestores de paquetes (Centro de software de Ubuntu, Synaptic, YaST, etc.).
agregado el autor Jesse Vogt, fuente
Cuando la aplicación no está empaquetada, el asistente se llama ./configure; hacer; hacer instalar .
agregado el autor Joel, fuente
Los comentarios no son para discusión extendida; esta conversación ha sido movido al chat .
agregado el autor World Engineer, fuente
Si desea seguir discutiendo la validez de esta pregunta, muévase al chat o mejor aún, Meta de Ingeniería de Software .
agregado el autor World Engineer, fuente
@ Arslan00: los proveedores de código cerrado en general se están disparando en el pie. Tienen términos de licencia que dificultan que los creadores de distribución de Linux creen paquetes legalmente. Sin embargo, no se proporcionan envases a sí mismos. ¿Por qué molestarse con intelliJ cuando Eclipse viene de serie?
agregado el autor James Anderson, fuente
El problema aquí es que el cartel claramente nunca ha usado un moderno sistema de escritorio de Linux como UBUNTU, MINT SUSE, etc. Si alguna vez hubiera usado un sistema así, sabría que existen sistemas de administración de paquetes simples y fáciles de usar basados ​​en GUI que son muy buenos. mucho más fácil de usar que el desorden del instalador de Windows. Abajo, ya que el cartel claramente no quiere las respuestas, sino que simplemente quiere que se confirmen sus prejuicios.
agregado el autor James Anderson, fuente
Nunca podría entender un punto de dichos asistentes, el 99,99% de los usuarios hará clic ciegamente en "Continuar" de todos modos, por lo que una instalación silenciosa y no interactiva tiene mucho más sentido.
agregado el autor SK-logic, fuente
"Tomemos, por ejemplo, la configuración de una pila LAMP. Todos estos son software de código abierto en los repositorios predeterminados, pero ¿puedes configurar todo de una vez sin un script?" - En Ubuntu específicamente (no sé si está en los repositorios de otras distribuciones), sí: sudo apt-get install lamp-server ^ (el caret es importante) (tampoco lo sé si aparece en el centro de software GUI)
agregado el autor Izkata, fuente
@ Arsalan00: cuando escribe "hay tantas formas de instalar software en Linux" está hablando de programas no incluidos en un sistema de administración de paquetes, ¿verdad? Debe agregar esto a su pregunta para que sea más claro.
agregado el autor Peter LeFanu Lumsdaine, fuente
@DebugErr Estás ofendido por una simple broma. No se pretendía ofender.
agregado el autor Michael Hampton, fuente
Steam y Opera permiten descargar paquetes DEB para sistemas Debian/Ubuntu.
agregado el autor Thorbjørn Ravn Andersen, fuente
Es uno de los muchos signos de que Linux en cualquiera de sus versiones actuales solo está destinado a servidores y otros entornos especializados, no para uso del consumidor. Las personas normales están completamente sobrecargadas incluso por apt-get o "centros de software" desconocidos. Debe darles a esas personas un archivo .exe para hacer clic, no un archivo .tar.gz o una página de guías largas sobre cómo hacer que el software básico funcione. Lamento haber molestado a alguien con mi opinión.
agregado el autor Traubenfuchs, fuente
Creo que todo depende de a lo que estés acostumbrado. Estoy acostumbrado a Linux. Cuando estoy en Windows, me pregunto por qué instalar programas es tan poco amigable para el usuario.
agregado el autor Raquel Fantasia, fuente
La pregunta es: ¿Por qué instalar el software durante unos minutos mediante el proceso interactivo paso a paso, si puede instalarlo a través de Herramienta de empaquetado avanzada literalmente por pocos segundos?
agregado el autor kenorb, fuente
Esto es en parte cierto, que los desarrolladores no hacen asistentes de instalación. Por lo general, hay asistentes de instalación para productos más grandes o comerciales (como Java, Open Office, productos de Adobe, Chrome), especialmente con estas aplicaciones más complejas que, para su conveniencia, proporcionan configuraciones de inicio, componentes para seleccionar o simplemente por ley para aceptar. la licencia.
agregado el autor kenorb, fuente
Es simple, a los desarrolladores y usuarios de Linux no les gusta perder su tiempo, quieren centrarse en las cosas reales que son más importantes para usar su tiempo de la manera más eficiente.
agregado el autor kenorb, fuente
Los sistemas Linux están diseñados para funcionar como servidores (teóricamente durante años sin interacción humana) y pueden omitir todos los entornos gráficos de la instalación estándar. Por lo tanto, todo proceso de instalación debe ser no interactivo o fácil de controlar mediante scripts externos o utilidades de administración de configuración (por ejemplo, CPanel, Títere , etc.)
agregado el autor kenorb, fuente
@Traubenfuchs: cualquier distribución que usa RPM esencialmente hace eso. ¿Desea instalar controladores VLC o Nvidia en OpenSuse? Haz doble clic en .rpm y verás a un agradable y amigable asistente agregar sus repositorios a tu administrador de paquetes y luego obtener el programa para ti.
agregado el autor Magus, fuente
Hay muchos magos de Linux. Los reconoces fácilmente de la barba tupida.
agregado el autor Louis Lac, fuente
@VolkerSiegel Estoy publicando este comentario de forma cruzada porque quizás el autor de la pregunta original podría querer intervenir: "Preguntar al revés" es realmente una opinión. No creo que sea justo fragmentar las respuestas a esa pregunta con esta inversa porque no te gusta cómo se hizo (y un poco pedante imo ). Cualquier respuesta que termine aquí será simplemente la inversa de una respuesta válida a la otra. Siento que la respuesta adecuada si sientes que la pregunta es al revés es agregar tu propia respuesta que explique por qué te sientes así y luego responder la pregunta desde ese punto de vista.
agregado el autor Selali Adobor, fuente
Podría tener un sesgo aquí, pero ¿qué pasa con este sitio de SE y el cierre de preguntas útiles con razones que no tienen sentido? Y por alguna razón, esta misma pregunta, invertida de una manera que abre más oportunidades para la discusión fuera del tema, es más clara
agregado el autor Selali Adobor, fuente
@MichaelHampton ty. Conocí a algunos autoproclamados "profesionales" de Linux, sin embargo, quienes realmente pensaban que eran los tipos ... y cualquiera que use otras cosas es tonto, como si fuera una religión.
agregado el autor Sasha, fuente
Algunos de ellos lo hacen. Por ejemplo, instalar Oracle en Linux es fácil una vez que logras hacer que el instalador de GUI funcione.
agregado el autor user149844, fuente
¡Por favor! Creo que la mayoría de estos comentarios deberían estar marcados. Esta pregunta fue hecha en serio y muchas veces hice lo mismo. Incluso cuando me cansé de las ventanas (la mayoría de las veces necesito Python/git/nodejs/... muchas herramientas que son una molestia en el *** en Windows), nunca entendí por qué las instalaciones de Linux (de programas individuales - no significa instalar ningún tipo de pila) requiere varios pasos por programa. Incluso tener una interfaz de clic-clic-acabado es mejor ya que el instalador en realidad le está diciendo qué hacer (no importa si es una consola (enter-enter-end) o un instalador de interfaz gráfica de usuario).
agregado el autor Luis Masuelli, fuente
Para mí, la pregunta tendría más sentido cuando se girara ...
agregado el autor gofar, fuente
agregado el autor gofar, fuente
@JamesAnderson, lamento que hayas tomado la pregunta ese día. He utilizado las distribuciones de Linux modernas (en su mayoría, Ubuntu), y sé sobre el centro de software de Ubuntu. Pero, para mí es bastante común que el software que quiero no esté en el centro de software. Tome Java por ejemplo, o cualquier programa popular de código cerrado. Si soy afortunado, encontraré un RPM, pero muchas veces, solo dan una gran cantidad de archivos en un archivo tar.gz y esperan que ejecute un script de shell para iniciar ese programa (por ejemplo, IDI de intelliJ). Luego están los archivos make y los comandos apt-get de varios pasos.
agregado el autor equivalent8, fuente
No, hay muchas formas de instalar software en Linux. A veces, descargas algo, lo mueves a una ruta ejecutable. A veces, descarga un archivo y luego ejecuta algunos archivos bash que configuran el programa, etc. Hay muchas otras formas que los usuarios deben seguir para instalar sus programas favoritos en Linux. Mi pregunta es, ¿por qué no un instalador GUI de next-next-go?
agregado el autor equivalent8, fuente
Viendo las respuestas, ¿podemos estar de acuerdo en que esta falta de instaladores realmente se basa en una convención? O tal vez digamos una visión de lo que la base de usuarios percibida podría encontrar más apropiada.
agregado el autor equivalent8, fuente
@James Anderson: no todos son fáciles de usar y no todos tienen una opción libre. Digamos que tienes que ejecutar Scientific Linux. Si desea utilizar las nuevas funciones de algún software actualizado recientemente, puede garantizar que el administrador de paquetes solo tenga una copia 3 versiones obsoletas. Incluso compilando desde la fuente, necesitará actualizar manualmente una docena de dependencias, lo que probablemente romperá otro software que haya instalado. 1 paquete desactualizado == día perdido. Los instaladores de Windows pueden ser masas infladas de grasa congelada, redistribuibles de DirectX y copias de video de Bink, pero son mucho más convenientes.
agregado el autor Arjen Dijkstra, fuente
¿Te refieres a al compilar desde la fuente?
agregado el autor edmz, fuente
No hay no falta. Windows es no Linux. Linux es no Windows.
agregado el autor edmz, fuente
Eso es para gente perezosa. Hay algunos instaladores de GUI, pero son (imho) inútiles.
agregado el autor edmz, fuente

8 Respuestas

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

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

61
agregado
@marczellm Tu comentario es un non-sequitur. No hay razón para pensar que el instalador de Windows esté más actualizado que los paquetes de repositorio.
agregado el autor user4132, fuente
@ API-Beast Solo está tan actualizado como se molestan en empaquetarlo. No conozco demasiados proyectos que hagan instaladores para cada compromiso.
agregado el autor user4132, fuente
@DanFromGermany porque Linux no existía en 1990? ;-) En una nota más seria, las primeras distribuciones (por ejemplo, slackware) vinieron con un administrador de paquetes.
agregado el autor Florian Margaine, fuente
@ API-Bestia responde completamente a la pregunta. Los desarrolladores no tienen que hacer asistentes, esta tarea complicada es manejada por las distribuciones.
agregado el autor Florian Margaine, fuente
Bueno, eso es otra cosa completamente :-) pero sí, esto es un problema. Se ha abordado con proyectos como fpm sin embargo.
agregado el autor Florian Margaine, fuente
Bueno, los desarrolladores solo deben preocuparse por crear un paquete adecuado para cada distribución que quieran admitir, por lo que necesitarán uno o más RPM, debs, scripts de compilación para puertos, etc. Todos los sistemas como desarrollador son difíciles. Es por eso que la mayoría de las personas que mantienen paquetes para las distribuciones no son en realidad los desarrolladores ascendentes.
agregado el autor Alan Shutko, fuente
Muchos proyectos do proporcionan la última versión estable sin la necesidad de control de código fuente (a menos que desee la última versión de desarrollo ...). Sin embargo, aún tendrá que compilarlos, porque es imposible crear un binario que funcione de manera simple para cada sistema operativo tipo * nix (a diferencia de Windows, que es una plataforma muy estable y homogénea). Afortunadamente, los compiladores son muy fáciles de configurar e instalar en Linux en comparación con en Windows.
agregado el autor Rufflewind, fuente
"Afortunadamente, los compiladores son muy fáciles de configurar e instalar en Linux en comparación con en Windows" Yo diría que es una opinión, y es irrelevante si se considera el hecho de que no se puede esperar que la mayoría de las personas que usan clics y listo instaladores en sus otras plataformas para comenzar a configurar compiladores (o incluso ir a una terminal) para que su programa funcione. Después de todo, Linux también se promociona como excelente para usuarios ocasionales [al menos por usuarios de Linux])
agregado el autor Selali Adobor, fuente
+1 ... "cada instalación de paquete tiene el mismo proceso".
agregado el autor geo, fuente
Una desventaja seria de este enfoque es que los paquetes están (en algunos casos seriamente) desactualizados. En Windows puedo instalar la última versión siempre que puedo; en Linux tengo que usar (instalar y entender) un cliente de control de versiones para obtener la fuente, y diferentes compiladores o Make/CMake/etc. para construirlo.
agregado el autor G al Cubo, fuente
Los paquetes @WesleyWiser son generalmente para versiones estables, no para versiones de desarrollo.
agregado el autor API-Beast, fuente
Los repositorios de @WesleyWiser son administrados por terceros, como desarrollador, no puede simplemente enviar una nueva versión. El autor de la aplicación crea un instalador de Windows, por lo que siempre está actualizado.
agregado el autor API-Beast, fuente
@FlorianMargaine Si alguna vez ha desarrollado para Linux, sabe que es un completo disparate. En primer lugar, los repositorios de distribución tienen mantenedores, si su aplicación es de código cerrado, nunca se incluirá en ellos, e incluso si es de código abierto, puede tomar varios años de uso extensivo antes de que se incluya en cualquier distribución importante. OSS no es una especie de tierra de hadas. Ni siquiera me refiero a las incompatibilidades y el mantenimiento.
agregado el autor API-Beast, fuente
Esto realmente no responde a la pregunta ya que no explica la razón. No hiciste nada más que reiterar un hecho.
agregado el autor API-Beast, fuente
@marczellm La necesidad de compilar desde la fuente es, de hecho, un problema en Linux, pero no se debe a la falta de "instaladores de tipo asistente". El uso de paquetes no requiere automáticamente el uso de la infraestructura de descarga de paquetes provista por la distribución; para que las empresas también puedan proporcionar sus propios paquetes para descargar, junto con los programas setup.exe que proporcionan para Windows. Consulte, por ejemplo, la página de descarga de Opera en opera.com/download/guide/?os= linux . El problema de compilación a partir de la fuente en sí se explica muy bien por Rufflewind.
agregado el autor jigna Bavaliya, fuente

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.

41
agregado
El software propietario definitivamente vive fuera de esto, y vienen con magos. También instalo TeXLive manualmente ya que los paquetes de distribución tienden a quedarse atrás incómodamente.
agregado el autor nst, fuente
@ Arsalan00 Piense en el modelo de Linux como AppStore; en realidad es el mismo modelo. Puede preguntar por qué no hay asistentes para Android o iOS.
agregado el autor svec, fuente
@ Arsalan00: Dejando de lado que esto cambios , no estaba hablando de lo que pueden hacer las aplicaciones ni del sandboxing, solo el modelo de instalación. Y el modelo de instalación en Linux es casi el mismo que en Windows Store/AppStore/Play Store.
agregado el autor svec, fuente
@ Arsalan00: No he necesitado escribir un comando de shell único para instalar un programa en Linux en una década. dselect ha existido por siglos, así que tienen aptitude y Synaptic. El Centro de software de Ubuntu es un poco más nuevo pero también tiene varios años.
agregado el autor Lawrence B. Crowell, fuente
@Aaronaught: por lo que sé, Windows Installer still no hace la resolución de dependencia correctamente (por ejemplo, la descarga e instalación automática de IIS al instalar DotNetNuke) y still no Hacer la actualización automática correctamente. Esas son las características absolutas de mínimo que esperaría de un sistema de administración de paquetes en funcionamiento en 1994. En 2014, esperaría mucho más.
agregado el autor Lawrence B. Crowell, fuente
@MichaelHampton: Dile. Como dije, no recuerdo haber visto ninguno en los últimos 10 a 15 años. Incluso algunos de los ridículos instaladores de manzana dulce como Asus AI Suite todavía usan MSI debajo del capó (como lo demuestra su apariencia en Agregar o quitar programas). ¿Qué software de TI o de negocios altamente esencial no utiliza Windows Installer en algún nivel?
agregado el autor SocioMatt, fuente
Uh ... si Windows no tiene un "sistema de administración de paquetes en funcionamiento", entonces ¿qué es Windows Installer ? Nunca he escuchado que los desarrolladores tengan que volver a implementar esto, al menos no en los últimos 10-15 años.
agregado el autor SocioMatt, fuente
@ JörgWMittag: Solo estás tomando la meada ahora. No hubo no sistemas de administración de paquetes en 1994 que hicieron esto de manera general. Es posible que haya habido algunos muy poco confiables en 2004. No es culpa de Microsoft o de Windows que los editores de software desordenen esto; IIS ha sido completamente programable desde que Windows Vista (irónicamente, con el nombre apropiado Gestor de paquetes ). Y para la gestión de paquetes de aplicaciones, NuGet es bastante maduro.
agregado el autor SocioMatt, fuente
@ JörgWMittag: Windows incluso ha tenido chocolatey por un tiempo, para las personas que realmente desean ese estilo de administración de paquetes. No es muy popular, y eso es por una razón.
agregado el autor SocioMatt, fuente
@Aaronaught Y he perdido la cuenta de la cantidad de programas de Windows que no usa Windows Installer o algo basado en él, y por lo tanto son innecesariamente difíciles de administrar por parte de TI.
agregado el autor Michael Hampton, fuente
@Aaronaught MATLAB viene a la mente. Adobe CS antes de CS5. Ciertamente hay otros que he olvidado desde que me mudé al lado de Linux. Y, cualquier cosa puede crear una entrada en Agregar o quitar programas; Es sólo un par de entradas de registro. No se limita a Windows Installer.
agregado el autor Michael Hampton, fuente
@ Arsalan00 - * nix está lleno de convenciones, que tal vez sean configurables, pero cambiarlas probablemente cause problemas. Como el uso de/usr/bin/usr/local/bin
agregado el autor JeffJak, fuente
Como dijo Aaronaught, Windows ha tenido un instalador de paquetes común con soporte de instalación silenciosa durante 15 años. Los que no utilizan MSI, y que dependen en gran medida de los asistentes, suelen ser malintencionados, intentando instalar un montón de archivos no deseados junto con la aplicación en sí (incluidos los preciosos instaladores de Java y Adobe Acrobat Reader). De algo a lo que la gente estaba acostumbrada, llegamos a algo donde realmente quieres prestar atención a lo que se te muestra. Realmente no es culpa de Windows o MS, son los vendedores de aplicaciones.
agregado el autor Luaan, fuente
El punto de Jörg sigue en pie. Los usuarios solo están condicionados a tolerar una deficiencia en Windows. Los gestores de paquetes de Linux son una solución técnicamente superior. Sin embargo, nada impide que un desarrollador independiente publique algunos RPM en una página web. Los usuarios deben poder descargar y hacer doble clic para abrirlo.
agregado el autor Anon, fuente
Sin embargo, la mayoría de las personas no tecnológicas que conozco preferirían descargar un instalador y ejecutar el asistente en lugar de abrir una terminal y escribir un comando. Este gestor de paquetes es genial para nosotros, geeks, pero realmente molesta a un usuario de PC común que comenzó a usar PC después de la era de Windows 98.
agregado el autor equivalent8, fuente
Android y iOS son mucho más restrictivos en la forma en que funcionan y en la forma en que permiten que las aplicaciones funcionen. Linux es el polo opuesto de eso. Los sistemas operativos móviles aplican las convenciones, Windows parece recomendar las convenciones (carpeta de archivos de programa, registro, etc.), mientras que Linux es más configuración que la convención.
agregado el autor equivalent8, fuente

La mayoría del software de código cerrado, no free-as-in-beer para Linux viene con asistentes de instalación. Lo mismo ocurre con algunos software de código cerrado, free-as-in-beer, al menos hasta que la mayoría de las grandes distribuciones lo detectan. 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 el software de código abierto sea recogido por las principales distribuciones? ¿Por qué los desarrolladores no crean asistentes de instalación durante esa fase?

En primer lugar, a muchos desarrolladores de código abierto simplemente no les importa la distribución. Escriben el software para que lo usen, y lo ponen a la vista en caso de que sea útil para otros, pero ven el empaque para distribución como un problema de otra persona. Si le gusta, alguien se encargará de incluirlo en su distribución favorita.

A los desarrolladores de código abierto que les importa hacer la distribución todavía les conviene más trabajar dentro del sistema de gestión de paquetes, porque ahí es donde están sus clientes. Los usuarios de Linux no suelen buscar en la web en busca de software. Primero buscan en su gestor de paquetes. En su defecto, buscan en los repositorios "mantenidos por la comunidad", como los PPA de Ubuntu o AUR de Arch. Si no está en esos lugares, lo más probable es que su software no sea notado, y si se hace notar, es menos probable que sea de confianza.

Renunciar a los canales de distribución existentes es algo así como decidir que los anuncios de Superbowl son demasiado caros, por lo que usted será el anfitrión de su propio campeonato de fútbol y se anunciará allí. Puede ser menos costoso, pero también es menos efectivo.

En lo que respecta a la personalización de la configuración, para 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, respaldar y restaurar.

Para software cliente como un navegador web, es mucho mejor crear un asistente de configuración que aparece 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 desea 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 adelante, por cualquier motivo, 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.

22
agregado

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

Estos gestores de paquetes proporcionan una forma de instalar programas por medio de 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 específicos de Windows, solo por la manera uniforme en que los programas se empaquetan para su 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 soportan actualización centralizada de los paquetes.

14
agregado
dpkg y APT se usan tanto en Debian como en Ubuntu. apt-get , apt-cache y aptitude son envoltorios encima de dpkg . dpkg rara vez se usa directamente, un caso de uso que se me ocurre es instalar un paquete desde un archivo .deb .
agregado el autor Jesse Vogt, fuente
@ Arsalan00 suele haber una interfaz gráfica de usuario para los administradores de paquetes, como Ubuntu Software Center o yumex. Gestor de paquetes! = Terminal.
agregado el autor Florian Margaine, fuente
amigable para el usuario es un término subjetivo. En mi opinión, la mayoría de los usuarios de computadoras son muy reacios a usar las herramientas de la línea de comandos y les resultaría más fácil y más cómodo si pudieran usar un asistente. Incluso si se necesita más tiempo.
agregado el autor equivalent8, fuente
@ Arsalan00 si usa Ubuntu, solo vaya a opera.com/download/guide/? os = linux , descargue Opera para Ubuntu y haga doble clic en el archivo descargado. No hay terminal involucrada en absoluto.
agregado el autor jigna Bavaliya, fuente

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

Las distribuciones de Linux proporcionan gestores de paquetes.

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

  • These package managers aren't standardized in operation

    A package manager is a bit like providing your binary and letting the end-user choose the installer. They can choose the terminal, or they can choose a tool with a more advanced GUI, but it doesn't afford you the same level control of the process as with a "traditional" installation wizard.

    An example of what I mean by control is documentation. You can't give your end-user instructions like "Click Next, and you should see ". You can give command-line instructions for a specific tool, but then you're not only relying on the fact the user has that tool, but also losing most of the benefits of an install wizard (after all, most wizards are providing a front-end for simple command line instructions and kicking off scripts).

    This also ties into aesthetics. Now you're depending on your end-users distribution to provide an intuitive/appropriate interface. While you are fully aware of that fact, it's not unreasonable for a more casual user to complain if double clicking your file (installer in their view) opens up an ugly package manager, does nothing at all, or worst of all opens up a terminal window. (The experiences I've had with users and their aversion of the "dos prompt"/"black and white box"/"Thing that's going to delete all their files if they look at it funny" could probably fill a book)

  • Package formats aren't standardized across platforms.

    There are tools to convert between systems like rpm and deb, but it's not reasonable to expect your end-user to convert your packages if you're using them in a situation where an installation wizard would be provided on another platform (i.e. clicks-and-done). Providing up-to-date packages for an additional package format can be rather straight forward if you have a rudimentary build system, but you're still adding a new binary that needs to be supported.

    That's also adding a new binary people have to choose from depending on their platform (it sounds minor, but I'm sure someone here can attest to having to explain x86 vs x64 before [yes, there are ways to deduce the right platform from the browser, but then you're getting into even more complicated, and harder to support, procedures])

  • Package managers are "nicer" to open-source software.

    This isn't saying that you can't share closed-source software with a package management system, it can definitely be done. But once you try to share close-source software on Linux distributions you run into a wall as far as your options for getting your software into common repositories is concerned. Things like PPAs or the openSUSE Build Service are out, and even the Canonical Partners repositories aren't enabled by default.

    That means, unless you provide your own repository, you can't many of the major features of package management systems, including automatic updates. In my opinion, this is the most important benefit across most platforms that use these systems (e.g. iOS, Android, and Windows Store).

    And even if you provide a repository (another job of variable triviality), you still need to get users to set it up (which is another layer of support, another set of non-standard approaches, and another diversion from the original point of the installer)

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 está basada en una convención, y se basa en ambas partes.

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

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

Siento que el póster tenía un punto, pero podría haberlo expresado sin rodeos, y en realidad no proporcionó razones objetivas para ese punto. Si examinas las diferencias que establecí para un gestor de paquetes y un instalador, no me sorprendería que la mayoría de ellos no presenten problemas (tal vez incluso bordeando lo pedante). Pero (disculpe lo que espero que se vea como uso legítimo de un argumento publicitario) también somos usuarios en el sitio para programadores. Veo las distribuciones de Linux como una excelente alternativa de Windows para usuarios ocasionales (entre muchas otras cosas, obviamente). No proporcionar un procedimiento de clics y acción comúnmente definido que todos estos usuarios puedan usar realmente no es ideal imo .

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

Naturalmente, puede usar la GUI para hacer la mayoría de lo que su usuario promedio debe hacer, especialmente con ciertas distribuciones (irónicamente, las cosas que están haciendo esas distribuciones no siempre están incluidas en la comunidad de código abierto jardín "]) Pero no creo que sea despreciable que las convenciones de Linux favorezcan a alguien que se sienta cómodo con una CLI, o al menos no que tenga miedo de que su apariencia signifique que hicieron algo terriblemente mal.

No estoy diciendo que esto es lo que pretenden, pero realmente es lo que veo que hacen esas convenciones. Y los sistemas de administración de paquetes en Linux parecen estar siguiendo eso. Después de todo, la mayoría de sus "desventajas" casi no existen 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 lograr que esos usuarios un botón "Continuar", que les permite saber qué es ese botón "Continuar" (he visto a los usuarios que las herramientas que dicen presionar entrar con otro texto lo han engañado), y que les avisa cuándo han llegado a ese punto. el botón "Continuar" botón "

13
agregado
"Los formatos de paquetes no están estandarizados en todas las plataformas". - Todas las distribuciones compatibles con LSB (que son la mayoría de las principales) son compatibles con el formato de paquete LSB, que es un subconjunto de RPM con todas las características eliminadas que no se pueden asignar fácilmente a DEB. Las herramientas de línea de comando, API y ABI para RPM de LSB también están estandarizadas.
agregado el autor Lawrence B. Crowell, fuente
@AssortedTrailmix: el formato del paquete LSB está diseñado deliberadamente para ser procesado por Alien. Y el usuario final nunca necesita interactuar con Alien, el administrador de paquetes de LSB en Debian se encarga de eso. Además, la creación de asistentes de instalación se cuida explícitamente en el LSB. Si el asistente del instalador se vincula solo con las bibliotecas LSB, entonces puede ejecutarse en todos los sistemas LSB y puede llamar al administrador de paquetes LSB, porque está estandarizado, y puede instalar un paquete, porque está estandarizado, y al final usted terminará con un DEB en la base de datos DPKG en Debian y un RPM en SuSE.
agregado el autor Lawrence B. Crowell, fuente
@ Jörg W Mittag Apenas llamaría el cumplimiento de la norma LSB estandarizado. En Debian, "conformidad con LSB" está utilizando la herramienta Alien que mencioné en mi publicación (y es limitada). Y nuevamente, no estamos comparando scripts de instalación con paquetes. Está comparando a los asistentes de instalación (que permiten que incluso el usuario más informal instale el software sin ver nunca la temida caja negra) a los administradores de paquetes. Requerir el uso de una herramienta como Alien no proporciona el mismo proceso que el de un asistente de instalación.
agregado el autor Selali Adobor, fuente
Entiendo eso, pero supongo que no entendí tu punto. ¿No estás simplemente confirmando lo que dije? Mi punto era que un asistente de instalación y un administrador de paquetes no son lo mismo. No estaba sugiriendo que un instalador no puede usar un administrador de paquetes. Parece que estás de acuerdo con mi opinión, pero te encuentras atrapado en la pregunta retórica "Por ejemplo, ¿tu asistente incluiría varios formatos de paquetes para instalar?"
agregado el autor Selali Adobor, fuente
Esta es una gran respuesta y explica el problema desde el punto de vista del usuario ocasional.
agregado el autor equivalent8, fuente

Para grandes extensiones es ambas cosas. 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 de actualización por separado en Windows es disruptivo e ineficiente. El usuario necesita hacer clic en las actualizaciones de Java/Flash/Adobe/... en el arranque.
  • Repositorio único, de confianza. ¿Comprueba si descarga a través de conexión segura? ¿O no ha descargado desde una actualización de Reader desde get.adobe.com.hackers.example.com/setup.exe? Incluso si usted hace la mayoría de los usuarios, especialmente no los usuarios avanzados, no . En su lugar, vaya al centro de software o 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 son compatibles con esta configuración. De acuerdo. No todos necesitan uno, pero tarde o temprano alguien querrá usarlo por cualquier razón.
  • Los ABI de las bibliotecas en varias distribuciones pueden diferir. No entrar en detalles, tener un instalador pondría la responsabilidad de que el programa trabaje en usted en lugar de que las personas mantengan un paquete en el repositorio.
  • Conectado con el anterior: necesita 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 un error, por ejemplo, no incluyó openssl 1.0.1f en su paquete. La práctica demuestra que las personas sí incluyen bibliotecas obsoletas con vulnerabilidades de seguridad conocidas.
9
agregado
Yo diría que llamar a los diálogos perturbadores o ineficientes es un poco demasiado. Si un programa tiene un sistema de actualización mal diseñado que está molestando a los usuarios tan pronto como inician la sesión y no ofrecen una opción de actualizaciones silenciosas, es sobre todo culpa del programa. Dicho esto, no encuentro muchos programas que lo hagan (la mayoría de ellos son programas que no tienen un procedimiento de inicio tradicional), y el resultado final es posiblemente más manejable que un listado rápido cada cosa. que necesita ser actualizado.
agregado el autor Selali Adobor, fuente
Y "solo, confiable, repositorio" es algo engañoso. Realmente solo es parcialmente aplicable si estás escribiendo un software que puede terminar ahí. El software propietario no termina fácilmente en los repositorios predeterminados bien soportados para las distribuciones comunes de Linux. Incluso el repositorio para socios canónicos en Ubuntu (cuyo ingreso no es trivial), está deshabilitado de forma predeterminada y muchos lo consideran inseguro, ya que muchos riesgos de seguridad en el software alojado allí se han visto sin parches mucho más tiempo que el mismo software basado en Otros métodos de actualización.
agregado el autor Selali Adobor, fuente
+1 "Tener 20 programas que se actualicen por separado en Windows es perjudicial e ineficiente".
agregado el autor IQAndreas, fuente

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

Dado que en el mundo de Linux, el terminal es lo primero, y la GUI es opcional, se vuelve 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 se pueden implementar fácilmente de manera desatendida, de la misma manera que la instalación de Windows puede ser desatendida (lo difí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 compatibles con scripts. Entre las aplicaciones de escala empresarial, los productos de Adobe, por ejemplo, son conocidos por ser bastante difíciles de instalar de una manera programada.

6
agregado
@ Arsalan00: el "usuario no tiene que hacer nada que no sea ..." rompe la automatización. Si el usuario tiene que hacer cualquier cosa , no se puede automatizar. Idealmente, debería poder encender una máquina y dejarla arrancar a través de PXE, instalar un sistema operativo y luego instalar y configurar todo lo que necesita, sin la interacción del usuario. Con Linux, puedes hacer eso (excepto quizás algunas aplicaciones, pero no he encontrado ninguna hasta ahora).
agregado el autor acemtp, fuente
Además de lo que dijo @iveqy, la mayoría de los administradores de paquetes también tienen un caché de paquetes.
agregado el autor Jesse Vogt, fuente
@ Arsalan00 generalmente los administradores de paquetes pueden hacer preguntas si realmente lo necesitan. Las instalaciones sin conexión son posibles con los administradores de paquetes, solo descargue el paquete primero, tal como lo hace cuando descarga e instala el archivo. Y por último, es más fácil de usar, la mayoría de los usuarios novatos no deberían preocuparse por "dónde desea instalar esto", etc. debería "simplemente funcionar".
agregado el autor iveqy, fuente
@ Arsalan00 pero la instalación del software no es ciencia espacial. El instalador básicamente solo copia un montón de archivos en alguna ubicación. En la mayoría de los casos, no es absolutamente necesario "hacer que [los usuarios] conozcan de qué se trata la configuración". En OSX, los usuarios simplemente arrastran las aplicaciones a la carpeta de aplicaciones. En Linux, en teoría, los usuarios pueden simplemente hacer doble clic en el paquete rpm.
agregado el autor el.pescado, fuente
Odio presionar el siguiente solo porque los desarrolladores no lo hicieron de una manera más simple.
agregado el autor Silviu Burcea, fuente
Ese es un problema fácil de resolver. Muchos instaladores de Windows tienen una opción silenciosa y están precargados con buenos valores predeterminados para que el usuario no tenga que hacer nada más que solo presionar los siguientes botones.
agregado el autor equivalent8, fuente
@MainMa tu edición realmente golpea el clavo. Si los desarrolladores lo desean, pueden hacer que sus instaladores sean scripting o silenciosos. Pero el sistema de asistentes realmente ayuda al usuario novato a conocer de qué se trata la configuración, y los asistentes informan al usuario como los administradores de paquetes no pueden. Además, las instalaciones sin conexión son una necesidad importante para muchas personas.
agregado el autor equivalent8, fuente

El público objetivo es diferente. Unix, y sistemas similares a Unix, solían ser utilizados por programadores profesionales, administradores de sistemas, ingenieros y entusiastas 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 por ahí todavía lo hacen.

Windows no está dirigido a profesionales de la misma manera y, por lo tanto, tiene instaladores de propósito más general orientados a "usuarios" que solo quieren que se instale la cosa. 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 el profesional en mente.

1
agregado
@iveqy Cualquier archivo de configuración de texto le dará muchas más capacidades que cualquier "asistente" de instalación. Si tales magos pudieran hacerlo mejor, existirían, pero no lo hacen.
agregado el autor Colen, fuente
@iveqy Me acabo de dar cuenta de que nos hemos salido del tema. Esto no tiene nada que ver con lo que dije originalmente y el hecho de que todavía no veas a esos magos es una prueba más de lo que dije.
agregado el autor Colen, fuente
Un asistente de instalación le permite personalizar más que un administrador de paquetes que generalmente se usa en Linux.
agregado el autor iveqy, fuente
eso es cierto, pero la edición de los archivos de configuración de texto no es parte del proceso de instalación de la mayoría de los administradores de paquetes. Las preguntas típicas en un proceso de instalación de Windows son "dónde quiere poner esto", un administrador de paquetes ya lo decide en el entorno de Linux y "qué componentes de este programa desea instalar", y eso ya lo resolvió El mantenedor del paquete en el caso de los gestores de paquetes. Puedes ver que un administrador de paquetes es más fácil de usar ya que se usa para Android y iPhone, (tienda de aplicaciones y Google Play).
agregado el autor iveqy, fuente