Pourquoi les applications Linux mettent-elles souvent la langue avec laquelle elles ont été écrites dans le résumé?

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 connaître la différence entre GTK + et QT faisant une différence simplement en raison des exigences d'intégration du bureau, mais C vs C ++ vs Python vs Assembly vs etc.? Vraiment?

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

Je pense que l'utilisateur Linux traditionnel (un bricoleur geek qui a effectivement installé le système par lui-même) se soucie de ces informations (quelle technologie est derrière cet outil?). Je fais aussi partie de ces gars geek qui, par exemple, s'abstiendraient d'installer et d'utiliser un package simplement parce qu'il utilise une technologie que je n'aime pas. Certains appellent ce genre de comportement religion bien sûr. Stupide n'est-ce pas?

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

• Les emballeurs sont aussi geek (sinon plus) que ces utilisateurs Linux, donc ils ont trouvé que c'était une bonne idée d'ajouter de telles informations.

• Je pense que lorsque ces emballeurs mettent de telles informations sur la description de leurs paquets, ils le font probablement comme une forme de promotion. Cela fonctionne parfois (cela a fonctionné plusieurs fois sur moi).

C'est juste une supposition bien sûr.

Mon sentiment est que cela concerne la deuxième des quatre libertés logicielles :

La liberté d'étudier le fonctionnement du programme et de le modifier pour qu'il fasse ce que vous voulez (liberté 1). L'accès au code source en est une condition préalable.

La publicité de la langue (ou d'autres caractéristiques techniques) favorise la capacité de choix des personnes et encourage la participation à des projets de personnes qui maîtrisent 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 construire 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 à l’administrateur une indication sur la quantité de travail que ce processus va représenter pour leur système.

En cette ère d'outils de gestion de paquets omniprésents et de grande envergure, c'est un peu anachronique, mais la culture Unix est conservatrice dans le sens de ne pas jeter les choses qui semblent fonctionner, il faudra donc un certain temps avant que l'habitude ne meure.

En complément de la réponse des jasonwryans :

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

Bien sûr, cela n'a de sens que si vous êtes 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 déterminer si vous devez installer d'autres éléments (compilateur, bibliothèques, outils de génération).

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

Avoir une description de la langue dans laquelle quelque chose se trouvait a évité beaucoup de temps perdu.

Lorsqu'on lui demande «qu'est-ce que c'est?», Un développeur aura tendance à décrire sa nature, qui pour lui est liée au code source, plutôt qu'à sa fonction. On espère que quelqu'un réécrira la description pour qu'elle soit plus centrée sur l'utilisateur avant de se retrouver sur un package, mais mentionner le langage peut toujours être pertinent, par exemple pour l'extensibilité et la scriptabilité, ou utile pour avoir l'opportunité d'attirer des contributeurs.

De mon point de vue, ces informations sont essentielles pour attirer de nouveaux contributeurs, ainsi que pour donner aux utilisateurs potentiels une idée immédiate de la quantité de travail que cela pourrait impliquer 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 kits d'outils sélectionnés, comme GTK + mais pas QT, ou vice versa. Pour un administrateur qui gère un système et met régulièrement à jour ses composants sur une longue période, cela peut être uniquement une question pratique et non religieuse.

• Un autre aspect concerne les bibliothèques utilisées et les prérequis nécessaires pour compiler l'application.

C'est-à-dire pour les utilisateurs d'une distribution Linux basée sur la source, cela fait une grande différence si une application est écrite en C ou en Objective-C, car leur compilateur doit prendre en charge le langage en premier lieu. D'autres langues peuvent nécessiter l'installation d'une énorme pile de bibliothèques. La question est alors, encore une fois, combien de travail vous êtes prêt à accepter afin de compiler cette application.

• Un autre aspect est l'intention d'attirer des contributeurs.

La plupart des développeurs ont une préférence pour un petit nombre de langues, ou peuvent simplement manquer d'expérience dans d'autres. Afin de permettre à un plus grand nombre de personnes de contribuer à une application, certains projets ont même divisé leurs sources en deux langues différentes (comme Wesnoth, Vega Strike, Naev, pour n'en nommer que quelques-unes). L'un d'eux pour l'application principale (comme C ou C ++), l'autre pour une 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 biais et de préjugés contre certaines langues.

Je dirai simplement que j'ai vu des logiciels horriblement inefficaces écrits dans n'importe quelle langue. Si vous me demandez, pour plus d'efficacité, la qualité du code de l'application est beaucoup plus importante que la langue dans laquelle elle est écrite.

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

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

Sur les systèmes de bureau / serveur d'aujourd'hui, cela peut ne pas être si pertinent, mais pour les petits systèmes allant des systèmes embarqués aux netbooks et tablettes SSD, les langues ou les bibliothèques utilisées par un programme peuvent être un problème de rupture, à la fois en raison de la taille et considérations de portabilité.

En ce qui concerne la taille: l'ajout d'un interprète pour une langue supplémentaire, ainsi que tous les modules standard et modules complémentaires généralement utilisés, peuvent facilement ajouter 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, passer de l'exécution nà des n+1programmes Perl peut ne pas ajouter beaucoup aux exigences d'utilisation de la mémoire, car beaucoup de mémoire peut être partagée, mais passer des nprogrammes Perl et 0 programmes Python ànLes programmes Perl et 1 programme Python entraînent une augmentation significative de l'utilisation de la mémoire. Cela devient encore plus problématique lorsque chaque imbécile écrivant un logiciel libre a son propre langage de script / radtool préféré dans lequel il souhaite 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 cadres de bibliothèque) font un usage intensif des fonctionnalités qui peuvent être disponibles sur les gros systèmes de bureau / serveur Linux mais pas nécessairement disponibles sur les systèmes plus petits / intégrés / sans MMU. La dépendance au .sochargement dynamique du module au moment de l'exécution vient à l'esprit ...