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

seb24 · Le 29/07/2013, à 16:54

Tiens 3 articles sur le portage de XBMC sur Wayland et Mir:
Portage de XBMC sur Wayland : http://smspillaz.wordpress.com/2013/07/ … -take-two/
Portage de XBMC sur Mir episode 1 : http://smspillaz.wordpress.com/2013/07/23/xbmc-on-mir/
Portage de XBMC sur Mir Episode 2 : http://smspillaz.wordpress.com/2013/07/ … lient-api/

On pourrait résumer par : pas de problèmes circulez y'a toujours rien a voir.

Keiser · Le 29/07/2013, à 19:47

Cool,

Tout est pour le mieux dans le meilleur des mondes, Canonical avait grave raison et tout était justifié.

Tu peux te le mettre en signature si tu veux.

AGui · Le 30/07/2013, à 00:15

seb24 a écrit :

On pourrait résumer par : pas de problèmes circulez y'a toujours rien a voir.

On pourrait résumer par : certaines applications comme XBMC ne reposent pas sur un toolkit et doivent être portés vers une pile graphique spécifique. Certes le portage n'est pas plus compliqué pour Mir que pour Wayland, mais c'est toujours une charge supplémentaire pour un développeur qui voudrait par exemple porter son application Windows vers Linux. D'où risque de fragmentation de la plateforme Linux et de perte d'attractivité. Déjà que les parts de marché de toutes les distributions GNU/Linux sont faibles en comparaison de Windows et Mac OS, s'il faut en plus développer une version pour Ubuntu et une version pour les autres, le retour sur investissement sera encore plus faible. Sans parler des projets qui n'ont pas l'envergure de XBMC et qui n'auront simplement pas les moyens humains de développer et de maintenir deux versions. La tentation pourrait être de rester sur Xorg, le plus petit dénominateur commun. Donc on se trainerait Xorg plus longtemps, sans pouvoir profiter pleinement des avantages qu'apportent Mir et Wayland.

Tant qu'une des deux solutions ne se sera pas imposée, ou tant qu'il n'y aura pas une couche de compatibilité entre les deux, ce problème se posera.

seb24 · Le 30/07/2013, à 08:01

AGui a écrit :

seb24 a écrit :
On pourrait résumer par : pas de problèmes circulez y'a toujours rien a voir.
On pourrait résumer par : certaines applications comme XBMC ne reposent pas sur un toolkit et doivent être portés vers une pile graphique spécifique. Certes le portage n'est pas plus compliqué pour Mir que pour Wayland, mais c'est toujours une charge supplémentaire pour un développeur qui voudrait par exemple porter son application Windows vers Linux. D'où risque de fragmentation de la plateforme Linux et de perte d'attractivité. Déjà que les parts de marché de toutes les distributions GNU/Linux sont faibles en comparaison de Windows et Mac OS, s'il faut en plus développer une version pour Ubuntu et une version pour les autres, le retour sur investissement sera encore plus faible. Sans parler des projets qui n'ont pas l'envergure de XBMC et qui n'auront simplement pas les moyens humains de développer et de maintenir deux versions. La tentation pourrait être de rester sur Xorg, le plus petit dénominateur commun. Donc on se trainerait Xorg plus longtemps, sans pouvoir profiter pleinement des avantages qu'apportent Mir et Wayland.
Tant qu'une des deux solutions ne se sera pas imposée, ou tant qu'il n'y aura pas une couche de compatibilité entre les deux, ce problème se posera.

Les 3 articles montrent justement le contraire. Pas d'effort important pour faire un backend Mir une fois que le backend Wayland a été fait. Du coup je ne vois pas pourquoi ils devraient se traîner avec X. Et ça ne va justement pas dans le sens d'une fragmentation.

Dernière modification par seb24 (Le 30/07/2013, à 08:53)

AGui · Le 30/07/2013, à 12:35

On a pas lu les mêmes articles alors !

XBMC on Mir a écrit :

This was actually quite straightforward, and took about the same amount of time to get to same point of completeness as it did for Wayland support.

