Je ne comprends pas trop pourquoi les éditeurs de logiciels propriétaires[*] sous Linux "certifient" des distributions entières. En plus il s'agit souvent de distributions payantes et un peu anciennes (RH 8 ou 9 notamment), bonjour le support du matériel récent et la sécurité.
D'abord, quelle partie de la distrib' certifiée pour le produit en question : le minimum-sans-X, l'install desktop par défaut (avec aucun daemon lancé), les 14 CD de sources au complet ? Si il y a plusieurs versions officielles de noyau dans cette release ?
Qu'est-ce qui garantit qu'une mise à jour de sécurité ou l'installation d'un autre paquet qui ne faisait pas partie de l'install certifiée ne va pas tout casser ? Et qu'est-ce qui fait croire qu'il peut y avoir un tel risque ? Quand on liste les prérequis sous Windows, on ne dit pas "nécessite Office 2003", ou "incompatible avec Quake III", on ne parle que de l'OS, de la mémoire et du disque dur ! Le reste, c'est la hotline qui se débrouille.
Je pense qu'il serait bcp plus pertinent de lister précisément les dépendances importantes. Je suis sûr qu'il n'y en a pas tant que ca, si ils veulent garder des secrets de fabrication ils incluent de toute façon des libs statiques. Généralement, ca va être des versions minimum de noyau, de libc, de toolkit graphique, et de deux ou trois outils spécifiques. Les outils de base (shell, API réseau, langages interprétés ...) sont très stables et ne posent pas de pb de compatibilité ascendante.
Par exemple, une appli proprio peut réclamer : "noyau 2.6.5 ou suivant (avec modules réseau et RAID activés), libc6 version x.y.z ou +, gtk X.Y mais surtout pas X.Z, perl 3 ou +, incompatibilité avec le paquet trucmuche de la version 0.0.8 à la version 0.1.4 ...
Au fait, les distribs Fedora >2, Mandake 10.*, debian sarge et LFS 2.0 ont les paquets correspondant à ces critères." On me souffle dans l'oreillette que apt-get, urpmi, yum et yast sauraient même gérer les dépendances ...
Ce ne serait pas beaucoup plus difficile à tester pour l'éditeur, et au moins on sait vraiment de quoi on parle. On garde ainsi le choix de la distrib selon sa propre préférence (voire des choix officiels de l'entreprise), on n'est pas liés à un éditeur d'OS (ce qui est un des arguments forts des logiciels libres, non ? OK, si c'est pour une appli proprio c'est déjà raté), et surtout on garde la possibilité d'évoluer !
Ou alors j'ai raté un épisode ?
[*] Je pense surtout aux logiciels de CAO, traditionnellement UNIX et progressivement portés sous Linux ces temps-ci.
[^] # Re: Debian is still alive !
Posté par Jimmy . En réponse au journal Le futur de Debian. Évalué à 4.
D'abord, quelle partie de la distrib' certifiée pour le produit en question : le minimum-sans-X, l'install desktop par défaut (avec aucun daemon lancé), les 14 CD de sources au complet ? Si il y a plusieurs versions officielles de noyau dans cette release ?
Qu'est-ce qui garantit qu'une mise à jour de sécurité ou l'installation d'un autre paquet qui ne faisait pas partie de l'install certifiée ne va pas tout casser ? Et qu'est-ce qui fait croire qu'il peut y avoir un tel risque ? Quand on liste les prérequis sous Windows, on ne dit pas "nécessite Office 2003", ou "incompatible avec Quake III", on ne parle que de l'OS, de la mémoire et du disque dur ! Le reste, c'est la hotline qui se débrouille.
Je pense qu'il serait bcp plus pertinent de lister précisément les dépendances importantes. Je suis sûr qu'il n'y en a pas tant que ca, si ils veulent garder des secrets de fabrication ils incluent de toute façon des libs statiques. Généralement, ca va être des versions minimum de noyau, de libc, de toolkit graphique, et de deux ou trois outils spécifiques. Les outils de base (shell, API réseau, langages interprétés ...) sont très stables et ne posent pas de pb de compatibilité ascendante.
Par exemple, une appli proprio peut réclamer : "noyau 2.6.5 ou suivant (avec modules réseau et RAID activés), libc6 version x.y.z ou +, gtk X.Y mais surtout pas X.Z, perl 3 ou +, incompatibilité avec le paquet trucmuche de la version 0.0.8 à la version 0.1.4 ...
Au fait, les distribs Fedora >2, Mandake 10.*, debian sarge et LFS 2.0 ont les paquets correspondant à ces critères." On me souffle dans l'oreillette que apt-get, urpmi, yum et yast sauraient même gérer les dépendances ...
Ce ne serait pas beaucoup plus difficile à tester pour l'éditeur, et au moins on sait vraiment de quoi on parle. On garde ainsi le choix de la distrib selon sa propre préférence (voire des choix officiels de l'entreprise), on n'est pas liés à un éditeur d'OS (ce qui est un des arguments forts des logiciels libres, non ? OK, si c'est pour une appli proprio c'est déjà raté), et surtout on garde la possibilité d'évoluer !
Ou alors j'ai raté un épisode ?
[*] Je pense surtout aux logiciels de CAO, traditionnellement UNIX et progressivement portés sous Linux ces temps-ci.