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

19

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

Jordan Parmer
la source
2
Je voudrais mentionner que de nombreuses applications Windows ne sont pas open source ... Souvent, elles sont empaquetées avec les dépendances dont elles ont besoin, même si elles sont open source. Un exemple est pidgin. Vous n'avez pas besoin de télécharger gtk séparément sur Windows pour que pidgin fonctionne. Vous pourriez trouver que l'inclusion du langage sur Windows se produit lorsqu'il nécessite des dépendances externes, bien que je ne puisse pas penser à des exemples pour le moment, car il semble le plus difficile de ne pas nécessiter de dépendances externes.
xenoterracide

Réponses:

21

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.

tshepang
la source
Oui, je pense que vous avez un bon point ici. La culture * nix est une culture en effet.
Jordan Parmer
1
Cela permet également de gagner du temps en se demandant "hé, dans quelle langue le chrome est-il écrit?".
greenoldman
@macias: Le geek en moi me fait regarder les dépendances du paquet, où ce geek trouvera le plus souvent la langue. En fait, ce geek est si religieux que chaque fois qu'il visite un site Web, il s'énerve de ne pas pouvoir vérifier rapidement dans quelle langue l'outil inconnu est écrit. S'il s'agit de <insérer la langue non aimée>, ce geek s'enfuit et s'il est <insérer la langue préférée>, montre les préjugés du geek.
tshepang
4
Un exemple pratique sur la technologie qui pourrait être un problème est le mono / .NET car Microsoft a beaucoup de brevets dans ce domaine et a une longue histoire d'être "hostile" ... Par conséquent, il n'est pas étrange que certaines personnes souhaitent connaître ce genre de choses pour éviter de futurs problèmes.
Johan
1
Du point de vue de l'administrateur système, ce qu'un projet est écrit dicte souvent les dépendances qui doivent être disponibles.
JM Becker
12

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.

jasonwryan
la source
10

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.

dmckee
la source
2
Un exemple décent auquel je pense est une webapp appelée redmine. Il est écrit avec Ruby on Rails, ni ruby ​​ni rails n'est généralement fourni par défaut sur le système. Les applications Java sont également comme ça.
xenoterracide
10

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

Utilisateur inconnu
la source
Il suffit de parcourir les référentiels Ubuntu (via le Centre logiciel). Presque tous les résumés incluent la langue dans la première phrase. Je trouve assez drôle que la plupart des développeurs Linux semblent réellement développer pour d'autres développeurs Linux au lieu d'utilisateurs.
Jordan Parmer
@ j0rd4n n'étant pas un utilisateur ubuntu, pouvez-vous donner un exemple de progiciel? Je veux dire qu'ils ont vraiment mis C dans la description de Firefox? Je suppose que 90% des logiciels sous Linux ne sont pas destinés aux utilisateurs finaux, c'est une bibliothèque. Aussi ... vous ne saviez pas que les développeurs Linux développent pour eux-mêmes? c'est triste mais vrai ... en tant que programmeur perl je m'égare je n'ai encore rien écrit pour un utilisateur final :(
xenoterracide
J'utilise ubuntu, avec l'allemand comme langue d'interface, donc cela n'aidera que peu d'entre nous, à citer quelques exemples, mais je peux vous assurer: Dans synaptics, l'outil d'installation pour les nouveaux logiciels, j'ai fait un test et choisi 5 paquets - et n'en a trouvé aucun, mentionnant la langue dans laquelle il a été écrit.
utilisateur inconnu
Étendre mon commentaire: Souvent, le logiciel est écrit pour Unix (si vous trouvez des fichiers automake et autres) et pas nécessairement produit pour linux, mais à cause de la compatibilité, disponible sur différentes versions d'Unix.
utilisateur inconnu
6

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.

Bruce Ediger
la source
4

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.

Tobu
la source
Le référentiel Ubuntu a une quantité incroyable de descriptions de paquets dont les cinq premiers mots contiennent la langue. Je suis moi-même développeur, mais je n'ai jamais pensé que mes utilisateurs se souciaient de moi. Je pourrais comprendre, cependant, qu'étant open source, cela pourrait avoir plus de sens, mais développons-nous pour des personnes ou d'autres développeurs?
Jordan Parmer
1
@ j0rd4n Les développeurs sont aussi des gens!
Zach
3

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.

Nicolas Kaiser
la source
1

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.

Patrick
la source
Donc, dans les deux cas, vous avez un argument pour et un argument - ce qui n'est pas satisfaisant. Le code compilé qui est une source fermée est également courant sur Windows, donc l'argument de performance ne distinguerait pas un programme Linux
utilisateur inconnu
1
quelle? vous n'avez simplement aucun sens. Le pour et le contre est exactement la raison pour laquelle vous listeriez la langue. Si l'on n'avait que des «pros», alors tout le monde l'utiliserait. Et je ne comprends même pas ce que vous essayez de dire sur le code compilé et les systèmes d'exploitation.
Patrick
J'ai compris votre réponse de cette façon, que les gens annoncent implicitement les performances, si elles sont écrites en C / C ++, et qu'elles annoncent implicitement la portabilité si elles ne sont pas écrites en C / C ++. Ce qui est toujours un contre-argument - soit contre la portabilité, soit contre les performances - les deux raisons, sans parler de la langue. Alors pourquoi est-ce parfois cela, et à d'autres moments le contraire?
utilisateur inconnu
0

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

R ..
la source
Pourquoi les appelez-vous fous? Pourquoi ne coderaient-ils pas dans la langue qu'ils aiment? Quelle langue devraient-ils utiliser à la place?
tshepang