Articles précédents : Articles
- [22] L'OSDL créé le Mobile Linux Initiative
- [29] GDL, un clone libre d'IDL
- [182] Quand Mark Shuttleworth fait le point sur Ubuntu
- [45] L'EUCD en Finlande et le virus de protection des oeuvres
- [13] Formation libre sur Linux embarqué: un an après
- [10] BuildProcess : la boite à outil de l'administrateur Java/J2EE
- [80] DMCA français : lettre à Dominique de Villepin
- [4] Utilisons les Logiciels Libres - jeudi 20 octobre à Cannes
- [31] Oracle achète Innobase / InnoDB
- [33] Projet BetterDesktop
Liens connexes
- La réponse de Gaël Duval (9414 hits)
- La réponse de Gaël Duval (628 hits)
- Quand Mark Shuttleworth fait le point sur Ubuntu (2546 hits)
Dépêche modérée par
Dépêche éditée par
Articles : Gaël Duval répond à Mark Shuttleworth
Posté par Pierre Jarillon (page perso, ). Modéré le 21 octobre 2005.
Gaël Duval, nous fait le plaisir de nous apprendre que son nouveau rôle dans son entreprise le rapprochera de la communauté du logiciel libre. Ce changement de fonctions est permis grâce à la croissance de l'entreprise maintenant forte de 130 personnes.
Son point de vue sur la compatibilité binaire entre distributions est fort intéressant et en complet désaccord avec celui de Mark Shuttleworth. Est-ce un troll ? On peut penser que non car ce sujet mérite d'être débattu et Linuxfr est une bonne tribune pour cela.
![[fr]](../../../images/fr.png)
La réponse de Gaël Duval (9414 hits)![[en]](../../../images/en.png)
La réponse de Gaël Duval (628 hits)-
Quand Mark Shuttleworth fait le point sur Ubuntu (2546 hits)
> Lire les commentaires (441 commentaires, moyenne: 3).
Compatibilite binaire
La seule vraie question que pose la compatibilité binaire est de savoir si on souhaite pouvoir utiliser sous Linux des logiciels écrits par des entreprises qui :
1) Ne veulent pas donner leurs sources
2) Ne peuvent pas[*], savent pas ou ne veulent pas distribuer des logiciels compilés avec plusieurs toolchains différents.
[*] Cela peut arriver quand on emploie des "composants logiciels", c'est à dire, des objets précompilés revendus de proche en proche entre sociétés de nature essentiellement financières créant de la valeur par accords de propriété intellectuelle.
-
[^]Re: Compatibilite binaire
Posté par notbugme () le 21/10/2005 à 08:15. (lien). Évalué à 10.Je ne comprendrais jamais les gens qui s'extasient lorsqu'ils voient des PCs sous windows équipés de Firefox et 1 ou 2 autres logiciels libres (bref, 95% de propriétaire) et qui rejettent les PCs sous Linux/Gnome ou KDE avec toute la suite GNU, des milliers de logiciels libres... et un malheureux Skype ou lecteur Flash (Bref, 5% de propriétaire)
Pour moi, la répnse est OUI, sans aucun doute.
Non, je ne compte pas particulièrement utiliser de tels logiciels, mais le fait est qu'une plateforme est d'autant plus intéressante qu'elle a de logiciels qui tournent au-dessus.
Bref, qu'est-ce que ca t'apporte si les logiciels dont tu parles ne tournent pas sous Linux ? Rien
Qu'est-ce que ca t'enlève si ils y tournent ? Rien, au pire tu utilises pas.
En revanche, ca rend la plateforme Linux plus intéressante pour d'autres, donc ca augmente tes chances de pouvoir l'utiliser et assure la viabilité du projet Linux à long terme.-
[^]Re: Compatibilite binaire
Posté par gnap gnap (page perso, ) le 21/10/2005 à 08:20. (lien). Évalué à 10.« Bref, qu'est-ce que ca t'apporte si les logiciels dont tu parles ne tournent pas sous Linux ? Rien
Qu'est-ce que ca t'enlève si ils y tournent ? Rien, au pire tu utilises pas. »
Il me semble que ce que veut Grumbl, c'est qu'il ne trouve qu'il soit vraiment justifié que le monde du libre fasse des efforts pour aider des gens qui ne jouent pas le jeu du libre.
Pourquoi est-ce que les développeurs de libre devraient se soucier d'un problème qui n'est que celui des développeurs de logiciel propriétaire, in fine ?
La compatibilité binaire n'a pas vraiment d'intérêt pour le libre.
Si on peut la fournir, pourquoi pas. Comme tu le dis, « ça n'enlève rien ». Sauf qu'apparemment, cette compatibilité n'existe pas. Et on peut supposer, de cette situation, que ce n'est pas dans les faits trivial, que c'est plus pratique pour les distros de ne pas la gérer.-
[^]Re: Compatibilite binaire
Posté par 桃白白 (page perso, ) le 21/10/2005 à 08:32. (lien). Évalué à 2.Beaucoup de logiciels bien chers (type calcul FEM) tournent sous Linux et je comprend parfaitement qu'ils ne souhaitent pas ouvrir leur source.
-
[^]Re: Compatibilite binaire
Posté par gnap gnap (page perso, ) le 21/10/2005 à 08:37. (lien). Évalué à 3.« Beaucoup de logiciels bien chers (type calcul FEM) tournent sous Linux et je comprend parfaitement qu'ils ne souhaitent pas ouvrir leur source. »
Heu, oui, tu trouves qu'il est bien qu'il existe des logiciels propriétaires, donc.
Nous ne sommes pas d'accord donc. Chacun son point de vue, hein.-
[^]Re: Compatibilite binaire
Posté par toystorie () le 21/10/2005 à 08:53. (lien). Évalué à 5.Je ne pense pas qu'il ai dit qu'il trouvait bien que les logiciels soient proprietaires, mais il faut bien voir que dans ce domaine, les logiciels libres ont enormement de chemin a parcourir pour proposer des solutions equivalentes. C'est un fait, point ! ces societes developpent leur logiciels depuis plus de 30 ans pour certaines, je ne doute pas un instant des capacites du libre a rattrapper son retard mais tu ne peux ignorer une situation de fait...
Dans ces conditions, je comprends l'interet de mandriva a vouloir une certaine compatibilite binaire si cela leur permet d'attaquer ce marche (ou un autre) qui est en train de basculer massivement sur linux (redhat et suse, only...)-
[+] [^]Re: Compatibilite binaire
Posté par gnap gnap (page perso, ) le 21/10/2005 à 14:58. (lien). Évalué à -1.« il ai dit qu'il trouvait bien que les logiciels soient proprietaires, mais il faut bien voir que dans ce domaine, les logiciels libres ont enormement de chemin a parcourir pour proposer des solutions equivalentes »
Quand il écrit « je comprend parfaitement qu'ils ne souhaitent pas ouvrir leur source », il n'évoque pas une « situation de fait », il dit qu'il « comprend », et donc trouve normal, juste, que des boites fassent du logiciel propriétaire.-
[^]Re: Compatibilite binaire
Posté par Michel Galle () le 21/10/2005 à 15:44. (lien). Évalué à 10.vu comment ces sociétés sont structurées et organisées, que leur modèle repose sur la vente de licence et de secrets industriels, oui il est COMPREHENSIBLE qu'elles n'ouvrent pas leur source
et pour travailler avec pas mal de progiciels scientifiques, oui c'est une PLAIE pour moi l'utilisateur.
y a par exemple vente forcée de iforte pou autre compilateur fortran propriétaire, _forcée_ au sens où non, on ne peut pas faire marcher gnu fortran avec alors que oui il compilerait très bien aussi , c'est un cas que j'ai en ce moment)
ou des complications sur les licences (erreur dans la livraison des licences, numéro invalides
ou des logiciels qui s'imaginent chez eux, qui n'aident en rien pour des installations réseaux, c'est toujours une joie quand on pense déploiement sur des centaines de postes
etc.
mais ces entreprises ont leurs raisons qui ne sont pas les nôtres, elles ne PEUVENT PAS se "réinventer" (faut réellement avoir les moyens financiers pour réinventer un business, de nouveaux "codes" de travail, des nouveaux partenariats , se recréer une nouvelle image. demandez à Novell )
et donc elles continuent à vivre sur leurs rentes, et cette rentes eXIGENT le secret du code.
et de toute façon, souvent ce dit code ne leur appartient pas totalement... imaginez la même problématique associée à la chaîne de tous les ayants droits.
bref, il n'y a aucun espoir à attendre de ce coté là
et si linux (et le libre en général) veut réussir à construire une alternative, elle doit dans un premier temps être le MEILLEUR environnement pour CES logiciels, le MEILLEUR et même amener une REELLE plus-value sur windows et unix propriétaire
voyez cela comme un cheval de Troie.
linux se répand en étant aussi compatible avec des gros logiciels propriétaires
et la pression devient toujours plus forte (et réaliste au fur et à mesure que des outils de développements et plates-formes deviennent puissants) pour que des groupes et associations construisent les uns après les autres des alternatives libres à ces "gros logiciels propriétaires"-
[^]Re: Compatibilite binaire
Posté par Jiel (page perso, ) le 21/10/2005 à 18:43. (lien). Évalué à 3.On peut aussi citer Oracle, dans le même genre. Mais par contre, Oracle devra peut-être changer de stratégie un jour, car PostgreSQL (entre autres) se fait de plus en plus menaçant.
-
[^]Re: Compatibilite binaire
Posté par Guillaume Knispel () le 22/10/2005 à 02:24. (lien). Évalué à 4.C'est PAS parce QUE tu PARLES comme CA que CE que TU dis est PLUS lisiBLE!
Sincèrement, en tant que développeur de bibliothèque, je peux te dire une chose "mais ces entreprises ont leurs raisons qui ne sont pas les nôtres" <== tout à fait d'accord, et moi je suis developpeur de bibliothèque libre et j'ai mes raisons, qui ne sont pas celles d'un éditeur de logiciel propriétaire, qui me pousse à me contrefoutre de la compatibilité binaire si jamais elle engendre ne serait-ce que 5% de soucis en plus dans ma tête. Quand c'est trivial je vais pas m'amuser à faire exprès de tout casser. Mais quand on a besoin de changer, on change, point ! Hors de question de s'amuser à faire des hacks immondes pour que le paquet prévu pour X s'intall sur la distribution Y avec le noyau de celle de la Z.
Et heureusement (enfin malheureusement pour toi) c'est l'avis de bon nombres de développeur du libre, (y compris Linus tient), donc j'ai bien peur que l'appel de Gaël ne serve pas à grand chose. (la compatibilité au niveau source est une étape nécessaire mais non suffisante pour aller vers la compatibilité au niveau binaire (à un instant t, évidemment). <= c'est une blague ??? il veut que toutes les distri sortent en même temps tous les 6 mois ???)
(bon ok, en fait je comptes pas, la biblio est sous GPL, mais quand bien même elle serait sous LGPL je ne me priverais pas de faire la même chose...et d'ailleurs les devel de biblio sous LGPL font la même chose :P)
Et même en dehors des biblio l'environnement de la distri fait que la compatibilité binaire est... difficile (cf article sur Flash et soucis du devel par exemple). Et oui il n'y a pas que les bibliothèques et la hiérarchie dans la vie.
Au final la raison est simple et je m'étonne que Gaël n'ait pas réussit à l'identifier (sinon je ne pense pas qu'il se serait fait autant d'illusions sur la compatibilité binaire) : la diversité des distri n'a rien de comparable avec l'uniformité des OS de l'éditeur majoritaire.
(diversité des différents acteurs du developpement, des choix technologiques des distri, des modes de devel des uns et des autres, etc...). Vouloir faire concorder tout ça sur le thème au combien vaste et flou de la "compatibilité binaire" relève de l'illusion (à moins de définir et d'opérer une réduction drastique de l'étendue du champ de manoeuvres)-
[+] [^]Re: Compatibilite binaire
Posté par Sam Hocevar (page perso, ) le 22/10/2005 à 10:39. (lien). Évalué à -2.Salut, peux-tu s’il te plaît nous indiquer quelles sont les bibliothèques que tu développes et dont tu te fous de la compatibilité binaire ? Cela sera très utile aux développeurs qui pourraient avoir envie de les utiliser ; ainsi, ils pourront les éviter comme la peste et des gens compétents pourront les réimplémenter si elles ont un intéret.
-
[^]Re: Compatibilite binaire
Posté par Guillaume Knispel () le 22/10/2005 à 11:39. (lien). Évalué à 6.Salut, tu pourrais apprendre à lire ?
Ça aurait un interêt je n'aurais pas à me repeter.
J'ai dis que quand on est ammené à casser la compatibilité binaire, on le fait sans scrupule (comme beaucoup de monde dans le LL au cas ou tu aurais les yeux fermés). Le besoin est loin d'être présent à chaque version, Ça arrive moins de 1x par ans. Travaillant assez étroitement avec un feedback des utilisateurs (interface graphiques et installeurs de distributions), il ne s'en plaigne pas plus que les utilisateurs de toutes les autres bibliothèques qui ont une politique proche. Ils sont donc très content merci pour eux.
Et non je n'ai pas vraiment envi de donner le nom de la bibliothèque en question vu l'insulte portée à mon égard et le fait qu'apparement un grand nombre de gens ne comprend rien au problème et s'exprime quand même sur la question.-
[^]Re: Compatibilite binaire
Posté par spart (page perso, ) le 22/10/2005 à 14:15. (lien). Évalué à 3.Franchement, casser la compatibilité binaire tous les ans, à moins qu'il ne s'agisse d'une bibliothèque à ses premiers balbutiements, c'est vraiment beaucoup trop. Et le faire sans scrupule c'est carrément idiot (ou alors c'est un geste militant ?).
Dans les trois quarts des cas, il est possible de maintenir la compatibilité binaire de manière propre à très peu de frais ; et si on s'est préparé à la maintenir dès le début ça ne demande aucun effort particulier...
Des projets comme KDE maintiennent une compatibilité binaire sur toute une série majeure (+/- 3 ans) et ça me semble tout à fait honnête comme contrainte...-
[^]Re: Compatibilite binaire
Posté par Guillaume Knispel () le 22/10/2005 à 19:48. (lien). Évalué à 7.D'abords - de 1 != 1.
Et le faire sans scrupule c'est carrément idiot (ou alors c'est un geste militant ?).
Ça n'a rien d'idiot ni de militant. C'est répondre à un besoin de manière efficace en gardant un code sain et non rempli de wrappers et autres choses dédiées uniquement à la compatibilité, chose que le nombre subliminal de developpeur empeche de toute façon de faire. Ça ne gène surtout pas les développeurs utilisateurs (qu'est-ce qu'il en aurait à foutre de la compatibilité binaire ? ils passent de toute manière leur journée à faire tourner GCC et se basent de toute manière toujours sur les dernières versions et ils ont raison), en rien les utilisateurs finaux (qui utilisent soit une version packagée sur leur distri ou sur un liveCD (ou d7) ou alors un binaire statique dans le "pire" des cas).
Encore une fois on ne change pas pour le plaisir, et pour rassurer ceux qui ont la critique stérile facile (manque de compétence, idiotie ???(en même temps jusqu'à présent j'ai ni concu l'archi ni pris de décision de casser la compatibilité binaire, donc finalement je suis pas si visé que ça)) l'archi est suffisement bien faites pour qu'en réalité l'ABI ne change qu'avec l'API, sauf réponse à un problème contextuel émergeant et suffisement grave.
Et étant donné la diversité des projets, je ne vois pas pourquoi il faudrait prendre KDE comme modèle de référence. Surtout que dans mon cas le couplage interface / bibliothèque est très fort, que l'application ce contente d'être une interface plus ou moins intelligente et que la bibliothèque contient tout le moteur qui agit.
Et je ne vois pas non plus pourquoi il faudrait qu'un critère essentiel pour le monde propriétaire doit être respecté coute que coute quand il n'est pas essentiel selon un contexte donné alors que les spécificités du libre font qu'on peut justement s'en passer à un cout relativement faible.
En conclusion, je ne nie pas qu'il existe des domaines ou la compatibilité binaire puisse être interressante (toolkit graphique utilisé par une myriade d'applis, framework) mais il y en a d'autres où elle est un frein (bibliothèque de fonctionalités et non framework, voir quand c'est carrement le moteur de l'application). Tous les types étant représentés dans une distri, et certaines n'ayant rien à gagner par la préservation d'une soit disante sacro-sainte ABI qui dans leur cas ne l'est pas, on ne peut par conséquence pas atteindre une compatibilité binaire sur une distri (même en faisant semblant d'oublier que le concept de temps T de Gaël est une fumisterie).
Et oui le monde des bibliothèques est divers et ce qui est souhaitable et possible avec les unes n'est pas forcement possible avec d'autres, et encore moins souhaitable avec les dernières. Croire qu'à des contextes très différents et variés on peut à tous appliquer les mêmes critères uniformisés sans ce rendre compte qu'ils sont dans certains cas stériles revient à confondre une voiture de tourisme avec un 38 tonnes. Ce n'est pas parce que ce sont des véhicules avec des roues qui roulent sur les routes qu'ils servent à la même chose ni ne sont conçus de la même façon.
-
[^]Re: Compatibilite binaire
Posté par lasher () le 22/10/2005 à 22:15. (lien). Évalué à 0.Je propose de casser la compatibilité ascendante des processeurs x86. Après tout, le CISC c'est pourri, et le RISC c'est mieux. Ah tiens, Intel pense comme moi, sauf que eux ont mis un décodeur pour faire du CISC => RISC sur leurs processeurs récents. Je me demande pourquoi. Certainement pas à cause de tous ces logiciels qui tournaient très bien jusque là et qu'il aurait fallu recompiler à chaque nouvelle génération de processeur si on se permettait de tout casser...
Bon, je suis de mauvais foi, et j'ai compris l'argument initial. C'est vrai qu'il vaut mieux tout recasser de temps en temps. Mais généralement, cela signifie que le modèle suivi n'est plus pertinent. Donc au contraire, je ne comprends pas trop pourquoi une bibliothèque changerait de façon drastique sa structure à ses balbutiements. Au pire, on y rajoute de plus en plus de fonctionnalités, mais les premiers symboles restent là.-
[^]Re: Compatibilite binaire
Posté par gnap gnap (page perso, ) le 23/10/2005 à 09:08. (lien). Évalué à 7.Dites, on croirait qu'on parle de logiciel propriétaire, où seul est disponible ce que l'éditeur d'un logiciel fourni.
Sur toutes les distributions GNU/Linux, on trouve plusieurs paquets d'une même bibliothèque, par compatibilité (libssl0.9.7 et libssl0.9.8 présents dans debian etch). Où est le problème ? Ca peut gêner les développeurs, c'est vrai. Mais c'est plus où moins leur soupe. Pour les utilisateurs, ça ne change rien. Ca n'a rien à voir avec la « compatibilité ascendante des processeurs x86 ».
-
-
-
-
-
-
-
-
-
-
[^]Re: Compatibilite binaire
Posté par Zanton (page perso, ) le 21/10/2005 à 09:00. (lien). Évalué à 9.Si tu parles des logiciels scientifiques ou liés à des appareils scientifiques (type AFM, RMN, etc), je trouve ça au contraire absurde. C'est aussi cher parcequ'ils sont les seuls à en proposer et bien souvent, ce sont les mêmes qui proposent matériel et logiciel. C'est facile, ils ont les specs et ils font les logiciels qui vont avec. Vu le prix d'une machine, ils pourraient livrer les specs avec et après il serait possible que la communauté livre un logiciel pour faire fonctionner la machine. Parceque, quand ton prog de gestion de DSC a un bug, que t'appelles le service après-vente et qu'on te dit, que oui, il a été signalé et qu'il sera réparé dans la prochaine version du logiciel, c'est assez pénible (bien évidemment, ils vont pas la donner la prochaine version du logiciel). Si on avait les sources, on pourrait peut-être essayer de réparer le truc.
Vraiment, les machines coûtent tellement chères qu'ils n'ont pas besoin de se faire un max de thunes en plus avec leurs logiciels qui valent une fortune.
-
-
[^]Re: Compatibilite binaire
Posté par littletux (page perso, ) le 21/10/2005 à 20:15. (lien). Évalué à 2.
Pourquoi est-ce que les développeurs de libre devraient se soucier d'un problème qui n'est que celui des développeurs de logiciel propriétaire, in fine ?
Et les utilisateurs de logiciels libres ?
Ce serait pas pratique de trouver directement sur le site d'un projet un binaire qui fonctionne à tous les coups ?
C'est vrai ça faciliterai la vie des développeurs de logiciel propriétaire, mais on va pas nous plus compliquer la vie nos utilisateurs juste pour les faire chier, si ?!-
[^]Re: Compatibilite binaire
Posté par gnap gnap (page perso, ) le 22/10/2005 à 06:53. (lien). Évalué à 6.« Ce serait pas pratique de trouver directement sur le site d'un projet un binaire qui fonctionne à tous les coups ? »
Depuis que j'utilise Debian, ça ne m'arrive jamais d'avoir à compiler. Mandriva annonce 12000 paquets, j'en déduis que ça ne devrait non plus arriver aux utilisateurs de Mandriva.
Je ne trouve pas qu'il soit idéal que chacun aille sur le site d'un projet pour trouver un binaire. Par ailleurs, si un projet veut faire cela, il est possible de compiler en statique, il est aussi possible de proposer des paquets des bibliothèques nécessaires.
« mais on va pas nous plus compliquer la vie nos utilisateurs juste pour les faire chier, si ?! »
Non, bien sur. Cependant, si ça fait maintenant plusieurs années que le dynamique est là, ce n'est pas par pure idiotie. Il y a bien un intérêt à cela.-
[^]Re: Compatibilite binaire
Posté par Mildred (Jabber id, page perso, ) le 22/10/2005 à 13:13. (lien). Évalué à 2.Le problème c'est si tu utilise une distrib avec peu de moyens et qui ne contient pas le paquet que tu veux.
Le même problème si le logiciel que tu veux utiliser est peu connu (ou alors tu veux la version sortie il y a quelques heures)
Dans tous les cas, pas de paquet pour ta distrib ... tu fais comment ?
Une solution que j'ai remarquée, c'est autopackage qui va te permettre d'installer ton logiciel presque de partout ... Qui est utilisé notament par gajim.
Mais peu encore l'utilisent ... malheureusement.
Je ne dis pas qu'il faut utiliser autopackage de partout mais c'est un moyen simple d'installer ton logiciel lorsque tu ne trouve pas le paquet et et que tu n'as pas envie de compiler les sources ...
http://www.gajim.org/
http://www.autopackage.org/
-
-
-
-
-
[^]Re: Compatibilite binaire
Posté par Nicolas Boulay () le 21/10/2005 à 08:18. (lien). Évalué à 3.Dans les 2 cas, il s'agit d'avoir des binaires qui sortent dont ne sait où.
Vu l'évolution des lib et du compilo, j'ai du mal à voir comment pourrais se réaliser ce que demande Gael Duval. A moins de faire "au minimum" pour qu'un binaire s'install partout.
Une install binaire se résume souvent à qq logiciels (souvent bien chère), donc une gestion propre des libs n'est pas forcément nécessaire. Par exemple, une compil statique pourrait peut-être faire l'affaire ?
Ensuite, une arborescence pourrait être mis en commun sur toutes les distrib. Genre /opt ... qui aurait une structure similaire à /usr mais simplifié pour garder le commun dénominateur entre les distrib.-
[^]Re: Compatibilite binaire
Posté par woopla () le 21/10/2005 à 10:34. (lien). Évalué à 10.Y'a juste un problème avec ton /opt : dans l'énorme majorité des cas en entreprise, les applis sont installées dans des répertoires séparés (les tarballs sont concus comme ca), pour plusieurs raisons :
- ca permet d'avoir plusieurs versions en parallèle (indispensable)
- ca permet d'installer ca sur des serveurs NFS, en local, n'importe ou. Si tu "forces" les gens a installer dans /opt, ca va forcément causer des problèmes à un moment ou a un autre.
Pour la compil statique c'est un peu ce qui se passe, notamment les interpéteurs (TCL/Tk, Perl) sont fournis avec le soft. Les librairies genre libc, X, par contre, sont celles de la distrib.
Pour en revenir au coup des applis scientifiques, l'énorme majorité du cout des licences vient du support. Il est possible de payer les licences beaucoup moins cher sans support. Mais comme souvent le support est vital pour les utilisateurs, ben ils paient plein pot. Ou comme le disait mon boss : "quand le client a une usine à 2,5 milliards de dollars qui tourne pas à cause de ton logiciel, t'as intéret à te grouiller pour trouver une solution" :) Ils paient très cher pour le support, donc.
Le problème de ces applis, c'est qu'elles ne sont pas utilisées par beaucoup de monde, et qu'il faudrait une équipe de gens motivés qui s'y connaissent bien en prog et dans le domaine en question. C'est plus facile de commencer un projet de logiciel libre sur un domaine pas trop complexe, parce qu'on peut commencer tout seul dans son coin par une appli qui fait un petit bout, puis rajouter des fonctionnalités et intéresser des dévs supplémentaires.
Je commence à bosser dans une quinzaine de jours pour une boite qui fait des logiciels (propriétaires) pour la microélectronique. Je verrai bien ce qu'ils pensent de l'open source, ca pourra donner des discussions intéressantes :)--
Love is like a trampoline, first it's like "SWEET!!" then it's like *BLAMM!*
-
-
[^]Re: Compatibilite binaire
Posté par Aurélien Girard () le 21/10/2005 à 08:18. (lien). Évalué à 10.En tout cas le débat binaire contre sources est très intéressant.
J'ai toujours perçu la valeur ajoutée d'une distribution dans l'abondance d'applications directement installables.
Qui n'a pas été frustré en 1998/1999 par les supers logiciels fournis sur les CDs des magazines GLHMF et Login: qui étaient ininstallables sur sa distribution pour cause d'incompatibilité ou d'obsolescence de telle ou telle bibliothèque ?
C'est pour cette raison que j'ai été ravi il y a quelques années de troquer ma SuSE contre une Mandrake. Sur Internet je pouvais trouver toutes les ressources dont j'avais besoin, sans difficulté (grâce à URPMI).
Ce que je trouve vraiment sympa avec les distributions Linux, c'est ce concept de "catalogue" d'applications.
Sous Windows, il faut chercher l'installateur qui va saloper le système de fichier et la base de registres puis le crack douteux pour l'application.
Sous MacOS, c'est plus simple : un drag&drop remplace avantageusement l'installateur.
Sous Linux, c'est encore mieux : on feuillette tranquilement son catalogue d'applications, on fouille, on fait des découvertes. On coche les applications qui nous intéressent et quelques minutes plus tard elles sont installées. Quel confort !
Je le répète : je considère que l'intérêt d'une distribution est la quantité de packages disponibles et la qualité de leur intégration. Comme il n'y a pas de distribution unique, je ne vois pas d'intérêt à avoir un catalogue unique (il y a les sources pour ça).
Le monde GNU étant ce qu'il est, je ne suis vraiment pas persuadé qu'il soit viable ou même tout simplement possible de diffuser des logiciels compatibles binairement avec toutes les distributions Linux (à part pour quelques applications monolithiques compilées statiquement comme OOo ou Firefox).
-
[^]Re: Compatibilite binaire
Posté par Matthieu Moy (page perso, ) le 21/10/2005 à 08:19. (lien). Évalué à 8.Non, il y a une autre question, c'est de savoir si un utilisateur qui ne sait pas compiler un logiciel pourra installer quelque chose qui n'est pas fourni par sa distrib.
Pour prendre un mauvais exemple, sous windows, tu prends un logiciel pas trop gros et un peu vieux récupéré on-ne-sait-trop-ou. Pour l'installer sur un Windows récent, en général, tu prends le fichier et tu double-cliques dessus, point. Sous Linux, l'installation d'un paquet est ultra-simple, par contre, le binaire qui a deux-trois ans récupéré d'on-ne-sait-trop-ou à peu de chance de marcher, et la recompilation n'est pas forcément à la porté du premier venu.-
[^]Re: Compatibilite binaire
Posté par Infernal Quack (Jabber id, page perso, ) le 21/10/2005 à 09:52. (lien). Évalué à 9.C'est parce que les softs Windows embarquent avec eux toutes les librairies dont ils ont besoin (static vs. share) et ne dépendent que des librairies de bases de Windows.
Sous linux c'est pareil pour un soft static. Il suffit d'installer Opera en version statique pour voir que ça marche nickel même sur un linux plus vieux ou avec un Opera plus vieux. Par contre ça demande plus d'espace disque. Dans le genre, klick utilise le même principe.
Donc si la LSB décrit les base du système alors les logiciels proprio devraient comme sous Windows pouvoir s'installer partout si ils sont compilés en static.-
[^]Re: Compatibilite binaire
Posté par renoo () le 21/10/2005 à 10:41. (lien). Évalué à 2.Entierement d'accord, je crois que le mieux c'est le static et eventuellement des spécifiques non-static mais la version de base installable partout c'est bien. La place disque n'est plus trop un problème... ca peut gacher un peu de mémoire vive, mais je pense que le ratio avantages / desavantages est favorable au static avec comme gros gros avantage la pérénité.
-
[^]Re: Compatibilite binaire
Posté par Infernal Quack (Jabber id, page perso, ) le 21/10/2005 à 11:30. (lien). Évalué à 9.Moi je dirais plutôt share pour les logiciels libres et static pour les logiciels non libres.
Car les premier on peut les recompiler et en faire des paquets, pas les seconds.-
[^]Re: Compatibilite binaire
Posté par etk () le 21/10/2005 à 13:07. (lien). Évalué à 3.Mais imagine qu'une grosse faille de securite, exploitee, soit decouverte dans la bibliotheque libXXX utilisee par un programme libre et un proprietaire.
- le logiciel libre: les distributions pourront le recompiler avec la version corrigee de la bibliotheque, donc ce n'est pas grave qu'il soit linke statiquement
- le logiciel proprietaire: ne peut etre recompile par la distro (ni par l'utilisateur manuellement). Donc, ne sera corrige que s'il est linke dynamiquement avec la bibliotheque libXXX.-
[^]Re: Compatibilite binaire
Posté par Infernal Quack (Jabber id, page perso, ) le 21/10/2005 à 13:41. (lien). Évalué à 6.En même temps ça c'est le problème des logiciels propriétaires :)
Et sinon ils peuvent faire comme Opera qui fournit aussi des versions linkée dynamiquement pour toutes les versions majeures des distributions.
Et puis tu sais, Firefox intègre bien des bouts de bibliothèques qui auraient très bien pu être linkées dynamiquement, mais ils ont préféré inclure du code externe (augmentant ainsi les problèmes de sécurité).
-
[^]Re: Compatibilite binaire
Posté par Pooly (page perso, ) le 22/10/2005 à 20:00. (lien). Évalué à 4.Et pour la libC tu fais le lien aussi en statique ? Ça va vite casser en cas de modification de l'ABI du noyau :-)
Par exemple Solaris 10 ne fournit plus de libC static, juste la version dynamique, sinon il y a trop de bugs et de compatibilité à gérer lors des mises à jour. (exemple: les threads fournit par la libC de sun et celles des pthreads)
-
-
-
[^]Re: Compatibilite binaire
Posté par gnujsa () le 21/10/2005 à 15:52. (lien). Évalué à 6.La place disque n'est plus trop un problème... ca peut gacher un peu de mémoire vive [...]
Le static pose d'autres problèmes que l'occupation disque/mémoire: Les failles de sécuritées et les bugs ne sont pas corrigés lors d'une mise à jour du systeme. C'est un retour en arrière, c'est plus une solution de secour qu'une solution propre.
-
-
[^]Re: Compatibilite binaire
Posté par yves tennevin (page perso, ) le 21/10/2005 à 13:17. (lien). Évalué à 1.Ce que tu dis est surtout vrai parce que d'une manière générale Windows reste compatible binairement avec lui même, quelque soit sa version. C'est voulu par Microsoft. (Ca dois même probablement poser des problèmes parfois.)
Maintenant, tu trouve aussi des binaires non compatibles...
Par exemple dès que tu commence à regarder les OS 64 bits et 32 bits. Tu va en trouver aussi entre windows 95 et 2000/xp, voir même entre xp et 2000.
Maintenant pour en revenir aux systemes libres. La compatibilité binaire entre differents linux, pourquoi pas, mais à mon avis c'est mineur comme aspect, dans la mesure où tu peux tres bien faire du pré-compilé par distribution, vu que de toute manière tu sera forcé de garder ton code compatible entre les differents os non linux, que ce soit sous windows, sous *bsd, ou autres.
Maintenant de la à dire que les binaires sont mieux car tu peux ne pas arriver a compiler tes applications à cause de conflit de librairies pas à jour, je trouve ca un peu grossier comme argument. Que je sache, j'ai rarement de problèmes pour mettre à jour mon système et mes application sous FreeBSD, mais la, c'est peut être parce que à la base je suis pas sous Mandriva? [/troll]
esby
-
[^]Re: Compatibilite binaire
Posté par Matthieu Moy (page perso, ) le 23/10/2005 à 19:37. (lien). Évalué à 4.Je suis d'accord sur le fait que linker en statique réduit les problèmes, mais ce n'est pas tout. Ce que tu appelles "librairies de bases de Windows", ça inclue l'API graphique de base, par exemple. MS fait enormément d'efforts pour garder la compatililité binaire (ça n'a pas que des avantages, mais c'est un fait). Sous Linux, regarde de quand date le dernier cassage de compatibilité binaire des toolkits graphiques courrants ...
-
-
-
[^]Re: Compatibilite binaire
Posté par Pierre Jarillon (page perso, ) le 21/10/2005 à 08:24. (lien). Évalué à 10.La compatibilite binaire est à mon avis plus une direction à suivre qu'un but à atteindre. En effet, elle suppose que les bibliothèques et les API n'évoluent plus, ce qui me parait utopique et s'oppose à l'évolution.
Par contre, les bases de stabilisent. Mandrake avait un cycle de releases de 4 mois en 1999. Il est passé à 6 mois il y a 3 ans et maintenant, il est à un an. Cela montre bien que les soubassements atteignent un niveau de perfection tel que les améliorations deviennent de plus en plus ténues. Ce processus de stabilisation va dans le sens de la compatibilité binaire.
On retrouve le même dilemme dans le cas de la normalisation : Si on normalise trop tôt, on bloque l'innovation. Si on normalise trop tard, des divergences profondes (et souvent inutiles) apparaissent. Il n'y a alors plus de synergie. Finalement, il s'agit de maintenir un équilibre délicat entre innovation et normalisation.
-
[+] [^]Re: Compatibilite binaire
Posté par TImaniac (page perso, ) le 21/10/2005 à 08:33. (lien). Évalué à -1.La seule vraie question que pose la compatibilité binaire est de savoir si on souhaite pouvoir utiliser sous Linux des logiciels écrits par des entreprises qui :
La réponse de Gaël Duval est pourtant clair : la compatibilité des sources n'est pas la solution. Ce n'est pas une question d'open-source ou non. Tout le monde aurait à y gagner, pas seulement les entreprises qui déploient exclusivement des binaires : madame Michou veut des binaires. Il faut donc des packageurs et des mainteneurs. Et c'est une perte de temps considérable pour une tâche qui n'apporte strictement rien aux logiciels libres.-
[^]Re: Compatibilite binaire
Posté par gnap gnap (page perso, ) le 21/10/2005 à 08:40. (lien). Évalué à 7.« madame Michou veut des binaires. Il faut donc des packageurs et des mainteneurs. Et c'est une perte de temps considérable pour une tâche qui n'apporte strictement rien aux logiciels libres. »
Et pourquoi donc ? Un paquet est fait selon des choix. On choisit une distro plutôt qu'une autre en fonction de ces choix.
Il est incohérent de vouloir des paquets de binaires qui marchent partout, puisqu'il y a mille raison pour une distro de vouloir adapter son paquet, pour avoir une cohérence d'ensemble.
Les distros vivent principalement de leur activité de support. C'est forcément lié à la qualité de leurs paquets, aux choix réalisés pour faire ces paquets.-
[^]Re: Compatibilite binaire
Posté par TImaniac (page perso, ) le 21/10/2005 à 08:54. (lien). Évalué à 2.Il est incohérent de vouloir des paquets de binaires qui marchent partout, puisqu'il y a mille raison pour une distro de vouloir adapter son paquet, pour avoir une cohérence d'ensemble.
Ce que je tente d'expliquer c'est qu'il y a beau avoir 15000 raisons pour personnaliser un package, il y a une raison beaucoup plus forte de garder la compatibilité : l'intérêt de l'utilisateur. A partir du moment où tu ne comprends pas ce besoin (pourtant élémentaire) de Madame Michou (qui se balance royalement des différences entre un .rpm et un .deb) tu participes à la stagnation de Linux sur le desktop.-
[^]Re: Compatibilite binaire
Posté par gnumdk (page perso, ) le 21/10/2005 à 11:46. (lien). Évalué à 2.En meme temps, vous parlez d'un truc qui existe déja, qui demande à être améliorer mais qui fonctionne:
http://klik.atekon.de/
J'ai fait des tests sous différentes distribs, et les .cmg fonctionnent sur toutes les distribs.-
[^]Re: Compatibilite binaire
Posté par TImaniac (page perso, ) le 21/10/2005 à 12:58. (lien). Évalué à 2.Ca résoud le problème de l'installe mais pas de la maintenance des packages. Si je prends un machin comme ca, et que j'essai de l'installer dans 4 ans il se passera quoi ?
-
-
-
[^]Re: Compatibilite binaire
Posté par renoo () le 21/10/2005 à 10:44. (lien). Évalué à 1.Moi je pense qu'on choisit des logiciels et pas des distros qui supportent des logiciels.. sinon c'est un peu le coup de la vente/l'offre lié. En plus c'est pas perenne quid si la distro arrete de maintenir tartanpion ?
-
[^]Re: Compatibilite binaire
Posté par djibb (Jabber id, page perso, ) le 21/10/2005 à 11:01. (lien). Évalué à 3.moi je pense qu'elles ont toutes ou presque la meme offre logicielle et que la seule chose qui fait que ca change, c'est la maniere dont les binaires sont gérés.
Il faudrait VRAIMENT se mettre a travailler dans un sens d'un format de binaire general, avec par exemple, selon la distro un fichier de conf (le prefix par exemple... les endroites ds le menu...)
-
[^]Re: Compatibilite binaire
Posté par gnap gnap (page perso, ) le 21/10/2005 à 15:03. (lien). Évalué à 2.« Moi je pense qu'on choisit des logiciels et pas des distros qui supportent des logiciels.. sinon c'est un peu le coup de la vente/l'offre lié »
Dans le cadre du logiciel libre, ça ne veut pas dire grand chose, de choisir un logiciel. Il est libre, il est normal qu'il puisse en avoir différentes versions puisque les utilisateurs ne sont pas tous pareil et peuvent avoir des besoins divergeants.
Quand à la vente liée, il faudrait pas tout mélanger. Par analogie, quand t'achète une Renault, t'achète un ensemble de chose. Tu ne peux pas dire que c'est de la vente liée que de t'avoir vendu le klaxon avec la voiture. Pire, tu ne peux pas dire que c'est de la vente liée que de t'avoir donné une paire de lunette "I love Clio" avec.
L'activité d'une distribution, c'est bien de distribuer. Il n'y a rien d'étonnant à ce qu'ils distribuent des logiciels préparés par leurs soins.
-
-
-
-
[^]Re: Compatibilite binaire
Posté par olosta () le 21/10/2005 à 08:45. (lien). Évalué à 5.De toute façon la solution a ce problème c'est Java ou mono.
Bon je vais faire un tour...-
[^]Re: Compatibilite binaire
Posté par Pooly (page perso, ) le 22/10/2005 à 20:02. (lien). Évalué à 8.Même pas ! Tu dépends de la version de la JVM !
Et t'es bien embêter lorsqu'il faut downgrader ta JVM pour accéder à l'interface de ton routeur, alors que t'utilise une autre programme qui utilise une version supérieure...
-
-
[^]Re: Compatibilite binaire c'est la faute aux libs partagées
Posté par renoo () le 21/10/2005 à 10:37. (lien). Évalué à 2.C'est surtout un problème si on utilise des libs dynamiques ? Si tout est compilé statiquement il n'y a pratiquement pas de problemes de compatibilités binaires. Pour les outils de base les libs dynamiques ont vraiment un sens, pour une application métier précise le mieux est probablement de tout linker en statique ça permet de savoir en plus ce qui est réellement exécuté.
-
[^]Re: Compatibilite binaire c'est la faute aux libs partagées
Posté par gnumdk (page perso, ) le 21/10/2005 à 11:50. (lien). Évalué à 3.http://klik.atekon.de/architecture/
klik n'utilise pas de compilation statique, il apporte avec lui tout ce dont il a besoin et un "wrapper" se charge de tout rendre transparent.
-
[^]Re: Compatibilite binaire c'est la faute aux libs partagées Faux ;)
Posté par Ludovic Rio (page perso, ) le 21/10/2005 à 12:19. (lien). Évalué à 1.Si tout est compilé statiquement [...]
Cette hypothèse est un peu farfelue, notamment pour la taille des programmes (même pour une application orientée métier) ;)-
[^]Re: Compatibilite binaire c'est la faute aux libs partagées Faux ;)
Posté par gnap gnap (page perso, ) le 21/10/2005 à 15:04. (lien). Évalué à 3.Ca signifierait en fait dégrader la qualité des logiciels libres, dans l'intérêt de leur compatibilité avec des logiciels propriétaires. Ni plus ni moins.
Car il ne faudrait pas penser que le choix de faire du dynamique a été pris au hasard, par idiotie.
-
-
-
[^]Re: Compatibilite binaire
Posté par Alexandre Garel () le 21/10/2005 à 11:53. (lien). Évalué à 2.Perso, je trouve la compatibilité bianaire intéressante car par exemple si je veux utiliser le dernier inkscape, je doit le compiler à la main (donc connaitre les outils, galérer, installer tous ces outils sur ma machine , les headers etc...., plus d'espace que n'en prenait ma distrib au début). Un utilisateur actuel de windows ne comprendra absolument pas pourquoi sous linux il ne peut pas avoir le dernier programme, là sur le site, mais se contenter de la version contenue dans sa distro.
Perso, je ne pense pas que LSB soit le bon moyen d'atteinder la compatibilité binaire, mais plus un système/standard qui devrait permettre à linux d'indiquer ou se trouvent les librairies, d'avoir plusieurs version de la bibliothèque installés....
Une autre solution pourrait être que les sites comme inkscape proposent une version binaire tout linké en statique pour ceux qui la veulent vraiment (ce serait peut-être plus simple et prendrait moins de place que tous les outils de compile)
Encore une autre solution (complémentaire à la précédente) pourrait être que les distrib propose des fermes de compilation ou un dev ou un utilisateur puisse balancer un source, compiler et construire un paquet (en automatique) qu'il met sur la page de son projet.-
[^]Re: Compatibilite binaire
Posté par Alexandre Garel () le 21/10/2005 à 11:58. (lien). Évalué à 2.Je me réponds à moi même puisque klik fait effectivement bien l'affaire (le commentaire du dessus à été posté pendant que je rédigeais !). Alors yapuka fokon mette un lien vers klik sur les pages des projets !
-
-
[^]Re: Compatibilite binaire
Posté par herodiade () le 21/10/2005 à 19:19. (lien). Évalué à 9.et tu oublie :
3) ne veulent pas se donner la peine de compiler (et du coup, je suppose: tester, puisque c'est la partie la plus longue) sur les diverses distros.
Le jour ou les logiciels dont il est question dans cette enfilade (skype, oracle, opera ...) proposeront un package binaire linké dynamiquement et soit-disant "universel", je m'inquieterai sur la qualité et la stabilité du bouzin. LSB ou pas.
Comme le répètent Shuttleworth et Ulrich Drepper, prétendre à la compatibilité binaire, à la stabilité des ABI ("stabilité" au sens de constance entre les différentes distros) est une vaste fumisterie.
Merci Gael Duval pour cet enfumage de première.
Ce qui compte évidement, c'est d'avoir une stabilité des API (constance de l'interface de programmation) suffisante pour que la compilation (par l'utilisateur ou par le packageur) soit possible sans mal avec la version des libs qu'il à choisi (disont, dans une fenêtre raisonable de versions).
-
[^]Re: Compatibilite binaire
Posté par benp () le 22/10/2005 à 10:26. (lien). Évalué à 8.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 d-jo (page perso, ) le 22/10/2005 à 12:42. (lien). Évalué à 7.Ce genre de discours me semble très accrocheur mais totalement à côté de la plaque.
Il ne suffit pas d'éluder une question pour affirmer qu'elle ne se pose pas.
Si on veut éviter que le marché des systèmes d'exploitation grand public soit perpétuellement réduit à un ou deux acteurs, il faut que les éditeurs puissent faire des logiciels pour une multitude de SE. Il faut que les utilisateurs puissent installer rapidement et simplement des programmes depuis le web, depuis un CD-ROM.
Il y a donc quelque chose à penser en ce domaine. On peut critiquer LSB qui à au moins le mérite d'exister. Il faudra d'une façon ou d'une autre inventer quelque chose permettant de certifier qu'un logiciel binaire va fonctionner sur un ensemble de systèmes d'exploitation.
La compatibilité des sources actuelle est une tres bonne chose, mais totalement insuffisante. Même en terme de logiciels libres. Maintenir plus de 10000 paquets est un travail fastidieux et inutile. Les distributions perdent dans cette activité une grosse partie de l'argent quelles pourraient consacrer en R&D.
Nous avons donc un système qui pompe un maximum d'énergie pour RIEN et auquel l'utilisateur final ne pompe RIEN.
Moralité : les distros se ressemblent toutes et MS avec son API win32, se frotte les mains et rigole : linux ? Quel linux ?
Alors je ne dis pas que tes arguments ne sont pas bons. Je trouve qu'il serait bon d'adopter une attitude plus positive. Parceque l'état actuel des choses "n'aide pas à établir le sérieux" de GNU/Linux comme OS grand public.-
[^]Re: Compatibilite binaire
Posté par benp () le 23/10/2005 à 02:10. (lien). Évalué à 5.> Il ne suffit pas d'éluder une question pour affirmer qu'elle ne se pose pas.
Hein ? j'élude quoi ?
J'explique (en argumentant) que la compatibilité binaire entre les diverses distros demanderai un travail trop important pour qu'on puisse le faire, donnerai un résultat insuffisant et instable, et ne serait pas utile car il existe des solutions (au problème nommé: faire tourner l'appli x version y sur la plateforme z) qui marchent très bien (utiliser un package standard, ou installer par les sources, ou récupérer le package non officiel d'un autre utilisateur qui l'a construit).
> Il faut que les utilisateurs puissent installer rapidement et simplement des programmes depuis le web, depuis un CD-ROM.
Tout à fait, et c'est ce qu'ils font déjà. Tu utilise LFS ou quoi ?
> Maintenir plus de 10000 paquets est un travail fastidieux et inutile
OK alors on résume: si chaque paquet n'était packagé qu'une seule fois, il n'y aurait tout simplement qu'une seule distrib. Ça ne me semble vraiment pas souhaitable.
Parceque le fait de produire le binaire, c'est peanuts, c'est peut être 5% du temps passé sur la préparation du paquet (le tester, le mettre à l'épreuve, le documenter, ...). Faire le binaire + préparer le paquet (test, debug etc.) c'est bien le travail des distros. Autrement dit: polir, debugguer, améliorer les logiciels (et accessoirement les compiler et packager). S'il y a moins de personnes qu'ils le font, alors les logiciels seront moins bons (je parle des tests bien sûr, parceque la compilation/packaging, c'est maintenant totalement automatisé dans la plupart des cas).
Quand au "fastidieux et inutile", il faudra alors m'expliquer pourquoi un millier de developpeurs se pressent au portilion debian.-
[^]Re: Compatibilite binaire
Posté par d-jo (page perso, ) le 23/10/2005 à 12:11. (lien). Évalué à 3.>Hein ? j'élude quoi ?
Le problème.
A te lire tout va bien.
Tu ne prends même pas la peine de te placer sur le même présupposé que GD : faire un linux grand public. Alors que tu en conviendra, il existe pour chaque distribution une bonne façon d'installer un logiciel et plusieurs mauvaises.
Cette situation est intolérable dans un cadre grand public. On ne peux pas demander au gens de faire les choses de telle ou telle façon. Pour t'en convaincre, regarde les vidéos sur http://www.betterdesktop.org/welcome/
>OK alors on résume: si chaque paquet n'était packagé qu'une seule fois, il n'y aurait tout simplement qu'une seule distrib. Ça ne me semble vraiment pas souhaitable.
Franchement, je ne serai pas aussi enthousiaste que toi sur la diversité actuelle. Je ne vois vraiment pas de différences fondamentales entre les distros. Je trouve même qu'elles ont tendance à se ressembler de plus en plus.
Je pense au contraire que si les distros passaient moins de temps a packager (j'ai pas dit compiler) FrozenBubble, elles seraient plus libres pour innover et se démarquer les unes des autres.
Je n'ai jamais dit que je trouvais que la compatibilité binaire était une solution merveilleuse. J'ai juste fait remarqué que tout n'était pas si parfait que ça. Et qu'il faudrait bien imaginer quelque chose pour améliorer la situation si l'objectif est de faire du grand public
>Faire le binaire + préparer le paquet (test, debug etc.) c'est bien le travail des distros
Absolument pas. Le travail des distros est de faire un système d'exploitation fonctionnel.
Si la seule solution actuellement envisageable pour assurer un confort d'utilisation correct est de tout packager ce n'est qu'une conséquences, une tradition mais en aucun cas l'objectif des distros.
>il faudra alors m'expliquer pourquoi un millier de développeurs se pressent au portillon debian.
???
Je ne vois pas le rapport.-
[^]Re: Compatibilite binaire
Posté par benp () le 23/10/2005 à 12:56. (lien). Évalué à 6.>Hein ? j'élude quoi ?
Le problème.
A te lire tout va bien.
[...]
Et qu'il faudrait bien imaginer quelque chose pour améliorer la situation si l'objectif est de faire du grand public
[...]
Absolument pas. Le travail des distros est de faire un système d'exploitation fonctionnel.
Ah voilà. Là on touche à une différence fondamentale de position. Je considère que le plus important travail de mes fournisseurs de distros, c'est de s'assurer que tout marche bien ensemble. Donc de tester énormément les logiciels, chasser les bugs par tout les moyens etc. autrement dit, de polir et stabiliser le logiciel brut fournis par les developpeurs. La compilation/construction de packages est une étape infime (mais necessaire) de ce processus. Je ne vois pas pourquoi "faire du grand public" signifirai "sortir des logiciels peu/mal testés sur la plateforme" ; est-ce que c'est le point de vue de Mandriva ?
Même lorsque tu a une compatibilité binaire théorique (par ex. avec des softs ne dépendant que de la glibc), il faut tout tester à fond (ce qui prend autant de temps).
D'autre part Ubuntu vise aussi le grand public, et ses devs disent très bien s'en sortir avec les échanges de packages sources avec Debian Sid (et réciproquement).
Je pense au contraire que si les distros passaient moins de temps a packager (j'ai pas dit compiler) FrozenBubble, elles seraient plus libres pour innover et se démarquer les unes des autres.
Je me suis donné beaucoup de peine pour expliquer plus haut que l'amélioration de la compatiblité binaire sur la plateforme Linux (où l'utilisation de lib partagées est considérable != windows) exigerait un travail titanesque (pour un résultat approximatif au mieux). C'est *beaucoup* plus de travail que de packager l'appli.
Pour t'en convaincre, regarde les vidéos sur http://www.betterdesktop.org/welcome/
Oui, je pense aussi que l'ergonomie est un problème crucial et prioritaire. Avec l'interopérabilité des softs.
C'est pourquoi que je considère que la priorité pour les distros grand public, ce n'est pas de passer des centaines d'années-homme à tenter d'établir une compatibilité binaire (qui restera approximative et n'enlevera jamais le besoin de tester), mais de se concentrer sur l'interopérabilité entre les logiciels, les desktops environements, l'ergonomie, les standards Unix. Bref, de travailler sur freedesktop.org, POSIX, OpenUsability, Gnome HIG, les projets "Appeal" et "Tango" etc.
Et c'est justement ce que les developpeurs (de gnome, glibc, kde) font en ce moment. Ils n'ont rien compris ?
>il faudra alors m'expliquer pourquoi un millier de développeurs se pressent au portillon debian.
???
Je ne vois pas le rapport.
Tu disait que la construction, maintenant, testing etc. des packages était une tache pénible et ingrate, et je te demandait de m'expliquer pourquoi, dans ces condition, autant de bénévoles se réjouissent d'y participer.-
[^]Re: Compatibilite binaire
Posté par d-jo (page perso, ) le 24/10/2005 à 07:23. (lien). Évalué à 1.Je considère que le plus important travail de mes fournisseurs de distros, c'est de s'assurer que tout marche bien ensemble
C'est quoi "tout" ? tout ça à forcement une limite. Je trouve qu'il vaut mieux la fixer en connaissance de cause que d'en rester sur un "tout" indéfinie.
Je ne vois pas pourquoi "faire du grand public" signifirai "sortir des logiciels peu/mal testés sur la plateforme" ; est-ce que c'est le point de vue de Mandriva ?
Je croyais qu'on été la pour discuter
Je me suis donné beaucoup de peine pour expliquer
....
que de packager l'appli.
Je me suis donné beaucoup de mal pour expliquer que je reconnaissait la validité de tes arguments sur la compatibilité binaire. Ce n'est pas pour autant qu'il faut nier le fait que l'absence de compatibilité pose des problèmes.
Et c'est justement ce que les developpeurs (de gnome, glibc, kde) font en ce moment. Ils n'ont rien compris ?
Tu dois être ingénieur toi ;-) pour sortir des trucs pareils-
[^]Re: Compatibilite binaire
Posté par benp () le 24/10/2005 à 09:32. (lien). Évalué à 2.C'est quoi "tout" ? tout ça à forcement une limite. Je trouve qu'il vaut mieux la fixer en connaissance de cause que d'en rester sur un "tout" indéfinie.
Précisément.
Le "tout" ici, c'est : tout les logiciels / packages que mon fournisseur distribue.
C'est ça la limite, l'ensemble fini. Parceque mon dealer de linux peut difficilement s'assurer que "tout les packages externes susceptibles d'etre installés mais eventuellement fabriqués et distribués par d'autres (et sur lesquels il n' a pas le controle / ne peut pas les corriger)" fonctionnent avec sa distro.
Ce qui fait que, compatibilité binaire ou pas, une incertitude subsistera concernant l'intégration et le bon fonctionnement de ces packages sur ma distro, et on n'aura probablement pas un support officiel de Red Hat sur les packages Mandriva (ce qui n'aidera ni les débutants qui ne peuvent pas compiler eux-memes, puisqu'on ne pourra pas leur recommander d'utiliser des packages externes dont il ne sauraient pas gérer les incompatibilité, ni les ISV, qui veulent pouvoir faire du support "officiel" cf. oracle).
Ça donne ceci, dans le texte de Duval, lorsqu'il parle de la compatibilité binaire entre Mandriva et Red Hat (pourtant supposée bonne):
"Il en résulte qu'on obtient souvent une très bonne compatibilité au niveau source, et même parfois une compatibilité binaire, en fonction des versions utilisées, par exemple entre Red Hat/Fedora et Mandriva. Bien entendu, ce sont des compatibilités binaires accidentelles, ".
On voit bien que même dans ce cas "idéal" (deux distribs proches, LSB compliant) sa réponse est très vague et n'aidera pas l'utilisateur (surtout néophyte) à determiner si le package lambda pour RHEL marchera sur sa Mdv, ni l'ISV pour établir s'il peut supporter son package fabriqué sur RHEL pour les utilisateurs Mdv.
Ce n'est pas pour autant qu'il faut nier le fait que l'absence de compatibilité pose des problèmes
Ah, "nier", oui, je préfère (plutôt qu''éluder": ce que je ne pense pas avoir fait) !
Ou pour être plus précis: je pense que ça pose des tout petits problèmes, très secondaires (en fait, essentiellement pour les logiciels propriétaires - pourquoi se donner tant de peine avec eux - qui ont par ailleur des solutions de secours).
Ou bien: que la tentative de compatibilité binaire est la (mauvaise) solution a un autre problème.
D'autre part j'ajoutais que plus la "compatibilité des sources" (stabilité des API et interopérabilité entre environements logiciels: des objectifs plus faciles à atteindre) est bonne, moins la question de la compat binaire se pose (si la compilation et l'intégration fonctionne comme sur des roulettes, alors les ISV n'ont pas beaucoup d'effort à faire pour supporter plein de distros).
Quant à ceux qui souhaitent la compatibilité binaire pour installer de temps en temps la dernière version de nautilus ou autre, ça n'est pas le but qu'indique Duval (et pour le coup ce serait délirant, faire tourner gnome 2.12 sur gtk 1 ou 2 au choix ? ):
"Au final, je pense que la seule voie possible pour les distributions Linux est de se mettre d'accord sur des versions de logiciel et de bibliothèques communes à un instant t".
Ça ressemble à un voeux pieu.
-
-
-
-
-
-
[^]Re: Compatibilite binaire
Posté par Éric (Jabber id, page perso, ) le 22/10/2005 à 13:11. (lien). Évalué à 2.> Or, pour mémoire, il suffit d'avoir seulement un kernel différent
C'est justement ça qu'il aimerait changer. Que même sur une montée en version, on reste compatible au niveau binaire (enfin le plus possible).
Bref, si tu prend la situation actuelle (qui est justement critiquée) pour montrer que ce n'est pas possible ... tu te mord forcément la queue.
> 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.
Sur d'autres systèmes, que je ne nommerai pas mais qui font beaucoup parler ici, on peut installer des softs même si les libs sont dans des versions différentes, avec des patchs différents, et avec des kernels (très) différents.
Pourquoi nous on ne le pourrait pas techniquement ? tu m'expliques ?
Après c'est sûr qu'on peut parler de fenêtre de temps raisonnable (ce qu'il dit par "un instant t"), mais oui, pour des distributions sorties dans tes temps proches, ça serait bien que les binaires soient compatibles.
> - 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.
Si déjà on pouvait y arriver sur une même architecture (avoir juste besoin de choisir l'architecture et pas entre 300 binaires à chaque fois avec toujours "celui que je veux manque"), ça serait bien.
Si déjà, pour les architectures courantes (x86, amd64, mac) du grand public (les professionnels sur sparc c'est un peu un autre débat), quand je trouve un binaire de la bonne arch je pouvais l'installer avec une chance de réussite importante .. ça serait bien.
Notes aussi que mac a trouvé une bidouille infame pour avoir une compatibilité binaire entre versions *et* architectures. Je ne dis pas qu'il faut faire la même chose mais c'est étrange que dès qu'on parle de libre on a l'impression d'être super limité dans ce genre de problématiques alors que les autres y arrivent assez bien.
> À la première faille de sécu de firefox, par ex., les packages contenant les plugins
Pourquoi ? sauf cas où la faille touche justement l'API utilisée par les plugins, c'est justement l'exemple type où la compatibilité binaire ne devrait pas être cassée. D'ailleurs pour le coup, là, ça marche assez bien.-
[^]Re: Compatibilite binaire
Posté par benp () le 22/10/2005 à 17:54. (lien). Évalué à 2.>> Or, pour mémoire, il suffit d'avoir seulement un kernel différent
> C'est justement ça qu'il aimerait changer.
Vu la superbe représentation des devs Mandriva sur LKML, c'est sûr que les coups de gueule de Gaël Duval sur son blog vont faire changer les chose :)
> si tu prend la situation actuelle (qui est justement critiquée) pour montrer que ce n'est pas possible
Je dit que ce n'est ni possible, ni intéressant.
Et je dit bien que ce n'est pas possible : donc dans la situation actuelle et les situations futures.
> Pourquoi nous on ne le pourrait pas techniquement ? tu m'expliques ?
Bon sang, mais j'ai passé 1/2 heure à l'expliquer juste au-dessus !
> Si déjà, pour les architectures courantes (x86, amd64, mac) du grand public
Ah, mais si tu cherche un système pour pécé seulement, grand public (seulement), dont l'ABI ne change jamais afin de faire tourner des logiciels propriétaires closed source, mon vieux, c'est tout vu. Windows est adapté à tes besoins.
Les softs MS eux-mêmes ne supportent que 2 ou 3 versions de windows au plus (cf. le futur ie7, ou office 2003 etc.), et pourtant leur modèle closed source les forces à garder des tonnes d'immondices (comme le DOS) pour assurer une compatibilité ascendante.
> Notes aussi que mac a trouvé une bidouille infame
Oui, pour le format des binaires. Maintenant si on parle de la compatibilité ascendante chez Mac (et même en ne restant que sur la série des Mac OS X), tu verra que ce n'est pas ça du tout.
> Pourquoi ? sauf cas où la faille touche justement l'API utilisée par les plugins, c'est justement l'exemple type où la compatibilité binaire ne devrait pas être cassée. D'ailleurs pour le coup, là, ça marche assez bien.
Simpe: parce que les types de firefox cassent très régulièrement l'API, et font des updates groupées (incluant du refactoring, pas uniquement les patches sécus). Cf. par ex. la cata. 1.0.4 -> 1.0.5. Et après l'arrivée prochaine de 1.5, je doute qu'ils maintiennent 1.0.* bien longtemps ("upgradez les gars").-
[^]Re: Compatibilite binaire
Posté par lezardbreton (Jabber id, page perso, ) le 22/10/2005 à 19:07. (lien). Évalué à 2.Vu la superbe représentation des devs Mandriva sur LKML
Ca te perturberait si je te disais qu'il y en a ? Genre Arnaldo Carvalho de Melo ?-
[^]Re: Compatibilite binaire
Posté par benp () le 23/10/2005 à 02:11. (lien). Évalué à 0.>> Vu la superbe représentation des devs Mandriva sur LKML
> Ca te perturberait si je te disais qu'il y en a ? Genre Arnaldo Carvalho de Melo ?
Wow, avec ça ils sont super bien parés pour faire la loi sur LKML. Red Hat et Suse n'ont qu'à bien se tenir !-
[^]Re: Compatibilite binaire
Posté par lezardbreton (Jabber id, page perso, ) le 23/10/2005 à 08:10. (lien). Évalué à 4.Je n'ai pas dit qu'il y avait que lui. Par contre, au moins, il y en a, et ça correspond aussi au fait que le nombre de dev Red Hat est largement supèrieur à celui de Mandriva. C'est une réalité, tout le monde n'a pas les mêmes moyens...
-
[^]Re: Compatibilite binaire
Posté par benp () le 23/10/2005 à 12:25. (lien). Évalué à 2.Et bien lorsque les developpeurs les plus pointus techniquement (en l'occurence les devs du kernel, de glibc, de gcc) considèrent que pour avoir un logiciel de bonne qualité sous Linux, il ne faut pas tenter la compatibilité binaire à 100% mais plutôt se décarcasser sur la compatibilité avec les standards d'api (ANSI C, aka C89, C99, POSIX, fd.org ..., qu'on est encore loin d'avoir atteint), et que Monsieur Gaël Duval clame à l'inverse qu'il faut changer tout ça et se focaliser sur les binaires, excuse moi, mais je fait plutôt confiance aux developpeurs du kernel, de la glibc, de gcc etc.
Que j'ai tort ou raison, la faible représentation des devs mdk dans ces projets cruciaux fait que ces priorités ne changeront pas (au-delà de LSB).
Ceux qui font évoluer les choses ne sont pas les commercials qui disent leur opinion sur leur page perso, mais les developpeurs (si tu veut vraiment de la compat binaire, au lieu de raler contre les choix devs, tu n'a qu'à y travailler).-
[^]Re: Compatibilite binaire
Posté par gnap gnap (page perso, ) le 23/10/2005 à 17:11. (lien). Évalué à 2.Quelqu'un a le droit d'avoir un avis sur un le sujet qu'il veut, il a le droit de l'exprimer.
Ce n'est pas parce que son avis n'est pas dominant qu'il « râle ».
Son avis ne me parait pas très judicieux mais ce n'est pas le problème. Déjà, de fait, ce sont ceux qui sont aux manettes qui font les choix. Ce n'est pas la peine de blâmer les autres parce qu'ils s'expriment publiquement.
-
-
-
-
-
[^]Re: Compatibilite binaire
Posté par Éric (Jabber id, page perso, ) le 22/10/2005 à 21:05. (lien). Évalué à 1.> Et je dit bien que ce n'est pas possible : donc dans la situation actuelle et les
> situations futures.
Désolé. 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.
> Ah, mais si tu cherche un système pour pécé seulement, grand public
> (seulement), dont l'ABI ne change jamais afin de faire tourner des logiciels
> propriétaires closed source, mon vieux, c'est tout vu. Windows est adapté à tes
> besoins.
Ca te défrise que le grand public sous PC puisse vouloir des binaires relativement stables ?
Si pour toi utiliser du lociel libre c'est forcément compiler des sources sur une architecture exotique je pense que tu as loupé une marche.
Ce n'est pas parce qu'un binaire est dispo et qu'il va être possible de l'installer assez facilement sur tous les PC que ça change quoi que ce soit à la dispo des sources ni au fait que ceux qui ont des archi moins courantes ou des config spéciales peuvent continuer à profiter de ces sources.
Pouvoir aller chercher les sources, pouvoir avoir une compatibilité des sources, pouvoir faire fonctionner ça sur plein d'architectures, pouvoir modifier ces sources et corriger .. tout ça c'est super et je ne le remet pas du tout en cause.
Par contre il y a une différence entre pouvoir le faire et y être obligé. 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, ça ne fait qu'ajouter un peu de simplicité pour ceux qui ne veulent pas le faire
Ca n'a rien à voir ni avec Windows ni avec le close source. Ca marche aussi coté libre (regardes le nombre de gros projets libres à proposer des binaires sur leur site)
> Les softs MS eux-mêmes ne supportent que 2 ou 3 versions de windows au plus
Damned, 2 ou 3 versions ? on parle bien de Windows qui sort une version tous les 2 à 3 ans ? de à trois versions ça fait 6 ans.
Tu crois que les binaires d'Openoffice que je peux télécharger ils tournent sur une distrib d'il y a 6 ans ? (petite info: le même binaire d'OOo 1.1.5 il tourne sur un windows d'il y a 10 ans)
6 ans ... mais je n'en demande même pas la moitié. Si déjà un binaire pouvait être valable sur à peu près toutes les distro du même style pendant un ou deux ans ça serait une énorme amélioration.
> Simpe: parce que les types de firefox cassent très régulièrement l'API, et font
> des updates groupées (incluant du refactoring, pas uniquement les patches
> sécus). Cf. par ex. la cata. 1.0.4 -> 1.0.5. Et après l'arrivée prochaine de 1.5, je
> doute qu'ils maintiennent 1.0.* bien longtemps ("upgradez les gars").
Ben voilà, et si c'était simplement ça à remettre en cause ? ne changer les API que sur des choses vraiment majeure, et plus on est dans les couches basses moins les changer souvent ? C'est super bête dit ainsi, mais actuellement un binaire a une durée de vie de moins d'un an sur les distro, c'est très faible, très très faible. Et je ne parle même pas du fait de devoir distribuer 10 binaires différents pour une même architecture afin de couvrir toutes les possibilités.-
[^]Re: Compatibilite binaire
Posté par benp () le 23/10/2005 à 01:52. (lien). Évalué à 5.> 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 Mildred (Jabber id, page perso, ) le 22/10/2005 à 13:47. (lien). Évalué à 2.Au final l'utilisateur trouvera presque toujours un package sur mesure. Sauf pb de brevet ou logiciel propriétaire (mais cf. ci-dessous).
Personellement, j'ai eu souvent des problèmes pour trouver les paquets que je voulais ...
Ce problème arrive pour les distrib peu connues (avec peu de ressources) et les paquets peu connus.
Par exemple, a un moment j'avais des problèmes récurrents avec mplayer et Ubuntu ... j'ai du les compiler dans /usr/local. debian-marillat marchant mal avec ubuntu
de même avec la bibliothèque Ogre3D --> /usr/local
avec blender (je veux la dernière version) --> ~/.local/blender/
...
Et lorsque c'est gnome ou kde qui manque, peut on envisager de le compiler dans /usr/local ? personellement, je n'oserait pas. Heureusement, Ubuntu l'a compilé pour moi.
Et ce sont des logiciels libres ...-
[^]Re: Compatibilite binaire
Posté par benp () le 23/10/2005 à 02:18. (lien). Évalué à 1.> j'avais des problèmes récurrents avec mplayer et Ubuntu ... j'ai du les compiler dans /usr/local. debian-marillat marchant mal avec ubuntu
Oui ubuntu est jeune est c'est en train de se mettre en place. Maintenant c'est ok, il y a PLF.
> avec blender (je veux la dernière version) --> ~/.local/blender/
Ça c'est une autre question (les paths d'installation). Tu peut bien l'installer system-wide (/usr ou /usr/local) comme le ferait d'ailleur un package venant d'une autre distrib (si tu avait la fameuse "compatibilité binaire"). Mais tu hésite à le faire pour ne pas pourir ta distro, ce que je comprend bien. Mais tu aurait autant hésité (pour les mêmes raison
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.