Pourquoi les applications Linux mettent souvent la langue dans laquelle il a été écrit?

Lors de la présentation d'applications, Windows et Mac parlent principalement de fonctionnalités. Les applications Linux, d'autre part, ont plus de détails sur la langue utilisée pour l'écrire (et les bibliothèques qui l'accompagnent) plutôt que sur les fonctionnalités. Pourquoi donc?

Je pourrais comprendre la différence entre GTK + et QT faire une différence juste en raison des exigences d'intégration de bureau, mais C vs C ++ vs Python vs Assemblée vs etc? Vraiment?

Par exemple: foo est un simple blah blah écrit en C / GTK +.

Je pense que l'user Linux traditionnel (un bricoleur geek qui a effectivement installé le système par soi-même) se soucie de cette information (quelle technologie est derrière cet outil?). Je suis aussi un de ces gars geek qui, par exemple, s'abstenir d'installer et d'utiliser un package juste parce qu'il utilise une technologie que je n'aime pas. Certains appellent ce genre de comportement la religion bien sûr. C'est idiot, n'est-ce pas?

Quoi qu'il en soit, je peux penser à deux raisons:

  • Les packagers sont aussi geek (sinon plus) que les users de Linux, donc ils ont trouvé une bonne idée d'append de telles informations.

  • Je pense que quand ces emballeurs mettent de telles informations sur leurs descriptions de packages, ils le font probablement comme une forme de promotion. Cela fonctionne parfois (ça m'a marché plusieurs fois).

C'est juste une supposition bien sûr.

Mon sens est lié à la deuxième des quatre libertés logicielles :

La liberté d'étudier comment fonctionne le programme, et le changer pour qu'il fasse ce que vous souhaitez (liberté 1). L'access au code source est une condition préalable à cela.

La publicité de la langue (ou d'autres caractéristiques techniques) soutient la capacité des gens à choisir, et encourage la participation à des projets par des personnes qui maîsortingsent ces langues.

Cela peut être partiellement historique. Même dans un passé pas si lointain, il était habituel pour les administrateurs système individuels de build et d'installer tout ce qui fonctionnait sur leur système.

Les notes sur la langue et les bibliothèques utilisées pour implémenter un outil donnent un indice à l'administrateur quant à la quantité de travail que ce process va être pour son système.

En cette ère d'outils de gestion de packages omniprésents et de grande envergure, c'est un peu anachronique, mais la culture unix est conservasortingce dans le sens de ne pas jeter des choses qui semblent fonctionner, donc il faudra un certain time avant que l'habitude ne décède.

En réponse à la réponse de jasonwryans :

Si vous nommez la langue dans laquelle elle a été écrite, la personne qui la reçoit peut estimer à quel point il sera difficile de fournir un correctif, d'get des informations ou d'étendre le programme.

Bien sûr, cela n'a de sens que si vous êtes un programmeur.

Où avez-vous vu les résumés? Dans un référentiel, ou un package comme .deb ou .rpm?

Si vous le construisez à partir de la source, les informations peuvent être utiles pour identifier, si vous devez installer d'autres choses (compliler, bibliothèques, build-tools).

Unix, et maintenant LInux et les BSD, ont toujours eu une base logicielle vraiment fracturée, et une base matérielle beaucoup plus diverse existait dans un passé plutôt récent. Il était important de savoir que certains logiciels fonctionnaient dans les intepreters que vous aviez sur votre système, ou que vous pouviez comstackr le code source. Si vous ne disposez pas d'un interpréteur Common Lisp, d'un interpréteur Tcl ou d'un interprète quelconque, vous ne voulez pas déranger le téléchargement de la source, mais seulement pour découvrir que vous ne pouvez pas l'exécuter.

Avoir une description de ce que quelque chose de la langue a empêché beaucoup de time perdu.

Lorsqu'on vous request «quelle est cette chose?», Un développeur aura tendance à décrire sa nature, qui est pour eux liée au code source, mais plutôt à sa fonction. On espère que la description sera plus cinput sur l'user avant de se refind sur un package, mais la mention de la langue peut être pertinente, par exemple pour l'extensibilité et la scriptabilité, ou pour attirer des consortingbuteurs.

De mon sharepoint vue, une telle information est essentielle pour attirer de nouveaux consortingbuteurs, et donner aux users potentiels une idée immédiate de la quantité de travail que cela pourrait entraîner pour intégrer l'application dans leur système.

  • Un aspect général est les bibliothèques utilisées lors de l' exécution de l'application.

Certaines installations sont limitées à quelques boîtes à outils sélectionnées, comme GTK + mais pas QT, ou vice versa. Pour un administrateur qui maintient un système et met régulièrement à jour ses composants sur une longue période, cela peut être une question pratique et non religieuse.

  • Un autre aspect est les bibliothèques utilisées et les prérequirejs nécessaires pour comstackr l'application.

Ie pour les users d'une dissortingbution Linux basée sur la source, cela fait une grande différence si une application est écrite en C, ou en Objective-C, parce que leur compilateur doit soutenir la langue en premier lieu. D'autres langues peuvent rendre nécessaire l'installation d'une énorme stack de bibliothèques. La question est donc, encore une fois, combien de travail vous êtes prêt à accepter afin de comstackr cette application.

  • Un aspect différent est l'intention d'attirer des consortingbuteurs.

La plupart des développeurs préfèrent un petit nombre de langues ou peuvent simplement manquer d'expérience dans d'autres langues. Afin de permettre à un plus grand nombre de personnes de consortingbuer à une application, certains projets ont même divisé leurs sources en deux langues différentes (comme Wesnoth, Vega Ssortingke, Naev, etc.). L'un d'eux pour l'application principale (comme C ou C ++), l'autre pour la modification facile (comme Python ou Lua). Voici un lien vers un chapitre de «L'architecture des applications Open Source» qui décrit comment et pourquoi cela a été fait dans Wesnoth.

  • Enfin, il y a évidemment beaucoup de parti pris et de préjugés contre certaines langues.

Je vais juste dire que j'ai vu des logiciels horriblement inefficaces écrits dans n'importe quelle langue. Si vous me requestz, pour l'efficacité, la qualité du code de l'application est beaucoup plus importante que la langue dans laquelle il est écrit.

Je pense que beaucoup de cela a à voir avec la publicité de performance. Une application écrite dans un langage compilé (C, C ++, …) va beaucoup mieux que l'écriture dans un langage script (perl, python, …).

Mais il est également lié à la compatibilité. Une application écrite dans un langage de script est également susceptible d'être plus portable à travers les architectures et les systèmes d'exploitation avec peu ou pas de modification.

Sur les systèmes de bureau / server d'aujourd'hui, il peut ne pas être aussi pertinent, mais pour les systèmes plus petits allant des systèmes embarqués aux netbooks SSD et aux tablettes, les langages ou bibliothèques utilisés par un programme peuvent être un problème de taille ou de taille considérations de portabilité.

En ce qui concerne la taille: l'ajout d'un interpréteur pour une langue supplémentaire, avec tous les modules standard et les modules complémentaires généralement utilisés, peut facilement append des centaines de mégaoctets aux besoins de stockage. Il en va de même pour les familles de bibliothèques, en particulier celles associées aux principaux environnements de bureau comme Gnome et KDE. Pire encore, aller de n en n+1 programmes Perl peut ne pas append autant aux besoins d'utilisation de memory, puisqu'une grande quantité de memory peut être partagée, mais allant de n programmes Perl et 0 programmes Python à n programmes Perl et 1 programme Python se traduit par un pic important de l'utilisation de la memory. Cela devient encore plus problématique lorsque chaque logiciel libre d'écriture a son propre langage de script / radtool préféré dans lequel il veut programmer … Perl, Python, PHP, Ruby, JavaScript, Bourne shell, Bash, Csh, ….

En ce qui concerne la portabilité: De nombreux langages interprétés (ainsi que des frameworks de bibliothèques) utilisent beaucoup les fonctionnalités disponibles sur les gros systèmes de bureau / server Linux, mais pas nécessairement sur les systèmes plus petits / embeddeds / sans MMU. La dépendance au chargement dynamic du module .so à l'exécution vient à l'esprit …