Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

sylvainsjc · Le 31/07/2013, à 16:20

Smon a écrit :

Si d'autres distribs veulent utiliser Mir elles sont libres, voire même encouragées, à le faire.

Par qui ? une source STP

seb24 · Le 31/07/2013, à 16:41

sylvainsjc a écrit :

Smon a écrit :
Si d'autres distribs veulent utiliser Mir elles sont libres, voire même encouragées, à le faire.
Par qui ? une source STP

Ca par exemple ? https://lists.ubuntu.com/archives/mir-d … 00183.html

sylvainsjc · Le 31/07/2013, à 16:45

ben, c'est pas très "publique" comme source non ?

seb24 · Le 31/07/2013, à 16:57

sylvainsjc a écrit :

ben, c'est pas très "publique" comme source non ?

Pour le moment Mir n'a pas eu encore de version stable et même la doc est encore en chantier. Et vu le retour de flamme qu'ils ont eu après l'annonce de Mir je suppose qu'ils vont attendre d'avoir quelque chose de stable et un minimum solide pour faire des annonces publiques.

AGui · Le 31/07/2013, à 18:22

Smon a écrit :

C'est pas dommage, c'est la richesse du libre qui amène une forme d'émulation collective positive.
Au passage, c'est "juste" grâce à ça que les systèmes libres dominent le monde.
Le libre unifié, ce serait le début de la fin. Et de toutes façon ça n'est pas possible, ça va à l'encontre du genre humain.

Je suis d'accord avec toi sur le fait que le libre n'en serait pas là où il est sans sa diversité, mais il n'y serait pas non plus si différents acteurs avec des objectifs parfois divergeants n'avaient pas collaboré sur des projets communs. Les deux composantes sont essentielles. Parfois, faire un fork ou créer un projet concurrent peut être productif, parfois non. On ne peut pas faire de généralité comme tu le fais, et chaque situation est spécifique. Pour le cas de Mir, j'attends toujours qu'on me démontre qu'il apporte réellement quelque chose.

Et c'est la même chose pour les formats de paquets. Les besoins sont les mêmes pour tout le monde, avoir des formats différents n'apporte strictement rien. C'est incompréhensible qu'il n'y ait pas un format standard. Deb, rpm, ou n'importe quoi d'autre, ça n'a aucune importance. Au lieu de ça, il y a un pseudo standard avec packagekit, qui ne supporte que le plus petit dénominateur commun des fonctionnalités permises par chaque format, et qui est une horreur à maintenir...

Smon a écrit :

Et pourquoi ça devrait être exclusif à l'audio ? Si ça fonctionne bien dans ce cas, ça fonctionnera aussi bien pour les serveurs vidéos.

En y regardant de plus près, c'est pas vraiment comparable. Le support de OSS par ALSA est surtout là pour la rétro-compatibilité. ALSA et PulseAudio sont plus complémentaires que concurrents (ALSA est une dépendance de PulseAudio). Les applications et les toolkits ne nécessitent aucune modification, elles ne parlent qu'à ALSA dans tous les cas.

Et puis pour le serveur graphique, il y a quand même plus d'impact sur les performances de l'application. Toute couche de compatibilité impliquera forcément une légère perte de performances (voir XMir et XWayland). Mais oui, dans l'absolu, si aucun des deux ne s'impose comme le standard, j'espère que c'est vers ça que ça évoluera.

Smon a écrit :

Depuis quand développer une nouveau logiciel c'est "Se séparer de la communauté du libre" ?
LibreOffice c'était se séparer de la communauté ? MariaDB aussi ? Nginx ? lighttpd ? Xfce ? Et j'en passe et des meilleurs ?

On repart dans un débat qu'on a déjà eu. Je n'ai jamais critiqué Canonical pour Unity, alors qu'ils avaient déjà choisi de développer leur propre solution. Je pense que Mir est un mauvais choix parce qu'il a une influence sur l'attractivité de la plateforme Linux pour les développeurs (seb24: oui je sais, la plupart des développeurs utilisent des toolkits . Il n'en reste pas moins qu'il y a des exceptions, comme XBMC et comme pas mal d'application propriétaires existantes).

Au passage, Nginx et lighttpd utilisent le même protocole http que les autres serveurs web, et pourtant ils ont réussi à innover par rapport à Apache sans tout réinventer. Wayland est un protocole, extensible en plus, et chacun peut l'implémenter selon ses besoins. La diversité est tout à fait possible en collaborant sur certains éléments fondamentaux.

seb24 a écrit :

Il me semble que Maya utilise Qt non ?

Je savais pas, mais oui, tu as raison, ils sont passés à Qt, y compris pour les versions Windows et Mac OS d'ailleurs. Par contre ça a nécessité une réécriture totale de l'interface.

coolspot · Le 01/08/2013, à 18:12

AGui a écrit :

Smon a écrit :
C'est pas dommage, c'est la richesse du libre qui amène une forme d'émulation collective positive.
Au passage, c'est "juste" grâce à ça que les systèmes libres dominent le monde.
Le libre unifié, ce serait le début de la fin. Et de toutes façon ça n'est pas possible, ça va à l'encontre du genre humain.
Je suis d'accord avec toi sur le fait que le libre n'en serait pas là où il est sans sa diversité, mais il n'y serait pas non plus si différents acteurs avec des objectifs parfois divergeants n'avaient pas collaboré sur des projets communs. Les deux composantes sont essentielles. Parfois, faire un fork ou créer un projet concurrent peut être productif, parfois non. On ne peut pas faire de généralité comme tu le fais, et chaque situation est spécifique. Pour le cas de Mir, j'attends toujours qu'on me démontre qu'il apporte réellement quelque chose.

Ca a été dit et re-dit. C'est un problème politique plus que technique. En clair MIR apporte la tranquillité à Cannonical et à ses développeurs qui peuvent faire ce qu'ils veulent sans avoir besoin d'avoir une validation de commit par les mainteneurs Wayland qui ne travaille pas à Cannonical.

Si ils en avaient les moyen à la google je suis sur qu'il forkerait même Linux pour avoir la maitrise totale de leur distribution et plus à avoir à supporter le caractère de cochon du Msieur Torvald.
Alors certe l'utilisateur lambda, final tout comme le devellopeur d'application GNU/Linux s'en moque de ces problème politique mais pour les développeurs de Cannonical c'est une bénédiction pour eux et pour Ubuntu.

