Pourquoi les développeurs ne font-ils pas d'assistants d'installation sur Linux?
Je suis sûr qu'il ne s'agit pas de paresse ou de quelque chose comme ça, mais je n'arrive pas à comprendre pourquoi les développeurs d'applications, même principalement destinées aux consommateurs, ne font aucune sorte d'assistant d'installation où vous allez suivant-suivant-terminer. Les mêmes applications ont généralement des installateurs pour Windows et Mac OS, alors pourquoi pas Linux?
Y a-t-il une raison technique à cette tendance ou s'agit-il simplement d'une convention?
EDIT (23-09-2014): Cette question n'a pas été posée pour lancer une guerre des flammes Windows vs Linux. J'ai utilisé les 3 principaux systèmes d'exploitation et à part Linux, les deux autres (Windows et Mac OS) ont tous deux des installateurs. Je n'ai pas encore installé Oracle mais quoi que j'aie besoin d'installer, je n'ai jamais vu de programme d'installation GUI pour Linux.
Oui, je sais que Linux a des gestionnaires de paquets, donc les développeurs n'ont pas "besoin" de faire les installateurs. Mais il existe encore une énorme quantité de logiciels qui sont soit obsolètes dans les gestionnaires de packages par défaut, soit tout simplement non disponibles. De plus, puisque Linux est vendu comme une alternative à Windows pour les utilisateurs occasionnels (Ubuntu fait de gros efforts dans ce domaine), il serait beaucoup plus logique de simplement donner aux utilisateurs ce qu'ils connaissent.
Prenons par exemple la configuration d'une pile LAMP. Ce sont tous des logiciels open source dans les référentiels par défaut, mais pouvez-vous tout configurer en une seule fois sans script? Regardez maintenant le serveur WAMP sous Windows. Vous venez d'exécuter un programme d'installation et il installe plusieurs logiciels de telle manière qu'ils fonctionnent bien les uns avec les autres. Ensuite, il définit de bonnes valeurs par défaut et d'autres choses. Les installateurs peuvent le faire, pas les gestionnaires de packages. Oui, vous pouvez trouver un script pour cela en ligne, mais où? Et lequel?
Les installateurs ne sont pas une technologie obsolète du passé. Ils sont toujours utiles et 95% des utilisateurs sont déjà à l'aise avec eux.
Les développeurs ont juste besoin de fournir un package pour une distribution. Chaque distribution a alors un moyen d'installer ce package. Cette façon peut être dans un terminal (apt-get) ou via une interface graphique, par ex. Centre logiciel Ubuntu.
La beauté est que les développeurs n'ont qu'à se soucier de construire un package approprié; les distributeurs se chargent du reste, et chaque installation de package a le même processus.
Parce qu'ils n'en ont pas besoin. Les distributions Linux ont généralement des systèmes de gestion de packages fonctionnels, contrairement à Windows, où chaque application doit réimplémenter l'installation et la mise à jour encore et encore et encore et encore.
La plupart des logiciels de sources fermées, non libres de la bière pour Linux ne sont livrés avec des assistants d'installation. Il en va de même pour certains logiciels à source fermée, gratuits comme de la bière, au moins jusqu'à ce que la plupart des grandes distributions les récupèrent. Pour les logiciels open source, les gestionnaires de packages sont une solution clairement supérieure.
Qu'en est-il donc des premières étapes avant que les logiciels open source ne soient récupérés par les principales distributions? Pourquoi les développeurs ne créent-ils pas d'assistants d'installation pendant cette phase?
Tout d'abord, beaucoup de développeurs open source ne se soucient pas de la distribution. Ils écrivent des logiciels pour eux-mêmes et les mettent au cas où ils seraient utiles à d'autres, mais ils voient le packaging pour la distribution comme le problème de quelqu'un d'autre. S'il est assez apprécié, quelqu'un se chargera de l'intégrer dans sa distribution préférée.
Les développeurs open source qui font se soucient de la distribution sont encore mieux de travailler dans le système de gestionnaire de paquets, car c'est là que se trouvent leurs clients. Les utilisateurs de Linux ne recherchent généralement pas de logiciels sur le Web. Ils recherchent d'abord leur gestionnaire de paquets. A défaut, ils recherchent les référentiels "maintenus par la communauté", comme les PPA d'Ubuntu ou l'AUR d'Arch. Si vous n'êtes pas dans ces endroits, votre logiciel ne sera probablement pas remarqué, et s'il est remarqué, il est moins susceptible d'être approuvé.
Renoncer à ces canaux de distribution existants, c'est un peu comme décider que les annonces Superbowl sont trop chères, donc vous allez héberger votre propre championnat de football et y faire de la publicité à la place. C'est peut-être moins coûteux, mais c'est aussi moins efficace.
En ce qui concerne la personnalisation de la configuration, pour des logiciels comme un serveur Web qui sont traditionnellement plus faciles à gérer avec un fichier de configuration, ce qui facilite le partage, la sauvegarde et la restauration de la configuration.
Pour un logiciel client comme un navigateur Web, il est préférable de créer un assistant de configuration qui apparaît la première fois qu'un nouvel utilisateur exécute le logiciel, plutôt que de le faire au moment de l'installation. La principale raison est que Linux est un système d'exploitation multi-utilisateurs, vous devez donc le personnaliser de toute façon. Cela facilite également la réexécution de l'assistant de configuration ultérieurement, quelle qu'en soit la raison, sans avoir à conserver le programme d'installation pour réinstaller l'intégralité du logiciel. Ce type d'assistant est assez courant dans les logiciels Linux.
Les distributions Linux (aussi, je pense, en tant qu'unices BSD) ont une interface conviviale pour l'installation du programme, via ce qu'on appelle les gestionnaires de paquets (ou la gestion des ports dans le cas BSD): pacman pour Arch, dpkg pour Debian/Ubuntu , etc.
Ces gestionnaires de paquets fournissent un moyen d'installer des programmes au moyen de fichiers de configuration uniformes. Une fois que le programme dont vous avez besoin est conditionné en fonction du gestionnaire de packages de votre distribution, vous pouvez simplement exécuter sa commande d'installation sur le package sélectionné (avec des personnalisations spécifiques à l'utilisateur occasionnelles, mais souvent aucune) et le gestionnaire fait le reste.
Les gestionnaires de packages sont généralement plus conviviaux que les processus d'installation spécifiques aux programmes de Windows, uniquement pour la façon uniforme dont les programmes sont conditionnés pour l'installation. Ils vous permettent généralement également d'interroger la base de données du gestionnaire de packages pour le programme que vous recherchez, voir ses dépendances.
Ils prennent également en charge la mise à jour centralisée des packages.
Je me suis souvent posé cette question, ainsi qu'à d'autres, et j'aimerais aborder un point que je vois souvent évoqué avant de comprendre pourquoi Linux voit moins d'installateurs:
Les distributions Linux fournissent des gestionnaires de packages.
Cependant, je ne dirais pas que le gestionnaire de packages d'une distribution Linux remplace un programme d'installation pour, en partie, les raisons suivantes:
Ces gestionnaires de packages ne sont pas standardisés en fonctionnement
Un gestionnaire de paquets, c'est un peu comme fournir votre binaire et laisser l'utilisateur final choisir l'installateur. Ils peuvent choisir le terminal ou choisir un outil avec une interface graphique plus avancée, mais cela ne vous offre pas le même niveau de contrôle du processus qu'avec un assistant d'installation "traditionnel".
La documentation est un exemple de ce que j'entends par contrôle. Vous ne pouvez pas donner à votre utilisateur final des instructions telles que "Cliquez sur Suivant, et vous devriez voir". Vous pouvez donner des instructions en ligne de commande pour un outil spécifique, mais vous ne vous fiez pas seulement au fait que l'utilisateur possède cet outil, mais vous perdez également la plupart des avantages d'un assistant d'installation (après tout, la plupart des assistants fournissent une façade -fin pour des instructions de ligne de commande simples et des scripts de lancement).
Cela est également lié à l'esthétique. Vous dépendez maintenant de la distribution de vos utilisateurs finaux pour fournir une interface intuitive/appropriée. Bien que vous soyez pleinement conscient de ce fait, il n'est pas déraisonnable pour un utilisateur plus occasionnel de se plaindre si un double-clic sur votre fichier (programme d'installation à leur avis) ouvre un gestionnaire de paquets laid, ne fait rien du tout, ou pire ouvre une fenêtre de terminal. (Les expériences que j'ai eues avec les utilisateurs et leur aversion pour le "dos Prompt"/"boîte noir et blanc"/"Chose qui va supprimer tous leurs fichiers s'ils le regardent drôle" pourraient probablement remplir un livre)
Les formats de package ne sont pas standardisés sur toutes les plateformes.
Il existe des outils pour convertir entre des systèmes comme
rpmetdeb, mais il n'est pas raisonnable de s'attendre à ce que votre utilisateur final convertisse vos packages si vous les utilisez dans une situation où un assistant d'installation le ferait être fourni sur une autre plate-forme (c'est-à-dire clics et faits). Fournir des packages à jour pour un format de package supplémentaire peut être assez simple si vous avez un système de construction rudimentaire, mais vous ajoutez toujours un nouveau binaire qui doit être pris en charge.Cela ajoute également un nouveau binaire que les gens doivent choisir en fonction de leur plate-forme (cela semble mineur, mais je suis sûr que quelqu'un ici peut attester d'avoir à expliquer x86 vs x64 avant [oui, il existe des moyens de déduire la bonne plate-forme de la navigateur, mais vous entrez dans des procédures encore plus compliquées et plus difficiles à prendre en charge])
Les gestionnaires de packages sont "plus agréables" pour les logiciels open source.
Cela ne veut pas dire que vous ne pouvez pas partager un logiciel de source fermée avec un système de gestion de packages, cela peut certainement être fait. Mais une fois que vous essayez de partager des logiciels de source proche sur des distributions Linux, vous vous heurtez à un mur en ce qui concerne vos options pour placer vos logiciels dans des référentiels communs. Des éléments tels que les PPA ou le service de construction openSUSE sont sortis, et même les référentiels Canonical Partners ne sont pas activés par défaut.
Cela signifie que, à moins que vous ne fournissiez votre propre référentiel, vous ne pouvez pas utiliser la plupart des principales fonctionnalités des systèmes de gestion de packages, y compris les mises à jour automatiques. À mon avis , c'est l'avantage le plus important sur la plupart des plates-formes qui utilisent ces systèmes (par exemple iOS, Android et Windows Store).
Et même si vous fournissez un référentiel (un autre travail de trivialité variable), vous devez toujours demander aux utilisateurs de le configurer (qui est une autre couche de support, un autre ensemble d'approches non standard et un autre détournement du point d'origine du installateur)
Maintenant, après avoir dit tout cela, je n'ai toujours pas résolu le problème d'origine, pourquoi les installateurs sont moins courants sur Linux malgré ces facteurs (entre autres). La question initiale demande si elle est technique ou basée sur une convention, et elle est basée sur les deux en partie.
Si vous regardez les facteurs ci-dessus que j'ai mentionnés, ils rendent également les choses plus complexes pour un installateur "semblable à un assistant". Par exemple, votre assistant inclurait-il plusieurs formats de package à installer? Comment gérez-vous l'apparence dans les distributions? La liste continue, et une chose que les packages vous offrent , c'est que rien de tout cela ne vous concernera ( pour le meilleur ou pour le pire ) tant que vous fournissez les bons packages. Et selon la nature de votre projet, vous pouvez commencer à profiter de ces ressources plus "spécialisées", comme la soumission d'applications au Ubuntu Software Center. Tout cela concernerait la technique.
Mais l'aspect que je trouve personnellement le moteur est la convention. (J'espère avoir enterré cela suffisamment profondément pour que les gens qui ont dévalorisé cette autre réponse à l'oubli aient arrêté de lire ..)
Je pense que l'affiche avait un point, mais aurait pu le dire trop brutalement, et n'a pas fourni de raisons objectives pour ce point. Si vous examinez les différences que j'ai indiquées pour un gestionnaire de paquets et un installateur, je ne serais pas surpris si vous trouviez que la plupart d'entre eux n'étaient presque pas des problèmes (peut-être même à la limite de pédant). Mais (excusez ce que j'espère est considéré comme une utilisation légitime d'un argument ad hominem), nous sommes également des utilisateurs sur site pour les programmeurs. Je vois les distributions Linux comme une excellente alternative à Windows pour les utilisateurs occasionnels (parmi beaucoup d'autres choses évidemment). Ne pas fournir une procédure de clics et d’effets couramment définie que tous ces utilisateurs peuvent utiliser n’est vraiment pas idéal imo .
Mais en même temps, je ne trouve pas que beaucoup de choses sous Linux soient particulièrement idéales pour ce groupe. Bien sûr, certaines distributions ont des gestionnaires de packages basés sur une interface graphique, mais cela signifie que ces personnes doivent commencer à chercher comment utiliser un outil distinct, qui n'est pas strictement axé sur l'installation de votre programme (comparer this et - ce à ce ).
Naturellement, vous pouvez utiliser l'interface graphique pour faire la majorité de ce que votre utilisateur occasionnel moyen doit faire, en particulier avec certaines distributions (ironiquement, les choses que ces distributions font ne sont pas toujours adoptées dans la communauté open source [regardez les plaintes concernant Ubuntu et c'est "muré" garden "]) Mais je ne pense pas que ce soit indéniable que les conventions Linux favorisent quelqu'un qui est à l'aise avec une CLI, ou à tout le moins qui n'a pas peur de son apparence signifie qu'il a fait quelque chose d'horriblement mal.
Je ne dis pas que c'est ce qu'ils visent, mais c'est vraiment ce que je vois faire ces conventions. Et les systèmes de gestion de paquets sous Linux semblent suivre cela. Après tout, la plupart de leurs "inconvénients" sont presque inexistants si votre utilisateur final est plus à l'aise avec les concepts sous-jacents.
Les installateurs sur la plupart des autres plates-formes ne sont pas vraiment affectés par cela, et sont conçus ainsi, pour citer un commentaire sur la question, "99,99% des utilisateurs [peuvent] cliquer aveuglément sur" Continuer ". Le problème avec la gestion des packages est d'amener ces utilisateurs à un bouton "Continuer", leur faisant savoir ce qu'est ce bouton "Continuer" (j'ai vu des utilisateurs se faire tromper par des outils qui ont dit appuyer sur Entrée avec un autre texte), et leur faire savoir quand ils ont frappé cette "côte en cliquant" l'étape "Bouton" Continuer ".
Pour les grandes étendues, c'est les deux. Le modèle de distribution Linux est plus proche de l'AppStore/Play Store que de celui traditionnel de Windows/Mac OS X - et même cette plate-forme se déplace à partir de ce que j'ai entendu.
La convention est que c'est plus simple. La plupart des arguments pour l'AppStore/Play Store s'appliquent également à Linux:
- Mises à jour automatiques. La mise à jour de 20 programmes séparément sous Windows est perturbatrice et inefficace. L'utilisateur doit cliquer sur les mises à jour Java/Flash/Adobe/... au démarrage.
- Référentiel unique et fiable. Vérifiez-vous si vous téléchargez via une connexion sécurisée? Ou vous n'avez pas téléchargé depuis une mise à jour de Reader depuis get.Adobe.com.hackers.example.com/setup.exe? Même si vous faites la plupart des utilisateurs, surtout pas les utilisateurs avancés, ne le faites pas. Au lieu de cela, vous allez au centre de logiciels ou à un programme similaire sous Linux et obtenez une copie de confiance.
De plus, les avantages suivants peuvent ne pas s'appliquer à l'AppStore/Play Store:
- Tous les Linux n'ont pas d'interface graphique - pensez au serveur http - mais la plupart des distributions prennent en charge une telle configuration. D'accord. Tout le monde n'en a pas besoin, mais tôt ou tard, quelqu'un voudra l'utiliser pour une raison quelconque.
- Les ABI des bibliothèques sur diverses distributions peuvent différer. Ne pas entrer dans les détails en ayant un installateur mettrait la responsabilité du programme travaillant sur vous au lieu de personnes qui gèrent un paquet dans le référentiel.
- Connecté avec le précédent - vous devez gérer les dépendances d'une manière ou d'une autre. Le regroupement est considéré comme inapproprié pour une raison - dans ce cas, vous devez vous assurer que vous avez mis à jour la bibliothèque vers la version sans bogue - par exemple, vous n'avez pas inclus openssl 1.0.1f dans votre bundle. La pratique montre que les gens incluent des bibliothèques obsolètes avec des failles de sécurité connues.
Généralement, l'installation n'a pas besoin d'interaction avec un utilisateur (la plupart apt-get packages par exemple), ou peut être scripté. Cela facilite l'automatisation afin de déployer un logiciel sur de nombreuses machines. Au lieu de faire des choses via l'assistant, vous faites ces mêmes choses via des scripts ou des fichiers de configuration.
Étant donné que dans le monde Linux, le terminal vient en premier et l'interface graphique est facultative, il devient évident pourquoi ils manquent d'assistants d'installation réels.
Windows, en revanche, est très orienté utilisateur. La plupart des fichiers MSI peuvent être facilement déployés sans surveillance, de la même manière que l'installation de Windows peut être sans surveillance (la facilité/difficulté de faire fonctionner WAIK est un sujet différent). Cela signifie également qu'un tas d'applications pour Windows ne sont pas basées sur MSI et ne sont pas scriptables. Parmi les applications à l'échelle de l'entreprise, les produits Adobe, par exemple, sont connus pour être assez difficiles à installer de manière scriptée.