Si je comprends bien l'anglais, il dit que le portage a été assez simple, et que ça lui a pris autant de temps pour Mir que pour Wayland. Pas moins parce qu'il avait déjà fait le portage vers Wayland. Dans le second lien, il explique aussi que Mir est le seul serveur graphique à permettre un fonctionnement asynchrone qui ne freeze pas l'application, grâce à l'utilisation de threads pour le traitement des inputs, mais que ça doit être implémenté dans l'application. D'ailleurs ce serait intéressant d'avoir un avis d'expert sur ce point. J'ai pas les compétences pour juger des avantages et des inconvénients de ce fonctionnement par rapport à un fonctionnement synchrone. On tient peut-être là un vrai différence technique entre les deux.

Dans tous les cas, même si l'effort est minimal, il faut quand même lire 2 documentations, comprendre le fonctionnement des 2 systèmes, écrire 2 codes, les tester sur 2 systèmes différents, et maintenir 2 codes, suivre le développement des 2 projets pour prendre en compte les éventuelles évolutions, etc... Ce sera toujours du temps perdu par rapport à un standard unique. C'est ça que j'appelle de la fragmentation.

Elzen · Le 31/07/2013, à 09:28

AGui a écrit :

Dans tous les cas, même si l'effort est minimal, il faut quand même lire 2 documentations, comprendre le fonctionnement des 2 systèmes, écrire 2 codes, les tester sur 2 systèmes différents, et maintenir 2 codes, suivre le développement des 2 projets pour prendre en compte les éventuelles évolutions, etc... Ce sera toujours du temps perdu par rapport à un standard unique. C'est ça que j'appelle de la fragmentation.

Genre, de la même façon qu'il faut déjà lire les specs deb d'un côté et les specs rpm de l'autre (sans compter le reste) pour faire un paquet correct ?

Sinon, y a une solution simple : publier le code sous licence libre et laisser les gens motivés faire le portage.

Smon · Le 31/07/2013, à 10:31

Pareil pour Alsa / OSS / PulseAudio.

Pareil pour GTK / Qt / Tout le tralala

Pareil pour Linux / BSD

Bref, finalement on reste dans ce qui a toujours été fait dans le monde du libre : des projets similaires mais différents.

Mais bon, comme là c'est Canonical et que Canoncal c'est le mal ...

Dernière modification par Smon (Le 31/07/2013, à 10:32)

seb24 · Le 31/07/2013, à 11:13

Elzen a écrit :

AGui a écrit :
Dans tous les cas, même si l'effort est minimal, il faut quand même lire 2 documentations, comprendre le fonctionnement des 2 systèmes, écrire 2 codes, les tester sur 2 systèmes différents, et maintenir 2 codes, suivre le développement des 2 projets pour prendre en compte les éventuelles évolutions, etc... Ce sera toujours du temps perdu par rapport à un standard unique. C'est ça que j'appelle de la fragmentation.
Genre, de la même façon qu'il faut déjà lire les specs deb d'un côté et les specs rpm de l'autre (sans compter le reste) pour faire un paquet correct ?
Sinon, y a une solution simple : publier le code sous licence libre et laisser les gens motivés faire le portage.

Oui on en revient au principal : que ce soit libre.
Je rajouterais en plus : avoir des specs/APIs et documentation suffisamment claire pour encourager les gens a le faire. Ce qui a l'air d’être le cas.

De ce que je comprends des articles du dev, les choses ont l'air d’être en plus assez similaires entre Wayland et Mir ou en gros il faut remplacer les fonctions wayland_xxx par Mir_xxx . J'ai vu ca aussi pour un debut de portage de GTK sous Mir ou le gars a repris visiblement le travail réalisé sur Wayland et l'un des commit consiste juste a renommer certaines fonctions.

Smon · Le 31/07/2013, à 11:38

Ouais en gros tu bricoles une factory et c'est bon quoi.

AGui · Le 31/07/2013, à 11:59

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

