> Le monde propriétaire le fait. Ce n'est pas parce que la licence change quand ça change la technique aussi. C'est possible techniquement.
Un détail: dans le monde windows (aka "propriétaire"), on réimplémente / réinvente la roue sans cesse (ou se linke statiquement lorsqu'on a acheté une lib). L'essentiel des API/libs partagées sont celles d'un seul fournisseur, microsoft. Des miliers de boites réécrivent les mêmes fonctionalités, en permanence.
Dans le LL on mutualise le travail jusqu'au sang ; on fait des libs par centaines. On réutilise tant qu'on peut. On partage les fonctionalités.
Et c'est pour ça qu'avec un nombre de developpeurs beaucoup plus restreint, on arrive à un résultat très satisfaisant.
La contrepartie, c'est qu'il peut y avoir un jeu de dépendances très complexes entres les logiciels. Mais on s'en est toujours bien sorti parceque ce jeu de dépendance est établi à la configuration/compilation, par les sources. C'est astucieux, ça marche bien, et l'aspect fastidieux de la chose est
Maintenant, dans ces mêmes conditions, on pourrait travailler à avoir une compatibilité binaire approximative. Mauvaise idée: les ressources pour arriver à ce résultat seraient considérables: bien au delà de nos moyens, et bien au-delà de l'effort pour arriver à ce résultat sous windows (où les dépendances sont généralement nulles); et dans tout les cas, "approximatif" n'est pas suffisant: pourquoi souhaiter un environement fragile lorsqu'on à déjà quelque chose de robuste ?
> Le fait de distribuer des binaires un minimum permutables entre les distros ça ne retire rien du tout à ce qu'il est possible de faire
Mais si. Ça prendrai un temps infini, pour un résultat toujours douteux. Tu pense que les developpeurs kde/gnome/kernel/glibc sont incompétents lorsqu'ils disent que ce n'est pas un objectif pertinent ? Personellement je suis plutot content qu'ils travaillent à améliorer leurs applis, pas à bidouiller sur les binaires.
Pourquoi tu rale ? tu devrait plutot faire ce que tu dit puisque c'est si facile...
> le même binaire d'OOo 1.1.5 il tourne sur un windows
Cet exemple tombe à point. Les types d'OOo ont (un peu à la manière des éditeurs de logiciels propriétaires sous win32) tout ré-écrit, même leur propre toolkit graphique. C'est un travail ENORME. Un travail nécéssaire à l'époque, il n'y avait pas d'autres choix.
Même chose pour firefox, qui intègre un maximum de libs redondantes avec le système dans les tarballs binaires: ils peuvent se le permettre car leurs ressources (support financier, nombre de devs, ...) sont énormes, et parcequ'à leurs début il a fallu faire ça (pas le choix). Et encore, il s'agit d'appli ayant finalement relativement peu d'interactions avec le reste du système.
Maintenant les choses on changé, et je suis heureux que les developpeurs n'aient pas que ça à foutre ...
Il faut arréter de réver: combien d'appli gnome ou kde en C/C++ connait tu qui soient compatibles entres les distros majeures ?
Le mode de developpement des logiciels propriétaires sous win32 n'est pas adapté aux logiciels sous Unix libre (btw, ne pas oublier les *BSD), et ce qui est pour eux un besoin impératif (la compat. binaire) est pour nous totalement accéssoire.
Je me répete, mais bon j'ai pas l'impression que tu ai lu: la preuve: les logiciels propriétaires sous *nix s'en sortent très bien avec *nos* méthodes. À l'heure des machines virtuelles sous qemu pour 0 euros, ils peuvnt tous se payer un parc de compilation & tests pour les distribs majeures, ou trouver d'autres solutions: skype, kqemu, opera, sun jdk, nvidia, vmware, intel c++, oracle...
> Ben voilà, et si c'était simplement ça à remettre en cause ? ne changer les API que sur des choses vraiment majeure,
Mais c'est évidement remis en cause (par eux même), ce n'est pas quelque chose qui est arrivé volontairement. Les developpeurs ne se sont pas dit: "hé, les gars, et si on s'amusait à péter toute la compatibilité binaire dans la branche stable". L'exemple était là pour illustrer le fait qu'il est très dur, même pour des developpeurs chevronnés. Dans la plupart des cas, une simple correction de bug entraine un changement dont ne peut pas mesurer toutes les conséquences (cf. les raisons de la sortie de php 4.4 par ex.).
[^] # Re: Compatibilite binaire
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 5.
Un détail: dans le monde windows (aka "propriétaire"), on réimplémente / réinvente la roue sans cesse (ou se linke statiquement lorsqu'on a acheté une lib). L'essentiel des API/libs partagées sont celles d'un seul fournisseur, microsoft. Des miliers de boites réécrivent les mêmes fonctionalités, en permanence.
Dans le LL on mutualise le travail jusqu'au sang ; on fait des libs par centaines. On réutilise tant qu'on peut. On partage les fonctionalités.
Et c'est pour ça qu'avec un nombre de developpeurs beaucoup plus restreint, on arrive à un résultat très satisfaisant.
La contrepartie, c'est qu'il peut y avoir un jeu de dépendances très complexes entres les logiciels. Mais on s'en est toujours bien sorti parceque ce jeu de dépendance est établi à la configuration/compilation, par les sources. C'est astucieux, ça marche bien, et l'aspect fastidieux de la chose est
Maintenant, dans ces mêmes conditions, on pourrait travailler à avoir une compatibilité binaire approximative. Mauvaise idée: les ressources pour arriver à ce résultat seraient considérables: bien au delà de nos moyens, et bien au-delà de l'effort pour arriver à ce résultat sous windows (où les dépendances sont généralement nulles); et dans tout les cas, "approximatif" n'est pas suffisant: pourquoi souhaiter un environement fragile lorsqu'on à déjà quelque chose de robuste ?
> Le fait de distribuer des binaires un minimum permutables entre les distros ça ne retire rien du tout à ce qu'il est possible de faire
Mais si. Ça prendrai un temps infini, pour un résultat toujours douteux. Tu pense que les developpeurs kde/gnome/kernel/glibc sont incompétents lorsqu'ils disent que ce n'est pas un objectif pertinent ? Personellement je suis plutot content qu'ils travaillent à améliorer leurs applis, pas à bidouiller sur les binaires.
Pourquoi tu rale ? tu devrait plutot faire ce que tu dit puisque c'est si facile...
> le même binaire d'OOo 1.1.5 il tourne sur un windows
Cet exemple tombe à point. Les types d'OOo ont (un peu à la manière des éditeurs de logiciels propriétaires sous win32) tout ré-écrit, même leur propre toolkit graphique. C'est un travail ENORME. Un travail nécéssaire à l'époque, il n'y avait pas d'autres choix.
Même chose pour firefox, qui intègre un maximum de libs redondantes avec le système dans les tarballs binaires: ils peuvent se le permettre car leurs ressources (support financier, nombre de devs, ...) sont énormes, et parcequ'à leurs début il a fallu faire ça (pas le choix). Et encore, il s'agit d'appli ayant finalement relativement peu d'interactions avec le reste du système.
Maintenant les choses on changé, et je suis heureux que les developpeurs n'aient pas que ça à foutre ...
Il faut arréter de réver: combien d'appli gnome ou kde en C/C++ connait tu qui soient compatibles entres les distros majeures ?
Le mode de developpement des logiciels propriétaires sous win32 n'est pas adapté aux logiciels sous Unix libre (btw, ne pas oublier les *BSD), et ce qui est pour eux un besoin impératif (la compat. binaire) est pour nous totalement accéssoire.
Je me répete, mais bon j'ai pas l'impression que tu ai lu: la preuve: les logiciels propriétaires sous *nix s'en sortent très bien avec *nos* méthodes. À l'heure des machines virtuelles sous qemu pour 0 euros, ils peuvnt tous se payer un parc de compilation & tests pour les distribs majeures, ou trouver d'autres solutions: skype, kqemu, opera, sun jdk, nvidia, vmware, intel c++, oracle...
> Ben voilà, et si c'était simplement ça à remettre en cause ? ne changer les API que sur des choses vraiment majeure,
Mais c'est évidement remis en cause (par eux même), ce n'est pas quelque chose qui est arrivé volontairement. Les developpeurs ne se sont pas dit: "hé, les gars, et si on s'amusait à péter toute la compatibilité binaire dans la branche stable". L'exemple était là pour illustrer le fait qu'il est très dur, même pour des developpeurs chevronnés. Dans la plupart des cas, une simple correction de bug entraine un changement dont ne peut pas mesurer toutes les conséquences (cf. les raisons de la sortie de php 4.4 par ex.).