Elzen · Le 01/08/2013, à 20:04

AGui a écrit :

Oui il y a d'autres projets qui font doublon, et c'est dommage. Mais ce n'est pas une raison d'en rajouter.

Au contraire. Comme l'a dit Smon, la diversité est non seulement une caractéristique fondamentale et incontournable (humains, plein de gens, donc pas possible de se mettre d'accord, tout ça), mais c'est également et surtout la très grande force du libre. J'irai jusqu'à dire que le système de fenêtrage étant actuellement la seule pièce de nos systèmes pour laquelle on n'ait aucune alternative, il est d'autant plus important qu'il y ait plusieurs projets concurrents. Franchement, vivement qu'on ait enfin le choix entre deux serveurs graphiques différents.

Smon a écrit :

Mais le mieux est de s'adapter au toolkit de la plateforme sur laquelle tu t'installes.
Par exemple, une application bien pensée utilisera des views différentes pour KDE ou Gnome, pour s'adapter soit au QML soit au GTK.

Ça, pas forcément. Coder dans une bibli graphique précise, c'est bien ; ce qu'il faut, c'est que les différentes biblis graphiques puissent être utilisées correctement quel que soit l'environnement (le gros soucis du Qt à la sauce KDE, d'ailleurs (tandis que le Qt normal passe très bien)).

Smon a écrit :

LibreOffice c'était se séparer de la communauté ? MariaDB aussi ? Nginx ? lighttpd ? Xfce ? Et j'en passe et des meilleurs ?

Juste : techniquement parlant, Xfce est l'environnement le plus ancien parmi ceux encore actuellement utilisés (projet lancé quelques mois avant KDE, 'me semble ; et qui présentait le même défaut à l'origine, à savoir d'être basé sur des biblis non-libres).

Haleth · Le 01/08/2013, à 20:07

Diversité ?
Le clone, c'est la diversité ?

Si c'est pour, techniquement et concrêtement faire la même chose, c'est mal.

Parcque faire un projet juste pour des vagues raisons poliques, qui se résument à "c'est moi qui ai la plus grosse, j'ai dev le projet en vogue", c'est mal.

seb24 · Le 01/08/2013, à 20:34

Haleth a écrit :

Diversité ?
Le clone, c'est la diversité ?
Si c'est pour, techniquement et concrêtement faire la même chose, c'est mal.
Parcque faire un projet juste pour des vagues raisons poliques, qui se résument à "c'est moi qui ai la plus grosse, j'ai dev le projet en vogue", c'est mal.

Oui on appel ça un fork ^^ . C'est l'un des atouts qui est mis en avant dans le libre.
Mir ce n'est pas des raisons politiques. Mais ils veulent mener un projet comme ils le veulent, c'est un choix technique. Peut être vont-ils faire de la merde (ce qui fait partie aussi du jeux) ou peut être pas.

Au passage j'ai posté quelques articles plus haut ou tu as un début de réponse : non ce ne sont pas de clones.

Haleth · Le 01/08/2013, à 20:35

Un fork, c'est partir d'une même base, avec des objectifs différents

Ici, ce n'est pas un fork.

seb24 · Le 01/08/2013, à 20:36

Haleth a écrit :

Un fork, c'est partir d'une même base, avec des objectifs différents
Ici, ce n'est pas un fork.

Un peu car ils réutilisent certaines bases de Wayland. Mais c'est en effet ni un clone ni un fork.

AGui · Le 01/08/2013, à 22:23

coolspot a écrit :

Ca a été dit et re-dit. C'est un problème politique plus que technique. En clair MIR apporte la tranquillité à Cannonical et à ses développeurs qui peuvent faire ce qu'ils veulent sans avoir besoin d'avoir une validation de commit par les mainteneurs Wayland qui ne travaille pas à Cannonical.
Alors certe l'utilisateur lambda, final tout comme le devellopeur d'application GNU/Linux s'en moque de ces problème politique mais pour les développeurs de Cannonical c'est une bénédiction pour eux et pour Ubuntu.

C'est peut-être une partie de l'explication, mais je pense pas que ce soit la raison principale. Dépendre de l'upstream ça a des inconvénients mais ça a quand même pas mal d'avantages aussi. Ils bénéficient de l'expertise de personnes extérieures et ils peuvent mettre plus de leurs développeurs sur ce qui compte vraiment pour l'utilisateur final : toute la partie interface.

Et Wayland est un protocole, en écrivant leur propre compositeur, ils auraient eu le même contrôle sur leur code, tout en étant compatible avec les autres. Ca aurait peut-être nécessité qu'ils forkent une partie des extensions, qu'ils en écrivent d'autres, mais Wayland permet tout ça. Tu peux avoir plusieurs extensions incompatibles entre elles en même temps, l'application déclare les extensions qu'elle utilise quand elle démarre, et chaque application ne voit que celles qui la concerne. Ca permet de pouvoir facilement faire évoluer le protocole en gardant une compatibilité avec l'existant sans bricolage. Oui, Wayland est très bien pensé !

Elzen a écrit :

J'irai jusqu'à dire que le système de fenêtrage étant actuellement la seule pièce de nos systèmes pour laquelle on n'ait aucune alternative, il est d'autant plus important qu'il y ait plusieurs projets concurrents.

C'est quoi les alternatives à CUPS ou à dbus par exemple ? Ce sont des éléments qui répondent à des besoins basiques rencontrés par tous les environnements, et le fait que tout le monde les utilise simplifie grandement les choses. Si de nouvelles fonctionnalités sont nécessaires, elles sont ajoutés upstream et bénéficient à tout le monde. A moins d'un code vieillissant difficilement maintenable, il n'y a pas de raison de créer un nouveau projet (c'était le cas pour le serveur X11, d'où la création de Wayland). D'ailleurs Xorg n'est pas la seule implémentation d'un serveur X, tout comme Weston n'est pas voué à être la seule implémentation d'un compositeur Wayland.

Elzen a écrit :

Franchement, vivement qu'on ait enfin le choix entre deux serveurs graphiques différents.

