Fin de l'attribution des commits extérieur à Ubuntu
On ne va pas refaire ce débat, mais j'imagine que tu sais qu'il y a du pour et du contre sur cette mesure.
Pas de GPLV3 uniquement, afin d'être compatible avec les autres environnement
Mir a aussi du code LGPL (part qui est amenée à grossir vu le futur besoin de supporter les pilotes proprio).
Travail/contribution upstream des patchs pour Qt, Gtk, … avec détection au runtime, afin qu'un soft Qt/Gtk/EFL déjà compilé puisse tourner sous Wayland ou Mir.
Vu que l'ensemble est encore en développement, j'imagine qu'il ne faut pas s'attendre à ce que les patchs soient proposés avant la stabilisation des API en octobre.
Dans la même veine, développement d'un WaylandMir et d'un MirWayland
Quel intérêt ? Il restera toujours X en point commun entre les deux.
Mise en place d'un protocole pour pas qu'un compositeur différent d'Unity soit cassé tout les quatre matins à chaque mise à jour système.
La compatibilité de l'API de la libmirserver sera maintenue à partir d'octobre (première version de Mir en production).
Après, on peut dire que la communauté du dev libre voit le mal partout
C'est entièrement de la faute de Canonical si Mir est parti sur un si mauvais pied vis à vis de la communauté.
Maintenant il faut aussi essayer d'analyser la situation plus pragmatiquement sans sombrer dans la paranoïa.
Objectivement, Canonical a fait des pas dans la bonne direction en offrant de la documentation et en tentant d'ouvrir des discussions constructives avec les personnes potentiellement concernées par Mir (il y a un type de chez Fedora qui passe de temps en temps pour demander de rajouter des trucs dans la doc, il y a des paquets Mir dans Arch Linux…)
Ni Mir ni Wayland ne vont disparaître avant un bon bout de temps. Qu'on se le dise.
Maintenant il faut apprendre à coexister pour éviter les problèmes de compatibilités que tu évoques et que personne ne souhaite.
Tu sembles mieux t'y connaître que moi donc je ne vais pas te suivre dans ton pari. On aura bien vite l'occasion de comparer les benchs.
De ce que j'ai cru comprendre, Mir implémente (ou va implémenter ?) un scenegraph générique en interne pour les shells basiques tout en fournissant une interface pour permettre au shell d'implémenter son propre scenegraph s'il le souhaite (ce qui sera le cas avec Unity 8). Je ne sais pas si ça peut t'aider dans ta réflexion :-)
édit : c'est justement en cours de discussion sur mir-devel. Malheureusement l'archive web n'a pas l'air d'être à jour, du coup je ne peux pas te donner de lien.
D'ailleur Mir utilise les meme pieces de maniere general, sauf qu'il ne respecte pas les regles et a une approche aggressive envers la communaute.
avait une approche agressive ;)
Depuis l'annonce on voit bien qu'ils ont essayé d'arrondir les angles. Trop tard ou pas, c'est un autre sujet.
Il y a des rumeurs qui disent que nvidia va sortir une interface EGL à son pilote proprio, comme ça ça sera la même interface que les pilotes libres.
EGL est une condition nécessaire mais pas suffisante.
La preuve, les pilotes Android fournissent aussi une interface EGL et il est pourtant impossible de faire fonctionner un Weston de base dessus (et Mir a dû implémenter une interface spécifique).
Je m'avoue volontiers incompétent dans ce domaine, mais une chose est sûr : les divers compositeurs Wayland devront être adaptés pour supporter les pilotes proprios.
S'il est possible de factoriser ce support dans la libwayland-server, tant mieux. Mais je n'ai pas l'impression que ça soit l'objectif.
Et si l'architecture est pourrie ? Et s'il manque des fonctionnalités ?
En effet, je ne parle que de théorie.
Comme je l'ai dit plus haut, Canonical a lancé des efforts pour ouvrir le développement de Mir et donc pour permettre aux développeurs concernés de communiquer leurs besoins (oui, ça peut paraître ironique mais c'est bel et bien le cas).
Je ne sais pas si ça va donner quelque chose. Probablement rien à court terme.
Je crois bien me souvenir qu'il y a des gens qui le font chez Intel. De plus ceux qui ont fait les premiers essais de tilling window manager ont modifié aussi Weston et ne sont pas parti de zéro. Weston était prévu à l'origine pour être un exemple, c'est tout. Il est logique que les gens fassent leur propre implémentation.
Que je sache, il s'agit toujours de forks et non de plugins. Si ces projets vivent, ils vont probablement continuer de diverger.
D'où l'intérêt de l'approche plugin.
Au fait, ma mauvaise opinion sur « les Waylands » vient principalement de cet article + commentaires : http://smspillaz.wordpress.com/2012/12/24/sideways/
(il travaillait chez Canonical à l'époque, Mir était un POC en interne et son adoption n'avait pas encore été décidée)
Le fait que le scénario du pire (les Waylands donc) ce soit réalisé est celon moi l'une des raison qui ont fait perdre la foi en Wayland chez Canonical. C'est pour ça que j'essaye de comprendre.
C'est étonnamment pas du tout l'avis de tous les gens que l'on pourrait juger techniquement compétents sur le sujet : les développeurs de la stack graphique sous Linux, qui sont étrangement aussi plus ou moins liés à Wayland/Weston.
La présomption d'incompétence chez tous les autres n'est pas forcément légitime non plus ;)
Le débat Mir/Wayland n'est actuellement pas objectif. Vu la façon dont Canonical a sortit Mir de son chapeau, il est parfaitement compréhensible que les promoteurs de Wayland ce soient tous braqués.
Canonical a fait des efforts (et continue d'en faire) pour ouvrir d'avantage Mir. Mais le mal a été fait. Reste à espérer que le temps rapprochera tout ce beau monde.
Euh non, Wayland s'appuie sur KMS/DRM, rien de folklo la dedans, rien de specifique pour des pilotes proprios.
Tu n'as pas compris ce que je voulais dire.
Il est apres possible d'utiliser des implementations differente pour contourner des drivers proprio ou mal goupille, RPi et Android principalement
Ces implémentations vont devoir être faites. Ceux qui espèrent encore pouvoir fournir un compositeur Wayland sans support des pilotes proprios ne souhaitent simplement pas toucher le grand public.
Ma question était : est-ce que ce support devra être implémenté séparément dans chaque compositeurs Wayland ?
Si oui, je persiste à dire que c'est ultra casse gueule.
Mir fait exactement la meme chose. Aucune difference technique entre les deux de ce cote la.
Il y a un compositeur Mir que tout le monde est sensé utilisé en rajoutant juste la partie Shell.
Il y a une multitude de compositeurs Waylands qui semblent chacun réinventer une partie de la roue.
T'inquiete pas. Oublie Mir. Change de distro si tu utilises Ubuntu, car ils ne travaillent pas avec la communaute et essaye de construire leur propre ecosysteme controle comme Android. Ils sont en marche pour faire un Ubuntu/Linux… sans grand interet pour la communaute !
Tu devrais t'intéresser à la communauté Ubuntu avant de porter de tels jugements ;)
(ok, c'est trolldi, donc tu es pardonné)
si ils veulent que Mir soit utilise par d'autre DE c'est a eux et a eux seul de faire le port. Ce sont eux qui ont forke c'est a eux d'assumer.
C'est tout le problème de Mir : il a été annoncé de façon totalement désastreuse.
Tout le monde s'est braqué et je vois mal les grands acteurs comme Gnome ou KDE changer d'opinion à son sujet avant plusieurs longs mois (le temps qu'on puisse tirer un premier bilan de la mise en production des premiers Waylands et de Mir).
Désolé mais non, parce que l'ajout de Mir implique des modifications dans d'autres projets, comme celles nécessaires à l'ajout de Wayland : Mesa, tous les toolkits…
Je ne parlais pas du côté client mais plutôt de la partie entre le compositeur et le matériel (le driver model).
Cette partie n'ai apparemment pas définie dans libwayland-server, ce qui implique que chaque compositeur en fera sa propre implémentation.
Techniquement, il est possible de développer un nouveau frontend pour Mir qui lui permette de parler Wayland à ses clients (cf. la doc de Mir). ce qui ferait de Mir un compositeur Wayland comme un autre.
Ce qui n'apporterai pas magiquement le support des pilotes Mir (libres, Android, bientôt proprio) aux autres compositeurs Wayland.
Quand des boites comme Jolla disent avoir porté Wayland pour qu'il utilise les drivers Android, ça veut juste dire qu'ils ont codé un compositeur spécifique (forké en l’occurrence).
Pour en revenir à mon point initial, l'idée du « chacun son implémentation » va pour moi poser plus de problèmes qu'autre chose.
Il aurait mieux fallut rendre Weston plus flexible pour que les différents shells viennent s'y implémenter en tant que plugins.
Même si Mir a été annoncé (trop ?) tard et avec une maladresse incroyable, il me parait techniquement mieux architecturé. On a un serveur qui fourni une API (pas un protocole) et le shell qui vient se brancher dessus (via une couche d'abstraction, ou pas).
C'est certes beaucoup plus restrictif, mais ça limite les risques de divisions.
En ce moment il y a les logins manager et les environnements de bureau et cela ne pose aucun soucis. Certes un system compositor ferait plus de chose que le login manager, mais il n'y a pas de raison que les environnements deviennent incompatibles. Le but du system compositor est principalement d'assurer le changement d'utilisateur et d'environnement justement (Chapter 2. Types of Compositors). L'avantage avec Wayland justement c'est que l'on peut imbriquer tout ça sans trop de soucis puisque l'imbrication est justement supportée (nested compositing).
S'ils ont bien pris soin de standardiser cette partie et que les extensions customs de chaque DE ne se marchent pas dessus, ça peut en effet marcher.
Personne n'est obligé de ré-implémenter son propre compositeur, il est tout à fait possible d'utiliser Weston et de coder juste la partie qui gère les fenêtres ou autre dans un module pour weston
Tout à fait. Mais en pratique personne ne le fait.
C'est là que le bât blesse selon moi, je n'aurais rien à redire si tout le monde avait étendu Weston plutôt que de refaire son propre truc.
L'approche de Mir semble plutôt être de vouloir tout gluer ensemble
Mir en lui même est indépendant et n'a pas besoin de Unity (cf les exemples fournis dans les sources).
Les deux bases de codes sont développées séparément, avec un couche de compatibilité entre les deux (Mir étant développé en C++ tandis que Unity 8 est développé en QML).
[Mir is a] general purpose display server that other distributions, desktops, and other upstreams can use
Ce n'est pas non plus ce que j'avais compris lors de l'annonce initiale, mais il semble que Canonical ne cherche plus à restreindre Mir aux besoins de Unity.
(tant mieux mais trop tard ?)
Quelle vaste blague, je pense que l'on peut attendre longtemps l'aide de Cannonical sur ce point. Si ils veulent que les autres shells marchent, ils peuvent tout à fait les porter, on n'attends que ça. J'ai comme l'impression que cela ne vas pas se produire.
Sachant qu'ils ce sont pris un vent et que personne ne c'est montré intéressé, ça risque de prendre du temps en effet.
Et il est clair qu'ils ne vont pas s'amuser à porter un DE si c'est pour que le patch ne soit pas accepté upstream après.
Il ne faut pas confondre le travail du compositeur avec celui des applications qui ne font que du rendu, en utilisant en grande partie un version d'OpenGL ou du rendu software sur le CPU. Même les drivers propriétaires sont obligés de fournir une librairie 'libgl' si ils veulent que les applications marchent avec leur driver. Coder une application avec des "spécificités de l'implémentation de Wayland faite par Gnome-Shell" est un non-sens. Le protocole est fixé, versionné, et les extensions sont ajoutées dans Wayland, pas par les compositeurs qui vont "remplacer" Weston.
Specific compositor implementations may have their own interfaces provided as extensions
C'est ça qui me fait peur.
Xorg aussi utilise des extensions par rapport aux specs X11, mais vu que tout le monde l'utilise la question de la compatibilité entre les implémentation ne se pose pas.
Sauf que sous l'ère X tout le monde utilise l'implémentation de référence tandis que tout porte à croire que personne n'utilisera Weston en pratique.
Je ne connais pas les tréfonds de la "libwayland-server" donc si tu me dis qu'elle définie suffisamment de code commun pour éviter tous les problèmes que j'évoque, je veux bien te croire.
Mais j'avais plutôt l'impression qu'elle se concentrait sur l'implémentation d'un système d'IPC tout en faisant l'impasse sur un modèle de driver (encore une fois, je me trompe peut-être).
Merci, tu mets le doigt sur ce que je disais en fait.
Sauf si je fais fausse route, cette FAQ est inexacte. Wayland ne réutilise pas les drivers ni l'infrastructure existante, Wayland n'est qu'un protocole, pas un morceau de code.
Weston, UNE implémentation, (qui était certes probablement unique à l'époque) réutilise en effet la pile graphique libre.
Ce que je veux dire c'est que l'ensemble des compositeurs Wayland ne semblent pas partager de code à ce niveau (l'interface) et que c'est selon moi extrêmement casse gueule.
Ça ne devrait donc rien changer pour ce qui est des pilotes proprios.
De ce que je sais les pilotes proprios ont besoin d'une interface spécifique car ils ne peuvent pas s'intégrer dans KMS/GEM &co pour des raisons de licence.
Ce qui va se passer selon moi c'est qu'un beau jour Canonical va publier un communiqué disant « on s'est mis d'accord avec AMD et Nvidia sur le support d'une API dans leurs drivers. Voici le header en question. ».
J'imagine déjà le bordel entre toutes les implémentations de Wayland.
(notez que la situation serait exactement la même si Canonical avait décider de faire son propre compositeur Wayland plutôt que Mir)
Pour avoir suivi les discussions autours de Mir et Kubuntu, le truc qui en ressortait c'était « Ubuntu passe à Mir, ce qui n'empêche certes pas les dérivés d'utiliser Wayland. Par contre le truc absolument horrible c'est qu'on va perdre la possibilité de switcher de bureau depuis l'écran de login. Brûlons Canonical pour cette hérésie ! »
Seulement voila, Wayland n'est qu'un protocole et, que je sache, chaque gestionnaire de bureau implémente son propre compositeur en utilisant ses propres extensions.
Il me semble que KDE et Gnome ont eux aussi prévu d'utiliser un compositeur système pour gérer les sessions, ce qui implique de lancer le compositeur en question bien avant l'écran de login.
Du coup je doute fortement que les compositeurs seront (ou resteront) suffisamment compatibles entre eux pour permettre le switch des environnements de bureau.
Pour cette raison, entre autre, j'ai du mal comprendre pourquoi Wayland demande à tout le monde de ré-implémenter son propre compositeur.
De ce point de vue, l'approche Mir qui consiste à séparer l'implémentation du bureau du serveur d'affichage avec une couche de glue entre les deux me parait être conceptuellement plus intelligente.
C'est certes plus proche de l'infrastructure X actuelle, mais ça permet de factoriser beaucoup de code entre les DE (car oui, Mir en lui même n'est absolument pas spécifique à Unity, Canonical à même proposé son aide pour porter les autres shells).
Par exemple, si je ne m'abuse, quand les pilotes proprios vont supporter Mir, c'est bien chaque compositeur Wayland qui va devoir se rendre compatible indépendamment.
Bonjour les bugs entre les différentes implémentations. Et qu'est-ce qui nous dit qu'une appli Gnome continuera de fonctionner aussi bien sous Kwin si l'appli en question a été codée en suivant les spécificités de l'implémentation de Wayland faite par Gnome-Shell ?
Bref, je suis assez pessimiste sur l'avenir de tout ça et j'ai besoin d'être rassuré par des gens qui s'y connaissent.
À votre bon cœur messieurs dames !
ou alors il faudra remplacer Mir par Xorg ce qui est une manip plus compliquée encore que d'installer un pilote tiers…
C'est ce que j'ai dit dans mon commentaire : le plan pour la 13.10 est d'avoir un fallback automatique vers X si le pilote utilisé ne supporte pas Mir.
Non, sous Ubuntu 13.10 c'est toute la session qui sera lancée sur Xmir.
Grosso modo, par rapport à la situation actuelle, cela revient juste à intercaler Mir entre le matériel et X.
Ce n'est sensé rien changer pour l'utilisateur si le pilote graphique utilisé est compatible (pilotes libres en fait).
Il y aura un fallback automatique vers le X « traditionnel » pour les pilotes proprios (qui seront compatibles Mir d'ici la 14.04).
Les problèmes de performance actuels sont des bugs, ils devraient être résolus ou au moins minimisés d'ici octobre.
Le but de cette intégration prématurée dans Ubuntu 13.10 est de s'assurer que l'ensemble soit parfaitement au point pour la prochaine LTS dans moins d'un an, au détriment (potentiel) de la stabilité de cette version intermédiaire.
Ça me parait gros. On a un super partenaire mais on préfère rien dire parce que c'est pas notre genre de buzzer trop tôt… Sérieux ?
Ça s'appelle du marketing.
Quel serait l'intérêt de faire une annonce maintenant alors que la première version fonctionnelle d'Ubuntu Touch n'est pas prévue avant octobre et qu'il faudra ensuite compter jusqu'à 6 mois pour certifier le tout avant commercialisation ?
Concernant Mir, les raisons de son développement sont clairement indiquées dans le Wiki et dans les divers articles sur les blogs des développeurs.
L'objectif est simplement d'avoir un système qui soit parfaitement adapté aux besoins futurs d'Ubuntu/Unity, surtout en ce qui concerne les problématiques de convergence (le mot d'ordre est « no compromise »).
D'accord ou pas, c'est un autre problème. Mais je ne vois pas pourquoi il faudrait chercher une raison cachée alors que celles avancées par Canonical se tiennent.
Pas forcément.
Valve utilise SDL pour tous ses portages.
SDL supporte X, Wayland et supportera bientôt Mir (le portage est en cours).
Du coup, à priori, il suffirait que Valve mette à jour ses jeux en intégrant une version récente de SDL pour que ceux-ci fonctionnent partout.
De toute façon, les appli X tourneront encore sous Wayland (via Xwayland) et sous Mir (Xmir). Du coup il y aura toujours au moins une compatibilité à ce niveau et donc Valve ne sera même pas obligé de changer quoi que ce soit à ses portages actuels.
Quand on regarde où en est Canonical dans ses projets/partenariats commerciaux :
- rien pour la version pour ordiphones/tablettes
Faux. Cela fait plusieurs mois maintenant qu'on sait qu'ils ont trouvé au moins un partenaire.
Le premier modèle d'Ubuntu phone ne devant pas sortir avant une dizaine de mois, il est probable que son nom ne soit dévoilé que début 2014 (histoire de faire le buzz près de la date de sortie). Mark en a reparlé dans une interview récente.
Donc toutes les décisions de Canonical vont concourir à créer [une] incompatibilité [avec les autres distributions].
Je ne vois pas ce que ça leur apporterait.
Se fermer de la sorte reviendrait à se passer de communauté, ce qui les priverait d'une main d'œuvre bon marché et démotiverait probablement une bonne partie de leurs développeurs (qui sont issus de cette communauté).
D'ailleurs, le fait que les core-apps d'Ubuntu Touch soient développées uniquement par la communauté montre bien qu'ils ne cherchent pas à s'isoler.
Pour revenir sur Mir, il sera installable en parallèle des divers compositeurs Wayland et de X.
Du coup on a clairement vu pire en ce qui concerne l'incompatibilité avec les autres distros, non ?
Donc, je pose la question : pourquoi vouloir absolument chercher le mal partout ? Et si les développeurs d'Ubuntu ne créaient que les outils qu'ils estiment nécessaire, sans arrière pensée diabolique ?
LXC is an interesting technology that is useful for many things. It is great for Juju or providing a lightweight alternative to virtualization. It is not the right choice for application confinement because it doesn't provide significant benefits over AppArmor in its current form, but has several drawbacks: it is a new technology, it requires privileges to start/stop applications, it requires several different bind mounts for each application (which becomes messy when lots of applications are running), does not (easily) provide fine-grained access controls to files, and is generally too heavyweight for application confinement. While LXC could with effort possibly be made to provide a similar level of fine-grained confinement that AppArmor currently has, you would still have to deal with the challenging parts such as D-Bus and Ubuntu Online Accounts and would have difficulties allowing access to things such as the clipboard or individual keys within a keyring. AppArmor is mature and provides a jump start on application confinement (it was specifically designed for this purpose). It is lightweight, provides a simpler implementation that is easy to extend and allows us to unify the application confinement pieces in an elegant manner.
Dans la langue des grenouilles, ça dit grosso-modo que LXC c'est bien mais pas vraiment adapté à ce cas d'utilisation. On pourrait toujours faire avec mais il se trouve qu'AppArmor répond apparemment à tous les besoins et qu'il est intégré à Ubuntu depuis plus de 5 ans (donc éprouvé).
Au contraire, ce format se voulant plus simple il devrait être plus facilement compatible avec les autres distributions.
D'ailleurs, on est même pas sûr qu'il s'agira réellement d'un nouveau format. Il y a des discussions intéressantes sur la mailing-list avec des développeurs de Listaller, 0install et Nix.
Le PoC développé par Colin Watson est certes original, mais il a un avantage que les autres n'ont pas : il réutilise le code de dpkg, ce qui simplifie les choses et peu potentiellement permettre une meilleure intégration avec les outils d'administration Debian usuels.
On verra bien ce qui en ressortira. Il y aura une session consacrée à ce sujet la semaine prochaine lors de l'UDS.
Les paquets .deb ont pour vocation d'être intégrés dans des dépôts et sont donc « audités » manuellement par des tiers.
C'est un excellent système pour empaqueter un OS, mais ça pose de gros problèmes quand on commence à vouloir permettre à n'importe qui de soumettre son application et de la publier le plus automatiquement possible.
D'où l'idée d'un format de paquet beaucoup plus bête qui ne nécessiterai pas forcément d'être root, qui se contenterait de copier les fichiers d'une appli dans un répertoire unique (pas d'interférence avec le reste du système), qui n'autoriserait pas le moindre script de pre/post install et qui n'aurait qu'une prise en charge minimaliste des dépendances (du genre juste dépendre d'une version du SDK).
Donc voilà. Des besoins différents impliquent des solutions différentes. Et ce (potentiellement) nouveau format n'est pas du tout fait pour remplacer APT.
Sauf que ça n'a jamais été la raison principale pour développer Mir.
Les développeurs n'ont jamais dit qu'il était impossible d'adapter Wayland (protocole + Weston) à leurs besoins (cf les nombreux articles sur les blogs des développeurs).
Ils ont juste considéré qu'une solution maison leur profiterai d'avantage à plus ou moins long terme, surtout en terme de souplesse.
On peut être d'accord (ou pas) et se demander s'ils prendraient la même décision aujourd'hui au regard des récentes avancés des projets Wayland.
Mais ce qui est fait est fait et le développement de Mir avance aujourd'hui (enfin) en toute transparence, que ce soit au niveau du code que des discussions techniques.
il est intéressant de voir qui travaille derrière Mir : ce sont principalement deux développeurs qui ont été embauchés il y a juste un an (date de création de leurs comptes Launchpad) P. S. Jenkins et Alan Griffiths.
Pour information, ce fameux « P. S. Jenkins » est un bot ;-)
C'est lui qui s'occupe de compiler et de lancer les tests unitaires automatiquement sur chaque nouvelle branche et c'est lui qui s'occupe de merger ces branches dans la branche principale (d'où son « score de contribution » élevé dans Launchpad).
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 3.
L'avis personnel de Mark n'est pas représentatif de l'ensemble de la communauté Ubuntu.
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à -1.
On ne va pas refaire ce débat, mais j'imagine que tu sais qu'il y a du pour et du contre sur cette mesure.
Mir a aussi du code LGPL (part qui est amenée à grossir vu le futur besoin de supporter les pilotes proprio).
Vu que l'ensemble est encore en développement, j'imagine qu'il ne faut pas s'attendre à ce que les patchs soient proposés avant la stabilisation des API en octobre.
Quel intérêt ? Il restera toujours X en point commun entre les deux.
La compatibilité de l'API de la libmirserver sera maintenue à partir d'octobre (première version de Mir en production).
C'est entièrement de la faute de Canonical si Mir est parti sur un si mauvais pied vis à vis de la communauté.
Maintenant il faut aussi essayer d'analyser la situation plus pragmatiquement sans sombrer dans la paranoïa.
Objectivement, Canonical a fait des pas dans la bonne direction en offrant de la documentation et en tentant d'ouvrir des discussions constructives avec les personnes potentiellement concernées par Mir (il y a un type de chez Fedora qui passe de temps en temps pour demander de rajouter des trucs dans la doc, il y a des paquets Mir dans Arch Linux…)
Ni Mir ni Wayland ne vont disparaître avant un bon bout de temps. Qu'on se le dise.
Maintenant il faut apprendre à coexister pour éviter les problèmes de compatibilités que tu évoques et que personne ne souhaite.
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 2. Dernière modification le 19 juillet 2013 à 13:43.
Intéressant, merci.
Tu sembles mieux t'y connaître que moi donc je ne vais pas te suivre dans ton pari. On aura bien vite l'occasion de comparer les benchs.
De ce que j'ai cru comprendre, Mir implémente (ou va implémenter ?) un scenegraph générique en interne pour les shells basiques tout en fournissant une interface pour permettre au shell d'implémenter son propre scenegraph s'il le souhaite (ce qui sera le cas avec Unity 8). Je ne sais pas si ça peut t'aider dans ta réflexion :-)
édit : c'est justement en cours de discussion sur mir-devel. Malheureusement l'archive web n'a pas l'air d'être à jour, du coup je ne peux pas te donner de lien.
avait une approche agressive ;)
Depuis l'annonce on voit bien qu'ils ont essayé d'arrondir les angles. Trop tard ou pas, c'est un autre sujet.
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 0.
EGL est une condition nécessaire mais pas suffisante.
La preuve, les pilotes Android fournissent aussi une interface EGL et il est pourtant impossible de faire fonctionner un Weston de base dessus (et Mir a dû implémenter une interface spécifique).
Je m'avoue volontiers incompétent dans ce domaine, mais une chose est sûr : les divers compositeurs Wayland devront être adaptés pour supporter les pilotes proprios.
S'il est possible de factoriser ce support dans la libwayland-server, tant mieux. Mais je n'ai pas l'impression que ça soit l'objectif.
En effet, je ne parle que de théorie.
Comme je l'ai dit plus haut, Canonical a lancé des efforts pour ouvrir le développement de Mir et donc pour permettre aux développeurs concernés de communiquer leurs besoins (oui, ça peut paraître ironique mais c'est bel et bien le cas).
Je ne sais pas si ça va donner quelque chose. Probablement rien à court terme.
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 2.
Que je sache, il s'agit toujours de forks et non de plugins. Si ces projets vivent, ils vont probablement continuer de diverger.
D'où l'intérêt de l'approche plugin.
Au fait, ma mauvaise opinion sur « les Waylands » vient principalement de cet article + commentaires : http://smspillaz.wordpress.com/2012/12/24/sideways/
(il travaillait chez Canonical à l'époque, Mir était un POC en interne et son adoption n'avait pas encore été décidée)
Le fait que le scénario du pire (les Waylands donc) ce soit réalisé est celon moi l'une des raison qui ont fait perdre la foi en Wayland chez Canonical. C'est pour ça que j'essaye de comprendre.
La présomption d'incompétence chez tous les autres n'est pas forcément légitime non plus ;)
Le débat Mir/Wayland n'est actuellement pas objectif. Vu la façon dont Canonical a sortit Mir de son chapeau, il est parfaitement compréhensible que les promoteurs de Wayland ce soient tous braqués.
Canonical a fait des efforts (et continue d'en faire) pour ouvrir d'avantage Mir. Mais le mal a été fait. Reste à espérer que le temps rapprochera tout ce beau monde.
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 1.
Tu n'as pas compris ce que je voulais dire.
Ces implémentations vont devoir être faites. Ceux qui espèrent encore pouvoir fournir un compositeur Wayland sans support des pilotes proprios ne souhaitent simplement pas toucher le grand public.
Ma question était : est-ce que ce support devra être implémenté séparément dans chaque compositeurs Wayland ?
Si oui, je persiste à dire que c'est ultra casse gueule.
Il y a un compositeur Mir que tout le monde est sensé utilisé en rajoutant juste la partie Shell.
Il y a une multitude de compositeurs Waylands qui semblent chacun réinventer une partie de la roue.
Tu devrais t'intéresser à la communauté Ubuntu avant de porter de tels jugements ;)
(ok, c'est trolldi, donc tu es pardonné)
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 1.
C'est tout le problème de Mir : il a été annoncé de façon totalement désastreuse.
Tout le monde s'est braqué et je vois mal les grands acteurs comme Gnome ou KDE changer d'opinion à son sujet avant plusieurs longs mois (le temps qu'on puisse tirer un premier bilan de la mise en production des premiers Waylands et de Mir).
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 1.
Je ne parlais pas du côté client mais plutôt de la partie entre le compositeur et le matériel (le driver model).
Cette partie n'ai apparemment pas définie dans libwayland-server, ce qui implique que chaque compositeur en fera sa propre implémentation.
Techniquement, il est possible de développer un nouveau frontend pour Mir qui lui permette de parler Wayland à ses clients (cf. la doc de Mir). ce qui ferait de Mir un compositeur Wayland comme un autre.
Ce qui n'apporterai pas magiquement le support des pilotes Mir (libres, Android, bientôt proprio) aux autres compositeurs Wayland.
Quand des boites comme Jolla disent avoir porté Wayland pour qu'il utilise les drivers Android, ça veut juste dire qu'ils ont codé un compositeur spécifique (forké en l’occurrence).
Pour en revenir à mon point initial, l'idée du « chacun son implémentation » va pour moi poser plus de problèmes qu'autre chose.
Il aurait mieux fallut rendre Weston plus flexible pour que les différents shells viennent s'y implémenter en tant que plugins.
Même si Mir a été annoncé (trop ?) tard et avec une maladresse incroyable, il me parait techniquement mieux architecturé. On a un serveur qui fourni une API (pas un protocole) et le shell qui vient se brancher dessus (via une couche d'abstraction, ou pas).
C'est certes beaucoup plus restrictif, mais ça limite les risques de divisions.
On verra bien ce que tout ça donnera !
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 1.
S'ils ont bien pris soin de standardiser cette partie et que les extensions customs de chaque DE ne se marchent pas dessus, ça peut en effet marcher.
Tout à fait. Mais en pratique personne ne le fait.
C'est là que le bât blesse selon moi, je n'aurais rien à redire si tout le monde avait étendu Weston plutôt que de refaire son propre truc.
Mir en lui même est indépendant et n'a pas besoin de Unity (cf les exemples fournis dans les sources).
Les deux bases de codes sont développées séparément, avec un couche de compatibilité entre les deux (Mir étant développé en C++ tandis que Unity 8 est développé en QML).
(http://www.jonobacon.org/2013/07/10/mir-for-everyone/)
Ce n'est pas non plus ce que j'avais compris lors de l'annonce initiale, mais il semble que Canonical ne cherche plus à restreindre Mir aux besoins de Unity.
(tant mieux mais trop tard ?)
Sachant qu'ils ce sont pris un vent et que personne ne c'est montré intéressé, ça risque de prendre du temps en effet.
Et il est clair qu'ils ne vont pas s'amuser à porter un DE si c'est pour que le patch ne soit pas accepté upstream après.
http://wayland.freedesktop.org/docs/html/sect-Protocol-Interfaces.html :
C'est ça qui me fait peur.
Xorg aussi utilise des extensions par rapport aux specs X11, mais vu que tout le monde l'utilise la question de la compatibilité entre les implémentation ne se pose pas.
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 1.
Sauf que sous l'ère X tout le monde utilise l'implémentation de référence tandis que tout porte à croire que personne n'utilisera Weston en pratique.
Je ne connais pas les tréfonds de la "libwayland-server" donc si tu me dis qu'elle définie suffisamment de code commun pour éviter tous les problèmes que j'évoque, je veux bien te croire.
Mais j'avais plutôt l'impression qu'elle se concentrait sur l'implémentation d'un système d'IPC tout en faisant l'impasse sur un modèle de driver (encore une fois, je me trompe peut-être).
[^] # Re: Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 1. Dernière modification le 18 juillet 2013 à 15:23.
Merci, tu mets le doigt sur ce que je disais en fait.
Sauf si je fais fausse route, cette FAQ est inexacte. Wayland ne réutilise pas les drivers ni l'infrastructure existante, Wayland n'est qu'un protocole, pas un morceau de code.
Weston, UNE implémentation, (qui était certes probablement unique à l'époque) réutilise en effet la pile graphique libre.
Ce que je veux dire c'est que l'ensemble des compositeurs Wayland ne semblent pas partager de code à ce niveau (l'interface) et que c'est selon moi extrêmement casse gueule.
De ce que je sais les pilotes proprios ont besoin d'une interface spécifique car ils ne peuvent pas s'intégrer dans KMS/GEM &co pour des raisons de licence.
Ce qui va se passer selon moi c'est qu'un beau jour Canonical va publier un communiqué disant « on s'est mis d'accord avec AMD et Nvidia sur le support d'une API dans leurs drivers. Voici le header en question. ».
J'imagine déjà le bordel entre toutes les implémentations de Wayland.
(notez que la situation serait exactement la même si Canonical avait décider de faire son propre compositeur Wayland plutôt que Mir)
# Waylands et Mir ?
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 5.
Une chose me trouble depuis quelques temps.
Pour avoir suivi les discussions autours de Mir et Kubuntu, le truc qui en ressortait c'était « Ubuntu passe à Mir, ce qui n'empêche certes pas les dérivés d'utiliser Wayland. Par contre le truc absolument horrible c'est qu'on va perdre la possibilité de switcher de bureau depuis l'écran de login. Brûlons Canonical pour cette hérésie ! »
Seulement voila, Wayland n'est qu'un protocole et, que je sache, chaque gestionnaire de bureau implémente son propre compositeur en utilisant ses propres extensions.
Il me semble que KDE et Gnome ont eux aussi prévu d'utiliser un compositeur système pour gérer les sessions, ce qui implique de lancer le compositeur en question bien avant l'écran de login.
Du coup je doute fortement que les compositeurs seront (ou resteront) suffisamment compatibles entre eux pour permettre le switch des environnements de bureau.
Pour cette raison, entre autre, j'ai du mal comprendre pourquoi Wayland demande à tout le monde de ré-implémenter son propre compositeur.
De ce point de vue, l'approche Mir qui consiste à séparer l'implémentation du bureau du serveur d'affichage avec une couche de glue entre les deux me parait être conceptuellement plus intelligente.
C'est certes plus proche de l'infrastructure X actuelle, mais ça permet de factoriser beaucoup de code entre les DE (car oui, Mir en lui même n'est absolument pas spécifique à Unity, Canonical à même proposé son aide pour porter les autres shells).
Par exemple, si je ne m'abuse, quand les pilotes proprios vont supporter Mir, c'est bien chaque compositeur Wayland qui va devoir se rendre compatible indépendamment.
Bonjour les bugs entre les différentes implémentations. Et qu'est-ce qui nous dit qu'une appli Gnome continuera de fonctionner aussi bien sous Kwin si l'appli en question a été codée en suivant les spécificités de l'implémentation de Wayland faite par Gnome-Shell ?
Bref, je suis assez pessimiste sur l'avenir de tout ça et j'ai besoin d'être rassuré par des gens qui s'y connaissent.
À votre bon cœur messieurs dames !
# Contribution d'AMD
Posté par Malizor . En réponse au journal Rétro-ingénierie de la gestion d'énergie sur les cartes graphiques NVIDIA. Évalué à 4.
Justement, dans quelle mesure est-ce que l'énorme code dump d'AMD permettra d'aider à la rétro-ingénierie de la gestion de l'énergie chez Nvidia ?
Les infrastructures sont-elles très différentes ?
[^] # Re: X11 to Mir to X11
Posté par Malizor . En réponse au journal Des nouvelles de Mir.. Évalué à 2.
C'est ce que j'ai dit dans mon commentaire : le plan pour la 13.10 est d'avoir un fallback automatique vers X si le pilote utilisé ne supporte pas Mir.
[^] # Re: X11 to Mir to X11
Posté par Malizor . En réponse au journal Des nouvelles de Mir.. Évalué à 2.
Non, sous Ubuntu 13.10 c'est toute la session qui sera lancée sur Xmir.
Grosso modo, par rapport à la situation actuelle, cela revient juste à intercaler Mir entre le matériel et X.
Ce n'est sensé rien changer pour l'utilisateur si le pilote graphique utilisé est compatible (pilotes libres en fait).
Il y aura un fallback automatique vers le X « traditionnel » pour les pilotes proprios (qui seront compatibles Mir d'ici la 14.04).
Les problèmes de performance actuels sont des bugs, ils devraient être résolus ou au moins minimisés d'ici octobre.
Le but de cette intégration prématurée dans Ubuntu 13.10 est de s'assurer que l'ensemble soit parfaitement au point pour la prochaine LTS dans moins d'un an, au détriment (potentiel) de la stabilité de cette version intermédiaire.
[^] # Re: Paranoïa
Posté par Malizor . En réponse au journal Ubuntu vs les autres distributions GNU/Linux. Évalué à 9.
Ça s'appelle du marketing.
Quel serait l'intérêt de faire une annonce maintenant alors que la première version fonctionnelle d'Ubuntu Touch n'est pas prévue avant octobre et qu'il faudra ensuite compter jusqu'à 6 mois pour certifier le tout avant commercialisation ?
Concernant Mir, les raisons de son développement sont clairement indiquées dans le Wiki et dans les divers articles sur les blogs des développeurs.
L'objectif est simplement d'avoir un système qui soit parfaitement adapté aux besoins futurs d'Ubuntu/Unity, surtout en ce qui concerne les problématiques de convergence (le mot d'ordre est « no compromise »).
D'accord ou pas, c'est un autre problème. Mais je ne vois pas pourquoi il faudrait chercher une raison cachée alors que celles avancées par Canonical se tiennent.
[^] # Re: Unity
Posté par Malizor . En réponse au journal Ubuntu vs les autres distributions GNU/Linux. Évalué à 3. Dernière modification le 25 mai 2013 à 21:18.
Le software-center est aussi dans les dépôts Debian.
De fait, il n'est donc pas spécifique à Ubuntu.
[^] # Re: Steam
Posté par Malizor . En réponse au journal Ubuntu vs les autres distributions GNU/Linux. Évalué à 10.
Pas forcément.
Valve utilise SDL pour tous ses portages.
SDL supporte X, Wayland et supportera bientôt Mir (le portage est en cours).
Du coup, à priori, il suffirait que Valve mette à jour ses jeux en intégrant une version récente de SDL pour que ceux-ci fonctionnent partout.
De toute façon, les appli X tourneront encore sous Wayland (via Xwayland) et sous Mir (Xmir). Du coup il y aura toujours au moins une compatibilité à ce niveau et donc Valve ne sera même pas obligé de changer quoi que ce soit à ses portages actuels.
# Paranoïa
Posté par Malizor . En réponse au journal Ubuntu vs les autres distributions GNU/Linux. Évalué à 7.
Faux. Cela fait plusieurs mois maintenant qu'on sait qu'ils ont trouvé au moins un partenaire.
Le premier modèle d'Ubuntu phone ne devant pas sortir avant une dizaine de mois, il est probable que son nom ne soit dévoilé que début 2014 (histoire de faire le buzz près de la date de sortie).
Mark en a reparlé dans une interview récente.
Je ne vois pas ce que ça leur apporterait.
Se fermer de la sorte reviendrait à se passer de communauté, ce qui les priverait d'une main d'œuvre bon marché et démotiverait probablement une bonne partie de leurs développeurs (qui sont issus de cette communauté).
D'ailleurs, le fait que les core-apps d'Ubuntu Touch soient développées uniquement par la communauté montre bien qu'ils ne cherchent pas à s'isoler.
Pour revenir sur Mir, il sera installable en parallèle des divers compositeurs Wayland et de X.
Du coup on a clairement vu pire en ce qui concerne l'incompatibilité avec les autres distros, non ?
Donc, je pose la question : pourquoi vouloir absolument chercher le mal partout ? Et si les développeurs d'Ubuntu ne créaient que les outils qu'ils estiment nécessaire, sans arrière pensée diabolique ?
[^] # Re: gros deb?
Posté par Malizor . En réponse au journal Un nouveau format de paquets pour Ubuntu. Évalué à 4.
Réponse dans la FAQ:
Dans la langue des grenouilles, ça dit grosso-modo que LXC c'est bien mais pas vraiment adapté à ce cas d'utilisation. On pourrait toujours faire avec mais il se trouve qu'AppArmor répond apparemment à tous les besoins et qu'il est intégré à Ubuntu depuis plus de 5 ans (donc éprouvé).
[^] # Re: gros deb?
Posté par Malizor . En réponse au journal Un nouveau format de paquets pour Ubuntu. Évalué à 7. Dernière modification le 10 mai 2013 à 20:30.
Au contraire, ce format se voulant plus simple il devrait être plus facilement compatible avec les autres distributions.
D'ailleurs, on est même pas sûr qu'il s'agira réellement d'un nouveau format. Il y a des discussions intéressantes sur la mailing-list avec des développeurs de Listaller, 0install et Nix.
Le PoC développé par Colin Watson est certes original, mais il a un avantage que les autres n'ont pas : il réutilise le code de dpkg, ce qui simplifie les choses et peu potentiellement permettre une meilleure intégration avec les outils d'administration Debian usuels.
On verra bien ce qui en ressortira. Il y aura une session consacrée à ce sujet la semaine prochaine lors de l'UDS.
[^] # Re: gros deb?
Posté par Malizor . En réponse au journal Un nouveau format de paquets pour Ubuntu. Évalué à 6. Dernière modification le 10 mai 2013 à 20:21.
Ce n'est pas du tout le même usage.
Les paquets .deb ont pour vocation d'être intégrés dans des dépôts et sont donc « audités » manuellement par des tiers.
C'est un excellent système pour empaqueter un OS, mais ça pose de gros problèmes quand on commence à vouloir permettre à n'importe qui de soumettre son application et de la publier le plus automatiquement possible.
D'où l'idée d'un format de paquet beaucoup plus bête qui ne nécessiterai pas forcément d'être root, qui se contenterait de copier les fichiers d'une appli dans un répertoire unique (pas d'interférence avec le reste du système), qui n'autoriserait pas le moindre script de pre/post install et qui n'aurait qu'une prise en charge minimaliste des dépendances (du genre juste dépendre d'une version du SDK).
Donc voilà. Des besoins différents impliquent des solutions différentes. Et ce (potentiellement) nouveau format n'est pas du tout fait pour remplacer APT.
[^] # Re: Weston utilisable...
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 4.
Sauf que ça n'a jamais été la raison principale pour développer Mir.
Les développeurs n'ont jamais dit qu'il était impossible d'adapter Wayland (protocole + Weston) à leurs besoins (cf les nombreux articles sur les blogs des développeurs).
Ils ont juste considéré qu'une solution maison leur profiterai d'avantage à plus ou moins long terme, surtout en terme de souplesse.
On peut être d'accord (ou pas) et se demander s'ils prendraient la même décision aujourd'hui au regard des récentes avancés des projets Wayland.
Mais ce qui est fait est fait et le développement de Mir avance aujourd'hui (enfin) en toute transparence, que ce soit au niveau du code que des discussions techniques.
# P. S. Jenkins
Posté par Malizor . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 10.
Pour information, ce fameux « P. S. Jenkins » est un bot ;-)
C'est lui qui s'occupe de compiler et de lancer les tests unitaires automatiquement sur chaque nouvelle branche et c'est lui qui s'occupe de merger ces branches dans la branche principale (d'où son « score de contribution » élevé dans Launchpad).