La compatibilité binaire entre les distributions est une chimère, impossible et sans véritable intéret (oui, autoconf/automake/make/gcc permettent aux devs des distros de faire des binaires adaptés à leur environement):
- Il n'y a pas d' « instant t » pour les distributions: Debian met plusieurs années à sortir, Fedora et Ubuntu sortent tout les 6 mois, Mandriva tout les ans ... Or, pour mémoire, il suffit d'avoir seulement un kernel différent (il en sort un nouveau tout les 3 mois) pour ne plus être compatibles (les modules du kernel t+1 ne sont pas adaptés au kernel t).
Donc il est impossible d'avoir les mêmes versions des libs compilées avec le même compilateur, avec les mêmes patches, sur le même kernel, en même temps, et sur toutes les distros. À partir de là, la compatibilité binaire ne peut arriver que "par chance" ou "par hasard", comme dit Shutlleworth.
- Quand bien même il y aurai une « compatibilité binaire à l'instant t », en quoi celà serait plus important que le travail de compat ascendante (compat binaire à l'instant t, t -1, t +1 - qui est tout aussi impossible) ?
Car il est clair que tout les utilisateurs n'upgradent pas leur système au même moment. Ainsi l'objectif d'universalité ne serait toujours pas atteint.
- Le monde n'est pas i386. GD souhaite-t-il qu'à terme, les binaires Debian/sparc tournent sur Mdv/x86 ? ça n'a aucun sens. Cette compat ne peut exister qu'au niveau des sources.
- Même si toutes les distros à l'instant t étaient compatibles et utilisaient les mêmes logiciels, les mises à jour sécu sont gérées différement (backports ou upgrade de version, ...). À la première faille de sécu de firefox, par ex., les packages contenant les plugins deviendraient incomptibles entre les distros. La distribution des packages adéquat doit être gérée ... par les distributions !
- La LSB conçue comme un layer de compatibilité binaire (elle n'est pas que ça) est une illusion que dénonce d'ailleur un des plus éminents spécialistes du sujet, le mainteneur de la glibc: http://www.livejournal.com/users/udrepper/8511.html
En bref il nous dit: la compatibilité est possible seulement aun niveau des sources, LSB est fait par des amateurs incompétents.
- Il y a de nombreux projets de normalisation / standardisation qui ont pour vocation d'améliorer la compatibilité (au niveau des sources) ou les échanges entre les distros, entre les implémentations, et entre les libs/softs utilisés sous linux: POSIX, Freedesktop.org, Launchpad, Posixtestssuite, Tango, D-Bus, C89 ...
Pourquoi GD met-il l'accent sur le projet le plus improbable (la compat binaire) plutôt que d'affirmer publiquement son soutient à ces initiatives réalistes et pragmatiques ?
- Le respect de la LSB et le fait que les libs soient présentent dans la même version entre plusieurs distribution ne suffit pas à assurer la compat des packages. Il y a aussi des choix technologiques qui sont important, et dont l'intégration n'est possible qu'en compilant ad hoc à partir des sources: type de serveur de son utilisé (arts ? esd ? jack ?), présence ou non de certaines libs et outil pour des raisons politique souveraines à chaque distro (mp3, divx, SELinux, quicktime, ...), façon de privilégier, pour tel logiciel, les fonctionalités ou la maturité (eg. choix d'apache1 ou apache2), emplacement et droit (et uid/gid propriétaires) sur les repertoires/fichiers ...
Celà introduit suffisament de différences pour qu'un package lambda présente toujours un risque d'incompatibilité, entre deux distros, légère ou pas.
- Si la compatibilité à 100% est impossible, est-il vraiment sérieux, pour quelqu'un qui prend la qualité logicielle au sérieux (mais est-ce le cas de Gaël Duval ?) d'en faire part ? Est-ce que Mandriva peut se permettre de recommander à ses utilisateurs d'essayer les packages Red Hat (ou l'inverse) ? dans ce cas, à quoi bon chippoter sur la compat binaire ?
- Si le but implicite est de permettre l'échange de packages entre les distros, on peut se demander si cet objectif est vraiment judicieux: avec plus de 10 000 packages, les developpeurs de distros semblent ne pas avoir trop de mal à faire des binaires pour leurs plateformes. Quand ils font oublis (ou autre), la communauté le fait à leur place et s'en sort très bien aussi (cf. plf, debian-marillat, etc.). Au final l'utilisateur trouvera presque toujours un package sur mesure. Sauf pb de brevet ou logiciel propriétaire (mais cf. ci-dessous).
Mais surtout: l'importance du travail, d'un developpeur de distribution, la vrai valeur ajoutée de ce travail, ce n'est pas vraiment qu'il fasse un binaire packagé (un utilisateur moyen peut le faire), c'est qu'il ai bien pris le temps de le tester, de le polir, de l'intégrer proprement, de vérifier s'il ne pose pas de soucis / conflits avec les autres logiciels de la distro, que son update ne pose pas de pb etc.
Vouloir se fier à la compatibilité binaire, c'est vouloir éviter le premier pas, la compilation (qui permet de vérifier bien des choses) de ce travail de qualité logicielle, et probablement les pas suivants aussi...
- Si le but implicite de ce machin est de permettre aux ISV / logiciels propriétaires de tourner sur toutes les distribs sans avoir à compiler sur chaque plateforme, on peut supposer que son interet pour les ISV soit de ne pas essayer / tester / faire du qa sur les divers distribs. Le résultat serait bien sûr des logiciels insuffisament stable.
Preuve ? si vous étes utilisateurs de Mdv (qui est très compatible RH nous dit GD) et que vous avez le choix entre un rpm Mdv et un rpm RH, vous choisissez lequel ? le Mdv, parceque la stabilité de l'autre vous inquietera (Red Hat n'ayant pas testé sur votre plateforme).
On peut aussi trouver inadéquat que les distros fassent un tel sacrifice (celui de devenir uniformes) et déploient de tels effort seulement pour faire tourner du logiciel propriétaire dans des conditions n'assurant pas sa pleine stabilité/compatibilité ...
- GD ne nous explique pas vraiment quel est son problème avec la « compatibilité par les sources », en quoi c'est insuffisant. Pour l'échange entre distros ? (mais on voit ci-dessus que l'alternarive "binaire" est un objectif impossible si on est rigoureux, là ou l'échange par les sources est faisable et finalement simple).
Pour les logiciels propriétaires ? cf. ci-dessus: les ISV qui veulent de la stabilité garantie ne supporteront jamais que les distros sur lesquels ils ont bcp testé (oracle -> RHEL & Suse), ou compileront et testeront sur plein de distros (skype, opera ...), ou fourniront un système de compilation automatisé sur mesure (nvidia). Bref, les ISV comme les LL ont des solutions pour gérer l'incompat (binaire et technologique), elles passent toute par la compilation sur la plateforme cible, et ça fonctionne bien comme ça.
Le propos de Gaël Duval n'aide pas à établir le sérieux de son produit, et il est dommage que linuxfr s'en soit l'echo.
[^] # Re: Compatibilite binaire
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 8.
- Il n'y a pas d' « instant t » pour les distributions: Debian met plusieurs années à sortir, Fedora et Ubuntu sortent tout les 6 mois, Mandriva tout les ans ... Or, pour mémoire, il suffit d'avoir seulement un kernel différent (il en sort un nouveau tout les 3 mois) pour ne plus être compatibles (les modules du kernel t+1 ne sont pas adaptés au kernel t).
Donc il est impossible d'avoir les mêmes versions des libs compilées avec le même compilateur, avec les mêmes patches, sur le même kernel, en même temps, et sur toutes les distros. À partir de là, la compatibilité binaire ne peut arriver que "par chance" ou "par hasard", comme dit Shutlleworth.
- Quand bien même il y aurai une « compatibilité binaire à l'instant t », en quoi celà serait plus important que le travail de compat ascendante (compat binaire à l'instant t, t -1, t +1 - qui est tout aussi impossible) ?
Car il est clair que tout les utilisateurs n'upgradent pas leur système au même moment. Ainsi l'objectif d'universalité ne serait toujours pas atteint.
- Le monde n'est pas i386. GD souhaite-t-il qu'à terme, les binaires Debian/sparc tournent sur Mdv/x86 ? ça n'a aucun sens. Cette compat ne peut exister qu'au niveau des sources.
- Même si toutes les distros à l'instant t étaient compatibles et utilisaient les mêmes logiciels, les mises à jour sécu sont gérées différement (backports ou upgrade de version, ...). À la première faille de sécu de firefox, par ex., les packages contenant les plugins deviendraient incomptibles entre les distros. La distribution des packages adéquat doit être gérée ... par les distributions !
- La LSB conçue comme un layer de compatibilité binaire (elle n'est pas que ça) est une illusion que dénonce d'ailleur un des plus éminents spécialistes du sujet, le mainteneur de la glibc: http://www.livejournal.com/users/udrepper/8511.html
En bref il nous dit: la compatibilité est possible seulement aun niveau des sources, LSB est fait par des amateurs incompétents.
- Il y a de nombreux projets de normalisation / standardisation qui ont pour vocation d'améliorer la compatibilité (au niveau des sources) ou les échanges entre les distros, entre les implémentations, et entre les libs/softs utilisés sous linux: POSIX, Freedesktop.org, Launchpad, Posixtestssuite, Tango, D-Bus, C89 ...
Pourquoi GD met-il l'accent sur le projet le plus improbable (la compat binaire) plutôt que d'affirmer publiquement son soutient à ces initiatives réalistes et pragmatiques ?
- Le respect de la LSB et le fait que les libs soient présentent dans la même version entre plusieurs distribution ne suffit pas à assurer la compat des packages. Il y a aussi des choix technologiques qui sont important, et dont l'intégration n'est possible qu'en compilant ad hoc à partir des sources: type de serveur de son utilisé (arts ? esd ? jack ?), présence ou non de certaines libs et outil pour des raisons politique souveraines à chaque distro (mp3, divx, SELinux, quicktime, ...), façon de privilégier, pour tel logiciel, les fonctionalités ou la maturité (eg. choix d'apache1 ou apache2), emplacement et droit (et uid/gid propriétaires) sur les repertoires/fichiers ...
Celà introduit suffisament de différences pour qu'un package lambda présente toujours un risque d'incompatibilité, entre deux distros, légère ou pas.
- Si la compatibilité à 100% est impossible, est-il vraiment sérieux, pour quelqu'un qui prend la qualité logicielle au sérieux (mais est-ce le cas de Gaël Duval ?) d'en faire part ? Est-ce que Mandriva peut se permettre de recommander à ses utilisateurs d'essayer les packages Red Hat (ou l'inverse) ? dans ce cas, à quoi bon chippoter sur la compat binaire ?
- Si le but implicite est de permettre l'échange de packages entre les distros, on peut se demander si cet objectif est vraiment judicieux: avec plus de 10 000 packages, les developpeurs de distros semblent ne pas avoir trop de mal à faire des binaires pour leurs plateformes. Quand ils font oublis (ou autre), la communauté le fait à leur place et s'en sort très bien aussi (cf. plf, debian-marillat, etc.). Au final l'utilisateur trouvera presque toujours un package sur mesure. Sauf pb de brevet ou logiciel propriétaire (mais cf. ci-dessous).
Mais surtout: l'importance du travail, d'un developpeur de distribution, la vrai valeur ajoutée de ce travail, ce n'est pas vraiment qu'il fasse un binaire packagé (un utilisateur moyen peut le faire), c'est qu'il ai bien pris le temps de le tester, de le polir, de l'intégrer proprement, de vérifier s'il ne pose pas de soucis / conflits avec les autres logiciels de la distro, que son update ne pose pas de pb etc.
Vouloir se fier à la compatibilité binaire, c'est vouloir éviter le premier pas, la compilation (qui permet de vérifier bien des choses) de ce travail de qualité logicielle, et probablement les pas suivants aussi...
- Si le but implicite de ce machin est de permettre aux ISV / logiciels propriétaires de tourner sur toutes les distribs sans avoir à compiler sur chaque plateforme, on peut supposer que son interet pour les ISV soit de ne pas essayer / tester / faire du qa sur les divers distribs. Le résultat serait bien sûr des logiciels insuffisament stable.
Preuve ? si vous étes utilisateurs de Mdv (qui est très compatible RH nous dit GD) et que vous avez le choix entre un rpm Mdv et un rpm RH, vous choisissez lequel ? le Mdv, parceque la stabilité de l'autre vous inquietera (Red Hat n'ayant pas testé sur votre plateforme).
On peut aussi trouver inadéquat que les distros fassent un tel sacrifice (celui de devenir uniformes) et déploient de tels effort seulement pour faire tourner du logiciel propriétaire dans des conditions n'assurant pas sa pleine stabilité/compatibilité ...
- GD ne nous explique pas vraiment quel est son problème avec la « compatibilité par les sources », en quoi c'est insuffisant. Pour l'échange entre distros ? (mais on voit ci-dessus que l'alternarive "binaire" est un objectif impossible si on est rigoureux, là ou l'échange par les sources est faisable et finalement simple).
Pour les logiciels propriétaires ? cf. ci-dessus: les ISV qui veulent de la stabilité garantie ne supporteront jamais que les distros sur lesquels ils ont bcp testé (oracle -> RHEL & Suse), ou compileront et testeront sur plein de distros (skype, opera ...), ou fourniront un système de compilation automatisé sur mesure (nvidia). Bref, les ISV comme les LL ont des solutions pour gérer l'incompat (binaire et technologique), elles passent toute par la compilation sur la plateforme cible, et ça fonctionne bien comme ça.
Le propos de Gaël Duval n'aide pas à établir le sérieux de son produit, et il est dommage que linuxfr s'en soit l'echo.