Je fais partie de ceux qui aimerait qu'un seul format de paquet soit adopté par tout le monde. Mais il existe des outils pour les développeurs pour automatiser la création des différents paquets (Open Build Service par exemple), et en tant qu'utilisateur, c'est aussi possible de convertir un deb en rpm et inversement avec alien.

Idem pour les serveurs audio, j'ai jamais fait l'expérience d'une application qui ne sort pas de son parce que j'utilise pas le bon serveur audio. Soit il y a une couche de compatibilité, soit tu peux en utiliser plusieurs en même temps.

Pour les toolkits, ça n'a rien à voir. Aux dernières nouvelles, je peux utiliser plusieurs applications écrites avec des toolkits différents en même temps. Ca ne fait pas parti des éléments qui définissent Linux en tant que plateforme.

La comparaison la plus pertinente, c'est en effet Linux / BSD, même s'il existe une couche de compatibilité qui permet à BSD d'exécuter des binaires Linux. Et je regrette justement que Ubuntu veuille se séparer de Debian et du reste des distributions Linux. Je pense pas que ce soit bénéfique pour eux.

Prenons un logiciel comme Maya par exemple. Autodesk ne propose du support que sur RHEL et Fedora (Red Hat est leader sur le marché des workstation, de loin). Vu qu'ils ne supportent pas Ubuntu, pourquoi développer un backend pour Mir ? Actuellement, tu peux quand même utiliser Maya sous Ubuntu en bidouillant un peu (sans support officiel). S'ils passent à Wayland, ce ne sera plus possible, à moins d'une couche de compatibilité. C'est ce genre d'application qui est susceptible de rester sur X encore plus longtemps que s'il n'y avait eu qu'une seule pile graphique de nouvelle génération.

Smon · Le 31/07/2013, à 12:18

AGui a écrit :

Oui il y a d'autres projets qui font doublon, et c'est dommage.

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.

Mais ce n'est pas une raison d'en rajouter.

Bien au contraire !

Je fais partie de ceux qui aimerait qu'un seul format de paquet soit adopté par tout 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.

Mais il existe des outils pour les développeurs pour automatiser la création des différents paquets (Open Build Service par exemple), et en tant qu'utilisateur, c'est aussi possible de convertir un deb en rpm et inversement avec alien.

Et il est possible de créer des couches de compatibilité. De toutes façon, un application bien développée utilise des mapper et des adapters pour dialoguer avec un programme ou un precessus indépendant. Ça lui permet de ne pas être tributaire d'une application en particulier ou d'une évolution majeure qui péterait tout.

Idem pour les serveurs audio, j'ai jamais fait l'expérience d'une application qui ne sort pas de son parce que j'utilise pas le bon serveur audio. Soit il y a une couche de compatibilité, soit tu peux en utiliser plusieurs en même temps.

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

Pour les toolkits, ça n'a rien à voir. Aux dernières nouvelles, je peux utiliser plusieurs applications écrites avec des toolkits différents en même temps. Ca ne fait pas parti des éléments qui définissent Linux en tant que plateforme.

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.

La comparaison la plus pertinente, c'est en effet Linux / BSD, même s'il existe une couche de compatibilité qui permet à BSD d'exécuter des binaires Linux. Et je regrette justement que Ubuntu veuille se séparer de Debian et du reste des distributions Linux. Je pense pas que ce soit bénéfique pour eux.

Ubuntu ne veut pas se séparer de Debian ni des autres distribs. Ubuntu utilises ce dont il a besoin, c'est tout.

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

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 ?

Prenons un logiciel comme Maya par exemple. Autodesk ne propose du support que sur RHEL et Fedora (Red Hat est leader sur le marché des workstation, de loin). Vu qu'ils ne supportent pas Ubuntu, pourquoi développer un backend pour Mir ? Actuellement, tu peux quand même utiliser Maya sous Ubuntu en bidouillant un peu (sans support officiel). S'ils passent à Wayland, ce ne sera plus possible, à moins d'une couche de compatibilité. C'est ce genre d'application qui est susceptible de rester sur X encore plus longtemps que s'il n'y avait eu qu'une seule pile graphique de nouvelle génération.

