bonjour
GNU/Linux is not Windows !
Ca parait evident, pourtant quand je lis certains commentaires j'ai l'impression que certains ont vraiment du mal à l'assimiler...
Dans le monde windows, Billou fournit un OS, et tous ceux qui veulent faire un programme l'ecrivent pour qu'il soit compatible avec cet OS, et accessoirement ils fournissent l'installateur avec.
Dans le monde GNU, il existe d'abord des programmes, et ensuite seulement certaines personnes sélectionnent les programmes disponibles (et leur version) pour en faire un système d'exploitation.
Et comme en plus GNU/Linux est un monde où les standards sont rois (je ne comprend pas trop le reproche sur le manque de standardisation dans linux), il n'y a pas besoin d'écrire plusieurs version d'un même programme pour les différentes distributions.
C'est vrai que ces standards se situent au niveau du code source et de la compilation. C'est donc la que le concept de distribution, totalement absent du monde windows, intervient : le développeur de programme fournit un soft "universel" (quoi qu'un peut repoussant dans son mode d'installation) et c'est le développeur de la distrib qui se charge de transformer le soft (compiler et packager avec gestion des dépendances) pour en faire un produit tres facile à installer (je pourrais dire "activer") dans l'ensemble "distribution".
Apres, les développeurs qui se sentent obligés de fournir eux memes des paquets compilé pour les différentes distribs, c'est soit qu'ils font du soft closed-source, soit que leur soft n'est pas suffisament pertinent pour etre intégré dans les distribs et qu'ils ont du mal à l'accepter....
Pour moi, le grand nombre de distributions disponibles n'est pas un problème. Certes, cela pourrait traduire le fait que certains ferait (peut etre) mieux de contribuer à une grosse distrib plutot que de s'épuiser à faire vivoter une distrib confidentielle, mais ce n'est pas la diversité en soi qui est en cause.
Passons maintenant au problème des dépendances :
fun sun soulève trois questions :
1) un programme qui s'installe sans dépendances est-il meilleur qu'un programme qui a des dépendances ? Pour moi, la réponse est non ! Certes, si on installe un seul programme sur sa machine, c'est plus facile si les libs sont incluses dedans. Mais dès qu'on a plusieurs programmes, il vaut que le code soit splitté au maximum. De sorte que plusieurs programmes puissent utiliser des libs communes, installées une seule fois sur la machine. Imaginons que la moitiés des applis pour linux (celles utilisant gtk) soit livrées avec des libs statiques (c'est à dire gtk intégré dans chacun des soft) : ca va rapidement prendre pas mal de place (et comme dirait Guy Roux, la place sur un ordi il faut pas la gâcher...). Dans le cas de firefox/thunderbird, la lib graphique est xul. Donc on a une version de xul dans firefox, une dans thunderbird. Comme j'aime bien ces programmes, j'ai donc 2 fois xul sur mon ordi. (parce que ce n'est pas parce que j'avais déjà firefox que la version de thunderbird installée était moins grosse).
2) (bon, c'est totalement la suite du 1, mais faut bien aérer un peu le texte...) Je continue donc : la meilleure facon de distribuer (et meme de concevoir) un programme est de faire appel a des libs partagées. Imaginons qu'on ait 15 programmes sur sa machine qui utilise Gtk et qu'on découvre une faille de sécurité dans Gtk. Si chaque appli integre une version de Gtk, il faut les mettres les 15 à jour (d'abord au niveau des développeurs, ensuite sur sa machine). Si en plus ces applis n'ont pas été installé par le gestionnaire de paquet (parce que c'est bien ca le but d'avoir des soft qu'on télécharge "pret à l'emploi", c'est d'installer la dernière version "à la main"), alors il faut faire soit meme les mises à jour une par une....
Avec la philosophie libs partagées + gestionnaire de paquet, il n'y a qu'un soft à mettre à jour et en plus ca se fait tout seul.
3) la version des libs requises. Disons que tu n'utilises pas directement Gtk, mais des produits plus proche de l'utilisateur, comme Gimp par exemple. En tant qu'utilisateur, tu aimes bien avoir les dernières versions d'un programmes (de Gimp, donc). Pourquoi ? Parce qu'il y a de nouvelles fonctionalités, parce qu'il est plus rapide, parce que des bugs/failles de sécurité ont été résolu, etc... Mais Gtk est un programme au meme titre que Gimp, donc chaque version apporte de nouvelles fonctionnalités, est plus rapide, corrige des bugs, etc.... Pourquoi voudrais-tu que les développeurs de Gimp se passent des améliorations de Gtk ?
Maintenant, un peu de théorie : qu'est-ce qu'une lib ? (et je ne te garantis pas un réponse exacte
) C'est donc un programme, avec une interface et plein de code compliqué à l'intérieur d'une boite noire. Tu lis demandes quelque chose, ca fait un calcul et ca retourne un résultat. Sauf qu'ici, l'interface c'est des fonctions disponibles.
Par exemple, peut etre qu'une des fonctions offertes par Gtk est "affiche rectangle", qui prend comme paramètre les coordonnées du coin supérieur gauche, la longueur horizontale et la longueur verticale, et qui retourne comme résultat un rectangle tracé sur l'écran. Mais pour l'instant, on ne sait pas comment il s'y prend (et on a pas besoin de savoir). Si d'une version à l'autre de Gtk, le code qui trace les rectangles est modifié (amélioration, correction de bug), un programme qui utilise la fonction "affiche rectangle" peut utiliser indiférement l'une ou l'autre des versions. Si maintenant, les développeurs de Gtk décide d'introduire une fonction "affiche carré", pourquoi un développeur d'appli basé sur Gtk se priverait d'utiliser cette nouvelle fonction ? Sauf que maintenant, si cette appli qui utilise "affiche carré" se retrouve en face de la vieille version de Gtk dans laquelle cette fonction n'existait pas, ca va coincer... d'où une dépendance Gtk>5.6.1 (au pif) où 5.6.1 est justement la version où "affiche carré" est apparue.
Détail au passage : as-tu déjà compilé un module pour le noyau ? Si tu le fais, on te demande les kernel-headers (pas les sources, justes les headers). En fait, les headers contiennent juste la listes des fonctions qui sont disponible à l' "interface" du noyau, pour que le module qui les utilises puissent les connaitres à la compilation. Parce que si tu essayes de compiler un soft qui utilise une fonction que le compilateur ne connais, ca va méchamment planter....
Tout ca pour dire que ceux qui reproche au monde GNU/Linux l'existence des dépendances n'ont pas vraiment assimilé tout leur intéret par rapport au monde windows...
a+
lugburz
