AGui a écritUne application qui utilise dbus fonctionnera sur n’importe quelle distribution GNU/Linux. Avec Wayland et Mir, ce ne sera plus le cas, au moins pour certaines applications.
Possible. Et ?
C'est toi qui as choisi cet exemple, hein ; ne fais pas semblant de me reprocher qu'il ne corresponde pas 😛
AGui a écritMais le processus que je décris est commun dans les projets où l’équipe est suffisamment ouverte.
Ou pas. Ou alors, il y a très peu d'équipes « suffisamment » ouvertes.
AGui a écrit Si tu consultes les archives de la mailing list Wayland, tu trouveras plusieurs conversations de ce type sur les derniers mois, et aucun email sans réponse, mis à part le tout dernier.
Ce qui est très honorable de leur part, mais ne contredis pas ce que je disais.
AGui a écritA ma connaissance, c'est la première fois qu’on développe un concurrent à un projet FreeDesktop auquel tout le monde a apporté son soutien, Canonical y compris.
« À ta connaissance » 😉
(Oui, je sais, je devrais aller à la pêche aux exemples. 'flemme. Mettons que tu as de la chance pour cette fois et que ce qui n'est pas mondialement connu au point que ça vienne tout de suite à l'esprit n'existe pas 😛)
AGui a écritHonnêtement, je ne savais pas qu’il y avait des différences techniques.
C'est écris dès l'en-tête de la page que tu cites toi-même en lien :
Chaque renommage consiste en :
* la reprise du code source de l'application d'origine
* la modification du nom et du logo (non libre au sens DFSG)
* l'application de patchs spécifiques à Debian
(Gras évidemment ajouté par moi)
Puis-ce que tu as toi-même apporté des patchs à quelques applis, peux-tu m'expliquer ce que c'est qu'appliquer des patchs, sinon apporter des différences techniques ? 🙂
Comme je l'ai dit, Debian a fait avec Iceweasel très exactement ce que Canonical a fait avec Mir : se désolidariser du projet initial pour pouvoir bosser dans leur coin et avec leurs objectifs. La seule différence, mais elle est de taille, entre les deux, est que, quand Debian a fait ceci (ce n'est effectivement pas un
fork), il y avait plein de code à reprendre dans Firefox, tandis qu'au moment où Canonical a fait de même, il n'y avait pas grand chose à reprendre dans Mir. Or, se désolidariser d'un projet dans lequel il n'y a pas encore grand chose, mécaniquement, c'est faire un projet distinct.
AGui a écritDe même, tu n'as pas à développer deux versions distinctes de ton application pour qu'elle fonctionne sous Unity et Gnome-shell.
Ça, ça dépend grandement de l'application. Je ne pense pas, par exemple, qu'une lentille ou un indicateur conçu pour Unity puisse fonctionner tel quel dans GNOME-Shell, me trompes-je ?⁽¹⁾ Pour Wayland/Mir, et pour l'écrasante majorité des applications, ça ne changera pas grand chose : combien d'applications dépendent directement de la Xlib, actuellement ? Pour toutes les autres, il suffira que la bibliothèque graphique utilisée ait été modifiée. Et pas d'inquiétude, ça le sera.
(1) Ce qui est amusant, c'est que, justement, Unity est une réponse à un problème de ce genre, causé par la fondation GNOME : Il se trouve que GNOME-Shell est conçu comme un plug-in pour le navigateur Mutter, ce qui rend, sauf développements particuliers, l'environnement GNOME 3 incompatible avec tout autre gestionnaire de fenêtres. Unity, en tant que plug-in pour Compiz, est également une manière de rendre Compiz compatible GNOME 3.
AGui a écritVisiblement, j’ai pas été clair sur le principe avec lequel j'étais d'accord. La concurrence sans souci de compatibilité présente des avantages que tu as très bien décrits (c’est avec cette partie que je suis d’accord). Ca présente également des inconvénients, et j’ai détaillé ceux qui s’appliquent en particulier à Mir.
Sur ces points, nous sommes d'accord.
AGui a écritComme je ne pense pas que l'idée selon laquelle la concurrence est toujours préférable à la mise en commun est une vérité générale, et que chaque cas est unique, j’attendais que tu décrives en particulier les avantages qui s’appliquent à Mir afin de pouvoir juger si ces avantages surpassent les inconvénients.
Je ne crois pas avoir, dans la discussion qui précède, opposé concurrence et mise en commun, à moins que tu n'entendes par ce dernier mot « tout le monde bosse sur le même projet et avec les mêmes objectifs », ce qui est, humainement parlant, strictement impossible.
Au contraire, il me semble avoir indiqué explicitement que ce qui fait la grande force des logiciels libres, c'est de pratiquer allègrement le mélange des deux. C'est de développer des solutions différentes, répondant aux mêmes problèmes de manières divergentes, mais en se coordonnant tout de même suffisamment pour que chacun en bénéficie.
Or, la seule condition pour que ce principe s'applique, est que les développeurs de Mir et ceux de Wayland collaborent. Ce qui n'est, peut-être, pas suffisamment le cas pour l'instant (sachant que, comme cela a été déjà dit, étant donné les réactions qu'a déjà essuyé Canonical, il est normal qu'ils restent dans leur coin avant d'avoir quelque chose de sérieux à proposer), mais rien ne permet pour l'instant d'affirmer que ce ne sera pas le cas par la suite (en fait, il me semble que les antécédents vont dans ce sens. Par exemple, je crois savoir que les développeurs d'Unity et ceux de GNOME-Shell ont pas mal collaboré, et qu'il est reconnu que les deux interfaces ont été améliorées par cet apport). Il me semble donc très prématuré de faire des reproches à ce sujet.
Concernant le caractéristiques particulières du cas Wayland/Mir, pour moi, ça se rattache très fortement au cas Webkit/Gecko. J'y reviendrai un peu plus bas.
AGui a écritJe répondais simplement à cette remarque : "Si on avait eu, depuis le départ, un autre serveur graphique en état de marche, il y a fort à parier que la situation d’obsolescence du bouzin ne serait pas la même". Je suis d’accord sur le fait que la concurrence est un facteur qui contribue à la qualité du code, sans pour autant en faire une condition nécessaire.
En effet, autant pour moi.
AGui a écritJe pense qu'un tour sur les dépôts de Wayland et Weston contredirait cette affirmation. Certaines extensions n’étaient pas prêtes, mais l’architecture générale du protocole était fixée.
Je n'en suis pas aussi sûr ; enfin, tout dépend de ce que l'on entend par « fixé ». Mais soit. Voir le cas Webkit/Gecko plus bas, encore une fois.
AGui a écritL'innovation ne se limite pas à ce qui n'est pas encore standardisé, l’essor des technologies web vient aussi de l’amélioration des performances sur les moteurs de rendu ou sur les compilateurs javascript, qui ne nécessitent pas de perte de compatibilité. Et un modèle de développement à la HTML5 pour le protocole Wayland aurait été possible, je l'ai déjà expliqué.
Certes, mais il s'agit là d'une « tambouille interne », qui ne concerne en rien ce qui sert d'interface avec le reste du monde, qui sont précisément le point sur lequel tu reproches à Mir de ne pas être compatible avec Wayland.
AGui a écritJe ne vois pas du tout ce qui te permet d’affirmer ça. Si je reprends encore l’exemple des formats de paquets, il n’y a pas eu d’harmonisation une fois passée la période de forte innovation.
« À ta connaissance » 😉 Il y a bel et bien des harmonisations entre les paquets. Je n'ai pas tous en tête, mais, par exemple, l'utilitaire « alien » permet de convertir un paquet initialement au format RPM vers le format deb. Lors des compilations manuelles, l'utilitaire « checkinstall » permet de faire en sorte que le logiciel ainsi installé soit reconnu et pris en charge par le gestionnaire de paquets, ce qui permet par exemple sa désinstallation propre.
Ces solutions sont assez peu généralisées, en raison de la nature du système de paquet, qui est assez différente de celle du serveur graphique (il s'agit, pour les paquets, d'un truc ancré dans le système et qui n'a pas énormément de raisons de ne pas lui être spécifiques, d'autant que le travail d'empaquetage sera à réaliser même si le système de paquets est le même – en témoignent Debian et Ubuntu, ou Fedora et Mageia, qui, quoiqu'utilisant le même format, ont des dépôts différents), mais, quand on en a besoin, il y a ce qu'il faut.
Mais, comme je l'ai déjà signalé ci-dessus, la situation à laquelle celle du serveur graphique se rapproche le plus, c'est celle du moteur de rendu dans un navigateur.
Dans les deux cas, nous avons un « extérieur » qui est formaté d'une certaine manière, et l'outil est censé traduire ce formatage en instructions compréhensibles pour faire tourner la chose. Dans les deux cas, ce qui garantirait la parfaite compatibilité, c'est qu'il existe des normes pour forger l'un et l'autre : quelque chose qui dise, par exemple, que la propriété CSS « border-radius » est censée arrondir les angles, et de quelle manière elle doit le faire.
Cette propriété CSS est maintenant normée, et les différents moteurs de rendus la reconnaissent telle qu'elle. Mais à l'époque où elle ne l'était pas encore, où elle était encore en cours de travail, les moteurs de rendus ont commencé à travailler chacun de leur côté, en proposant la manière qui leur paraissait la plus intéressante de fonctionner. On avait, ainsi, une propriété CSS -moz-border-radius, chez Gecko, et une -webkit-border-radius, chez Webkit. Et les deux ne fonctionnaient pas de la même façon du tout (de mémoire, pour cibler un coin en particulier, on devait avoir un -moz-border-radius-topleft contre un -webkit-border-top-left-radius, ou quelque chose comme ça).
Cette propriété n'étant pas encore normée, ça demandait un certain travail si l'on voulait la faire reconnaître par les différents navigateurs ; il fallait savoir comment ça fonctionnait sur chaque et formater les choses correctement. Mais cela permettait de tester plusieurs solutions possibles, et de choisir la plus intéressante. À partir du moment où cela a été fait, les navigateurs se sont adaptés.
Nous avons, en l'espèce, un Wayland qui est proposé d'un côté, avec plein de propriétés « wayland_machin ». Et nous avons, de l'autre, un Mir qui arrive avec plein de propriétés « mir_machin », exactement de la même façon. Il faudrait, à terme, qu'il existe un organisme qui ne soit pas lié à l'un ou à l'autre, et qui, comme le fait le W3C pour le Web, regarde les deux trucs et détermine quel serait la meilleure manière pour la propriété « machin » (tout court) de fonctionner, et que les deux autres s'adaptent. C'est ainsi que la compatibilité serait garantie.
Mais, quand l'équipe de dev de Webkit (puisque c'est lui le plus récent des deux) a commencé à bosser sur son moteur de rendu, que se serait-il passé si on était venu les voir en disant « bon, alors, vous reprenez toutes les propriétés en -moz- comme vous le dicte Gecko pour être parfaitement compatible avec, sinon on ne veut pas de vous » ? M'est avis que le résultat n'aurait pas été particulièrement fameux. On aurait peut-être eu un Gecko bis, mais on aurait eu bien plus de difficultés à avoir ce Web standard et permettant l'apparition d'autres moteurs de rendus qui est en partie dû à la présence de plusieurs moteurs de rendus bien distincts.
La différence fondamentale entre les deux cas réside dans le fait qu'au moment où Webkit s'est lancé, le Web existait déjà depuis un bon moment (mais en ayant déjà été le fruit d'une histoire comme celle-là : Netscape Navigator et Microsoft Internet Explorer faisaient aussi de bons candidats pour cette comparaison, au tout début du Web). Donc, il y avait, quand le projet Webkit a démarré, déjà plein de propriétés pour lesquelles il n'a pas fallu passer par la case « -webkit- », mais implémenter directement la norme.
Pour Mir et Wayland, on est au début du travail. Il manque encore le « W3C du serveur graphique » et tout ce qui va avec. Mais il me semble que c'est, précisément, par l'existence de ces deux projets et le fait qu'ils explorent chacun les différentes propriétés séparément, que l'on permettra d'avoir un vrai truc standard et interopérable, et non pas juste un « l'équipe de Wayland décide de tout, et les autres n'ont d'autre choix que de suivre ou de ne pas marcher »… ce qui serait dommage, même s'ils restent très ouverts.