Tu veux que je te dises quoi ? Autodesk a décidé de n'éditer que pour RedHat, c'est leur choix. Tu veux l'utiliser, tu utilises du RedHat, ou tu ne l'utilises pas.

seb24 · Le 31/07/2013, à 12:22

Il me semble que Maya utilise Qt non ? En théorie la majorité des applications modernes utilisent un toolkit. Donc sauf cas spéciaux le problème ne devrait pas se poser je pense.
l'Autre option serait de développer un backend wayland pour les applications non compatible restantes.

Haleth · Le 31/07/2013, à 12:34

Ouais, et puis de toutes façons, ca va être un bon produit qui va être utilisable facilement par tous.
Comme pour unity, le portage vers le monde extérieure va être rapide et simple.

La seule vérité de ce topic est la suivante:

Canoncal c'est le mal ...

Ouais en gros tu bricoles une factory et c'est bon quoi.

T'as tout compris.
On va commencer par utiliser une demi-douzaine de design pattern, ensuite on y verras plus clair.

Pour commencer, j'pense qu'un observer de factory de singleton est nécessaire.

seb24 · Le 31/07/2013, à 12:36

Haleth a écrit :

Ouais, et puis de toutes façons, ca va être un bon produit qui va être utilisable facilement par tous.
Comme pour unity, le portage vers le monde extérieure va être rapide et simple.

On est pas dans la même dynamique visiblement pour Mir par rapport à Unity

Smon · Le 31/07/2013, à 13:03

Et surtout les bases de la conception d'Unity sont en constante évolution. Et juger un projet alors qu'il ne s'est même pas encore stabilisé dans ses fondements, c'est quand même un peu gonflé ...

Enfin, on n'est plus à ça prêt hein ... Y'a même eu un dev de Kwin pour dire que la GPL c'est le mal parce que Mir l'utilise alors bon

Dernière modification par Smon (Le 31/07/2013, à 13:04)

Haleth · Le 31/07/2013, à 13:04

C'est valable comme argument ?
Des systèmes qui évoluent, y'en a plein.

Spitfire 95 · Le 31/07/2013, à 13:16

Smon vient de reconnaitre qu'Unity, le DE par défaut depuis la 11.04, n'est aujourd'hui, à l'aube de la 13.10, toujours pas stabilisé, en gros.

Dernière modification par Spitfire 95 (Le 31/07/2013, à 13:17)

Smon · Le 31/07/2013, à 13:19

Je n'ai jamais dit que le développement d'Unity était stabilisé.

Smon · Le 31/07/2013, à 13:20

Haleth a écrit :

C'est valable comme argument ?
Des systèmes qui évoluent, y'en a plein.

Le rapport ?

Spitfire 95 · Le 31/07/2013, à 13:22

Que ces projets qui évoluent sont pourtant portés sous plusieurs distributions sans problèmes ?

Smon a écrit :

Je n'ai jamais dit que le développement d'Unity était stabilisé.

C'est bien ce que je dis

Smon · Le 31/07/2013, à 13:43

Je n'ai pas dit "Unity ne peut pas être porté parce qu'il évolue".
D'ailleurs je n'ai pas dit qu'il ne pouvait pas être porté tout court ...

En revanche, j'ai dit que les "bases de la conception d'Unity sont en constante évolution".
Reprocher à un projet qui n'a même pas encore stabilisé ses bases de ne pas faire en sorte d'être facilement portable, c'est juste une grosse blague.

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

En fait on est dans deux cas différents :
- Unity c'est fait pour fonctionner sur Ubuntu. Jusqu’à présent il n'y a pas eu d'effort pour qu'il puisse être porte sur d'autres environnement de manière simple. C'est pas impossible mais ça demande visiblement pas mal de travail. Unity 8 je pense sera plus simple a porter.
- Mir a été fait pour ne pas dépendre exclusivement d'Ubuntu. Donc y'a pas mal de doc, une API pour que les gens puissent porter des backend et un debut de docs pour pouvoir l'utiliser sur d'autres distributions. Le tout devrait être stabiliser d'ici Octobre.

