> Tu peux synchroniser les versions de composantes sans forcément scléroser les projets, ce sont deux choses distinctes.
Tu te trompes à ce sujet. Si tu décides que les distributions majeures utiliseront le même noyau, le même X, le même GCC, les constructeurs se borneront à supporter ces versions et point barre.
Si tu cales ton cycle de développement sur celui des pilotes/logiciels propriétaire, tu es foutu. Si un constructeur refuse de supporter tel ou tel version du noyau ou de Xserver, tu fais quoi? selon Mark S., soit je fige mon interface pour lui faire plaisir, soit je fous des gros hacks pourris pour contourner ça.
C'est ce que faisait XGL ou Beryl avec les pilotes propriétaires, au fur et à mesure des hacks, la situation est devenu inmaintenable.
Au final, c'est AIGLX qui a gagné parce qu'ils ont préféré faire les choses proprement et qu'ils ont obligé les constructeurs à adapter leurs pilotes. Idem pour Beryl qui a disparu au profit de Compiz.
La synchronisation n'est pas une mauvaise chose, mais il faut des objectifs communs, c'est ce que fait Eclipse, Freedesktop.org.
Mais ça ne peut pas marcher entre des distributions ayant des objectifs différents, avec un calendrier rigide sur 2 ans alors que la plupart des logiciels libres n'ont pas une vision claire de ce que sera leur avenir au-delà de 6mois/1 an.
ça ne peut par marcher, si on joue dans un rapport de force entre distributions/upstream.
Si il doit avoir synchronisation, elle doit se faire en upstream et pas ailleurs.
> la facilité offerte aux développeurs de solutions propriétaires serait également offerte aux développeurs du libre.
Justement, le logiciel libre n'a pas besoin de cette facilité. Quand on casse une interface dans le noyau ou dans X, les pilotes sont quasi automatiquement corrigés que ce soit par le mainteneur du pilote, du changement d'API, ou un tiers.
G. K-H explique très bien pourquoi une API interne stable dans Linux n'a pas de sens et n'est pas souhaitable.
C'est même un argument majeur pour libérer les pilotes, les boites propriétaires n'ont guère le choix, soit elles fournissent un effort supplémentaire pour suivre les développements, soit elles libérent les informations. Sur le long terme, seule la seconde solution est viable.
Ce que tu appelles difficulté est en fait une force du libre, à tout moment, si un composant n'est pas satisfaisant, je peux le remplacer sans avoir à me retenir.
Si tu prends Gnome-vfs, c'était une merde en pourriture, plus personne n'osait y toucher. En moins de 6 mois, on a pu écrire un remplaçant gvfs -avec une meilleure architecture- et modifier tout gnome afin d'utiliser celui-ci.
Aurait-il été de possible de faire de même si on devait se soucier de la compatibilité ? si on ne pouvait pas modifier le code librement ?
> c'est une perte de ces différences qui seraient préjudiciables aux projets qui seraient délaissés par toutes les distributions participant.
Si on poussait la logique jusqu'au bout, effectivement, on aurait une espèce de méta-distribution avec des différences mineures.
C'était envisageable dans le cadre des distributions dérivées de Debian mais ça ne l'est pas au niveau des distributions GNU/Linux.
[^] # Re: La réponse d'Aaron Seigo
Posté par GeneralZod . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 6.
Tu te trompes à ce sujet. Si tu décides que les distributions majeures utiliseront le même noyau, le même X, le même GCC, les constructeurs se borneront à supporter ces versions et point barre.
Si tu cales ton cycle de développement sur celui des pilotes/logiciels propriétaire, tu es foutu. Si un constructeur refuse de supporter tel ou tel version du noyau ou de Xserver, tu fais quoi? selon Mark S., soit je fige mon interface pour lui faire plaisir, soit je fous des gros hacks pourris pour contourner ça.
C'est ce que faisait XGL ou Beryl avec les pilotes propriétaires, au fur et à mesure des hacks, la situation est devenu inmaintenable.
Au final, c'est AIGLX qui a gagné parce qu'ils ont préféré faire les choses proprement et qu'ils ont obligé les constructeurs à adapter leurs pilotes. Idem pour Beryl qui a disparu au profit de Compiz.
La synchronisation n'est pas une mauvaise chose, mais il faut des objectifs communs, c'est ce que fait Eclipse, Freedesktop.org.
Mais ça ne peut pas marcher entre des distributions ayant des objectifs différents, avec un calendrier rigide sur 2 ans alors que la plupart des logiciels libres n'ont pas une vision claire de ce que sera leur avenir au-delà de 6mois/1 an.
ça ne peut par marcher, si on joue dans un rapport de force entre distributions/upstream.
Si il doit avoir synchronisation, elle doit se faire en upstream et pas ailleurs.
> la facilité offerte aux développeurs de solutions propriétaires serait également offerte aux développeurs du libre.
Justement, le logiciel libre n'a pas besoin de cette facilité. Quand on casse une interface dans le noyau ou dans X, les pilotes sont quasi automatiquement corrigés que ce soit par le mainteneur du pilote, du changement d'API, ou un tiers.
G. K-H explique très bien pourquoi une API interne stable dans Linux n'a pas de sens et n'est pas souhaitable.
C'est même un argument majeur pour libérer les pilotes, les boites propriétaires n'ont guère le choix, soit elles fournissent un effort supplémentaire pour suivre les développements, soit elles libérent les informations. Sur le long terme, seule la seconde solution est viable.
Ce que tu appelles difficulté est en fait une force du libre, à tout moment, si un composant n'est pas satisfaisant, je peux le remplacer sans avoir à me retenir.
Si tu prends Gnome-vfs, c'était une merde en pourriture, plus personne n'osait y toucher. En moins de 6 mois, on a pu écrire un remplaçant gvfs -avec une meilleure architecture- et modifier tout gnome afin d'utiliser celui-ci.
Aurait-il été de possible de faire de même si on devait se soucier de la compatibilité ? si on ne pouvait pas modifier le code librement ?
> c'est une perte de ces différences qui seraient préjudiciables aux projets qui seraient délaissés par toutes les distributions participant.
Si on poussait la logique jusqu'au bout, effectivement, on aurait une espèce de méta-distribution avec des différences mineures.
C'était envisageable dans le cadre des distributions dérivées de Debian mais ça ne l'est pas au niveau des distributions GNU/Linux.