Si tu veux pas passer pour un troll, il va falloir développer un peu. C'est quoi les bénéfices d'avoir le choix entre Wayland et Mir ? Honnêtement, j'en vois aucun et je pense que si Canonical n'a pas utilisé Wayland, c'est parce qu'ils pensaient qu'il ne serait pas prêt pour mi-2014, la date "limite" à laquelle il peuvent espérer se faire une place sur le marché des OS mobiles. Ce qui se trouve être une mauvaise évaluation, vu qu'il sera utilisé fin 2013 dans Sailfish.

Funigtor · Le 01/08/2013, à 22:35

Si vraiment Mir fait un flop, Canonical va l'abandonner, au moins sur l'image desktop classique. Et si ça marche, alors il n'y aura pas de problème.

Elzen · Le 02/08/2013, à 00:59

AGui a écrit :

C'est quoi les alternatives à CUPS ou à dbus par exemple ?

J'n'imprime jamais, donc je n'ai pas regardé pour CUPS ; pour D-Bus, il me semble qu'il y a plusieurs implémentations différentes, non ? Édit tardif : et il y a plein d'autres moyens de communiquer entre différentes applis, c'est juste souvent une mise en place plus lourde (par exemple, entre MPD et ses différents clients, pas de D-Bus). Mais c'est vrai que je ne pensais pas à ces trucs-là.

AGui a écrit :

Si de nouvelles fonctionnalités sont nécessaires, elles sont ajoutés upstream et bénéficient à tout le monde.