Lork Scorguar · Le 31/07/2013, à 14:03

seb24 a écrit :

En fait on est dans deux cas différents :
- Unity c'est fait pour fonctionner sur Ubuntu. Jusqu’à présent il n'y a pas eu d'effort pour qu'il puisse être porte sur d'autres environnement de manière simple. C'est pas impossible mais ça demande visiblement pas mal de travail. Unity 8 je pense sera plus simple a porter.

Donc ca doit être pour ça qu'il y a Unity sur Arch, Fedora, etc?
Unity tout comme Mir sont portables, en grande partie parce que ce sont des logiciels libres, donc faut arréter de dire que c'est chiant, c'est le mal, c'est spécifique à Ubuntu.
Canonical a des besoins, l'existant n'y répond pas donc ils créent. Ca ne veut pas dire pour autant que ça n'est pas libre, pas compatibles etc.

Qu'on aime pas Unity/Mir etc c'est un fait, chacun son opinion mais ça n'empeche que Canonical fait des efforts et simplifie grandement l'utilisationn de GNU/Linux par les débutant apportant ainsi de nombreux utilisateurs déçu de Windows.
Alors oui on ne pourrait avoir qu'un seul serveur graphique. Mais s'il y a des besoins/envies différentes, le libre permet justement de faire autrement.

Dernière modification par Lork Scorguar (Le 31/07/2013, à 14:06)

seb24 · Le 31/07/2013, à 14:06

Lork Scorguar a écrit :

seb24 a écrit :
En fait on est dans deux cas différents :
- Unity c'est fait pour fonctionner sur Ubuntu. Jusqu’à présent il n'y a pas eu d'effort pour qu'il puisse être porte sur d'autres environnement de manière simple. C'est pas impossible mais ça demande visiblement pas mal de travail. Unity 8 je pense sera plus simple a porter.
Donc ca doit être pour ça qu'il y a Unity sur Arch, Fedora, etc?
Unity tout comme Mir sont portables, en grande partie parce que ce sont des logiciels libres, donc faut arréter de dire que c'est chiant, c'est le mal, c'est spécifique à Ubuntu.
Canonical a des besoins, l'existant n'y répond pas donc ils créent. Ca ne veut pas dire pour autant que ça n'est pas libre, pas compatibles etc.

De ce que j'avais compris pour Unity il y avait pas mal de lib Gnome patches. Patch nom dispo en upstream. Du coup ça pouvait poser des problèmes. Mais a vrai dire je m'y suis pas plus intéressé.

Lork Scorguar · Le 31/07/2013, à 14:08

Patchs non dispos en upstream en grande partie parce l'upstream les refuse. Donc ça n'est pas la faute que Canonical si Unity est plus dur à porter sur les autres distributions.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#551 Le 29/07/2013, à 16:54

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

#552 Le 29/07/2013, à 19:47

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

#553 Le 30/07/2013, à 00:15

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

#554 Le 30/07/2013, à 08:01

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

#555 Le 30/07/2013, à 12:35

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

#556 Le 31/07/2013, à 09:28

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

#557 Le 31/07/2013, à 10:31

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

#558 Le 31/07/2013, à 11:13

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

#559 Le 31/07/2013, à 11:38

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

#560 Le 31/07/2013, à 11:59

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

#561 Le 31/07/2013, à 12:18

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

#562 Le 31/07/2013, à 12:22

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

#563 Le 31/07/2013, à 12:34

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

#564 Le 31/07/2013, à 12:36

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

#565 Le 31/07/2013, à 13:03

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

#566 Le 31/07/2013, à 13:04

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

#567 Le 31/07/2013, à 13:16

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

#568 Le 31/07/2013, à 13:19

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

#569 Le 31/07/2013, à 13:20

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

#570 Le 31/07/2013, à 13:22

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

#571 Le 31/07/2013, à 13:43

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

#572 Le 31/07/2013, à 13:57

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

#573 Le 31/07/2013, à 14:03

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

#574 Le 31/07/2013, à 14:06

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

#575 Le 31/07/2013, à 14:08

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

Pied de page des forums