alors que tous ces sites proposent des binaires windows qui marchent ( en 3 clics j'exagère à peine ).
Oui mais il faut voir a quel prix...
La gestion de dépendances sous windows est bien pire que totu ce que l'on peut trouver sous linux.
Il existe surtout 2 sortes de programmes sous windows : les "faites le vous même" et les "pousse toi que je m'y mette".
Les faites-le vous même sont livrées bruts, pas de dépendances, parfois juste un simple MSI pour limiter la taille au maximum. A vous de comprendre que les erreurs absconces du type : ##@@@&& : procedure entry not found in bidules.dll veut dire qu'il faut que vous installiez au choix : internet explorer 6 ou 5.5, diverses runtime VB ou .Net, windows media player mis a jour, la console de management, un driver ASPI etc. Ce qu'il y a d ebien par rapport a Linux c'est que el droit a l'erreur est tres faible. Vous croyiez que la mise a jour du media player en version 9 resoudrait le problème ? Perdu et en plus maintenant vous etes coincés avec le mastondonte de service. Il y a aussi des pièges droles, comme la MSVCRT buguée qui peut vous planter une install IE 5.5 au beau millieu et vous interdire toute mise a joru par la suite sous pretexte que : "Une installation d'une version précédente internet explorer ne s'est par terminé, veuillez finir cette installation avant de procéder a la mise a jour". Un grand moment de bonheur (car l'install précédente plante bien sur.)
L'autre type d'install, c'est le pousse toi de la que je m'y mette. La on a un beau executable et on a qu'a cliquer sur suivant, suivant suivant pour installer le logiciel. Sauf que derrière le programme est supposé chercher les DLLs dont il a besoin sur le système, verifier la version, verifier les autres logiciels qui se servent de ces DLLs et suivant les cas metre a jour ou non. dans la pratique le programme arrive souvent avec ses gros sabot et ecrase les DLLs en place par les siennes avant d'avertir l'utilsiateur qu'un redémarrage est necessaire. Et au reboot surprise, la DLL MSCVRT buguée est revenue, un certains nombre de DLLs sont regressées et un eptit message vous annonce calmement que telle ou telle appli ne fonctionne plus. La réponse de MS a ce problème a été de réinventer la bibliotheque statique. Si un programme veut ecraser une DLL système il est immédiatement conatoner dans son repertoire et la DLL système reste en place. La DLL nouvelle se retrouve alors dans le repertoire de cantonnement. Ca permet d'avoir 40 fois la même DLL en copie. Bien sur cette manip fonctionne bien avec l'installeur MSI, beaucoup moins avec les autres. En plus les tests de versions Beta (de DirectX par example) se retrouvent simplifiées. Le nombre de personnes ayant installé la beta de la version 9 qui ont du reprendre leur poste du départ est impressionnant.
Sincèrement je préfère aller chercher mes dépendances moi même et pouvoir revenir en arrière facilement (même si parfois c'est long et casse pied, GLibC POWA !!) que d'avoir la surprise au reboot.
# Est-ce vraiment un mal ?
Posté par Jerome Herman . En réponse au journal RPM o RPM !!!. Évalué à 4.
Oui mais il faut voir a quel prix...
La gestion de dépendances sous windows est bien pire que totu ce que l'on peut trouver sous linux.
Il existe surtout 2 sortes de programmes sous windows : les "faites le vous même" et les "pousse toi que je m'y mette".
Les faites-le vous même sont livrées bruts, pas de dépendances, parfois juste un simple MSI pour limiter la taille au maximum. A vous de comprendre que les erreurs absconces du type : ##@@@&& : procedure entry not found in bidules.dll veut dire qu'il faut que vous installiez au choix : internet explorer 6 ou 5.5, diverses runtime VB ou .Net, windows media player mis a jour, la console de management, un driver ASPI etc. Ce qu'il y a d ebien par rapport a Linux c'est que el droit a l'erreur est tres faible. Vous croyiez que la mise a jour du media player en version 9 resoudrait le problème ? Perdu et en plus maintenant vous etes coincés avec le mastondonte de service. Il y a aussi des pièges droles, comme la MSVCRT buguée qui peut vous planter une install IE 5.5 au beau millieu et vous interdire toute mise a joru par la suite sous pretexte que : "Une installation d'une version précédente internet explorer ne s'est par terminé, veuillez finir cette installation avant de procéder a la mise a jour". Un grand moment de bonheur (car l'install précédente plante bien sur.)
L'autre type d'install, c'est le pousse toi de la que je m'y mette. La on a un beau executable et on a qu'a cliquer sur suivant, suivant suivant pour installer le logiciel. Sauf que derrière le programme est supposé chercher les DLLs dont il a besoin sur le système, verifier la version, verifier les autres logiciels qui se servent de ces DLLs et suivant les cas metre a jour ou non. dans la pratique le programme arrive souvent avec ses gros sabot et ecrase les DLLs en place par les siennes avant d'avertir l'utilsiateur qu'un redémarrage est necessaire. Et au reboot surprise, la DLL MSCVRT buguée est revenue, un certains nombre de DLLs sont regressées et un eptit message vous annonce calmement que telle ou telle appli ne fonctionne plus. La réponse de MS a ce problème a été de réinventer la bibliotheque statique. Si un programme veut ecraser une DLL système il est immédiatement conatoner dans son repertoire et la DLL système reste en place. La DLL nouvelle se retrouve alors dans le repertoire de cantonnement. Ca permet d'avoir 40 fois la même DLL en copie. Bien sur cette manip fonctionne bien avec l'installeur MSI, beaucoup moins avec les autres. En plus les tests de versions Beta (de DirectX par example) se retrouvent simplifiées. Le nombre de personnes ayant installé la beta de la version 9 qui ont du reprendre leur poste du départ est impressionnant.
Sincèrement je préfère aller chercher mes dépendances moi même et pouvoir revenir en arrière facilement (même si parfois c'est long et casse pied, GLibC POWA !!) que d'avoir la surprise au reboot.
Kha