Non-sens, ou tautologie, selon le point de vue. Bref, ça n'apporte pas grand chose, comme remarque.
(Les fonctionnalités sont ajoutés upstream quand l'équipe qui gère l'upstream décide de s'en occuper elle-même ou d'accepter un patch extérieur. Or, l'équipe qui gère l'upstream et la personne qui demande la fonctionnalité sont loin d'avoir toujours la même définition de « nécessaire ». Ai-je besoin de citer les multiples trolls ayant eu lieu entre Torvalds et l'équipe de GNOME (tu sais, ces fameux « nazis de l'interface »), au sujet des divergences d'opinions sur les fonctionnalités nécessaires pour un environnement graphique, par exemple ?)

AGui a écrit :

A moins d'un code vieillissant difficilement maintenable, il n'y a pas de raison de créer un nouveau projet

Ç't'un point de vue, pas une vérité générale.

AGui a écrit :

D'ailleurs Xorg n'est pas la seule implémentation d'un serveur X

Il y a eu feu XFree86 (le passage de l'un à l'autre s'étant fait pour des raisons de licences et dans la douleur)… et à part lui ?

AGui a écrit :

Si tu veux pas passer pour un troll, il va falloir développer un peu. C'est quoi les bénéfices d'avoir le choix entre Wayland et Mir ?

Si tu ne veux pas passer pour un troll, il va falloir que tu lises un peu ce qui a déjà été développé

On a parfois la flemme de se répéter, mais bon, pour la énième fois : avoir plusieurs projets concurrents pour la même chose est tout simplement plus sain : ça permet d'avoir des divergences d'opinions qui s'expriment dans la créativité, plutôt que dans le blocage (si les divergences d'options ont lieu entre les membres d'une même équipe, le développement ralentit très souvent ; tandis que si deux équipes développent deux visions différentes, chacune des deux peut s'inspirer de ce que fait l'autre autant que partir sur son propre chemin ; il est un truc parfaitement acquis entre devs du monde libre qu'une relation de coopération et de compétition simultanées entre plusieurs projets est le meilleur moyen qui soit de rendre l'ensemble dynamique. Tiens, justement, ne crois-tu pas que l'une des raisons pour lesquelles le code de X est devenu si vieux et si peu maintenable est justement que, X ayant été essentiel et à peu près sans concurrence, les devs ont préféré laisser les choses en l'état ? 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).
Cela introduit en plus davantage de sécurité (deux implémentations différentes ayant très peu de chances d'être affectées par les mêmes failles, les attaques sur l'un ne toucheront pas l'autre, et réciproquement ; édit tardif : la chose est encore plus vraie quand les deux ne sont pas deux implems différentes de strictement la même chose. On pourrait, par exemple, comparer Mir à Gecko, et Weston à Webkit/Qt, et simplement constater que Webkit/GTK n'apporte pas la même chose que Gecko à l'écosystème des moteurs de rendus.), ainsi qu'une meilleure prise en charge de la diversité de l'existant (comme je l'ai déjà dit, la nécessité ou pas d'une fonctionnalité dépend fortement du point de vue. Deux points de vue différents, ce sont autant de chances supplémentaires que la fonctionnalité que tu veux passe quelque part. Niveau fiabilité, il vaut mieux plusieurs projets distincts, chacun pouvant être plus adapté que l'autre à un objectif donné, qu'un seul truc unique qui sera patché sans concertation en fonction des différentes réutilisations).

Ce ne sont qu'une petite partie des raisons, mais j'suis occupé, là, je code un truc pour lequel il existe des tas d'autres logiciels concurrents, mais dont aucun ne correspond précisément à ce que je veux

AGui a écrit :

Honnêtement, j'en vois aucun et je pense que si Canonical n'a pas utilisé Wayland, c'est parce qu'ils pensaient qu'il ne serait pas prêt pour mi-2014, la date "limite" à laquelle il peuvent espérer se faire une place sur le marché des OS mobiles. Ce qui se trouve être une mauvaise évaluation, vu qu'il sera utilisé fin 2013 dans Sailfish.

Confer ma réponse précédente sur le troll, et les réponses qui t'ont déjà été faites, notamment sur les objectifs de Canonical qui ne se résument pas clairement pas à ça, et sur les réserves qu'on peut émettre à propos de Sailfish.

Tiens, justement, vu que tu relances le sujet des objectifs de Canonical, j'te renvoie à la réponse de coolspot qui t'était adressée au post précédent le mien :

coolspot a écrit :

Ça a été dit et re-dit. C'est un problème politique plus que technique. En clair MIR apporte la tranquillité à Cannonical et à ses développeurs qui peuvent faire ce qu'ils veulent sans avoir besoin d'avoir une validation de commit par les mainteneurs Wayland qui ne travaille pas à Canonical.

Il se trouve que Canonical a justement été, pendant tout le temps où ils utilisaient GNOME 2, soumis au problème que j'ai déjà explicité plus haut des divergences d'opinions entre l'équipe qui gère l'upstream et les gens qui veulent l'intégrer : l'équipe de GNOME refusait énormément de choses qui venait d'eux, et ils étaient obligés de patcher ce qu'il leur fallait comme ils pouvaient, en interne à Ubuntu. C'est d'ailleurs l'une des raisons qui a motivé la décision de faire Unity.
On peut d'ailleurs noter que Debian a eu un problème du même ordre avec l'équipe de Mozilla, d'où le renommage des applications. Qui, techniquement, apporte encore moins, soit dit en passant : râles-tu autant contre l'existence d'Iceweasel ? La différence principale entre les deux situations étant qu'au moment où Debian a décidé de passer outre la mauvaise volonté de Mozilla, il y avait déjà du code à reprendre ; tandis qu'au moment où Canonical s'est lancé dans le travail sur Mir, il n'y avait pas grand chose à reprendre et aucune assurance que ce serait pérenne, d'où la nécessité évidente de débuter un autre développement en parallèle plutôt que d'attendre indéfiniment. Et une fois le développement bien entamé, même s'il s'avérait qu'en fait, l'attente aurait été moins longue que prévue, ce serait juste fondamentalement stupide d'abandonner ce qui a déjà été fait, donc autant continuer.

Dernière modification par Elzen (Le 02/08/2013, à 12:07)

ledragonBleu · Le 02/08/2013, à 04:23

La diversité c'est bien, mais il faut que le coeur du système reste plus proche possible pour tout le monde. Sinon on se retrouverai avec une libc par distribution, voire même un noyaux complètement différent pour tout le monde. Il faut trouver son juste milieu. C'est pas pour rien que le projet freedesktop est né.

On a tendance à l'oublié mais techniquement il y a une très grosse différence entre avoir le choix de plusieurs bureaux graphiques, plusieurs applications de bureautiques ou avoir plusieurs protocoles graphiques.

La grande force du libre et surtout de Linux c'est que chaque distribution est construite sur une base commune, ce qui permet de créer une application une fois et de la porter facilement sur les autres distributions sans compilation.

Ce qu'il risque d'arriver si MIR et Wayland cohabitent c'est qu'il devra avoir une version GNU/Linux générique, et une autre version Ubuntu/Mir.
Et pour ceux qui disent qu'il suffit de faire des backends, on va vite se retrouver ce pour quoi on a voulu remplacer X, c'est à dire une grosse usine à gaz.

The Uploader · Le 02/08/2013, à 08:12

ledragonBleu a écrit :

voire même un noyaux complètement différent pour tout le monde.

Tu veux dire un noyau qui plante ou non selon les patchs introduits au petit bonheur de la chance par les mainteneurs de la distrib' ?
C'est déjà le cas.

Lork Scorguar · Le 02/08/2013, à 11:52

Genre Hurd et Linux? ou encore le kernel BSD utilisé dans Debian/kFreeBSD?
On a tellement d'exemples de diversité dans le monde GNU/Linux et le libre en général que je ne vois pas comment on peut critiquer une nouvelle diversité au niveau des serveurs graphiques.
Par contre, il serait souhaitable que les deux projets bien que différents partagent une partie commune pour permettre facilement le passage de l'un à l'autre.

AGui · Le 02/08/2013, à 19:36

Attention, réponse fleuve !

Elzen a écrit :

pour dbus, il me semble qu'il y a plusieurs implémentations différentes, non??

Ils parlent de l'intégrer au noyau, donc certainement. Par contre, le protocole des signaux est le même pour toutes les implémentations. Ce sera aussi le cas pour Wayland. Weston, Gnome-shell et KWin seront des implémentations différentes d'un compositeur Wayland, mais compatibles entre elles.

Elzen a écrit :

Non-sens, ou tautologie, selon le point de vue. Bref, ça n'apporte pas grand chose, comme remarque. (Les fonctionnalités sont ajoutés upstream quand l'équipe qui gère l'upstream décide de s'en occuper elle-même ou d'accepter un patch extérieur. Or, l'équipe qui gère l'upstream et la personne qui demande la fonctionnalité sont loin d'avoir toujours la même définition de «?nécessaire?».

C'est là que la collaboration est importante. Si tu développes un truc dans ton coin, puis tu vas voir les développeurs upstream une fois fini en leur disant "voilà j'ai fait ça, vous pouvez l'intégrer ?" il y a pas mal de chances de se faire remballer. Pour le kernel, la plupart des patchs qui sont refusés c'est à cause de ça. Si tu commences par expliquer ton besoin sur la mailing list du projet upstream, ils vont discuter de la meilleure manière d'y répondre, et te conseiller sur comment développer ton patch pour qu'il soit intégré. Alors oui, il y a des fois où la réponse sera : "non ça ne colle pas avec la vision du projet". Mais pour la base du système, où les fonctions sont bien définies, il y a très peu de cas où les besoins sont vraiment différents, et donc c'est assez logique de mutualiser ces éléments là.

Mis à part l'exemple de Mir, c'est d'ailleurs dans ce sens que vont les choses, avec de plus en plus d'éléments partagés entre les différents environnements (networkmanager, dbus, telepathy, et pas mal d'autres projets hébergés sur FreeDesktop.org). Mes remarques concernent ces éléments là, elles ne sont évidemment pas valables pour tout ce qui concerne ce à quoi l'utilisateur final est confronté, où les choix peuvent varier en fonction du public cible. Tous tes exemples concernent le haut-niveau (Gnome/Torvalds, Gnome-shell/Unity, Firefox/Iceweasel).

Elzen a écrit :

Il y a eu feu XFree86 (le passage de l'un à l'autre s'étant fait pour des raisons de licences et dans la douleur)… et à part lui??

Il y a au moins MicroXwin.

Elzen a écrit :

On a parfois la flemme de se répéter, mais bon, pour la énième fois (...)

Ca c'est la théorie. Je parlais du cas spécifique de Wayland et Mir, en pratique. D'après les versions alpha de Mir, c'est très proche de Weston, en retirant tout les éléments qui le rendent flexible et facilement évolutif pour se concentrer sur une architecture très liée à Unity. Qu'ils s'en soient inspirés ou non, confrontés aux mêmes problèmes et avec les mêmes outils, ils ont trouvés plus ou moins les mêmes solutions.

Sur la théorie, j'ai déjà dit que j'étais d'accord sur le principe, mais je pense qu'il y a des cas dans lesquels avoir un standard apporte plus de bénéfices. Pour faire une métaphore foireuse, c'est comme au niveau économique, on peut être pour le libre échange et la concurrence non faussée, tout en considérant qu'il y a certains secteurs essentiels au fonctionnement de la société où l'absence de concurrence est plus adaptée (éducation, système de santé, sécurité, gestion des réseaux de communication et d'énergie).

Elzen a écrit :

Tiens, justement, ne crois-tu pas que l'une des raisons pour lesquelles le code de X est devenu si vieux et si peu maintenable est justement que, X ayant été essentiel et à peu près sans concurrence, les devs ont préféré laisser les choses en l'état??

Il y a d'autres projets qui sont soumis à la concurrence et qui pourtant ont aussi des problèmes de code obsolète. OpenOffice par exemple (d'ailleurs Calligra 2.7 vient de sortir hier, et ça devient vraiment une réelle alternative à LibreOffice). Mais reprenons l'exemple des formats de paquets : la concurrence a peut-être permis d'avoir plusieurs bons gestionnaires de paquets, mais les problèmes de maintenance viennent de packagekit, la couche de compatibilité qu'il a fallu rajouter par dessus (parce que les développeurs ont besoin d'un socle commun).

Elzen a écrit :

Cela introduit en plus davantage de sécurité (deux implémentations différentes ayant très peu de chances d'être affectées par les mêmes failles, les attaques sur l'un ne toucheront pas l'autre, et réciproquement ; édit tardif : la chose est encore plus vraie quand les deux ne sont pas deux implems différentes de strictement la même chose. On pourrait, par exemple, comparer Mir à Gecko, et Weston à Webkit/Qt, et simplement constater que Webkit/GTK n'apporte pas la même chose que Gecko à l'écosystème des moteurs de rendus.), ainsi qu'une meilleure prise en charge de la diversité de l'existant (comme je l'ai déjà dit, la nécessité ou pas d'une fonctionnalité dépend fortement du point de vue.

Wayland est un protocole, il y aura différentes implémentations. Tu peux faire ta propre extension pour ton besoin spécifique si vraiment tu n'arrives pas à convaincre l'upstream de son intérêt, tout en conservant les extensions pour lesquelles tes besoins sont les mêmes que pour les autres.
Gecko et Webkit sont deux implémentations différentes des mêmes standards HTML. Ils sont compatibles entre eux en très grande majorité, et pourtant le web est un des domaines dans lequel il y a le plus d'innovation en ce moment. Donc avoir un standard ne bride pas nécessairement l'innovation.

Elzen a écrit :

Il se trouve que Canonical a justement été, pendant tout le temps où ils utilisaient GNOME 2, soumis au problème que j'ai déjà explicité plus haut des divergences d'opinions entre l'équipe qui gère l'upstream et les gens qui veulent l'intégrer?: l'équipe de GNOME refusait énormément de choses qui venait d'eux, et ils étaient obligés de patcher ce qu'il leur fallait comme ils pouvaient, en interne à Ubuntu.

Ca pourrait expliquer la création de Mir si seulement ils avaient eu des problèmes avec l'équipe Wayland. Wayland est développé par plus ou moins les mêmes personnes qui travaillent sur Xorg, et je suis pas au courant de problèmes entre Canonical et Xorg. Je crois même avoir lu qu'il y a eu quelques patchs soumis par des employés de Canonical pour Wayland, qui ont tous été acceptés ! Ils n'ont même pas essayé de discuter de leurs besoins et des choses qu'ils ne comprennaient pas dans Wayland.

Elzen · Le 03/08/2013, à 00:28

AGui a écrit :

Ils parlent de l'intégrer au noyau, donc certainement. Par contre, le protocole des signaux est le même pour toutes les implémentations. Ce sera aussi le cas pour Wayland. Weston, Gnome-shell et KWin seront des implémentations différentes d'un compositeur Wayland, mais compatibles entre elles.

Mais, comme je l'ai mentionné (dans un édit que tu as certainement vu, puisque tu cites par la suite un autre édit arrivé en même temps) D-Bus est (très) loin d'être le seul moyen pour que deux applis communiquent entre elles. La présence de plusieurs implémentations d'une même spécification est bien sûr très intéressante ; mais l'existence de plusieurs spécifications distinctes n'est pas non plus une mauvaise chose.

AGui a écrit :

C'est là que la collaboration est importante. Si tu développes un truc dans ton coin, puis tu vas voir les développeurs upstream une fois fini en leur disant "voilà j'ai fait ça, vous pouvez l'intégrer ?" il y a pas mal de chances de se faire remballer. Pour le kernel, la plupart des patchs qui sont refusés c'est à cause de ça. Si tu commences par expliquer ton besoin sur la mailing list du projet upstream, ils vont discuter de la meilleure manière d'y répondre, et te conseiller sur comment développer ton patch pour qu'il soit intégré. Alors oui, il y a des fois où la réponse sera : "non ça ne colle pas avec la vision du projet". Mais pour la base du système, où les fonctions sont bien définies, il y a très peu de cas où les besoins sont vraiment différents, et donc c'est assez logique de mutualiser ces éléments là.

Juste par curiosité, à combien de projets as-tu essayé d'appliquer ces belles théories ?
Principe de base : si les devs ne sont pas d'accord avec une proposition ou n'ont pas le temps de s'en charger eux-mêmes, dans l'écrasante majorité des cas, ils ne sont pas plus d'accord et n'ont pas plus le temps pour t'aider à la faire.
Autre principe de base : se mettre d'accord sur une interface commune est bien sûr un élément essentiel ; mais à interface commune, différentes implémentations vont quand même être plus adaptées dans un cas que dans l'autre, donc ce n'est pas parce qu'il y a une base « bien définie » qu'il ne faut pas plusieurs manières de faire.
En fait, sans vouloir te vexer, quand je te lis, j'ai l'impression que tu ne sais simplement pas à quoi ressemble le développement à plusieurs…

AGui a écrit :

Mis à part l'exemple de Mir, c'est d'ailleurs dans ce sens que vont les choses, avec de plus en plus d'éléments partagés entre les différents environnements (networkmanager, dbus, telepathy, et pas mal d'autres projets hébergés sur FreeDesktop.org).

C'est limite malhonnête, comme affirmation : tu prends un truc qui semble à peu près aller dans ton sens, tu poses que le truc que tu critiques est la seule exception, et roulez jeunesse.
Dans la réalité, il y a effectivement pas mal d'éléments de FreeDesktop qui sont repris dans plein de projets parce qu'ils réussissent plutôt très bien à faciliter la vie des devs, mais c'est plutôt ce cas-là qui est l'exception, et l'existence de multiples trucs et machins dans tous les sens sans beaucoup de compatibilités qui reste la norme ; qu'on soit d'accord ou pas avec cet état de fait.

AGui a écrit :

Mes remarques concernent ces éléments là, elles ne sont évidemment pas valables pour tout ce qui concerne ce à quoi l'utilisateur final est confronté, où les choix peuvent varier en fonction du public cible. Tous tes exemples concernent le haut-niveau (Gnome/Torvalds, Gnome-shell/Unity, Firefox/Iceweasel).

Pas du tout, non. Au contraire, même. La dispute entre Torvalds et l'équipe de GNOME était le seul truc qui concernait le haut niveau, et donné uniquement à titre d'exemple sur les divergences d'opinions, sans aucune valeur technique. En revanche, pour Unity comme pour Iceweasel (notons au passage que, justement, pour l'utilisateur, Iceweasel ou Firefox, ça ne change rien, donc tu aurais dû te rendre compte toi-même en parlant que ce que tu pointais là n'avait pas de sens), c'est bel et bien de la partie technique et bas niveau que je parlais : le fait, essentiel, de pouvoir faire ce qu'il faut pour faire marcher le logiciel sans avoir besoin de l'aval d'autres gens.
La valeur ajoutée de Mir, pour Canonical, est très exactement la même que la valeur ajoutée d'Iceweasel pour l'équipe de Debian : la possibilité de travailler librement et en fonction de leurs objectifs propres, sans devoir dépendre de la volontés de gens qui n'ont pas forcément les mêmes idées qu'eux. En toute logique, si tu critiques Canonical pour Mir, tu dois critiquer aussi Debian pour Iceweasel ; ou alors tu fais deux poids, deux mesures.

AGui a écrit :

Il y a au moins MicroXwin.

Intéressant ; tu saurais sur quoi on peut tester ça ?

AGui a écrit :

Ca c'est la théorie. Je parlais du cas spécifique de Wayland et Mir, en pratique.

Hum. Permet-moi de reprendre : quand on pointe que « tout élément de l'ensemble présente telle propriété », bah, quand tu prends un élément de l'ensemble, quel qu'il soit, il présente la propriété. Si tu en trouves un qui ne la présente pas, c'est que l'énoncé de départ était faux. On est bien d'accord que c'est évident, ça ?
Bah maintenant, il a été développé en long, en large et en travers, en quoi, pour chaque partie du système d'exploitation, avoir plusieurs options différentes est intéressant. En application directe de cette propriété générale, Wayland et Mir étant deux options différentes pour une partie du système d'exploitation, avoir les deux est donc intéressant, c'est de la logique de base.
Partant de là, si ce que tu cherches à démontrer est qu'avoir le choix entre Wayland et Mir n'est pas intéressant, c'est bel et bien au développement général, et non pas seulement à ce « cas spécifique », que tu t'attaques. Si tu es d'accord avec le principe général, il n'y a pas besoin de montrer en quoi il s'applique à ce « cas spécifique », son application est évidente ; si tu n'es pas d'accord avec, ce n'est pas en faisant semblant que ce « cas spécifique » est déconnecté du reste que tu vas réussir à être convainquant.

AGui a écrit :

D'après les versions alpha de Mir, c'est très proche de Weston, en retirant tout les éléments qui le rendent flexible et facilement évolutif pour se concentrer sur une architecture très liée à Unity. Qu'ils s'en soient inspirés ou non, confrontés aux mêmes problèmes et avec les mêmes outils, ils ont trouvés plus ou moins les mêmes solutions.

Certes. On peut d'ailleurs dire la même chose de plein d'autres projets (j'ai, par exemple, déjà cité Gecko et Webkit). Et ?

AGui a écrit :

Sur la théorie, j'ai déjà dit que j'étais d'accord sur le principe, mais je pense qu'il y a des cas dans lesquels avoir un standard apporte plus de bénéfices.

J'adore les énoncés du genre « je suis d'accord avec le principe, mais je pense que le principe ne devrait pas s'appliquer ». Petit tip : en vrai, ça s'appelle ne pas être d'accord avec le principe.
(Et, accessoirement, il n'est pas question de standardisation ici. Parler de normes serait déjà plus adapté)

AGui a écrit :

Pour faire une métaphore foireuse, c'est comme au niveau économique, on peut être pour le libre échange et la concurrence non faussée, tout en considérant qu'il y a certains secteurs essentiels au fonctionnement de la société où l'absence de concurrence est plus adaptée (éducation, système de santé, sécurité, gestion des réseaux de communication et d'énergie).

Ouais, exactement de la même façon qu'on peut être pour la démocratie, mais à condition qu'il n'y ait qu'une élite qui décide. C'est du même niveau.
Si tu penses que l'absence de concurrence est plus adaptée à certains secteurs (et ce, à d'autant plus forte raison si tu considères que ces secteurs sont essentiels et que c'est la raison pour laquelle l'absence de concurrence y est plus adaptée), c'est que tu n'es pas pour le principe général de « libre échange et concurrence non-faussée », mais que tu as une autre vision du monde qui en englobe quelques aspects.

AGui a écrit :

Il y a d'autres projets qui sont soumis à la concurrence et qui pourtant ont aussi des problèmes de code obsolète. OpenOffice par exemple (d'ailleurs Calligra 2.7 vient de sortir hier, et ça devient vraiment une réelle alternative à LibreOffice). Mais reprenons l'exemple des formats de paquets : la concurrence a peut-être permis d'avoir plusieurs bons gestionnaires de paquets, mais les problèmes de maintenance viennent de packagekit, la couche de compatibilité qu'il a fallu rajouter par dessus (parce que les développeurs ont besoin d'un socle commun).

Bon, là, j'ai l'impression que tu confonds « nécessaire » et « suffisant »…

AGui a écrit :

Wayland est un protocole, il y aura différentes implémentations. Tu peux faire ta propre extension pour ton besoin spécifique si vraiment tu n'arrives pas à convaincre l'upstream de son intérêt, tout en conservant les extensions pour lesquelles tes besoins sont les mêmes que pour les autres.

Tu peux… quand il y a des implémentations communes. C'est la situation du « chacun patche dans son coin » qui génère plein de problèmes, mais marche effectivement à peu près en pratique. Sauf qu'on parle ici d'un cas où, précisément, il n'y avait à peu près rien à reprendre dans Wayland quand Canonical a lancé Mir. Du coup, de façon assez évidente, ça donne deux développements distincts.

AGui a écrit :

Gecko et Webkit sont deux implémentations différentes des mêmes standards HTML. Ils sont compatibles entre eux en très grande majorité, et pourtant le web est un des domaines dans lequel il y a le plus d'innovation en ce moment. Donc avoir un standard ne bride pas nécessairement l'innovation.

Juste un truc qui est pourtant essentiel, mais que tu sembles curieusement avoir oublié : la « très grande majorité » de compatibilité entre Gecko et Webkit, c'est précisément… la partie de la norme HTML qui n'est pas en pleine innovation. La partie en pleine innovation, c'est-à-dire les balises et propriétés qui ne sont pas encore gravées dans le marbre, c'est précisément là que réside les différences fondamentales entre Webkit et Gecko.
Soit, très exactement la même chose que pour Wayland et Mir… sauf que, les deux étant nouveaux, la partie compatible car déjà « gravée dans le marbre » est encore à peu près nulle. Mais pas d'inquiétude, ça viendra. Et ça viendra d'autant plus sûrement qu'ils bossent chacun comme ils l'entendent, de la même manière que l'existence de plusieurs moteurs de rendus ayant chacun des manières très différentes de mettre en place les nouvelles specs HTML est un facteur essentiel dans la mise en place correcte de ces nouvelles specs.

AGui a écrit :

Ca pourrait expliquer la création de Mir si seulement ils avaient eu des problèmes avec l'équipe Wayland. Wayland est développé par plus ou moins les mêmes personnes qui travaillent sur Xorg, et je suis pas au courant de problèmes entre Canonical et Xorg. Je crois même avoir lu qu'il y a eu quelques patchs soumis par des employés de Canonical pour Wayland, qui ont tous été acceptés ! Ils n'ont même pas essayé de discuter de leurs besoins et des choses qu'ils ne comprennaient pas dans Wayland.

Quand bien même il n'y aurait jamais eu de problèmes à ce niveau et pour ce truc-là en particulier (et j'ai quand même quelques doutes à ce sujet), je trouve que tu fais bien vite abstraction des multiples soucis qu'ils ont déjà eu à ce niveau, mais pour d'autres trucs. Encore une fois, il faut parfois regarder un peu la généralité, plutôt que d'essayer de se persuader qu'un « cas spécifique » en est totalement déconnecté.

AGui · Le 04/08/2013, à 21:47

Elzen a écrit :

Mais, comme je l'ai mentionné (...) D-Bus est (très) loin d'être le seul moyen pour que deux applis communiquent entre elles.

Une 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.

Elzen a écrit :

Juste par curiosité, à combien de projets as-tu essayé d'appliquer ces belles théories ? (...) En fait, sans vouloir te vexer, quand je te lis, j'ai l'impression que tu ne sais simplement pas à quoi ressemble le développement à plusieurs…

Mes seules contributions au logiciel libre en tant que développeur se limitent en effet à quelques patchs pour corriger des bugs simples dont personne ne s'occupait, dans des logiciels KDE. Mais le processus que je décris est commun dans les projets où l’équipe est suffisamment ouverte. 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. Des exemples concrets ici et là.

Elzen a écrit :

C'est limite malhonnête, comme affirmation : tu prends un truc qui semble à peu près aller dans ton sens, tu poses que le truc que tu critiques est la seule exception, et roulez jeunesse.
Dans la réalité, il y a effectivement pas mal d'éléments de FreeDesktop qui sont repris dans plein de projets parce qu'ils réussissent plutôt très bien à faciliter la vie des devs, mais c'est plutôt ce cas-là qui est l'exception, et l'existence de multiples trucs et machins dans tous les sens sans beaucoup de compatibilités qui reste la norme ; qu'on soit d'accord ou pas avec cet état de fait.

A 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.

Elzen a écrit :

Pas du tout, non. Au contraire, même. La dispute entre Torvalds et l'équipe de GNOME était le seul truc qui concernait le haut niveau, et donné uniquement à titre d'exemple sur les divergences d'opinions, sans aucune valeur technique. En revanche, pour Unity comme pour Iceweasel (notons au passage que, justement, pour l'utilisateur, Iceweasel ou Firefox, ça ne change rien, donc tu aurais dû te rendre compte toi-même en parlant que ce que tu pointais là n'avait pas de sens), c'est bel et bien de la partie technique et bas niveau que je parlais : le fait, essentiel, de pouvoir faire ce qu'il faut pour faire marcher le logiciel sans avoir besoin de l'aval d'autres gens.
La valeur ajoutée de Mir, pour Canonical, est très exactement la même que la valeur ajoutée d'Iceweasel pour l'équipe de Debian : la possibilité de travailler librement et en fonction de leurs objectifs propres, sans devoir dépendre de la volontés de gens qui n'ont pas forcément les mêmes idées qu'eux. En toute logique, si tu critiques Canonical pour Mir, tu dois critiquer aussi Debian pour Iceweasel ; ou alors tu fais deux poids, deux mesures.

Honnêtement, je ne savais pas qu’il y avait des différences techniques. Je pensais que Debian avait forké Firefox à cause de la licence de son nom et de son logo, c’est d’ailleurs la raison principale mentionnée sur la page Wikipedia. Mais en pratique, l'impact d'Iceweasel sur les utilisateurs, sur les développeurs d'extension pour Firefox et pour les développeurs web est négligeable. De même, tu n'as pas à développer deux versions distinctes de ton application pour qu'elle fonctionne sous Unity et Gnome-shell. J'ai déjà développé en quoi il y avait lieu d'avoir des craintes pour Mir.
Ce n’est pas le seul projet pour lequel j’ai cette position, par exemple j’ai déjà dit dans ce thread que Gnome aurait mieux fait d’adopter les mêmes systèmes de notification et de centralisation des comptes en ligne que Plasma et Unity plutôt que de développer leurs propres solutions incompatibles.

Elzen a écrit :

Intéressant ; tu saurais sur quoi on peut tester ça ?

Aucune idée, j’ai jamais testé MicroXwin moi-même.

Elzen a écrit :

Hum. Permet-moi de reprendre : quand on pointe que « tout élément de l'ensemble présente telle propriété », bah, quand tu prends un élément de l'ensemble, quel qu'il soit, il présente la propriété. Si tu en trouves un qui ne la présente pas, c'est que l'énoncé de départ était faux. On est bien d'accord que c'est évident, ça ?
Bah maintenant, il a été développé en long, en large et en travers, en quoi, pour chaque partie du système d'exploitation, avoir plusieurs options différentes est intéressant. En application directe de cette propriété générale, Wayland et Mir étant deux options différentes pour une partie du système d'exploitation, avoir les deux est donc intéressant, c'est de la logique de base.
Partant de là, si ce que tu cherches à démontrer est qu'avoir le choix entre Wayland et Mir n'est pas intéressant, c'est bel et bien au développement général, et non pas seulement à ce « cas spécifique », que tu t'attaques. Si tu es d'accord avec le principe général, il n'y a pas besoin de montrer en quoi il s'applique à ce « cas spécifique », son application est évidente ; si tu n'es pas d'accord avec, ce n'est pas en faisant semblant que ce « cas spécifique » est déconnecté du reste que tu vas réussir à être convainquant.

Visiblement, 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. Comme 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.

Elzen a écrit :

Si tu penses que l'absence de concurrence est plus adaptée à certains secteurs (...), c'est que tu n'es pas pour le principe général de « libre échange et concurrence non-faussée », mais que tu as une autre vision du monde qui en englobe quelques aspects.

Soit.

Elzen a écrit :

Bon, là, j'ai l'impression que tu confonds « nécessaire » et « suffisant »…

Je 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.

Elzen a écrit :

Tu peux… quand il y a des implémentations communes. C'est la situation du « chacun patche dans son coin » qui génère plein de problèmes, mais marche effectivement à peu près en pratique. Sauf qu'on parle ici d'un cas où, précisément, il n'y avait à peu près rien à reprendre dans Wayland quand Canonical a lancé Mir.

Je 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.

Elzen a écrit :

Juste un truc qui est pourtant essentiel, mais que tu sembles curieusement avoir oublié : la « très grande majorité » de compatibilité entre Gecko et Webkit, c'est précisément… la partie de la norme HTML qui n'est pas en pleine innovation. La partie en pleine innovation, c'est-à-dire les balises et propriétés qui ne sont pas encore gravées dans le marbre, c'est précisément là que réside les différences fondamentales entre Webkit et Gecko.

L'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é.

Elzen a écrit :

Soit, très exactement la même chose que pour Wayland et Mir… sauf que, les deux étant nouveaux, la partie compatible car déjà « gravée dans le marbre » est encore à peu près nulle. Mais pas d'inquiétude, ça viendra. Et ça viendra d'autant plus sûrement qu'ils bossent chacun comme ils l'entendent(...)

Je 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.

Haleth · Le 04/08/2013, à 22:20

Iceweasel n'est pas un fork, c'est un autre nom donné par le projet Debian pour Firefox.
Le git est le même. De fait, ce que tu fait pour firefox fonctionne sur Iceweasel .. logique, un nom n'a pas d'impact sur le fonctionnement du truc.

Elzen · Le 05/08/2013, à 01:00

AGui a écrit :

Une 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 écrit :

Mais 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 écrit :

A 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 écrit :

Honnê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 écrit :

De 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 écrit :

Visiblement, 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 écrit :

Comme 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 écrit :

Je 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 écrit :

Je 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 écrit :

L'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 écrit :

Je 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.

Dernière modification par Elzen (Le 05/08/2013, à 01:05)

The Uploader · Le 05/08/2013, à 09:12

AGui a écrit :

A 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.

Je ne crois pas que Wayland soit un 'projet [de standard] freedesktop', pas plus que systemd ni nouveau ne le sont.. Le projet Wayland est juste hébérgés sur freedesktop.org

Keiser · Le 05/08/2013, à 12:34

C'est un concours du post le plus long ?

Bigcake · Le 05/08/2013, à 14:38

Keiser a écrit :

C'est un concours du post le plus long ?

c'est ce qu'on appele avoir une discussion sur un forum.
C'est pas twitter ici, tu peux y développer ton opinion

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#576 Le 31/07/2013, à 16:20

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#577 Le 31/07/2013, à 16:41

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#578 Le 31/07/2013, à 16:45

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#579 Le 31/07/2013, à 16:57

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#580 Le 31/07/2013, à 18:22

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#581 Le 01/08/2013, à 18:12

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#582 Le 01/08/2013, à 20:04

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#583 Le 01/08/2013, à 20:07

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#584 Le 01/08/2013, à 20:34

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#585 Le 01/08/2013, à 20:35

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#586 Le 01/08/2013, à 20:36

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#587 Le 01/08/2013, à 22:23

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#588 Le 01/08/2013, à 22:35

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#589 Le 02/08/2013, à 00:59

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#590 Le 02/08/2013, à 04:23

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#591 Le 02/08/2013, à 08:12

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#592 Le 02/08/2013, à 11:52

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#593 Le 02/08/2013, à 19:36

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#594 Le 03/08/2013, à 00:28

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#595 Le 04/08/2013, à 21:47

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#596 Le 04/08/2013, à 22:20

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#597 Le 05/08/2013, à 01:00

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#598 Le 05/08/2013, à 09:12

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#599 Le 05/08/2013, à 12:34

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

#600 Le 05/08/2013, à 14:38

Re : Ubuntu travaille sur un nouveau serveur X et c'est pas Wayland

Pied de page des forums