Folco (./3546) :
D'ailleurs pour la petite histoire, quand madame trouve mon PC sous Win,
… ce qui ne devrait jamais être le cas!
Je ne fais plus de dual-boot et je ne le regrette pas.
elle reboot sous nux "parce que c'est quand même beaucoup plus simple" 
flanker (./3547) :
D'où l'intérêt d'avoir un framework bien complet proposé sur l'OS. Comme ça, pas besoin de le recopier à chaque fois...
Et du coup les logiciels ne marchent plus que sur cet OS, bonjour le lock-in propriétaire!
Quant au système de dépendances, il m'a tellement emmerdé que je trouve vraiment que c'est la pire des solutions 
Je dis à Apper d'installer le logiciel, il installe automatiquement tout ce qu'il faut, je ne vois pas de quoi je me plaindrais!
Folco (./3548) :
flanker (./3547) :
Quant au système de dépendances, il m'a tellement emmerdé que je trouve vraiment que c'est la pire des solutions
J'ai pas eu cette expérience, moi au contraire j'ai toujours trouvé ça facile qu'on installe les softs à ma place sans que j'y connaisse rien, qu'est-ce qui t'as fait chier par exemple ?
+1
flanker (./3549) :
Essaie d'utiliser des versions différentes de celles proposées par l'OS,
Il faut utiliser une distribution plus à jour alors.
et sur un OS non connecté à internet...
Et puis le logiciel, il tombe du ciel? D'où veux-tu installer le logiciel? D'une disquette 3,5"?
Uther (./3550) :
Pour un ancien défenseur acharné des bibliothèques statiques, tu as violemment retourné ta veste dis donc.
Le problème sur les calculatrices TI, c'est qu'il n'y a justement aucune résolution automatique des dépendances (entre autre parce que ces machines ne sont pas connectées directement à Internet), donc du coup les bibliothèques dynamiques sont casse-pieds (il faut aller les chercher une par une). De plus, le système d'exploitation ne gère pas nativement les bibliothèques dynamiques et donc il faut installer une surcouche (là encore manuellement!) qui s'appelle "kernel" sans en être un et qui les gère. C'est le parfait exemple de comment
ne pas développer un système de dépendances (et la faute est surtout de TI, mais il faut s'y faire et pas développer des workarounds qui rejettent tout sur l'utilisateur).
La situation est totalement différente sous GNU/Linux: Les bibliothèques dynamiques sont gérées nativement (ld.so fait partie intégrante du système), et les dépendances sont gérées automatiquement. Pour moi, cette résolution automatique est une condition nécessaire pour pouvoir distribuer des bibliothèques dynamiques (sinon → DLL hell!).
Je n'ai pas dit que Android était parfait sur tous les points, juste au niveau de la gestion des droits. Ceci dit, la duplication de code, même si elle a des désavantages, n'est pas a ce point dramatique, surtout sur les machines actuelles, pour lesquelles l'espace occupé par les exécutables n'est plus vraiment un problème.
D'un tu sous-estimes la place prise par un framework moderne comme la Plateforme KDE, et de deux, qu'en est-il de la sécurité? Le problème des mises à jour de sécurité ne se pose pas vraiment sur une calculatrice, je ne sais pas à quel point c'est un thème sur les smartphones, mais sur PC, les bibliothèques ont souvent des correctifs de sécurité! Du coup, si
n logiciels embarquent cette bibliothèque, ça fait
n logiciels à mettre à jour! (Et en plus, avec toutes les bibliothèques qu'ils embarquent, même si elles ne changent pas!)
Un autre problème est aussi que les bibliothèques sont souvent embarquées en recopiant la DLL, ce qui est totalement débile. Le but d'une bibliothèque dynamique est justement d'être partagée! Sinon, on est censés linker statiquement, mais ce n'est souvent pas prévu par les développeurs de la bibliothèque, et du coup on embarque toute la DLL.
(Ou alors on linke statiquement, mais la bibliothèque n'est pas optimisée pour, et du coup, on se retrouve avec presque toute la bibliothèque embarquée plutôt que seulement les parties utilisées effectivement.) À chaque fois que je vois une bibliothèque dynamique (.dll/.so/.dylib) embarquée avec un logiciel, j'ai envie de frapper son développeur.
La résolution automatique des dépendances c'est bien sur le papier, sauf que ça à aussi des gros défauts. Ça oblige un travail colossal et de la concertation pour que tout ça ne devienne pas un beau bordel, et malheureusement sous GNU/Linux avec la fragmentation absolue de l'écosystème, c'est un drame et pour moi la principale raison pour laquelle GNU/Linux n'arrive pas à percer.
GNU/Linux est exactement l'exemple de comment ça fonctionne. La concertation n'est nécessaire qu'à l'intérieur d'une distribution, et c'est à ça que sert une distribution. C'est normal qu'un binaire pour Ubuntu ne s'installe pas sous Fedora, par exemple. Ça n'a jamais été prévu. D'où l'intérêt de publier les sources plutôt que les binaires, et permettre ainsi aux packageurs de la distribution de compiler ton logiciel pour leur distribution.
C'est pour ça que l'installation de la moindre application sous GNU/Linux risque de tourner à l'horreur des l'on s'attèle à quelque-chose qui n'est pas dans les dépôts de ta distribution.
Le problème est alors là, que ce n'est pas dans les dépôts. Problème qui peut en général se corriger.
(Bien sûr, pas s'il y a des problèmes de licence ou autres, mais il y a aussi des dépôts tiers et au pire tu peux en ouvrir un.) Les contributions sont bienvenues.
Au lieu de dupliquer les bibliothèques ce qui ne coute plus grand chose de nos jours, on duplique le travail de packaging par le nombre de distribution, ce qui est difficile voire juste impossible pour les petits projets.
En principe, ce n'est pas aux projets upstream de se packager, mais aux packageurs de la distribution! Maintenant, il y a des développeurs upstream qui viennent packager leur logiciel dans Fedora, mais ce n'est pas le cas le plus courant et personne n'exige ça des projets upstream. On demande des sources sous une licence approuvée par FSF et OSI et c'est tout.
Je ne fais plus de dual-boot et je ne le regrette pas.
