J'ai souvent posé cette question à moi-même et à d'autres personnes, et j'aimerais aborder un point que je vois souvent soulevé avant que j'arrive à comprendre pourquoi Linux voit moins d'installateurs:
Les distributions Linux fournissent des gestionnaires de paquets.
Cependant, je ne dirais pas que le gestionnaire de paquets d'une distribution Linux remplace un programme d'installation pour, notamment, les raisons suivantes:
Ces gestionnaires de paquets ne sont pas standardisés
Un gestionnaire de paquets revient un peu à 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 permet pas de contrôler le processus de la même manière qu'avec un assistant d'installation "classique".
Un exemple de ce que je veux dire par contrôle est la documentation. 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 uniquement au fait que l'utilisateur dispose 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 -end pour des instructions simples en ligne de commande et le lancement de scripts).
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 de la part d’un utilisateur occasionnel de se plaindre si un double-clic sur votre fichier (le programme d’installation à leur avis) ouvre un gestionnaire de paquets moche, ne fait rien du tout ou, pire encore, ouvre un terminal fenêtre. (Les expériences que j'ai vécues avec les utilisateurs et leur aversion pour le "prompt prompt" / "boîte noire et blanche" / "Une chose qui va supprimer tous leurs fichiers s'ils le regardent de manière amusante" pourraient probablement remplir un livre)
Les formats de paquet ne sont pas standardisés sur toutes les plateformes.
Il existe des outils pour convertir des systèmes tels que rpmet deb, mais il n'est pas raisonnable d'attendre de l'utilisateur final qu'il convertisse vos packages si vous les utilisez dans une situation où un assistant d'installation serait fourni sur une autre plate-forme (c'est-à-dire clic-and-done ) Fournir des packages mis à jour pour un format de package supplémentaire peut être assez simple si vous avez un système de construction rudimentaire, mais que vous ajoutez toujours un nouveau fichier binaire qui doit être pris en charge.
Cela ajoute également un nouveau choix 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 qu'il doit 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 à supporter])
Les gestionnaires de paquets sont "plus agréables" pour les logiciels open source.
Cela ne veut pas dire que vous ne pouvez pas partager un logiciel à source fermée avec un système de gestion de paquets, cela est tout à fait possible. Mais une fois que vous essayez de partager un logiciel source près sur des distributions Linux, vous vous retrouvez face à des difficultés pour obtenir votre logiciel dans des référentiels communs. Des éléments tels que les PPA ou le service openSUSE Build sont supprimés et même les référentiels des partenaires Canonical ne sont pas activés par défaut.
Cela signifie que, sauf si vous fournissez votre propre référentiel, vous ne pouvez pas utiliser les principales fonctionnalités des systèmes de gestion de paquets, y compris les mises à jour automatiques. À mon avis , il s'agit du principal avantage de la plupart des plates-formes utilisant 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 (une autre couche de support, un autre ensemble d'approches non standard et un autre détournement du point d'origine de l'interface utilisateur). installateur)
Cela dit, je n’ai toujours pas abordé le problème initial, pourquoi les installateurs sont moins courants sous Linux malgré ces facteurs (entre autres). La question initiale demande si c'est technique, ou basé sur des conventions, et c'est basé sur les deux en partie.
Si vous examinez les facteurs ci-dessus que j'ai mentionnés, ils compliquent également la tâche d'un installateur de type "assistant". Par exemple, votre assistant inclurait-il plusieurs formats de paquet à installer? Comment gérez-vous l'aspect et la convivialité d'une distribution à l'autre? La liste est longue, et une chose que les paquets que ne vous offrent que rien de tout cela sera votre préoccupation ( pour le meilleur ou pour le pire ) tant que vous fournissez les bons paquets. Et selon la nature de votre projet, vous pouvez commencer à tirer parti de ces ressources plus "spécialisées", telles que la soumission d'applications au Centre de logiciel Ubuntu. Tout cela se rapporterait à la technique.
Mais l'aspect que je trouve personnellement être le moteur est la convention. (J'espère avoir enterré cela assez profondément pour que les gens qui ont rétrogradé cette autre réponse à l'oubli aient arrêté de lire ..)
Je pense que cette affiche avait un sens, mais aurait pu l'exprimer de manière trop crue, sans fournir de raisons objectives à ce point. Si vous examinez les différences que j'ai mentionnées pour un gestionnaire de paquets et un installateur, je ne serais pas surpris si vous trouviez que la plupart d'entre elles étaient quasiment sans problèmes (peut-être même à la limite de pédant). Mais (excusez ce que j'espère être considéré comme une utilisation légitime d'un argument ad hominem), nous sommes également des utilisateurs sur site pour les programmeurs. Je considère les distributions Linux comme une excellente alternative à Windows pour les utilisateurs occasionnels (entre autres choses évidemment). Ne pas fournir une procédure clics-et-fait généralement défini que tous ces utilisateurs peuvent utiliser est vraiment pas idéal imo .
Mais en même temps, je ne trouve pas que beaucoup de choses dans Linux soient particulièrement idéales pour ce groupe non plus. Bien sûr , certains ont distros gestionnaires de paquets basés sur l' interface graphique, mais que signifie que ces gens doivent commencer à chercher dans la façon d'utiliser un outil distinct, ce n'est pas strictement axée sur l'installation de votre programme (comparer ce et ce à cela ).
Naturellement, vous pouvez utiliser l’interface graphique pour créer la majorité des tâches que votre utilisateur occasionnel moyen doit faire, en particulier avec certaines distributions (paradoxalement, les activités de ces distributions ne sont pas toujours acceptées par la communauté open source [regardez les plaintes concernant Ubuntu et ses murs] garden "]) Mais je ne pense pas qu'il soit déniable que les conventions de Linux favorisent ceux qui sont à l'aise avec une interface de ligne de commande, ou du moins qu'ils ne craignent pas pour autant que son apparence ne leur ait fait faire une chose horriblement mal.
Je ne dis pas que c'est ce qu'ils visent, mais c'est vraiment ce que je vois dans 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 quasi inexistants si votre utilisateur final est plus à l'aise avec les concepts sous-jacents.
Les installateurs de la plupart des autres plates-formes ne sont pas vraiment affectés par cela et sont conçus pour, pour citer un commentaire à la question, "99,99% des utilisateurs [peuvent] cliquer à l'aveuglette sur" Continuer ". Le problème de la gestion des paquets est de les amener à un bouton "Continuer", leur indiquant ce qu'est le bouton "Continuer" (j'ai vu des utilisateurs se faire tromper par des outils disant d'appuyer sur Entrée avec un autre texte), et leur permettant de savoir quand ils ont cliqué sur cette touche " l'étape "Continuer" ".