Wayland et Weston 1.4

Posté par ariasuni le 07 février 2014 à 17:03. Édité par Davy Defaud, antistress, palm123, EdB, jcr83, Jiehong, reno, Nÿco, Johann Ollivier-Lapeyre, Melkor73, Xavier Teyssier, Nils Ratusznik et Goth. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

103

fév.

2014

Wayland et Weston sont sortis en version 1.4 le jeudi 24 janvier. Sous GNU/Linux et BSD (et d’autres…), lorsqu’une application veut afficher quelque chose à l’écran, elle doit utiliser le protocole X11 pour communiquer avec X.Org, qui se charge de faire l’affichage. Or, ces derniers sont très vieux et ne sont pas adaptés au matériel moderne.

X.Org a été conçu à une époque où l’on utilisait peu la carte graphique. Aujourd’hui, nos navigateurs Web (rendu HTML, CSS, JavaScript…) et nos interfaces graphiques (Qt, Cairo…) ont de nombreuses occasions de solliciter celle‐ci, sans compter que l’arrivée de Steam a permis l’arrivée de nombreux titres pour notre système d’exploitation favori.

Côté sécurité, X.Org est une vraie passoire : écrire un enregistreur de clavier est un jeu d’enfant… Wayland devrait changer ça, mais cela ne signifie pas la fin des failles. Par exemple, l’arrivée de WebGL (et bientôt de WebGL 2 ! cf. ici et là) dans nos navigateurs Web ouvre potentiellement de nouvelles failles dans nos systèmes, d’autant plus que les pilotes graphiques eux‐mêmes n’ont souvent pas été conçus dans une optique principale de sécurité, mais c’est un autre problème.

Mais alors, que sont Wayland et Weston ?

Sommaire

Rappels sur Wayland et Weston
Prise en charge de Wayland
- Boîtes à outils
- Environnements de bureau
Nouveautés
- Wayland
- Weston
La suite

Rappels sur Wayland et Weston

Wayland est un protocole de serveur d’affichage destiné à remplacer X11 (sans ses défauts). Il a le soutien officiel des développeurs X11/X.Org. Weston est une implémentation de référence de Wayland (pour la démonstration, mais il se pourrait qu’on le retrouve utilisé tel quel, notamment dans l’embarqué).

Côté développeur, seules quelques briques logicielles devront être adaptées (toutes les bibliothèques d’interfaces graphiques et certaines applications utilisant des fonctions graphiques de bas niveau). Une particularité de Wayland est que le protocole doit être implémenté dans le compositeur (qui est souvent également le gestionnaire de fenêtres : Kwin, Mutter, etc.), ce qui permet d’éviter les coûteuses communications entre le serveur X et le compositeur pour le rendu. Le protocole est également plus simple.

Les développeurs de Wayland et Weston sont majoritairement des développeurs de X.Org. Ils sont donc tout à fait au courant des failles de X.Org, et ne veulent pas les corriger car cela impliquerait un travail titanesque, et un changement d’API considérable qui obligerait beaucoup de développeurs à récrire leurs bibliothèques et applications pour prendre en compte les modifications. En repartant de zéro, il est possible de construire un modèle de sécurité solide. [Source]

Enfin, il sera toujours possible d’utiliser les applications qui n’auront pas migré grâce à XWayland (qui permet de faire tourner X.Org à l’intérieur de Wayland). Malgré l’utilisation d’une couche supplémentaire (Wayland + XWayland au lieu de X.Org tout seul), on attend des performances similaires voire meilleures (car on profite des améliorations de Wayland).

Pour mieux comprendre ce que sont Wayland et Weston, vous pouvez lire la série de dépêches intitulée X.Org est mort, vive Wayland !, dont les liens sont disponibles en première partie de dépêche.

OpenGL

Les bibliothèques et pilotes OpenGL sous GNU/Linux dépendent de X.Org, c’est pourquoi Wayland n’utilise pas OpenGL mais OpenGL ES (plus souvent implémenté pour l’instant dans les pilotes graphiques des puces pour smartphones et tablettes. Toutefois, les puces Intel, par exemple, bénéficient de la prise en charge d’OpenGL ES à partir des processeurs graphiques de génération Sandy Bridge, c’est‐à‐dire à partir des puces graphiques Gen6, dans la nomenclature du fondeur). À long terme, on pourra utiliser de l’OpenGL « classique » sous Wayland.

Linux

Pour afficher des messages à l’écran, le noyau était déjà obligé de s’occuper de la gestion du mode d’affichage (résolution, fréquence de rafraîchissement, profondeur de couleur), qui était alors réinitialisé lors du chargement du pilote pour X.Org. Au final, il y avait des problèmes de lenteur lors du changement entre session graphique et terminaux virtuels, et de mauvaises résolutions dans ces derniers.

KMS a alors été intégré au noyau pour gérer cela bien avant le lancement de la session graphique, ce qui est non seulement plus efficace, mais évite en plus les clignotements lors du chargement du pilote. Il y a donc une partie du pilote pour le noyau (pilotes [nom_du_pilote]-dri) et la partie X.Org (xf86-video-[nom_du_pilote_]).

Avec Wayland, les pilotes X.Org ne seront plus nécessaires, réduisant la quantité de code à maintenir.

Démonstration

Il y a plein de vidéos de démonstration disponibles, mais il y en a une en particulier que je tiens à vous montrer, car elle est vraiment originale. En effet, c’est la vidéo d’un compositeur Wayland un peu spécial…

Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)

Prise en charge de Wayland

Boîtes à outils

Wayland est déjà pris en charge par Qt depuis la version 5, GTK depuis la version 3, Clutter, la SDL, et les EFL. Il faut cependant garder à l’esprit que Wayland est toujours en développement et que la gestion de Wayland n’a pas été testée à grande échelle. Il ne faut donc pas attendre la même stabilité que des systèmes qui sont basés sur un protocole inchangé depuis plusieurs dizaines d’années, mais ça fonctionne et le plus gros du travail a été fait.

Environnements de bureau

La gestion de Wayland dans KDE est prévue pour l’été 2014, à partir de la sortie de KDE Frameworks 5. KDE Frameworks 5 est la nouvelle génération de kdelibs (migration vers Qt5, nettoyage de code, modularisation), commencée au printemps 2011. Toute application KDE utilisant les nouvelles bibliothèques ne nécessitera que peu de changements pour fonctionner, à l’exception notable de Kwin qui utilise de nombreuses fonctions de bas niveau.

GNOME Shell, l’environnement de bureau des canards, gère Wayland depuis GNOME 3.10, mais on attend une bien meilleure prise en charge pour GNOME 3.12.

Canonical n’a pas l’intention d’ajouter la prise en charge de Wayland à Unity. En effet, les gens de Canonical développent leur propre solution pour remplacer X.Org : Mir.

Enlightenment prend partiellement en charge Wayland depuis la version 0.18, la prise en charge complète arrivera avec la version 0.19.

Hawaii est un nouvel environnement de bureau, parce que les goûts et les couleurs… Il fait partie d’un projet de nouveau système d’exploitation, Maui, conçu à l’image d’elementary OS et Pantheon (et Ubuntu/Unity ?) pour réaliser un système cohérent et sans problèmes. Il est conçu sur des technologies modernes telles que systemd, Wayland et Qt5 (là où elementary OS a fait le choix de technologies GNOME, comme GTK).

Une très bonne nouvelle pour les utilisateurs de gestionnaires de fenêtres légers, il sera possible de migrer vers Wayland sans écrire un compositeur complet grâce à SWC, une bibliothèque qui fait moins de 6 000 lignes de code et qui « a pour but d’embarquer le strict minimum pour afficher des fenêtres sur l’écran. »

Nouveautés

Voici une liste des nouveautés introduites au sein de Wayland et Weston, traduction de l’annonce sur la liste de diffusion du projet.

Wayland

Protection des tampons SHM contre le signal SIGBUS.
Des fonctions utilitaires ont été ajoutées par Neil Roberts pour aider les compositeurs à se protéger contre des clients dysfonctionnels ou malveillants qui tronqueraient le fichier sous‐jacent aux tampons SHM et déclencheraient un signal SIGBUS.
Le protocole Subsurfaces a intégré le dépôt Wayland et fait donc partie officiellement du protocole Wayland (Pekka Paalanen). Une description est disponible ici : http://ppaalanen.blogspot.fr/2013/11/sub-surfaces-now.html.
wl_proxy_set_queue() accepte une file d’attente (queue, en anglais) NULL pour se réinitialiser sur celle par défaut. (Neil Roberts).
Quelques corrections de bogues, notamment une situation de concurrence entre wl_proxy_create() et wl_proxy_marshal().
Quelques améliorations sur les messages d’erreur liés au scanneur et des ajustements de la documentation.

Weston

Des boutons dans les fenêtres XWayland et des décorations correctes pour le compositeur imbriqué (moteur Wayland). (Jason Ekstrand)
Conversion de gl-render en module chargeable et ajout de la possibilité de passer de pixman à gl-render durant l’exécution. Cela permet un chargement du compositeur plus rapide, puisque gl-render et EGL + GLES 2 peuvent être chargés et initialisés plus tard lors de la phase de démarrage (Ander Conselvan de Oliveira).
Utilisation de logind pour l’accès privilégié (accès à la carte graphique — via le composant DRM du noyau — et aux périphériques d’entrée). Weston peut donc utiliser KMS sans bidouillage. (David Herrmann)
Meilleure gestion du débranchement de sortie. En effet, cela vautrait Weston car le débranchement de sortie (moniteur) n’était simplement pas pris en charge. Nous nettoyons désormais les choses de façon appropriée et nous faisons revenir les fenêtres dans la région visible quand leur sortie est débranchée. (Ander Conselvan de Oliveira et Xiong Zhang)
Animation du focus du clavier et exposay (aperçu de fenêtres de type exposé) contribué par Collabora.
Meilleure prise en charge des écrans tactiles, incluant le toucher‐déplacer et le toucher-activer pour les surfaces, et le glisser‐déposer. (Xiong Zhang)
Début du travail sur le protocole xdg-shell. C’est une tentative plus formelle de développer un protocole pour l’interaction entre les applications et un environnement de bureau. Le protocole wl_shell actuellement présent dans Wayland a toujours été un développement temporaire pour aider au démarrage de la prise en charge par les bibliothèques d’interfaces graphiques. Maintenant que GNOME Shell migre sur Wayland, nous avons un environnement de bureau complet pour orienter le travail et nous pouvons commencer les choses sérieuses. (Jasper St. Pierre, Rafael Antognolli)
Passage de tampon à travers un compositeur imbriqué. Nous avons spécifié une nouvelle extension EGL qui permet de faire passer des tampons à travers un compositeur imbriqué. Ceci permet au compositeur imbriqué de ne pas faire le rendu et à la place de présenter le contenu au compositeur sous‐jacent, en utilisant une subsurface ou autre (Neil Roberts).
Protocole de rognage et de mise à l’échelle. Ce protocole, que nous avions initialement mis en place dans Weston, permet à un client de spécifier que seul un sous‐rectangle de sa surface doit être présenté, et potentiellement agrandi. (Jonny Lamb et Pekka Paalanen)
Dans weston-terminal, on peut utiliser Ctrl + Maj + ↑/↓ pour défiler et voir l’historique de la sortie du terminal. Ajout d’un menu contextuel pour un accès simple au copier, coller et nouveau terminal (qui ont toujours été accessibles via Ctrl-Maj-C/V/N). (Kristian Høgsberg). Prise en charge de la sélection avec un écran tactile. (Xiong Zhang)

La suite

DRI3, qui vient d’intégrer la version 1.15 du serveur X.Org, ne figure pas encore dans cette livraison, et nous attendons symétriquement l’intégration de XWayland dans le serveur X qui, comme nous l’avons vu, permettra à Wayland de faire tourner les applications X11 classiques qui n’auront pas été adaptées.

Aller plus loin

Articles sur LinuxFr.org en rapport avec Wayland (318 clics)
Page Wikipédia sur Wayland (248 clics)
X.Org est mort, vive Wayland ! (463 clics)
X.Org est mort, vive Wayland ! (2) (141 clics)
X.Org est mort, vive Wayland ! (3) (201 clics)
Site de Wayland (sur freedesktop.org) (212 clics)
Vidéo d’Intel faisant la promotion de Wayland (248 clics)
Page Wikipédia sur la pile graphique de Linux (181 clics)

# vidéo pas si nouvelle

Posté par ZeroHeure le 08 février 2014 à 00:47. Évalué à 1. Dernière modification le 08 février 2014 à 00:48.

Il y a plein de vidéos de démonstration disponibles, mais il y en a une en particulier que je tiens à vous montrer, car elle est vraiment originale. En effet, c’est la vidéo d’un compositeur Wayland un peu spécial…

Si je ne m'abuse, les zolis effets de cette vidéos ont très peu à voir avec Wayland et sont surtout dus à Qt. Jetez donc un oeil à cette vidéo la http://www.youtube.com/watch?v=_FjuPn7MXMs eh oui! c'était en 2008, en QT4 avec X11.
NB : Wayland est apparu en novembre 2008.

"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
- [^] # Re: vidéo pas si nouvelle
  
  Posté par ariasuni le 08 février 2014 à 13:22. Évalué à 7.
  
  Euh c’est la même vidéo que la dépêche?!
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: vidéo pas si nouvelle
    
    Posté par Gof (site web personnel) le 09 février 2014 à 01:49. Évalué à 7.
    
    J'imagine qu'il voulais dire ça: http://www.youtube.com/watch?v=MXS3xKV-UM0
    
    La différence c'est que le wolfenqt de 2008 affiche des widgets, qui sont rendu par le même process que celui qui fait tourner le "monde 3D" alors que celle de wayland et Qt5 de la dépêche affiche des fenêtres rendues par d'autres processus.
    - [^] # Re: vidéo pas si nouvelle
      
      Posté par ZeroHeure le 09 février 2014 à 11:42. Évalué à 2.
      
      Merci pour tes précieux éclaircissements!
      
      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
    - [^] # Re: vidéo pas si nouvelle
      
      Posté par ariasuni le 09 février 2014 à 15:49. Évalué à 2.
      
      Il y a quand même un monde entre les deux… Ça permet de voir que la technique a pas mal progressé!
      
      Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: vidéo pas si nouvelle
        
        Posté par gyom gyom le 10 février 2014 à 09:52. Évalué à 1.
        
        Oui les effets sont zolis tout plein, mais pour bosser sur sa bécane 8h/j, je ne suis pas franchement convaincu…
        
        [^] # Re: vidéo pas si nouvelle
        
        Posté par ariasuni le 10 février 2014 à 10:29. Évalué à 5.
        
        Qui peut le plus peut le moins.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: vidéo pas si nouvelle
        
        Posté par barmic le 10 février 2014 à 11:20. Évalué à 2.
        
        Bof, en l'ergonomie (comme ailleurs) ce n'est pas qui peut le plus peut le moins, mais qui est le plus adapté/intégré est meilleur.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: vidéo pas si nouvelle
        
        Posté par ariasuni le 10 février 2014 à 11:49. Évalué à 2.
        
        Bah vu que Wayland est un protocole, on fait ce qu’on veut par-dessus.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: vidéo pas si nouvelle
        
        Posté par barmic le 10 février 2014 à 11:59. Évalué à 10.
        
        Le fait que ce soit un protocole ne change rien. HTTP peut très bien faire de l'envoi de fichier, mais il n'a pas pour autant déprécié, FTP/FTPS/SFTP/etc. Ce qui intéresse c'est de montrer des cas d'usages en vrai, le fait de montrer des trucs bizarres ça n'indique pas grand chose sur sa qualité pour faire ce dont on a besoin.
        
        Personnellement j'aime pas lancer eclipse pour modifier mes fichiers de conf', pourtant il est capable de faire bien plus qu'emacs ou vim et « qui peut le plus peut le moins ».
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: vidéo pas si nouvelle
        
        Posté par ariasuni le 10 février 2014 à 15:19. Évalué à 4.
        
        Bah si le protocole permet de faire des trucs qui déchirent avec fluidité, il permet logiquement de faire des trucs simples… avec fluidité.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: vidéo pas si nouvelle
        
        Posté par barmic le 10 février 2014 à 15:35. Évalué à 9.
        
        Très franchement pour moi c'est comme si tu me montrait un super marteau et que tu me dis « Regarde comment il plante bien les clous, il va super bien planter tes vis ! ». Je me retrouve en rien dans ces vidéos, pour moi c'est plus proche d'un quake moche que d'un quelconque bureau.
        
        Note bien que je ne critique pas wayland ou weston, mais l'argument basé sur ces vidéos qui, personnellement, ne me parlent pas le moins du monde.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: vidéo pas si nouvelle
        
        Posté par Thomas Douillard le 12 février 2014 à 13:22. Évalué à 5.
        
        Oui sauf que les cartes graphiques en offrent la possibilité, ça montre donc que les ergononomes et autres graphistes ne seront pas limités par les perfs ou une défaillance du support matériel quand les interfaces desktop seront complètement mortes.
# Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)

Posté par Le Gab le 08 février 2014 à 02:42. Évalué à 7.

Mais ça, franchement on s'en fout.
On veut surtout que ça affiche du pixel de manière fluide, une gestion du multi-écran et multi-périph d'entrée robuste.
De la sécurité et du code maintenable pour nos chers développeurs.
Je ne crache pas sur le concept de démo-technique mais quand je fais du suivi de Wayland, je trouve plus parlant la démo d'une situation réaliste que des démos à la compiz (monde 3D, flames, cube, particules,…).

Notons néanmoins que Xorg s'en sort encore très bien donc même si on trouvait l'évolution de Wayland pas très excitante, on n'est pas dans une impasse.

Voilà, un grand merci pour la dépêche, soit dit en passant.
- [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
  
  Posté par ariasuni le 08 février 2014 à 13:23. Évalué à 2.
  
  La prouesse technique démontre certains des avantages de Wayland parmi ceux dont tu parles. Comme je l’ai dit plus loin, je me souvenais de cette vidéo et je ne trouvais pas de vidéos qui montrait bien les capacités de Wayland pour le bureau.
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
    
    Posté par barmic le 10 février 2014 à 11:29. Évalué à 8.
    Le problème de ces vidéos c'est :
    - s'il faut envoyer pleins de kikoololerie pour arriver à nous montrer l'intérêt ça donne pas bien envie
    - ça ne donne pas trop d'infos sur une caractéristique primordiale pour beaucoup de monde, les besoins matériel pour le faire tourner. Oui c'est fluide, mais est-ce que ça ne consomme pas pas mal de ressources de bases pour ensuite pouvoir faire ce que l'on veut sans surplus (par rapport à la conso initiale). Est-ce que ça tourne sur n'importe quoi (des drivers graphiques pourri, propriétaire ou non, pas maintenu, sur un rendu entièrement CPU, etc) ? Je pense que c'est ça qui intéresse les gens alors que les belles vidéos (un moche toute de même, floues, pas vraiment lisibles et où on comprends pas forcément tout ce qui se passe,…) ça donne plus l'impression d'un discourt marketing fait pour enfumer (reconnais que c'est classique d'avoir une vidéo commerciale qui en met pleins la vue pour au final une grosse déception derrière)
    Note que je ne connais (et que je me fous) de wayland, je parle des vidéos qui cherchent à en jeter.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
      
      Posté par Maclag le 12 février 2014 à 09:46. Évalué à 8.
      
      En même temps, tu admettras que des vidéos de bureau ultra-sobre dans lesquelles il ne se passe absolument rien à part le lancement de quelques applications sans aucun effet spécial parce que "j'aime pas ça", c'est pas super vendeur non plus.
      
      Du coup je me demande ce que tu espères voir dans les vidéos?
      - [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par barmic le 12 février 2014 à 11:16. Évalué à 7.
        
        Ah mais si ! Des effets spéciaux c'est génial, je pense que tout le monde a apprécié de voir les vidéos XGL. Même si tu ne veux pas t'en servir, ces vidéos montrent un bureau en cours d'utilisation, là c'est clairement plus proche d'un RPG en mode vue subjective.
        
        Du coup je me demande ce que tu espères voir dans les vidéos?
        
        Un bureau, un truc comme looking glass, XGL, BumpTop ou DesktopX… Bref des trucs qui me permettent de voir des cas d'usage et pas euh… Je sais pas, je ne sais même pas ce qu'il y a sur cette vidéo (c'est quoi ces bonhommes qui cours partout ? Ça représentent quoi les pièces (leur organisation ne paraît pas possible. Comme on lance une application ? Pourquoi est-ce qu'on me montre un terminal illisible ? Pourquoi je m'ennuie devant une vidéo où le gars doit se déplacer pour coller une fenêtre à un mur ?).
        
        Bien sûr qu'ils ne font pas le boulot des gestionnaires de fenêtre, ça demande une recherche d'ergonomie etc, mais à la place de faire ce genre de vidéos si simplement ils refaisaient les vidéos de XGL, tout le monde serait skotché. Si en plus ils montrent qu'on change de carte graphique dynamiquement et que ça continue de fonctionner aux petits ognons, plus la peine d'argumenter sur Xorg, Mir ou wayland plus personne ne se posera la question.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par Renault (site web personnel) le 12 février 2014 à 11:32. Évalué à 5.
        
        Je sais pas, je ne sais même pas ce qu'il y a sur cette vidéo (c'est quoi ces bonhommes qui cours partout ? Ça représentent quoi les pièces (leur organisation ne paraît pas possible.
        
        Tu n'as pas compris la vidéo en effet. ;)
        Il n'y a dans cet exemple qu'une salle seulement, où en fait quand tu passes par les portes tu reviens dans la salle depuis une autre porte.
        Les bonhommes que tu vois, c'est juste ton avatar car comme la salle est unique et que la sortie par une porte aboutie sur une entrée par une autre porte, tu peux te voir quitter la salle.
        
        Le fonctionnement est simple, mais bien inutile en effet.
        
        [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par barmic le 12 février 2014 à 12:52. Évalué à 4.
        
        […] quand tu passes par les portes tu reviens dans la salle depuis une autre porte.
        
        Ils auraient pas pu faire un labyrinthe histoire de perdre vraiment les ceux qui regardent la vidéo ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par windu.2b le 13 février 2014 à 18:51. Évalué à 6.
        
        "Monstre & Cie" le faisait déjà, en 2001…
- [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
  
  Posté par Loïc Ibanez le 10 février 2014 à 15:27. Évalué à 1. Dernière modification le 10 février 2014 à 15:31.
  
  Une bonne partie des effets de compiz-fusion visent avant tout l'ergonomie du poste de travail et la productivité.
  
  Si Weston n'en reprend pas au moins 80% je ne suis pas prêt de migrer. Je déteste "Exposé" par exemple et je lui préfères le carrousel de fenêtres avec alt+tab.
  - [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
    
    Posté par Martin Peres (site web personnel) le 12 février 2014 à 15:54. Évalué à 5.
    
    Si Weston n'en reprend pas au moins 80% je ne suis pas prêt de migrer. Je déteste "Exposé" par exemple et je lui préfères le carrousel de fenêtres avec alt+tab.
    
    Weston n'aura jamais ça. Son rôle est d'être un démonstrateur et une implémentation de référence. Cela dit, tu peux quand même charger des plugins pour changer son comportement et ajouter les effets que tu veux.
    - [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
      
      Posté par reno le 12 février 2014 à 23:47. Évalué à 2.
      
      Euh tu es sur? http://www.phoronix.com/scan.php?page=news_item&px=MTUxNjA
      Moi pas ;-)
      - [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par Martin Peres (site web personnel) le 13 février 2014 à 01:13. Évalué à 5.
        
        Cool pour le alt-tab, mais le "ça" était "80% des plugins de compiz" ;)
        
        [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par Loïc Ibanez le 13 février 2014 à 09:17. Évalué à -6.
        
        Weston gère le alt-tab, quel progrès… il y a le choix entre combien de alt-tab différents dans compiz déjà ? 8 ? 10 ?
        
        Franchement pour moi dans l'état Weston est un proof of concept et pour au moins deux ans facile.
        
        [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par reno le 13 février 2014 à 10:07. Évalué à 10.
        
        Ça tombe bien, c'est son rôle!
        
        [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par Loïc Ibanez le 13 février 2014 à 11:36. Évalué à 1.
        
        Tout à fait d'accord.
        
        Le problème en lisant les commentaires c'est que beaucoup le présentent comme le successeur de Compiz-fusion puisque Compiz-fusion ne sera pas adapté sur Wayland. Hors ce n'est pas le cas.
        Vu que je ne veux ni de KDE ni de Gnome, et même si enlightenment qui a ma préférence a mis violemment le pied sur l'accélérateur dernièrement, je trouve que le passage à Wayland va créer un gros vide, celui de compiz-fusion+emerald.
        
        [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par claudex le 13 février 2014 à 11:43. Évalué à 7.
        
        Tu peux avoir Kwin sans KDE.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par navaati le 13 février 2014 à 13:46. Évalué à 3.
        
        Eh ben porte compiz-fusion, ou trouve quelqu'un pour le porter, mais tu peux pas te plaindre que ses créateurs veulent pas le faire et dire que c'est la faute à wayland, c'est n'importe quoi.
        
        [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par Le Gab le 13 février 2014 à 13:05. Évalué à 4.
        
        Weston gère le alt-tab, quel progrès… il y a le choix entre combien de alt-tab différents dans compiz déjà ? 8 ? 10 ?
        
        Et bien énumère les fonctionnalités que tu penses manquer?
        Du temps où j'étais sous Compiz, voire sous gnome 2.x avec sa version "débridable", j'aimais bien:
        
        le mode groupe de fenêtres avec préviz
        
        le mode grille
        
        le mode exposé
        
        Alt-tab, bien, c'est du alt-tab quoi, je vois pas comment Compiz peut fournir 10 versions différentes d'un selecteur de fenêtres sans tomber dans le Jacky'sme. :)
        J'ai fait le tour des différents plugins de Compiz, il ne m'était pas arrivé d'en utiliser plus que les 3 nommés plus haut or depuis 2 ans et des pousssières, je suis sous Gnome-Shell, ça ne me manque pas du tout, il y a d'autres façon de faire avec une certaine cohérence dérrière.
        
        Après, Xorg est encore là pour un moment donc du calme. Soit tes goûts ou ton utilisation auront évolués, soit Enlightenment sur qui tu mises comblera tes manques car je ne doute pas qu'il fournira avec E18 les sièges Sparco, pôts Remuse, Sono 800w et autres LED's dont raffolent certains linuxiens.
        
        [^] # Re: Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)
        
        Posté par khertan le 14 février 2014 à 01:16. Évalué à 2.
        
        Franchement pour moi dans l'état Weston est un proof of concept et pour au moins deux ans facile.
        
        C'est un peu le concept, c'est une implémentation de référence :)
# Quelques vidéos plus pertinentes

Posté par Scias le 08 février 2014 à 03:34. Évalué à 10.

Je regrette un peu que la (seule) vidéo de démonstration de cet article ne soit ni récente ni vraiment représentative des capacités et de l'état actuel de Weston/Wayland, donc voici quelques démonstrations plus récentes et montrant des choses plus "utiles" qu'un compositeur en vue FPS :

Orbital shell (un plugin pour Weston) : http://www.youtube.com/watch?v=bd1hguj2bPE
Kwin en tant que client sous Weston : http://www.youtube.com/watch?v=-V8i8zZPzbU
Chromium sous Wayland : http://www.youtube.com/watch?v=EJB2pznc6iY
Hawaii Desktop : http://www.youtube.com/watch?v=8_pR9FDDnjw
Weston/Wayland vs X.org sur Raspberry Pi : http://www.youtube.com/watch?v=0UkUal_hHx8
Dolphin-emu (émulateur Gamecube/Wii) : http://www.youtube.com/watch?v=3ZdXu1VM_VQ
…

Donc voilà pour les curieux. On peut quand même constater qu'il ne manque plus grand chose pour que Wayland ne devienne l'alternative qu'il nous faut.
- [^] # Re: Quelques vidéos plus pertinentes
  
  Posté par RB le 08 février 2014 à 13:11. Évalué à 10.
  
  Bon en même temps quand on voit ces vidéos on ne voit pas de différence avec le desktop que l'on a déjà (je sais que c'est le but, mais ce n'est juste pas "impressionnant" pour quelqu'un qui ne décèle pas le travail nécessaire afin d'avoir obtenu ce résultat).
  - [^] # Re: Quelques vidéos plus pertinentes
    
    Posté par Scias le 08 février 2014 à 14:39. Évalué à 1.
    
    Bon en même temps quand on voit ces vidéos on ne voit pas de différence avec le desktop que l'on a déjà (je sais que c'est le but, mais ce n'est juste pas "impressionnant" pour quelqu'un qui ne décèle pas le travail nécessaire afin d'avoir obtenu ce résultat).
    
    Néanmoins, maintenant il est tout à fait possible de faire un "compositeur en vue fps" comme montré dans l'article sur X.org.
    Wayland n'invente rien de ce côté, vu que c'est le compositeur qui fait ce que bon lui semble avec ses fenêtres dans les deux cas. Il donne juste la possibilité de le faire de manière beaucoup plus simple et performante.
    - [^] # Re: Quelques vidéos plus pertinentes
      
      Posté par navaati le 08 février 2014 à 15:54. Évalué à 0.
      
      Non. X11 ne permet pas de faire un compositeur en vue FPS comme dans la vidéo car il n'y a pas que l'affichage, il y a aussi les entrées, et X11 ne permet pas de les rediriger.
      - [^] # Re: Quelques vidéos plus pertinentes
        
        Posté par Scias le 08 février 2014 à 17:40. Évalué à 4.
        
        Comme le montre cette vidéo : https://www.youtube.com/watch?v=BrK4c7iFJLs c'est bien possible. Après je ne sais pas si c'est toujours d'actualité ou si c'est juste un workaround du côté de Compiz.
        Maintenant effectivement Wayland contrairement à Xorg a cette fonction innée, alors que Xorg n'a jamais été conçu pour ça.
  - [^] # Re: Quelques vidéos plus pertinentes
    
    Posté par Le Gab le 09 février 2014 à 13:39. Évalué à 7.
    
    Bon en même temps quand on voit ces vidéos on ne voit pas de différence avec le desktop que l'on a déjà (je sais que c'est le but, mais ce n'est juste pas "impressionnant" pour quelqu'un qui ne décèle pas le travail nécessaire afin d'avoir obtenu ce résultat).
    
    Mais ça n'a pas à être impressionnant au sens "tape à l'oeil". Et les gens qui s'intéressent à l'évolution de Wayland ne sont pas, j'ose supposé, vraiment dans la tranche des impressionnables.
    
    Une démonstration intérssante serait d'appliquer le même scénario à Xorg et Wayland.
    - Demarrage
    - Quelques manipulations de fenêtre (redimensionnement, déplacement) de contenu en tous genres (terminal, page web chargée déroulante, video)
    - branchement à chaud d'écran
    - changement de résolution
    - mise en veille, sortie de mise en veille
    - comparaison de la charge au niveau système (même si ils n'optimisent pas vraiment à cette étape)
    - configuration
    
    Bref, des cas réels.
    La plupart des points si ci-dessus sont déjà faisables sous Xorg mais un coût qu'on pourrait éviter.
    - [^] # Re: Quelques vidéos plus pertinentes
      
      Posté par ariasuni le 09 février 2014 à 15:55. Évalué à 7.
      
      Quand on voit le succès de sites tels que OMG! Ubuntu!, on peut quand même s’interroger. Tout utilisateur de GNU/Linux n’est pas forcément intéressé par la technique et je ne pense pas qu’un peu d’«impressionnant» puisse nuire à l’image que les gens se font de GNU/Linux, bien au contraire.
      
      Si je suis sous GNU/Linux aujourd’hui, c’est un peu grâce aux vidéos de compiz-fusion sur Youtube… Nostalgie nostalgie.
      
      Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: Quelques vidéos plus pertinentes
        
        Posté par barmic le 10 février 2014 à 11:52. Évalué à 6.
        
        Si je suis sous GNU/Linux aujourd’hui, c’est un peu grâce aux vidéos de compiz-fusion sur Youtube… Nostalgie nostalgie.
        
        Si le but c'est d'envoyer de la pub, c'est mal barré avec ces vidéos… XGL/Compiz étaient nettement plus joli (mais de très loin). Là c'est assez moche (les couleurs ternes, le flou de partout à en rendre peu lisible ce qui est écris, les bonhommes qui se déplace on ne sait pas trop ce qu'ils foutent là,…).
        
        Si c'est une démo technique, ça n'intéresse pas ceux qui s'y intéressent, si c'est pour claquer, on faisait mieux avant. Ça serait pas une perte de temps ? (à moins que ça les amuse ou que ça leur permet de faire des tests particulier :)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Quelques vidéos plus pertinentes
    
    Posté par Loïc Ibanez le 10 février 2014 à 15:37. Évalué à 3.
    
    Tout à fait. Tiny core Linux + compiz fusion + drivers intel récents et je faisais pareil et plus vite sur un pentium M avec une CG 915GM.
    
    C'est curieux comme sur AUCUNE vidéo de Wayland on ne voit la consommation de cpu et de ram… C'est plus que curieux, c'est carrément LOUCHE…
- [^] # Re: Quelques vidéos plus pertinentes
  
  Posté par ariasuni le 08 février 2014 à 13:17. Évalué à 2.
  
  Je trouvais pas de vidéos qui montrait bien la fluidité de Wayland.
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Quelques vidéos plus pertinentes
    
    Posté par ariasuni le 08 février 2014 à 20:35. Évalué à 2.
    
    Chromium sous Wayland
    
    Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Quelques vidéos plus pertinentes
  
  Posté par gyom gyom le 10 février 2014 à 09:56. Évalué à 1.
  
  C'est marrant que personne n'ait proposé cette vidéo, qui est quand même bien plus pertinente sur le pourquoi il faut passer à Wayland que tous vos "eye-candy-c'est-moi-qui-ait-la-plus-grosse"
  
  https://www.youtube.com/watch?v=RIctzAQOe44
  - [^] # Re: Quelques vidéos plus pertinentes
    
    Posté par ariasuni le 10 février 2014 à 10:30. Évalué à 4.
    
    Les aspects techniques ont quand même bien été expliqué dans les précédentes dépêches.
    
    Écrit en Bépo selon l’orthographe de 1990
# Diverses commentaires

Posté par Jarvis le 08 février 2014 à 08:57. Évalué à 0.

GNOME Shell, l’environnement de bureau des canards, gère Wayland depuis GNOME 3.10 mais on attend une bien meilleure prise en charge pour GNOME 3.12.

Mieux : les développeurs de Gnome 3.12 réfléchissent à retarder sa sortie pour prendre en charge pleinement Wayland 1.5 et pour aligner son calendrier sur Wayland.

Canonical n’a pas l’intention d’ajouter la prise en charge de Wayland à Unity. En effet, ils développent leur propre solution pour remplacer X.org, Mir.

[Mode Noob] C'est qui Canonical ? C'est quoi Unity ? [/Mode Noob]

En effet, cela vautrait weston

Ça veut dire quoi ?
- [^] # Re: Diverses commentaires
  
  Posté par ZeroHeure le 08 février 2014 à 11:13. Évalué à 6.
  
  [Mode Noob] C'est qui Canonical ? C'est quoi Unity ? [/Mode Noob]
  
  Entre parenthèse, d'après des stats de 2013,trouvées je ne sais plus où, OpenSuse c'est 400 000 utilisateurs, Fedora à peine plus, et Ubuntu 15 millions…
  Les stats se basent sur les mises à jour (yum, zypper et apt-get "update").
  
  "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
  - [^] # Re: Diverses commentaires
    
    Posté par woprandi le 08 février 2014 à 12:49. Évalué à 5.
    
    C'est tellement tendance de critiquer Ubuntu et co
    - [^] # Re: Diverses commentaires
      
      Posté par Jarvis le 08 février 2014 à 14:26. Évalué à -1.
      
      Je n'avais pas l'intention de critiquer Ubuntu ou lever un troll. Je trouve dommage que dans la dépêche soit un peu trop pour les initiés. Je ne suis pas sûr que les 15 millions d'utilisateurs d'Ubuntu sachent ce qu'est Canonical ou Unity. Enfin bref, j'aurais préféré une phrase plus précise est moins trollesque :
      
      Canonical, l'éditeur de la distribution Ubuntu, a fait un autre choix que d'intégrer Wayland à Unity, le gestionnaire de fenêtre. Ils sont en train de développer une solution maison : Mir.
      - [^] # Re: Diverses commentaires
        
        Posté par ariasuni le 08 février 2014 à 14:44. Évalué à 8.
        
        Enfin bref, j'aurais préféré une phrase plus précise est moins trollesque :
        
        Qu’est-ce qui est trollesque dans:
        
        Canonical n’a pas l’intention d’ajouter la prise en charge de Wayland à Unity. En effet, ils développent leur propre solution pour remplacer X.org, Mir.
        
        ? Ça s’appelle la stricte vérité, ça n’est pas dit de façon dénigrante. Faut arrêter de voir un troll à chaque fois qu’on parle d’Ubuntu.
        
        De plus, ce que tu dis est faux:
        
        Canonical, l'éditeur de la distribution Ubuntu, a fait un autre choix que d'intégrer Wayland à Unity, le gestionnaire de fenêtre. Ils sont en train de développer une solution maison : Mir.
        
        Unity n’est pas un gestionnaire de fenêtre. C’est Compiz le gestionnaire de fenêtre de Unity.
        
        Unity est un shell (logiciel fournissant une interface pour l'utilisateur) pour l'environnement de bureau GNOME développé par Canonical Ltd pour son système d'exploitation Ubuntu. […] L'interface Shell Unity est maintenant un plugin du gestionnaire de fenêtres Compiz, que Canonical prétend plus rapide que Mutter, le gestionnaire de fenêtres pour qui GNOME Shell est un plugin.
        
        Source. Même si perso j’aurais plutôt tendance à dire que Unity est un environnement de bureau se fondant sur GNOME (en considérant que Unity compte également les applications qui s’intègrent avec).
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Diverses commentaires
        
        Posté par Jarvis le 08 février 2014 à 21:49. Évalué à 0.
        
        ça s’appelle la stricte vérité
        
        Je trouve la phrase orienté. Il manque une explication du pourquoi. En même temps à ta décharge c'est une news sur Wayland pas sur Mir.
        
        Unity n’est pas un gestionnaire de fenêtre. C’est Compiz le gestionnaire de fenêtre de Unity.
        
        Sauf que Compiz n'est plus le gestionnaire de fenêtre de Unity pour sa version avec Mir.
        
        [^] # Re: Diverses commentaires
        
        Posté par ariasuni le 08 février 2014 à 22:04. Évalué à 2.
        
        Canonical, l'éditeur de la distribution Ubuntu, a fait un autre choix que d'intégrer Wayland à Unity, le gestionnaire de fenêtre. Ils sont en train de développer une solution maison : Mir.
        
        Sauf que Compiz n'est plus le gestionnaire de fenêtre de Unity pour sa version avec Mir.
        
        C’est vrai, mais du coup c’est quoi? Mutter? J’avoue que j’ai pas trop suivi, et j’ai beau chercher j’ai rien trouvé.
        
        Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Diverses commentaires
      
      Posté par cluxter le 09 février 2014 à 11:25. Évalué à 7.
      
      C'est surtout tellement tendance de réinventer la roue chez Canonical…
      
      Qu'ils aient envie de faire bande à part en faisant un serveur d'affichage parallèle à celui sur lequel tout le monde travaille, pourquoi pas, mais c'est un gaspillage de ressources à mon avis, ils feraient mieux de contribuer à Wayland. C'est d'ailleurs assez curieux pour une entreprise qui, je le rappelle, a pour objectif de faire du profit, donc d'économiser ses ressources.
      
      Rappelons qu'ils ont été considérés par des développeurs officiels du kernel Linux comme étant des personnes incompétentes qui ne comprenaient pas trop comment tout ça fonctionnait :
      
      Ils n’ont quasiment personne de suffisamment compétent pour écrire un serveur d’affichage, leur ignorance du fonctionnement de Wayland le met d’autant plus en évidence.
      […]
      La question est de savoir si vous souhaitez que l’avenir de Linux sur le bureau et potentiellement sur les plates‐formes mobiles repose sur un serveur d’affichage qui est développé par des personnes incapables de comprendre la solution libre de référence ? Le fait est que ce n’est pas afficher des choses à l’écran qui est la partie compliquée d’un serveur d’affichage ; récupérer les entrées et les envoyer de manière sécurisée à leur destination, ça c’est difficile. Gérer les méthodes d’entrées est difficile, un système d’entrée est difficile. Devinez ce qu’ils n’ont pas encore envisagé d’implémenter ?
      
      Dave Airlie
      
      Source et infos intéressantes : http://linuxfr.org/news/mir-un-serveur-d-affichage-de-trop
      
      Et de fait Canonical a commencé à avoir de sérieux problèmes ces derniers temps avec Mir. Je n'ai plus la source de l'article qui racontait ça, c'est bien dommage.
      
      Et là où je vois rouge, c'est quand je vois que 2 mecs de Canonical sont en train d'imposer les choix de Canonical à Debian parce qu'ils font partie des décideurs du projet Debian. Là j'ai juste envie de tout casser. Qu'Ubuntu fasse de la merde, c'est leur problème. Mais qu'ils viennent contaminer Debian, là c'est franchement flippant.
      - [^] # Re: Diverses commentaires
        
        Posté par Maclag le 12 février 2014 à 10:01. Évalué à 10.
        
        Ne mélangeons pas tout!
        
        Tu as lu que Canonical n'a pas de développeur expert sur les serveurs d'affichage et tu en conclus que Upstart (je suppose que tu parles d'Upstart?) c'est de la merde?
        
        Tu devrais aller lire le commentaire d'un certain Russ Albert dans la mailing list sur un bug qui demandait de virer un des membres du comité technique qui s'était énervé, qui est employé par Canonical, et qui défendait le choix Upstart.
        Ce "Russ" dont j'ai oublié le nom complet est l'un des partisans de systemd et il a écrit un beau résumé de l'histoire d'Upstart dans Ubuntu.
        
        Les dévs payés par Canonical que tu accuses de vouloir "imposer leur choix" chez Debian ont tout d'abord été des dévs Debian, qui avaient déjà l'idée d'implémenter un nouveau système d'init, mais n'ont pas trouvé le moyen de le faire dans le giron de Debian. Quand Ubuntu a démarré, ils ont eu la voie royale: un emploi, du temps, des ressources. Une fois que leur bébé est devenu un peu mûr, ils ont voulu le reverser à Debian, non pas par colonialisme, mais bien parce que c'est leur bébé et ils sont convaincus de la pertinence de la solution.
        
        Je n'ai vu personne au cours des débats déclarer que "Upstart c'est de la merde" avec des arguments pertinents derrière. Qu'il ait des défauts, certainement, mais systemd aussi.
        C'est d'ailleurs tellement de la merde que RedHat l'avait mis dans une de ses versions. Mais peut-être que chez RedHat non plus personne ne comprend rien à la vie…
        
        D'ailleurs, tu notes que la question de Mir ne semble même pas se poser chez Debian, alors que Wayland reçoit des paquets.
  - [^] # Re: Diverses commentaires
    
    Posté par RB le 08 février 2014 à 13:06. Évalué à 0.
    Pour autant que ce soit fiable:
    
    http://distrowatch.com/
    1. Mint
    2. Ubuntu
    3. Debian
    4. Mageia
    5. Fedora
    6. OpenSuse
    Donc on va dire que tu n'as pas forcément comparé avec les bons adversaires :)
    
    Sinon mint bien que basée sur ubuntu s'éloigne totalement de sa politique concernant le choix d'unity et je pense que cette distrib va suivre le mouvement wayland quand il sera disponible.
  - [^] # Re: Diverses commentaires
    
    Posté par Atem18 (site web personnel) le 08 février 2014 à 23:19. Évalué à 1.
    
    Entre parenthèse, d'après des stats de 2013,trouvées je ne sais plus où, OpenSuse c'est 400 000 utilisateurs, Fedora à peine plus, et Ubuntu 15 millions…
    Les stats se basent sur les mises à jour (yum, zypper et apt-get "update").
    
    Ouais enfin, il a beaucoup de de distributions se basant sur Ubuntu et dont les dépôts sont ceux d'Ubuntu. openSUSE et Fedora n'ont aucune dérivée officielle. Donc dire qu'il y a 15 millions d'utilisateurs d'Ubuntu, est un raccourci un peu facile. Utile, au niveau marketing, mais non fiable.
    - [^] # Re: Diverses commentaires
      
      Posté par ZeroHeure le 09 février 2014 à 11:45. Évalué à 2.
      
      Oui oui oui
      Mais tu vois, je doute très très très fortement qu'Ubuntu laisse utiliser ses serveurs par des dérivés si ceux-ci représentent la majorité des utilisateurs…
      
      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
      - [^] # Re: Diverses commentaires
        
        Posté par ariasuni le 09 février 2014 à 16:15. Évalué à 3.
        
        Pourtant si on compte les utilisateurs de Linux Mint, de Voyager, de NetRunner, etc, ça doit quand même faire beaucoup d’utilisateurs…
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Diverses commentaires
        
        Posté par ZeroHeure le 10 février 2014 à 00:28. Évalué à 2.
        
        Reste à définir "beaucoup".
        Compare l'ampleur des forums et wikis d'Ubuntu et des autres. Ce n'est bien sûr pas une mesure absolue, mais c'est un indice.
        Sérieusement, tu vois Shuttleworth laisser pomper sa bande passante et dire "c'est pas grave je finance la conccurrence"?
        Et vu les projets qu'il lance, je pense que ça va toujours bien pour lui
        Le classement de Distrowatch ne signifie pas grand chose, une fois qu'on sort de la communauté des geeks jeunes et ravis d'essayer autre chose.
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
- [^] # Re: Diverses commentaires
  
  Posté par ariasuni le 08 février 2014 à 23:48. Évalué à 1.
  
  En effet, cela vautrait weston
  
  Ça veut dire quoi ?
  
  J'ai trouvé ça amusant de traduire «crash» par «se vautrer». :p
  
  Écrit en Bépo selon l’orthographe de 1990
# Grosse fatigue

Posté par Abcd le 08 février 2014 à 12:27. Évalué à -10.

La propagande pour tenter de nous refourguer wayland machin chose continue à tourner à plein régime. La mentalité du monde libre continue à me donner de plus en plus la nausée, car non content de ne pas terminer le travail sur les logiciels déjà existant, ils poursuivent une perpétuelle fuite en avant pour tenter de nous faire croire qu'ils innovent alors qu'en fait dans la plupart des cas, ils se contentent de copier ou de réinventer des concepts déjà existants, et je trouve cela particulièrement pitoyable.

Côté sécurité, X.org est une vraie passoire

Mais personne ne pense à corriger le code. Non, il vaut mieux nous fourguer un autre machin qu'il faudra à son tour corriger parce qu'il se révélera lui aussi au final un pure passoire, mais sinon, c'est pas grave.

C'est un peu comme gimp en version 2.8 ils ont décidé que "Sauvegarder" c'est forcément au format xcf alors, on prend la tête des utilisateurs et on les oblige à utiliser "Exporter" en faisant croire que le format xcf est important, mais en fait en tant qu'utilisateur je m'en tamponne complètement du format xcf, j'utilise jpeg, tga et png et pour moi c'est super, donc j'ai downgradé en 2.6 pour être tranquille, c'est kon hein!?!

Et je vais pas parler du mode fenêtre unique, je suis hors sujet et je vais devenir désagréable.

Pour moi les systèmes Posix sont sensés contrairement à "fenêtre" s'adapter à l'utilisateur et pas le contraire, mais dans la réalité, on voit plus des développeurs qui se flattent l'ego plutôt que de penser à fournir un système véritablement user friendly qui s'adapte aux besoins des utilisateurs sans les obliger à fonctionner d'une manière plutôt que d'une autre.

C'est ça le vrai choix de la liberté, mais tout le monde semble l'avoir déjà oublié.
- [^] # Re: Grosse fatigue
  
  Posté par woprandi le 08 février 2014 à 12:51. Évalué à 10.
  
  Sinon tu peux lire le journal
- [^] # Re: Grosse fatigue
  
  Posté par Maclag le 08 février 2014 à 12:57. Évalué à 10.
  
  Je crois que tu n'as absolument aucune, mais alors aucune idée de ce dont tu parles.
  
  Côté sécurité, X.org est une vraie passoire
  
  Mais personne ne pense à corriger le code. Non, il vaut mieux nous fourguer un autre machin qu'il faudra à son tour corriger parce qu'il se révélera lui aussi au final un pure passoire, mais sinon, c'est pas grave.
  
  En fait, on t'attend pour gérer le développement de xorg, toi qui sais tellement mieux que des gens qui bossent dessus depuis des années ce qu'il faut faire.
  
  Je te refais un bout d'histoire récente de xorg:
  XFree change de licence, xorg naît, des développeurs commencent à bosser dessus pour… oh! tiens? "finir le boulot", c'est-à-dire maintenir et améliorer xorg.
  Après des années, tous les développeurs de xorg déclarent avoir atteint une limite. Le code est impossible à maintenir, traîne beaucoup trop de contraintes historiques, et seule une poignée de personnes dans le monde comprend vraiment le code. Ils décident que repartir de 0 pour faire du propre est la seule façon d'avoir un truc qui peut encore progresser.
  
  M'enfin si tu préfères penser qu'on aurait dû mieux travailler les bougies plutôt qu'inventer les ampoules…
  
  C'est un peu comme gimp en version 2.8 ils ont décidé que "Sauvegarder" c'est forcément au format xcf alors, on prend la tête des utilisateurs et on les oblige à utiliser "Exporter" en faisant croire que le format xcf est important, mais en fait en tant qu'utilisateur je m'en tamponne complètement du format xcf, j'utilise jpeg, tga et png et pour moi c'est super, donc j'ai downgradé en 2.6 pour être tranquille, c'est kon hein!?!
  
  En tant qu'utilisateur, je suis content de savoir que quand je sauvegarde, je ne perds aucune information dans le fichier, contrairement au JPEG, par exemple. De là je peux exporter vers le ou les formats qui m'intéressent pour utiliser l'image en l'état, et je peux quand même revenir dessus dans plusieurs semaines/mois/années avec d'autres requis sans problème.
  
  Et je vais pas parler du mode fenêtre unique, je suis hors sujet et je vais devenir désagréable.
  
  Rassure-toi: tu n'es plus à ça près.
  
  Pour moi les systèmes Posix sont sensés contrairement à "fenêtre" s'adapter à l'utilisateur et pas le contraire, mais dans la réalité, on voit plus des développeurs qui se flattent l'ego plutôt que de penser à fournir un système véritablement user friendly qui s'adapte aux besoins des utilisateurs sans les obliger à fonctionner d'une manière plutôt que d'une autre.
  
  Ah, ces méchants développeurs qui se foutent de nous. Quand je pense qu'il suffirait qu'on n'utilise plus leurs logiciels pour que ceux-ci ne soient plus populaire…
  Et puis avec ce qu'"on" leur paie, ils pourraient au moins faire ce qu'on exige.
  Ah, on me fait signe qu'"on" ne les paie pas…
  
  C'est ça le vrai choix de la liberté, mais tout le monde semble l'avoir déjà oublié.
  
  La liberté des développeurs devrait s'arrêter là où commencent les exigences des utilisateurs: à peu près au niveau de l'esclavagisme…
  - [^] # Re: Grosse fatigue
    
    Posté par claudex le 08 février 2014 à 14:35. Évalué à 10.
    
    s décident que repartir de 0 pour faire du propre est la seule façon d'avoir un truc qui peut encore progresser.
    
    Surtout qu'ils avaient commencer une mise à jour avec X12 mais, la plupart des développeurs se sont rendu compte qu'appeller le projet X12 voulait dire que tous les utilisateurs allaient pousser pour une compatibilité quasi totale avec X11, ce qui aurait empêcher de faire les changements nécessaires.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Grosse fatigue
      
      Posté par reno le 12 février 2014 à 23:53. Évalué à 3.
      
      Hum, si tu regarde la page sur X12 et que tu regarde Wayland, tu te dis que ça n'a rien à voir!
      Le point sur la transparence réseau par exemple..
      - [^] # Re: Grosse fatigue
        
        Posté par claudex le 13 février 2014 à 11:45. Évalué à 4.
        
        Je pense que ça montre justement le problème. Ils avaient besoin de garder la transparence réseau par exemple alors que ça nuit beaucoup au design propre que les développeurs de Wayland veulent.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Grosse fatigue
        
        Posté par reno le 13 février 2014 à 14:23. Évalué à 2.
        
        Remplace "design propre" par "conception simplifiée en optimisant pour l'affichage local" et je suis d'accord avec toi.
        Je ne trouve pas particulièrement "propre" d'avoir relégué l'affichage distant à un statut de 'seconde zone'.
        
        [^] # Re: Grosse fatigue
        
        Posté par xcomcmdr le 13 février 2014 à 14:32. Évalué à 3. Dernière modification le 13 février 2014 à 14:33.
        
        Au contraire, ça évite le code 'feature-creep' qui essaie de tout faire, à la Xorg.
        L'affichage local et l'affichage distant, ce ne sont pas du tout les mêmes contraintes.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Grosse fatigue
        
        Posté par reno le 13 février 2014 à 15:17. Évalué à -2.
        
        L'affichage local et l'affichage distant, ce ne sont pas du tout les mêmes contraintes.
        
        L'accès aux fichiers disque en local et en distant, ce ne sont pas du tout les mêmes contraintes, mais je suis content quand même que NFS existe..
        
        [^] # Re: Grosse fatigue
        
        Posté par ariasuni le 13 février 2014 à 15:25. Évalué à 8.
        
        Est-ce que tu as déjà vu le merdier que c’est NFS? En plus rien à voir, ce sont des logiciels différents qui s’occupent de gérer le système de fichier local et NFS.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Grosse fatigue
        
        Posté par reno le 13 février 2014 à 17:02. Évalué à -3.
        
        Est-ce que tu as déjà vu le merdier que c’est NFS?
        En plus rien à voir, ce sont des logiciels différents qui s’occupent de gérer le système de fichier local et NFS.
        RAF et RAF!
        L'important est que l'*interface*(l'API) soit la même (cf Plan9) mais comme avec Wayland ils n'ont fait que la moitié "facile" du boulot,
        on peut s'attendre à ce que le résultat soit un bazar incohérent..
        
        [^] # Re: Grosse fatigue
        
        Posté par freem le 14 février 2014 à 10:33. Évalué à 6.
        
        La conséquence est qu'avec wayland, il faudra obligatoirement utiliser un logiciel tiers pour de l'affichage distant.
        
        D'un autre côté, ce n'était pas le but de wayland de base, qui me semble plus cibler l'ordinateur personnel ( j'inclue dans ce terme les trucphones et les ordinateurs de voiture par exemple ) au lieu des serveurs d'applications.
        X me semble plus conçu pour les serveurs d'applications, c'est à dire pour les contraintes de coût d'il y a 30 ans, ou les ordinateurs étaient tellement coûteux qu'il était plus économique d'avoir un serveur d'application auquel se connectent des terminaux ( du genre incapables de faire quoique ce soit sans réseau. Nos machines actuelles, même si elles sont souvent uniquement utilisées avec un stupide navigateur internet, restent capables de faire des choses sans internet. C'est juste leurs utilisateurs qui n'en sont plus trop capables. ).
        
        A l'heure actuelle, n'importe quel gadget est assez puissant pour faire tourner les applications par lui-même, donc les serveurs d'applications n'ont plus un très grand intérêt, et c'est probablement pour ça que l'équipe de wayland n'a pas voulu s'embêter avec cette fonctionnalité. Enfin, c'est ce que je suppose.
        
        Et puis, VNC existe et est plus efficace ( il paraît, je n'ai jamais testé personnellement ) qu'utiliser Xorg directement.
        
        [^] # Re: Grosse fatigue
        
        Posté par ZeroHeure le 14 février 2014 à 13:31. Évalué à 9.
        
        VNC, RDP, NX existent et sont plus efficaces. En 3D, VNC (virtualgl.org) est terriblement efficace. VNC, n'est pas figé, il y a plein de variantes, d'évolutions etc.
        VNC et RDP sont multiplateformes, ce qui n'est pas rien.
        Il y a encore d'autres protocoles moins utilisés, ou plus jeunes (comme Spice qui n'a pas fini d'évoluer).
        Et puis on en inventera de nouveaux.
        Partant de là, laisser le libre choix du protocole devient une évidence.
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: Grosse fatigue
        
        Posté par claudex le 13 février 2014 à 16:53. Évalué à 4.
        
        Tu montre bien qu'on utilise pas le même système de fichier en local et en distant, et au final, peut-être que les toolkit implémenteront un système pour Wayland en local et un système pour le distant.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Grosse fatigue
        
        Posté par Martin Peres (site web personnel) le 13 février 2014 à 17:02. Évalué à 10.
        
        Tu montre bien qu'on utilise pas le même système de fichier en local et en distant, et au final, peut-être que les toolkit implémenteront un système pour Wayland en local et un système pour le distant.
        
        C'est aux compositeurs de faire ce travail. Pour info, Weston a un backend RDP et Kristian Høgsberg a déjà fait une démo de fenêtre distante. L'idée est vraiment de transmettre des images (avec mise à jour partielle, très bien pour le desktop) ou une vidéo compressée pour le support des vidéos ou des jeux (comme le fait NVIDIA avec le streaming de jeu). Alors oui, si tu peux streamer la vidéo sans la ré-encoder c'est mieux, mais c'est pas le plus générique.
        
        Au final, ça marchera mieux que X et sa transparence réseau qui n'existe plus. Je met au défi à quiconque de lancer thunderbird à distance, à travers internet!
        
        [^] # Re: Grosse fatigue
        
        Posté par claudex le 13 février 2014 à 17:07. Évalué à 8.
        
        Je ne suis pas convaincu que RDP soit le meilleur, peut-être un mélange vectoriel et bitmap est plus adapté, et dès qu'on veut faire du vectoriel, il faut que les toolkits suivent.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Grosse fatigue
        
        Posté par Albert_ le 13 février 2014 à 22:12. Évalué à 4.
        
        NX ou x2go cela fonctionne pas mal meme avec des applis 3D.
        
        [^] # Re: Grosse fatigue
        
        Posté par dave_null (site web personnel) le 14 février 2014 à 00:05. Évalué à 10.
        
        J'étais moi aussi dubitatif sur RDP, puis j'en ai eu besoin récemment. Le son et le presse papier (et pas juste du texte) sont gérés correctement. Plus intéressant pour moi, c'est aussi le cas de l'accélération graphique.
        
        Je peux jouer à Minecraft avec RDP en Full HD sur une connexion 100mbits/s, et ça fonctionne bien avec une faible latence. Le protocole est assez intelligent pour mettre à jour seulement ce qui change et adapter la qualité de la transmission à la volée.
        
        Plus concrètement, on peut travailler comme en local sans ralentissement, quel que soit le type de l'application, son toolkit et son thème graphique. La seule différence visible est des artefacts de compression type jpeg sur certains éléments quand ça bouge vite.
        
        Quand je pense à la lenteur de X11, les problèmes de sécurité (on peut utiliser SSH mais ça consomme du CPU), les problèmes en cas de perte de connexion ou de sortie de veille, son incapacité à être utile dans un contexte multimédia, de pouvoir fonctionner avec une application qui n’envoie pas de données vectorielles… je ne le regrette pas.
        
        X11 a été très utile mais il date d'une autre époque où les usages étaient bien différents.
        
        [^] # Re: Grosse fatigue
        
        Posté par cedric le 14 février 2014 à 03:28. Évalué à 5.
        
        peut-être un mélange vectoriel et bitmap est plus adapté, et dès qu'on veut faire du vectoriel, il faut que les toolkits suivent.
        
        Non, mais faut arreter avec le myth du vectoriel ! Aucun toolkit moderne, aucune application n'utilise un rendu "vectoriel" de nos jours. Et il y a de tres bonne raison. La premiere etant l'impossibilite pour un toolkit de garantir le resultat graphique. Ensuite le dessin vectoriel requiert beaucoup beaucoup plus de ressource CPU et GPU que du rendu bitmap. Et enfin, il reste a trouver un cas ou ca marche bien le rendu vectoriel…
        
        Donc peut etre que RDP n'est pas parfait, mais au moins il est sur la bonne piste. On peut tres probablement faire mieux en utilisant des codecs differents pour compresser les images, mais le principe restera le meme.
        
        [^] # Re: Grosse fatigue
        
        Posté par freem le 14 février 2014 à 10:42. Évalué à 0.
        
        Je suis à la fois d'accord et pas d'accord au sujet du vectoriel.
        
        Le vectoriel me semble plus adapté, clairement, parce que plus léger sur le réseau. Enfin, plus léger… si et seulement si on essaie pas de transmettre des photos! Pour des graphismes simples, du genre de ceux du thème qu'on avait du temps de windows 98.
        Si on se concentrait sur des thèmes fonctionnels plutôt qu'esthétiques, alors le vectoriel serait le plus adapté ( et par forcément le SVG, qui est hyper verbeux à cause de son héritage XML. Je ne sais pas si d'autres format vectoriel plus efficaces existent? ), léger sur le réseau pour une surcharge CPU/GPU raisonnable.
        
        En fait, c'est comme pour tout: il y a plusieurs solutions, chacune étant plus efficace en fonction de la situation. RDP doit probablement faire de la compression et sélection de zone ( à vous lire ), et donc plus efficace pour un environnement utilisant des graphismes de plus haute qualité, alors que le vectoriel serait plus efficace pour un thème épuré.
        
        [^] # Re: Grosse fatigue
        
        Posté par Corentin Rossignon le 14 février 2014 à 11:10. Évalué à 2.
        
        RDP est une solution. On pourrait imaginer remonter la transparence réseau au niveau du toolkit graphique (un plugin QPA dans le cas de Qt, nouveau backend dans GTK, …), généralement les toolkits ont un peu plus d'informations sur les données vraiment nécessaire à transférer (polices, pixmap, css, …) que le serveur X n'en as actuellement.
        
        [^] # Re: Grosse fatigue
        
        Posté par Martin Peres (site web personnel) le 14 février 2014 à 11:15. Évalué à 2.
        
        Tu voudrais faire un format de sortie SVG au niveau de Qt? Ça me semble pas déconnant dans certains cas ;) Et les images peuvent être embedded dans du SVG, donc devrait pas y avoir trop de suchis!
        
        [^] # Re: Grosse fatigue
        
        Posté par Corentin Rossignon le 14 février 2014 à 11:43. Évalué à 1.
        
        Pas un format de sortie mais juste envoyer par le réseau une série de commande de rendu à exécuter côté client alors que l'application tourne côté serveur.
        
        [^] # Re: Grosse fatigue
        
        Posté par Martin Peres (site web personnel) le 14 février 2014 à 11:50. Évalué à 2.
        
        Un truc comme ça? https://www.youtube.com/watch?v=qDyWjNju1yU
        
        [^] # Re: Grosse fatigue
        
        Posté par Corentin Rossignon le 14 février 2014 à 11:59. Évalué à 1.
        
        Oui mais au lieu d'utiliser un navigateur web on utiliserai une application qui fera office de serveur et dont le seul but sera de faire un rendu correct avec une meilleure intégration dans l'environnement client (presse-papier, glisser-déposer, …).
        PS : GTK propose le backend broadway pour un rendu dans un navigateur web comme sur la vidéo, c'est dans les dépôts arch si tu veux tester.
        
        [^] # Re: Grosse fatigue
        
        Posté par Martin Peres (site web personnel) le 14 février 2014 à 14:40. Évalué à 3.
        
        Ouais, c'est vrai qu'il manque certains aspects liés à l'intégration. Mais sinon, je voulais dire que c'était déjà possible de faire un client sans trop de modifs coté toolkits ;)
        
        [^] # Re: Grosse fatigue
        
        Posté par Wawet76 le 14 février 2014 à 11:49. Évalué à 4.
        
        Et enfin, il reste a trouver un cas ou ca marche bien le rendu vectoriel…
        
        MineStorm sur Vectrex !
- [^] # Re: Grosse fatigue
  
  Posté par Letho le 08 février 2014 à 13:26. Évalué à 8. Dernière modification le 08 février 2014 à 13:29.
  
  Côté sécurité, X.org est une vraie passoire
  
  Mais personne ne pense à corriger le code. Non, il vaut mieux nous fourguer un autre machin qu'il faudra à son tour corriger parce qu'il se révélera lui aussi au final un pure passoire, mais sinon, c'est pas grave.
  
  X est antédiluvien, il n'a pas cessé d'évoluer depuis des années, mais là on arrive à la limite. Je ne vois pas ce qui peut te choquer dans le fait que les développeurs repartent sur des bases plus saines. D'autant que la transition sera transparente pour les utilisateurs.
  
  C'est un peu comme gimp en version 2.8 ils ont décidé que "Sauvegarder" c'est forcément au format xcf alors, on prend la tête des utilisateurs et on les oblige à utiliser "Exporter" en faisant croire que le format xcf est important, mais en fait en tant qu'utilisateur je m'en tamponne complètement du format xcf, j'utilise jpeg, tga et png et pour moi c'est super, donc j'ai downgradé en 2.6 pour être tranquille, c'est kon hein!?!
  
  Différencier la sauvegarder du fichier de travail de l'export du fichier de « consomation » est tout à fait pertinent : quand je sauvegarde quelque chose, je m'attends à pouvoir le réouvrir dans les mêmes conditions sans avoir perdu d'information. Toi qui a l'air si prompt à analyser les besoins de l'utilisateur, pourrais-tu m'expliquer au juste comment sauvegarder mes calques dans un fichier jpg ?
  
  donc j'ai downgradé en 2.6 pour être tranquille, c'est kon hein!?!
  
  Ce n'est pas « kon », non, c'est surtout qu'en fait ~~tout le monde s'en branle~~ tout le monde s'en fiche. Pour rester poli. Et tout particulièrement les développeurs.
  
  Il y a deux choses qu'il faudrait peut-être voir à ne pas trop mettre de côté :
  - le besoin que l'utilisateur croit avoir n'est pas forcément légitime.
  - les développeurs ne sont pas nécessairement des cons totalement hermétiques à toute notion d'ergonomie.
  - [^] # Re: Grosse fatigue
    
    Posté par Loïc Ibanez le 10 février 2014 à 15:49. Évalué à -2.
    
    X est antédiluvien, il n'a pas cessé d'évoluer depuis des années, mais là on arrive à la limite. Je ne vois pas ce qui peut te choquer dans le fait que les développeurs repartent sur des bases plus saines. D'autant que la transition sera transparente pour les utilisateurs.
    
    Transition transparente pour les utilisateurs ? Ca veut donc dire que compiz-fusion+emerald tourneront sur Wayland ? Parce que moi en tant qu'utilisateur il est hors de question que je change de gestionnaire de fenêtres. Ou que je passe par un compositeur n'ayant pas les mêmes options que le précédent.
    - [^] # Re: Grosse fatigue
      
      Posté par claudex le 10 février 2014 à 19:42. Évalué à 4.
      
      Ca veut donc dire que compiz-fusion+emerald tourneront sur Wayland ?
      
      Non, le développeur de Compiz a dit qu'il préferait que Weston fasse tout le boulot et qu'il n'y avait pas d'intérêt de le porter sur Wayland.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: Grosse fatigue
        
        Posté par Loïc Ibanez le 11 février 2014 à 09:40. Évalué à 2.
        
        Oui oui, ça je le sais bien, je provoquais volontairement. Parce que pour l'instant Weston c'est… entre 2 et 3% des fonctionnalités de Compiz-fusion… donc dire que ce sera transparent pour l'utilisateur me fait bien rire.
        
        [^] # Re: Grosse fatigue
        
        Posté par Letho le 11 février 2014 à 11:09. Évalué à 10. Dernière modification le 11 février 2014 à 11:09.
        
        Oui oui, ça je le sais bien, je provoquais volontairement. Parce que pour l'instant Weston c'est… entre 2 et 3% des fonctionnalités de Compiz-fusion… donc dire que ce sera transparent pour l'utilisateur me fait bien rire.
        
        En parlant de pourcentage, je demande à voir celui des utilisateurs changeant le gestionnaire de fenêtres par défaut de leur environnement.
        
        Je reformule : pour l'utilisateur lambda laissant le boulot d'intégration à sa distribution, le passage de Xorg à Wayland sera transparent.
- [^] # Re: Grosse fatigue
  
  Posté par cedric le 08 février 2014 à 16:27. Évalué à 10.
  
  Côté sécurité, X.org est une vraie passoire
  
  Mais personne ne pense à corriger le code. Non, il vaut mieux nous fourguer un autre machin qu'il faudra à son tour corriger parce qu'il se révélera lui aussi au final un pure passoire, mais sinon, c'est pas grave.
  
  Vu ton niveau d'information technique, je vais partir de l'image que tu as choisi. X11, c'est une passoir au niveau meme du protocol. Il n'y a pas de securite, des que tu lances une application, c'est game over. Et c'est impossible de "corriger" le probleme sans casser le protocol (Les emulateurs, les logiciels de capture d'ecran, LibreOffice, … ne marcheraient plus du tout en rendant le protocol "securise"). En gros, c'est comme ci, tu disais qu'il suffirait de reboucher tous les trous de la passoire pour avoir une meilleur solution et que la moitie de la planete utilise la dite passoir pour essorer les nouilles. Autant dire que d'un point de vue fonctionnel, tes pates risques de rester assez humide et peu mangeable pour une bonne partie de la planete apres avoir corriger le probleme (Ils pourront se mettre a la soupe de nouille certe). C'est juste techniquement impossible de securiser le protocol sans casser un tres grand nombre d'application et la je n'ai pris que un seul exemple du protocol.
  
  Pour moi les systèmes Posix sont sensés contrairement à "fenêtre" s'adapter à l'utilisateur et pas le contraire, mais dans la réalité, on voit plus des développeurs qui se flattent l'ego plutôt que de penser à fournir un système véritablement user friendly qui s'adapte aux besoins des utilisateurs sans les obliger à fonctionner d'une manière plutôt que d'une autre.
  
  Oula, tu as ete tres tres mal informe ! Le monde du logiciel libre deja n'a rien a voir avec Posix qui est un standard qui s'arrete assez bas dans les couches logiciels. Et pour ce qui nous concerne ici, qui n'a rien a voir avec Posix et tout a voir avec le logiciel libre, tu es libre de contribue, mais si tu ne le fais pas, venir te plaindre ne sert a rien. Le logiciel libre n'a d'objectif que de satisfaire ceux qui le code. Si ca leur fait plaisir de satisfaire des energumenes retrograde qui gueulent sans rien comprendre, et bien tu as de la chance, sinon tant pis pour toi.
- [^] # Re: Grosse fatigue
  
  Posté par freem le 08 février 2014 à 19:35. Évalué à 5.
  
  Tu as raison de râler… enfin, de troller.
  
  Après tout, tu es libre de le faire, tout comme de contribuer au code. Et nous, on est libres de te demander ce que tu fais pour améliorer ce dont tu te plains: quel est ton dernier patch sur Xorg ou sur wayland/weston, stp?
  - [^] # Re: Grosse fatigue
    
    Posté par Stef le 10 février 2014 à 16:02. Évalué à 1.
    
    Justement il contribut si bien au libre qu'il fait des recherches complementaires sur ce qu'il ne comprend pas :
    
    La propagande pour tenter de nous refourguer wayland machin
    
    A bas c'est le sujet …
    
    Quand certain troll lui arrive quand meme à vomir pour le libre SVP
    
    La mentalité du monde libre continue à me donner de plus en plus la nausée
    
    j'aurai mis " s/contribue/continue "
    
    Et il continue à tous comprendre du sujet …
    
    Non, il vaut mieux nous fourguer un autre machin
    
    …
    
    Sinon il fait du report de bug sur linuxfr
    
    C'est un peu comme gimp en version 2.8 ils ont décidé que "Sauvegarder" c'est forcément au format xcf alors, on prend la tête des utilisateurs et on les oblige à utiliser "Exporter" en faisant croire que le format xcf est important
    
    ….
    
    Il utilise du oldstable pour étre tranquille
    
    donc j'ai downgradé en 2.6 pour être tranquille, c'est kon hein!?!
    
    Eu oui c'est con … et la sécurité ???
    
    Et puis il troll pour le bien pour la communauté
    
    Pour moi les systèmes Posix sont sensés contrairement à "fenêtre" s'adapter à l'utilisateur et pas le contraire, mais dans la réalité, on voit plus des développeurs qui se flattent l'ego plutôt que de penser à fournir un système véritablement user friendly qui s'adapte aux besoins des utilisateurs sans les obliger à fonctionner d'une manière plutôt que d'une autre.
    
    Oui posix y a un X ça fait linux … pour ta gouverne j'utlise 3 façons d'uiliser linux et les 3 ce sont adapté à moi (je t'explique pour faire simple l'un sans X l'autre en grand X et le dernier sous XBMC) c'est du lourd ça y a du X partout c'est posix c'est sur, jokex … bon allé je vais me flatter l'égo
    
    A oui j'oubliais si tu cherches un …
    
    système véritablement user friendly qui s'adapte aux besoins des utilisateurs sans les obliger à fonctionner d'une manière plutôt que d'une autre"
    
    …y a windows pour ça :-)
    
    C'est ça le vrai choix de la liberté, mais tout le monde semble l'avoir déjà oublié.
    - [^] # Re: Grosse fatigue
      
      Posté par freem le 12 février 2014 à 11:46. Évalué à 4.
      
      …y a windows pour ça :-)
      
      Surtout la dernière mouture :D
# ???

Posté par dragao13 le 08 février 2014 à 12:46. Évalué à -1. Dernière modification le 08 février 2014 à 12:49.

C'est quoi Canonical, c'est quoi Unity ?

Ben sans eux c'est moi et tout mon entourage qui n'utiliserions pas linux et ses innombrables instabilités et autres difficultés d'utilisation …

Ubuntu a rendu linux accessible à beaucoup de monde … Voilà qui ils sont : les premiers sur linux !!!

Mir sera très critiqué mais aussi très utilisé … Canonical a raison de faire son propre serveur d'affichage, il en aura une meilleure maitrise …

C'est la suite logique de la démarche avec unity pour ne pas subir gnome …
- [^] # Re: ???
  
  Posté par ariasuni le 08 février 2014 à 13:21. Évalué à 3.
  
  Canonical a raison de faire son propre serveur d'affichage, il en aura une meilleure maitrise …
  
  Pour faire quoi? Pour bosser tout seul dans son coin? Seul l’avenir nous dira s’ils ont eu raison ou non, mais pour moi les jeux sont fait… (sur le long terme)
  
  C'est la suite logique de la démarche avec unity pour ne pas subir gnome …
  
  Ils étaient pas obligé de créer Unity non plus, KDE ou Xfce auraient pu être pris et personnalisés au lieu de réécrire un truc complet. On pensera aussi à Cinnamon qui sont parti du code de GNOME Shell, au lieu, encore une fois, de réinventer la roue.
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: ???
    
    Posté par barmic le 10 février 2014 à 12:05. Évalué à 2.
    
    C'est la suite logique de la démarche avec unity pour ne pas subir gnome …
    
    Ils étaient pas obligé de créer Unity non plus, KDE ou Xfce auraient pu être pris et personnalisés au lieu de réécrire un truc complet. On pensera aussi à Cinnamon qui sont parti du code de GNOME Shell, au lieu, encore une fois, de réinventer la roue.
    
    Ils se basent encore pas mal sur Gnome et ils font pas mal de chose pour par exemple gérer les smartphones (en principe on aura des annonces d'ici fin avril je crois). Ils sont aussi entrain de passer à Qt/Quick de manière progressive.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: ???
  
  Posté par Maclag le 08 février 2014 à 13:28. Évalué à 10.
  
  Il est indéniable que Canonical a énormément contribué à la démocratisation de Linux sur le bureau.
  
  Il est malheureusement également indéniable que Mark Shuttleworth est un personnage controversé, et ce depuis la naissance d'Ubuntu.
  Pour histoire: il a envoyé un grand ~~Troll~~ message d'invitation aux développeurs Debian à passer à Ubuntu en critiquant allègrement Debian (ce qui ne l'empêche pas de baser Ubuntu dessus tout de même). Très classe!
  
  Je ne connais pas la nature des relations entre Canonical et l'équipe Gnome, si ce n'est que ce même M.S. avait également appelé à un grand mouvement de synchronisation des développements à tous les niveaux de l'écosystème Linux. Il suffisait que tout le monde s'accorde sur les dates de sortie: un logiciel à intégrer à Gnome sort un peu avant Gnome, qui a donc le temps de l'intégrer, puis les distros peuvent intégrer Gnome.
  Pour ce faire, il proposait une méthode toute bête: tout le monde devrait faire selon le cycle de développement d'Ubuntu. Curieusement, ça n'est pas passé.
  
  Le développement de Mir est un autre bel exemple de la mentalité M.S.: tout le monde était invité à participer à l'élaboration de Wayland. Canonical n'y a pas trop (pas du tout?) fait entendre sa voix.
  Plus tard, Canonical annonce avoir commencé à bosser sur Mir dans leur coin et appelle tout le monde à passer à Mir plutôt qu'à Wayland. Encore une fois très classe.
  
  Pour contribuer à Mir, il faut abandonner ses droits au profit de Canonical. Pourquoi donc? Simple: ainsi Canonical peut changer de licence pour Mir sans rien demander à personne, y compris tout passer en propriétaire s'ils le désirent.
  Et du coup ils achèvent de convaincre les dévs de ne surtout pas contribuer, ce qui ne serait pas arrivé de toute façon parce que Mir n'apporte absolument rien de transcendant par rapport à Wayland.
  
  Canonical cherche donc à développer son propre "écosystème" Mir+Unity. Je leur souhaite sincèrement bonne chance, et je pense qu'ils en auront besoin.
  
  Avec leurs décisions, Canonical est maintenant contrainte de mettre autant de ressources sur Mir et Unity que les ressources existantes sur Wayland et les environnements de bureau.
  Vaut-il mieux contrôler à 100% un développement sur ses propres ressources ou avoir moins de contrôle sur un environnement co-développé par "le bazar", c'est-à-dire quasiment tous les acteurs?
  
  Canonical n'est pas partie de 0. C'est donc que le bazar leur a permis d'être ce qu'ils sont aujourd'hui. Et paradoxalement, ils semblent aujourd'hui se méfier de ce bazar et reprendre une méthode d'évolution plus conservatrice, qui est la même que toutes les boites qui se sont pétées les dents en essayant de faire cavalier seul. Ce ne sont pas les exemples qui manquent!
  
  Donc non, je ne hais pas Canonical, mais je ne mettrais pas l'entreprise sur un piédestal non plus, et j'ai de gros doutes sur la pérennité de la boite d'ici quelques années. J'espère me tromper: c'est toujours bien un peu de diversité…
- [^] # Re: ???
  
  Posté par cluxter le 09 février 2014 à 11:54. Évalué à -1. Dernière modification le 09 février 2014 à 11:58.
  
  Que Linux soit utilisé dans le monde entier à la place de Windows, à la rigueur on s'en fout ?
  
  Linux a été conçu par des mecs compétents pour des mecs compétents. Pas par des marketeurs en quête de part variable à la fin du mois.
  
  Puis est arrivée Canonical avec des mecs incompétents (dixit Dave Airlie, pas n'importe qui donc) pour faire son produit Ubuntu (avec rentabilité financière exigée, c'est une entreprise) pour utilisateurs incompétents. Vous avez dit Microsoft..?
  
  Si Ubuntu c'est une copie semi-libre de Windows comme l'est Android, et avec des performances dégueulasses, je m'en passe très bien.
  
  N'oublie pas que si Ubuntu a pu émerger, c'est avant tout parce qu'elle est basée sur Debian qui est réputée pour sortir quand elle est stable et avec des solutions standards. Mir ne sera utilisé que par les Mme Michu et les Kéké sous Ubuntu, et c'est très bien comme ça parce que je n'ai absolument aucune envie de voir des kikoulol débarquer dans Debian suite à l'incompétence des gars de Canonical (qui sont d'ailleurs en train d'essayer de pourrir Debian avec 'upstart' à la place de 'systemd' ; qu'est-ce que je ne donnerais pas pour les kicker du projet Debian !).
  
  Il arrivera un jour où on comprendra qu'Ubuntu c'est à peu près aussi mauvais que Windows, comme c'est un peu déjà le cas avec Android. Ce n'est pour l'instant pas le cas car Ubuntu est encore largement basée sur Debian, mais à force de faire leurs trucs dans leur coin et de réinventer la roue pour chaque élément du système, c'est bien ce que Canonical va réussir à faire. Et j'ai presque hâte que ça arrive pour que ceux qui pensent qu'Ubuntu c'est trop bien parce que c'est du clic'n'point comme Windows comprennent leur douleur lorsqu'ils seront isolés du reste du monde et que tous les logiciels compatibles Wayland qu'on trouvera sur toutes les autres distributions ne pourront pas tourner sous Ubuntu. Enfin, j'imagine que comme d'hab avec Canonical, on aura droit à une nouvelle couche de compatibilité qui va encore alourdir le système, rajouter des failles de sécurité, demander des centaines d'heures de développement,… Vous avez dit Microsoft..?
  
  Un exemple concret pour conclure : Intel a décidé de retirer les patchs qu'ils avaient commencé à développer pour rendre leurs pilotes graphiques compatibles avec Mir, ils ne vont supporter que Wayland. Il est très probable que Nvidia et AMD suivent la même logique (Nvidia a déjà du mal à rendre ses pilotes propriétaires compatibles avec Wayland…). Les jeux Steam étant dépendants de la compatibilité des pilotes graphiques, on peut d'ores-et-déjà dire que Steam ne pourra un jour plus tourner sous Ubuntu. On peut penser ce qu'on veut de Steam, ce n'est pas la question. Ce que je veux montrer ici, c'est qu'un logiciel populaire comme Steam ne pourra pas tourner sous Ubuntu parce que Canonical a pensé que c'était mieux de faire bande à part, et qu'au final ils vont se retrouver isolés pas seulement pour Steam, mais pour tous les logiciels qui auront été développés pour Wayland. Autrement dit à peu près tous les logiciels (car je doute fortement que les développeurs s'amusent à fournir 2 versions graphiques de leurs logiciels, juste pour faire plaisir à Canonical quand tous les autres utilisent le même standard).
  - [^] # Re: ???
    
    Posté par claudex le 09 février 2014 à 12:14. Évalué à 4.
    
    (dixit Dave Airlie, pas n'importe qui donc)
    
    C'est aussi un employé de Red Hat, concurrent de Canonical. Je ne sais pas si on peut dire qu'il est vraiment objectif.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: ???
    
    Posté par dave_null (site web personnel) le 09 février 2014 à 12:16. Évalué à 10. Dernière modification le 09 février 2014 à 12:17.
    Résumons :
    
    Le bien
    - Linux
    - Debian
    - Wayland
    Le mal absolu
    - Les utilisateurs non experts en développement et administration de système d'exploitation
    - Les gens qui font des produits pour ces utilisateurs
    - Les gens du marketing
    - Et tout les produits développés par Canonical en général (Mir, upstart, Unity…)
    Je suis d'accord avec ton analyse sur le fait que développer Mir et une erreur, et je préfère SystemD à Upstart moi aussi mais je ne pense pas que la haine soit la solution.
  - [^] # Re: ???
    
    Posté par anaseto le 09 février 2014 à 12:25. Évalué à 2.
    
    Linux a été conçu par des mecs compétents pour des mecs compétents. Pas par des marketeurs en quête de part variable à la fin du mois.
    
    C'est pour ça que la plus grande part de marché de Linux c'est Android actuellement, si je ne m'abuse.
    
    Tu peux sans doute dire ça de certaines distributions, voire de certains *BSD peut-être, plus souvent de certains logiciels, mais là tu ne fais que généraliser ton cas d'utilisation, il me semble.
  - [^] # Re: ???
    
    Posté par woprandi le 09 février 2014 à 13:02. Évalué à 2.
    
    Merci pour cette tranche de rire
  - [^] # Re: ???
    
    Posté par ariasuni le 09 février 2014 à 16:50. Évalué à 8.
    Que Linux soit utilisé dans le monde entier à la place de Windows, à la rigueur on s'en fout ?
    - meilleur support matériel
    - plus de rapports de bugs
    - plus de développeurs qui travailleront dessus
    - etc
    Linux a été conçu par des mecs compétents pour des mecs compétents. Pas par des marketeurs en quête de part variable à la fin du mois.
    
    Bien, on supprime toutes les distributions et on apprend GNU/Linux via Linux From Scratch, comme ça on réduira les utilisateurs de GNU/Linux a l’élite.
    
    Puis est arrivée Canonical avec des mecs incompétents (dixit Dave Airlie, pas n'importe qui donc) pour faire son produit Ubuntu (avec rentabilité financière exigée, c'est une entreprise) pour utilisateurs incompétents. Vous avez dit Microsoft..?
    
    Ubuntu a quand même bien aider à démocratiser GNU/Linux…
    
    Si Ubuntu c'est une copie semi-libre de Windows comme l'est Android, et avec des performances dégueulasses, je m'en passe très bien.
    
    Ubuntu est constitué en très grande majorité de logiciels libres. Habituellement, Android est livré avec des logiciels non-libres (Google Apps, Samsung Apps, etc), et surtout avec impossibilité de bidouiller (impossible d’avoir un accès root, souvent le chargeur d’amorçage est verrouillé, etc). De plus, Android est développé dans le secret puis publié sous licence libre, alors que le développement d’Ubuntu est quand même largement plus public.
    
    N'oublie pas que si Ubuntu a pu émerger, c'est avant tout parce qu'elle est basée sur Debian qui est réputée pour sortir quand elle est stable et avec des solutions standards. Mir ne sera utilisé que par les Mme Michu et les Kéké sous Ubuntu, et c'est très bien comme ça parce que je n'ai absolument aucune envie de voir des kikoulol débarquer dans Debian suite à l'incompétence des gars de Canonical
    
    ???
    
    (qui sont d'ailleurs en train d'essayer de pourrir Debian avec 'upstart' à la place de 'systemd' ; qu'est-ce que je ne donnerais pas pour les kicker du projet Debian !).
    
    Les mecs ne sont pas arrivés chez Debian par la force non plus, hein. De plus, en des développeurs de Canonical a dit qu’il n’était pas opposé à systemd.
    
    Il arrivera un jour où on comprendra qu'Ubuntu c'est à peu près aussi mauvais que Windows, comme c'est un peu déjà le cas avec Android.
    
    Android aussi mauvais que Windows? Au moins il y a du libre derrière, j’imagine très très mal CyanogenMod, AOKP, OmniROM ou Replicant avec un logiciel non-libre.
    
    Ce n'est pour l'instant pas le cas car Ubuntu est encore largement basée sur Debian, mais à force de faire leurs trucs dans leur coin et de réinventer la roue pour chaque élément du système, c'est bien ce que Canonical va réussir à faire.
    
    Comparer l’influence d’Ubuntu et de Windows sur le monde du libre, c’est un peu comparer les pommes et des oranges…
    
    Et j'ai presque hâte que ça arrive pour que ceux qui pensent qu'Ubuntu c'est trop bien parce que c'est du clic'n'point comme Windows comprennent leur douleur lorsqu'ils seront isolés du reste du monde et que tous les logiciels compatibles Wayland qu'on trouvera sur toutes les autres distributions ne pourront pas tourner sous Ubuntu.
    
    Tu cliques avant de pointer? Plus sérieusement, je pense que Canonical s’assurera que la plupart des logiciels continueront à tourner sous Ubuntu (bien ou pas, c’est une autre histoire).
    
    Enfin, j'imagine que comme d'hab avec Canonical, on aura droit à une nouvelle couche de compatibilité qui va encore alourdir le système, rajouter des failles de sécurité, demander des centaines d'heures de développement,… Vous avez dit Microsoft..?
    
    ???
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: ???
      
      Posté par dinomasque le 09 février 2014 à 20:37. Évalué à 5.
      
      Que Linux soit utilisé dans le monde entier à la place de Windows, à la rigueur on s'en fout ?
      
      meilleur support matériel
      plus de rapports de bugs
      plus de développeurs qui travailleront dessus
      etc
      
      Si d'un coup de baguette magique le nombre d'utilisateurs de Windows et GNU/Linux s'inversait, ce dernier aurait certes plus de développeurs et un meilleur support matériel, mais pas forcément via des logiciels libres.
      
      Quand aux rapports de bugs, c'est loin d'être garanti : à part des utilisateurs engagés, qui effectue des rapports de bug au lieu de râler devant son écran ?
      
      BeOS le faisait il y a 20 ans !
      - [^] # Re: ???
        
        Posté par ariasuni le 09 février 2014 à 21:34. Évalué à 3.
        
        Si d'un coup de baguette magique le nombre d'utilisateurs de Windows et GNU/Linux s'inversait, ce dernier aurait certes plus de développeurs et un meilleur support matériel, mais pas forcément via des logiciels libres.
        
        De toute façon on se tape des pilotes non-libres pour Nvidia et ATI, on aurait simplement droit à un meilleur support si on a plus d’utilisateurs. Ça n’est qu’un exemple.
        
        Quand aux rapports de bugs, c'est loin d'être garanti : à part des utilisateurs engagés, qui effectue des rapports de bug au lieu de râler devant son écran ?
        
        Il y aura forcément un peu plus d’utilisateurs engagés comme tu dis dans la masse. Même si la proportion utilisateur engagé/utilisateur pas engagé risque d’être beaucoup plus faible que maintenant si ça arrivait.
        
        Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: ???
        
        Posté par groumly le 10 février 2014 à 06:09. Évalué à 3.
        
        Sur les bugs reports: mon experience dans le milieu "consommateur/grand public" me dit que t'as un bien meilleur feedback avec un crash reporter et un bon outil d'analytics (crash vs bug genant), et bien evidemment le dog fooding.
        Faire un bug report utilisable, c'est tres dur, et il faut encore se taper le triage derriere (doublon, bugs deja corriges etc). La plupart des ingenieurs sont pas capables de faire ca correctement, alors les utilisateurs…
        
        Bref, au final, ce qu'il te faut surtout pour trouver tous les problemes, c'est plein d'utilisateurs pour mettre a l'epreuve ton code.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: ???
        
        Posté par Maclag le 12 février 2014 à 10:17. Évalué à 6.
        
        Ça me rappelle une discussion que j'ai entendue une fois dans le bureau d'un admin:
        
        Coup de fil d'un "grand ponte" (mais pas en info apparemment). C'est là qu'on voit que dans les petites structures, l'admin sys fait aussi hotline pour les Nuls et larbin, suis content de faire complètement autre chose:
        
        "Allo? Ouai, j'appelle parce que l'ordinateur, ça marche pas là le truc!
        -Euh, oui, mais qu'est-ce qui ne marche pas exactement?
        -Ben le truc là que je veux regarder, ça marche pas.
        -L'ordinateur s'allume donc?
        -Hein? Oui, enfin, non, ça marche pas, quoi"
        
        L'admin sys (qui n'a bien évidemment que ça à foutre) s'est donc déplacé jusqu'au bureau de l'intéressé pour constater que "ça marche pas le truc", ça peut aussi vouloir dire "j'ai oublié de brancher le câble ethernet sur mon portable et curieusement je n'arrive pas à afficher mon site d'information préféré qui n'a rien à voir avec le boulot".
        
        Donc je confirme que tu ne veux pas que tout le monde rapporte ses bugs…
        
        [^] # Re: ???
        
        Posté par xcomcmdr le 12 février 2014 à 10:39. Évalué à 3.
        
        je n'arrive pas à afficher mon site d'information préféré qui n'a rien à voir avec le boulot
        
        linuxfr ?
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
    - [^] # Re: ???
      
      Posté par dinomasque le 09 février 2014 à 20:44. Évalué à 6.
      
      Si Ubuntu c'est une copie semi-libre de Windows comme l'est Android, et avec des performances dégueulasses, je m'en passe très bien.
      
      Ubuntu est constitué en très grande majorité de logiciels libres. Habituellement, Android est livré avec des logiciels non-libres (Google Apps, Samsung Apps, etc), et surtout avec impossibilité de bidouiller (impossible d’avoir un accès root, souvent le chargeur d’amorçage est verrouillé, etc). De plus, Android est développé dans le secret puis publié sous licence libre, alors que le développement d’Ubuntu est quand même largement plus public.
      
      Ars Technica a publié un article intéressant sur le sujet très récemment : http://arstechnica.com/information-technology/2014/02/neither-microsoft-nokia-nor-anyone-else-should-fork-android-its-unforkable/
      En synthèse : Google a rendu Android fonctionnellement non-forkable en mettant tous les morceaux intéressant dans les Google Mobile Services non libres et ne laissant dans AOSP plus qu'une coquille.
      
      L'exemple d'Android permet bien de dessiner un scénario catastrophe pour Ubuntu ou le "fauxpen-source" l'emporterait, laissant les hackers dans la même situation que du logiciel purement non-libre en pratique.
      
      cf. le départ fracassant de Jean-Baptise Queru de Google/AOSP : http://phandroid.com/2013/08/07/jbq-quits-aosp-qualcomm-to-blame/
      
      BeOS le faisait il y a 20 ans !
      - [^] # Re: ???
        
        Posté par ariasuni le 09 février 2014 à 21:39. Évalué à 3.
        
        Ars Technica a publié un article intéressant sur le sujet très récemment : http://arstechnica.com/information-technology/2014/02/neither-microsoft-nokia-nor-anyone-else-should-fork-android-its-unforkable/
        En synthèse : Google a rendu Android fonctionnellement non-forkable en mettant tous les morceaux intéressant dans les Google Mobile Services non libres et ne laissant dans AOSP plus qu'une coquille.
        
        Il y en a eu d’autres, et c’est très triste en effet. Néanmoins, les divers forks d’Android vivent très bien. Ça va nécessiter du boulot pour maintenir les applications AOSP de plus en plus abandonnées, mais ça fonctionnera. Pour les quelques fous qui sont prêts à risquer le brickage de leur téléphone… Mais le grand public restera sur des plateformes non-libres, et c’est bien là le problème.
        
        L'exemple d'Android permet bien de dessiner un scénario catastrophe pour Ubuntu ou le "fauxpen-source" l'emporterait, laissant les hackers dans la même situation que du logiciel purement non-libre en pratique.
        
        Il restera toujours des moyens. Le seul problème, ce sera qu’on nous mettra de plus en plus des bâtons dans les roues.
        
        cf. le départ fracassant de Jean-Baptise Queru de Google/AOSP : http://phandroid.com/2013/08/07/jbq-quits-aosp-qualcomm-to-blame/
        
        Franchement, j’ai pas compris. Pourtant mon niveau d’anglais est plutôt honorable… Est-ce que tu pourrais m’expliquer pourquoi il est parti?
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: ???
        
        Posté par dinomasque le 09 février 2014 à 23:41. Évalué à 6.
        
        La situation d'AOSP est assez grave : demain les applications "Android" dépendront à ce point aux API Google qu'elles ne pourront plus tourner que sur un smartphone ou elles sont installées.
        
        Les Cyanogen & cie seront une autre plateforme.
        
        Pour JB Queru, il a pété un cable quand il a découvert qu'il ne pouvait pas lancer AOSP sur un device Nexus (donc commandé exprès par Google pour en faire une machine exemplaire) parcequ'il n'y avait pas de driver (libre) pour la partie graphique.
        
        Autrement dit, seul "Android de Google" fonctionne sur les appareils d'aujourd'hui, les variantes basées sur AOSP ne fonctionnent pas.
        
        BeOS le faisait il y a 20 ans !
        
        [^] # Re: ???
        
        Posté par groumly le 10 février 2014 à 05:53. Évalué à 3.
        
        T'oublies la partie la plus croustillante: google interdit en pratique aux constructeurs de faire du aosp et en parallele du gms.
        Et ils commencent meme a dire aux constructeurs gms de se calmer sur la customisation (cf samsung).
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: ???
        
        Posté par Albert_ le 12 février 2014 à 10:45. Évalué à 1.
        
        Google se fait critiquer parcequ'il y a trop de variante de Android. Google fait en sorte de reduire cet eclatement et de limiter les trucs incompatibles. Google se fait critiquer parceque Android est verouille.
        
        Voila ca c'est comment l'histoire s'est deroule. Maintenant comparons avec la concurrence. L'OS des iphone est il ne serait que un tout petit peu ouvert et libre? Juste un peu? Non que dalle nada. Windows phone est il ne serait que un tout petit peu ouvert et libre? Nop nada que dalle. Apres les afficionados de ces deux systemes, les memes qui critiquaient Google du fait de l'eclatement de l'ecosysteme Android, peuvent continuer a cracher sur Google et Android il n'empeche que c'est tout de meme infiniment plus libre et ouvert que leurs OS favoris.
        
        [^] # Re: ???
        
        Posté par dinomasque le 13 février 2014 à 11:44. Évalué à 1.
        
        Ni Apple ni Android n'ont fanfaronné à propos du coté OpenSource de leur OS pour smartphone.
        
        BeOS le faisait il y a 20 ans !
# OpenGL ES et Sandy Bridge

Posté par karteum59 le 08 février 2014 à 13:56. Évalué à 4. Dernière modification le 08 février 2014 à 13:59.

les puces Intel, par exemple, bénéficient de la prise en charge d’OpenGL ES à partir des CPU de génération Sandy Bridge, c-a-d à partir des puces graphiques Gen6 dans la nomenclature du fondeur)

Il y a une raison technique qui explique le non-support sur les générations précédentes ? Pour ma part, j'ai un core i5 M520 avec une puce graphique "gen5", que j'estime encore suffisamment récent pour ne pas justifier un changement de machine, et il me semblait que la gen5 disposait déjà d'un pipeline entièrement programmable (par opposition au pipeline fixe conçu pour OpenGL 1.x qui fait que les vieux laptops avec un GMA950 ne pourront jamais supporter les shaders). Accessoirement sur la page sandy bridge de wikipedia, on lit "utilisation d'hafnium comme isolant au sein des transistors des processeurs", sauf que "Les gisements exploitables de hafnium à un coût acceptable seront épuisés autour de 2018" donc ce serait bien de ne pas changer de machine tous les 3-4 matins…
- [^] # Re: OpenGL ES et Sandy Bridge
  
  Posté par c0re5um le 08 février 2014 à 16:26. Évalué à -2.
  
  L'épuisement des gisements de terres rares doit commencer à chatouiller les pieds des grands constructeurs non ? Est-ce que certains savent comment les technos vont s'adapter pour palier à cette disparition; ou est-ce qu'il faut s'attendre à une cassure encore plus marqué ?
- [^] # Re: OpenGL ES et Sandy Bridge
  
  Posté par c0re5um le 08 février 2014 à 16:26. Évalué à -2.
  
  L'épuisement des gisements de terres rares doit commencer à chatouiller les pieds des grands constructeurs non ? Est-ce que certains savent comment les technos vont s'adapter pour palier à cette disparition; ou est-ce qu'il faut s'attendre à une cassure encore plus marqué ?
  - [^] # Re: OpenGL ES et Sandy Bridge
    
    Posté par cedric le 08 février 2014 à 16:33. Évalué à 4.
    
    Si c'est une terre rare, alors c'est un faux probleme. La raison de la rarete des dites terre rare et de leur production d'origine Chinoise, c'est qu'elles sont massivement melange a des gisements de Thorium, materiaux radioactif. Hors dans les pays occidentaux, l'exploitation de gisement radioactif est tres reglemente et surveille. De plus le Thorium est actuellement inutilisable pour toutes les centrales de la planete, ce qui en fait un dechet radioactif des le depart. Ceux la rend l'exploitation complique de ce genre de mine.
    
    Mais ce que font les Chinois, c'est juste de constituer des stocks de Thorium et lancer en parallele la R&D necessaire a la production nucleaire en utilisant comme carburant le Thorium… Ils sont d'ailleur les plus gros investisseurs dans le domaine, ce qui perenisera leur production de terre rare. Et d'ou ma remarque que la depletion des reserves de terre rare, n'est qu'un probleme d'ingenierie.
    - [^] # Re: OpenGL ES et Sandy Bridge
      
      Posté par karteum59 le 08 février 2014 à 17:25. Évalué à 5.
      
      Si c'est une terre rare, alors c'est un faux probleme
      
      1°/ Le hafnium ne fait pas parti des composés dits "terres rares" au sens chimique du terme. Et je n'ai pas inventé le fait que la plupart des gisements économiquement exploitables seraient épuisés vers 2018.
      2°/ faux problème ? Comme toute ressource finie et non renouvelable, la production de terres rares atteindra un jour un pic inexorable !
      3°/ Même dans le cas où les terres rares ne sont pas toujours "rares" dans la croûte (ça dépend des éléments chimiques), elles sont globalement très peu concentrées. Pour cela, leur exploitation est très polluante et aussi très énergivore. Or, on va aussi manquer d'énergie dans les années qui viennent…
      4°/ La filière thorium n'est pas au point. Elle est présentée comme un remède miracle, mais pour l'instant des difficultés techniques restent encore non résolues (et par définition, on ne sait pas si/comment on pourra les résoudre !)
      - [^] # Re: OpenGL ES et Sandy Bridge
        
        Posté par cedric le 09 février 2014 à 16:00. Évalué à 2.
        
        1/ Je n'ai pas trouve d'info sur le sujet, tu aurais un lien ? Parce que au meme titre, tous les puits de shale gaz actuellement en exploitation seront aussi vide en 2018 (Du fait de leur duree de vie d'environ 5 ans).
        
        2,3/ Toute exploitation de ressource suit une courbe qui passe par un maximum et decroit. Partant de la, tu peux considerer la terre comme une unique mine et donc il y a forcement un maximum et apres ce sera la decroissance. C'est une evidence et elle est indiscutable. Tout aussi indiscutable est le fait que la majorite des metaux que l'on utilise ne tiendront pour la plus part pas plus de 30 ans de production au rythme actuel. Et a part stopper toute activite, il n'y a aucun moyen d'empecher ces predictions de devenir des faits. Il devient donc logique de commencer a investir maintenant dans les technologies d'exploitation spatiale de ressource.
        
        4/ De ce que j'ai compris de la question, cela semble etre plus une question d'ingenierie que de recherche fondamentale. C'est a dire que les ressources etant la, il n'y a rien qui semble bloquant pour arriver a un resultat, contrairement a d'autre technologie, tel que la fusion, qui ont plus de probleme theorique a resoudre.
        
        [^] # Re: OpenGL ES et Sandy Bridge
        
        Posté par karteum59 le 09 février 2014 à 19:44. Évalué à 5. Dernière modification le 09 février 2014 à 19:49.
        
        Je n'ai pas trouve d'info sur le sujet, tu aurais un lien ?
        
        J'ai déjà mis ce lien dans mon post précédent plus haut.
        
        Il devient donc logique de commencer a investir maintenant dans les technologies d'exploitation spatiale de ressource.
        
        L'exploitation spatiale restera à mon avis à jamais de la science-fiction. Le fait que tu arrives éventuellement à ramener un jour 3 cailloux intacts d'un astéroïde ou planetoïde voisin ne veut pas dire
        
        que ça passe à l'échelle sur le volume (c'est toute la différence entre le lab et l'échelle industrielle !)
        
        que ça passe à l'échelle dans la durée (ben oui, tes objets celestes se baladent dans l'espace et ne vont pas rester bien sagement à proximité de notre bonne vieille terre. Accessoirement, on ne sait déjà pas nettoyer la poubelle spatiale qu'on est en train de créer…)
        
        que tu ne consommes pas de ressources pour l'ensemble de l'activité "minière" elle-même (regarde combien d'énergie il faut pour satelliser 1kg…). C'est précisément un élément limitant pour le passage à l'échelle sur le volume.
        
        Il n'y a pas d'alternative à la "chasse aux gaspis" !
        
        C'est a dire que les ressources etant la, il n'y a rien qui semble bloquant pour arriver a un resultat
        
        Bien sûr que si
        
        evidemment ce sont des problèmes d'ingénierie, mais ça ne veut pas dire qu'il y a toujours une solution ! Evidemment, la marche semble moins haute que pour la fusion (qui ne donnera dans tous les cas rien d'ici 50-100 ans), mais attention à ne pas considérer le thorium comme un remède miracle.
        
        le thorium lui-même est abondant, mais quid des autres éléments rares qui seront nécessaires pour que l'ensemble de l'édifice fonctionne ? (par exemple, les barres de MOX des centrales actuelles sont entourées de gaines de zirconium, dont les réserves au rythme actuel sont d'environ 40 ans)
        
        [^] # Re: OpenGL ES et Sandy Bridge
        
        Posté par cedric le 10 février 2014 à 03:05. Évalué à 2.
        
        Je n'ai pas trouve d'info sur le sujet, tu aurais un lien ?
        J'ai déjà mis ce lien dans mon post précédent plus haut.
        
        Je ne comprend pas les bases logique de ce site et j'ai du mal a accepter certaine chose. Ainsi l'hafnium est lie dans les mines au Zirconium, donc il me parait logique que tant qu'on mine du Zirconium, on mine en meme temps de l'hafnium. D'ou le fait que je sois sceptique quand au contenu de ce site web et d'ou le fait que je demande des informations plus detailles. En general sur ce genre de sujet assez capitale de probleme d'approvisionnement en ressource, tu as toujours un papier de la CIA, de scientifique ou d'un think tank qui explique en long et en large le probleme.
        
        que ça passe à l'échelle sur le volume (c'est toute la différence entre le lab et l'échelle industrielle !)
        
        Tout depend de ce que l'on cherche, mais certains asteroid contienne a eux seul plus par exemple de platine que ce que l'humanite a exploiter depuis qu'on exploite le platine. Les volumes ne sont clairement pas le probleme ici.
        
        que ça passe à l'échelle dans la durée (ben oui, tes objets celestes se baladent dans l'espace et ne vont pas rester bien sagement à proximité de notre bonne vieille terre. Accessoirement, on ne sait déjà pas nettoyer la poubelle spatiale qu'on est en train de créer…)
        
        Euh, tu te contredis un peu. D'un cote tu dis que les objets celetes se baladent et de l'autre qu'il reste trop a proximite de la terre :-) Plus serieusement, la mecanique et la navigation spatiale, au vu des prouesses realises par nos sondes est quelques chose de bien maitrise… Une fois qu'on saura comment "pousser" un asteroid !
        
        que tu ne consommes pas de ressources pour l'ensemble de l'activité "minière" elle-même (regarde combien d'énergie il faut pour satelliser 1kg…). C'est précisément un élément limitant pour le passage à l'échelle sur le volume.
        
        C'est effectivement un des challenge, mais je n'aurais pas mis celui la en premier. Il faut les cartographiers, reussir a "atterir" dessus, les decouper en petit morceaux et les traiter avant de les renvoyer la ou on en a besoin. Clairement des tres gros problemes d'ingenierie et il faut probablement compter en decennie avant de resoudre ces problemes. Mais le probleme des volumes n'est probablement pas le premier sur la liste.
        
        le thorium lui-même est abondant, mais quid des autres éléments rares qui seront nécessaires pour que l'ensemble de l'édifice fonctionne ? (par exemple, les barres de MOX des centrales actuelles sont entourées de gaines de zirconium, dont les réserves au rythme actuel sont d'environ 40 ans)
        
        Avec ce genre de question on ne va rien faire. Oui, toutes les ressources que l'on exploite, sont fini, s'epuiseront un jour et pour beaucoup d'entre elle dans un futur assez proche. De maniere corolaire, il n'y a aucune source d'energie qui ne consomme pas de ces matieres qui se rarefie pour etre produite. Soit on arrete tout pour ne pas les epuiser soit on avance. La veritable question etant plutot ou est-ce que l'on doit diriger ces ressources ? Dans des telephones et tablettes ou dans la technologie spatiale et l'energie ? Et non, la chasse au gaspi n'est qu'une solution temporaire qui repousse l'inevitable.
        
        [^] # Re: OpenGL ES et Sandy Bridge
        
        Posté par karteum59 le 10 février 2014 à 12:10. Évalué à 4.
        
        j'ai du mal a accepter certaine chose. Ainsi l'hafnium est lie dans les mines au Zirconium, donc il me parait logique que tant qu'on mine du Zirconium, on mine en meme temps de l'hafnium.
        
        Demande toi: l'hafnium est présent en quelle proportion dans le minerais ? Sa consommation évolue à quel rythme par rapport à l'ensemble du stock ?
        
        Tout depend de ce que l'on cherche, mais certains asteroid contienne a eux seul plus par exemple de platine que ce que l'humanite a exploiter depuis qu'on exploite le platine. Les volumes ne sont clairement pas le probleme ici.
        
        Sauf que nos soucis ne se limitent pas au platine (qui représente des faibles masses parmi tout ce qui est miné), mais plein d'autre chose aux ordres de grandeurs considérablement plus élevés. Tu vas faire quoi pour le zinc et le cuivre ?
        Encore une fois: qu'on sache ramener 3 cailloux n'est pas le sujet (et si dans le cas du platine, ramener 3 cailloux résoud le souci, tant mieux. Mais j'en doute…)
        
        Plus serieusement, la mecanique et la navigation spatiale, au vu des prouesses realises par nos sondes est quelques chose de bien maitrise… Une fois qu'on saura comment "pousser" un asteroid !
        
        Il y a comme un léger décalage entre "plus sérieusement" et "une fois qu'on saura comment pousser un astéroïde" ! Non, ça n'est pas (et à mon avis ne sera jamais) faisable. Je pense que tu surestimes beaucoup le niveau technologique de notre espèce. L'homme n'est pas un dieu au dessus des lois de la physique ! Dans la vraie vie, ça ne marche pas comme dans star wars.
        
        Euh, tu te contredis un peu. D'un cote tu dis que les objets celetes se baladent et de l'autre qu'il reste trop a proximite de la terre
        
        Où ça ?
        Hormis la lune et les satellites artificiels (+ leurs débris), il n'y a pas d'astéroïde en orbite stable autour de notre planète. Encore moins d'objet celeste exploitable sur le plan minier !
        
        C'est effectivement un des challenge, mais je n'aurais pas mis celui la en premier. Il faut les cartographiers, reussir a "atterir" dessus, les decouper en petit morceaux et les traiter avant de les renvoyer la ou on en a besoin. Clairement des tres gros problemes d'ingenierie et il faut probablement compter en decennie avant de resoudre ces problemes. Mais le probleme des volumes n'est probablement pas le premier sur la liste.
        
        Encore une fois: regarde combien d'énergie (et de matières) il faut pour satelliser un kg. Idem si tu veux imaginer de les "découper" (N.B. sans moteur thermique, puisqu'il n'y a pas d'oxygène, donc pas d'usage du pétrole hein :). De même pour ramener sur terre des volumes (donc des masses) élevées sans que ça se désintègre…
        
        [^] # Re: OpenGL ES et Sandy Bridge
        
        Posté par robin le 11 février 2014 à 19:34. Évalué à 3.
        
        Excellentissime la BD sur Star Wars, merci beaucoup !
        :o
        
        bépo powered
    - [^] # Re: OpenGL ES et Sandy Bridge
      
      Posté par karteum59 le 08 février 2014 à 17:48. Évalué à 4. Dernière modification le 08 février 2014 à 17:50.
      
      Mais ce que font les Chinois, c'est juste de constituer des stocks de Thorium et lancer en parallele la R&D necessaire a la production nucleaire en utilisant comme carburant le Thorium
      
      Au fait, en complément de ma réponse précédente, j'ajouterais que même si une solution technique est trouvée pour rendre le thorium utilisable, cela ne préjuge pas de la faisabilité de son passage à l'échelle et de sa durabilité. Car même si le Thorium lui-même est abondant sur terre, ses dépendances pourraient être rares. Par exemple, le combustible MOX des centrales actuelles est entouré de gaines de Zirconium, dont les réserves sont estimées à 40 ans (au rythme actuel, donc sans prendre en compte un éventuel accroissement de la demande). Dans un système complexe comme une centrale au thorium, il est à craindre que certains éléments minéraux (autres que le thorium lui-même) deviennent un goulet d'étranglement. Mais personne ne semble en avoir conscience, la spécialisation à outrance dans notre société et notre mode de pensée présumant des ressources habituelles infinies fait qu'on manque de systémiciens et de personnes ayant une vision un peu globale.
      Bref, considérer que le thorium est la solution-miracle à nos problèmes est encore très prématuré…
- [^] # Re: OpenGL ES et Sandy Bridge
  
  Posté par antistress (site web personnel) le 08 février 2014 à 16:43. Évalué à 2. Dernière modification le 08 février 2014 à 16:48.
  
  Sauf erreur de ma part, le Gen5 est en fait une légère évolution du GMA X4500HD donc tu as en gros les caractéristiques d'un Gen4 de dernière génération : transform and lighting, architecture de shaders unifiés avec le Shader model 4.0, DirectX 10.1 et OpenGL 2.1 (sous réserve de l’implémentation par les pilotes).
  
  J'ai un netbook avec GMA950 (Gen3 : DirectX 9.0c, OpenGL 1.4, Pixel Shader 2.0) : j'espère qu'il pourra faire tourner Wayland un jour ?
  - [^] # Re: OpenGL ES et Sandy Bridge
    
    Posté par ariasuni le 08 février 2014 à 17:17. Évalué à 2.
    Chez moi:
```
$ lspic | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
```
    Et Weston tourne comme un charme.
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: OpenGL ES et Sandy Bridge
      
      Posté par antistress (site web personnel) le 08 février 2014 à 19:50. Évalué à 2.
      
      Donc le pilote pour Intel Gen3 gérerait OpenGL ES ?
      - [^] # Re: OpenGL ES et Sandy Bridge
        
        Posté par ariasuni le 08 février 2014 à 19:58. Évalué à 2.
        
        Ben tout était fluide, et j’imagine que s’il ne supportait pas OpenGL ES ça ne fonctionnerait pas du tout, non?
        
        Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: OpenGL ES et Sandy Bridge
    
    Posté par karteum59 le 08 février 2014 à 17:57. Évalué à 4.
    
    Et donc justement: dès lors qu'il y a "architecture de shaders unifiés" (donc un HW 100% programmable), qu'est-ce qui s'oppose à ce que ça supporte les mêmes fonctionnalités que les générations suivantes ?
    (je ne suis pas spécialiste => est-ce que OpenGL 4.0 ou OpenGL-ES 3.0 présument des fonctionnalités HW particulières qui seraient absentes des cartes OpenGL2.1 par exemple ?)
- [^] # OpenGL « classique » sous Wayland.
  
  Posté par antistress (site web personnel) le 08 février 2014 à 16:54. Évalué à 2.
  
  À long terme, on pourra utiliser de l’OpenGL « classique » sous Wayland.
  
  D'ailleurs, peut-on en savoir plus à ce sujet ?
  - [^] # Re: OpenGL « classique » sous Wayland.
    
    Posté par ariasuni le 08 février 2014 à 17:24. Évalué à 3.
    
    Je crois que ça sera réglé par la nouvelle ABI. Présentation de Nvidia.
    
    Écrit en Bépo selon l’orthographe de 1990
# Bien...bien...bien

Posté par tipic le 08 février 2014 à 17:54. Évalué à 4. Dernière modification le 08 février 2014 à 17:57.

Cependant, une question, indépendante des détails technologiques :

Est-ce que Wayland, dans l'état actuel, est une alternative utilisable maintenant ? Bien sûr en tenant compte des migrations nécessaires des autres logiciels.

Je m'explique, je travaille actuellement sur une base Ubuntu Server 12.04 sur laquelle j'ai installé Mate(sans doute une question d'habitude, j'en conviens). Ubuntu après 5 ans dessus, depuis la 13, ne m'intéresse plus. Mes clients non plus.

Toujours actuellement, pour ma clientèle, c'est LinuxMint qui a tous les suffrages.Certes il est clair qu'il est basé sur Ubuntu 12.04, il est clair aussi que cette distrib est nettement au dessus d'Ubuntu 13.10.Il est clair aussi qu'il utilise toujours Xorg.
Pour ma part il n'y a plus de guerre avec Ubuntu, je l'ai abandonné. (Point)

Mais à nouveau, qu'est ce que me changera Wayland ? Si c'est une meilleure exploitation graphique ou une meilleure et plus directe communication avec le système ainsi qu'un ménagement des ressources du PC. OK!

ET surtout est ce exploitable maintenant ?

Une précision, je me fous complétement de savoir si le logiciel que j'utilise est Gnomesque, Kdesque…ou autresque. J'utilise ceux qui me sembles efficaces.
- [^] # Re: Bien...bien...bien
  
  Posté par ariasuni le 08 février 2014 à 18:24. Évalué à 7.
  
  Mais à nouveau, qu'est ce que me changera Wayland ? Si c'est une meilleure exploitation graphique ou une meilleure et plus directe communication avec le système ainsi qu'un ménagement des ressources du PC. OK!
  
  Oui, et bien plus. Cf. dépêches précédentes (dans les liens).
  
  ET surtout est ce exploitable maintenant ?
  
  Non, on aura GNOME (très bientôt) et KDE (mi- ou fin 2014 d’après ce que j’ai compris) capables de tourner sous Wayland, mais à mon avis il faudra compter un peu plus de temps avant que ça arrive dans les distributions (parce qu’il n’y a pas que deux environnements de bureau, sans compter les innombrables gestionnaires de fenêtres). Du coup pour gérer la transition proprement, il faut que tout puisse fonctionner. Normalement la transition sera transparente pour l’utilisateur.
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Bien...bien...bien
    
    Posté par tipic le 08 février 2014 à 22:57. Évalué à 1.
    
    Oui, ce serait bien.
- [^] # Re: Bien...bien...bien
  
  Posté par freem le 08 février 2014 à 19:59. Évalué à 6.
  
  A mon avis, l'utilisateur final ne verras pas de grande différence entre wayland et Xorg. Voire même, il n'en verra pas du tout.
  
  A ce que j'ai cru comprendre au fur et à mesure des releases de wayland, c'est qu'il sera plus maintenable, et plus léger car non dépendant du grand nombre de "sous-protocoles" nécessaires pour pouvoir oser se prétendre serveur Xorg. Il devrait également permettre une meilleure sécurité par le fait qu'il ne s'occupe que d'affichage, et pas de l'entrée contrairement à Xorg.
  
  Mais au final, seuls les développeurs verront la différence: moins de coût de maintenance, plus de facilité pour créer des serveurs graphiques alternatifs, et potentiellement un système moins gourmand… sauf que si on allège de 20Kio en RAM la gestion de l'affichage, avec des bouzins comme Gnome ou KDE, personne ne verra la différence, au vu de la lourdeur de ces derniers.
  
  Sauf si tu es le genre d'utilisateur à utiliser fréquemment les TTYs ou à lancer plusieurs serveurs graphiques, puisqu'il semble au vu de la dépêche, que ces switch seront plus efficaces? Personnellement, ça ne m'arrive pas tous les jours mais c'est une fonctionnalité utile, et la voir plus réactive me ferait grand plaisir :)
  - [^] # Re: Bien...bien...bien
    
    Posté par ariasuni le 08 février 2014 à 20:32. Évalué à 2.
    
    Tout les opérations graphiques seront plus efficaces, ou au moins autant avec Wayland qu’avec X.org. Et pour avoir testé weston, je peux te dire que la différence se ressent en terme de fluidité.
    
    Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Bien...bien...bien
    
    Posté par tipic le 08 février 2014 à 22:43. Évalué à 2. Dernière modification le 08 février 2014 à 22:48.
    
    Pour les TTY's, oui je les utilisent très souvent. Quand aux multiples sessions, jamais.
    PAr contre, je tiens à ce que cela reste souple. Les applications principales sur ou depuis une machine reste pour moi la gestion des serveurs en console, une consommation minimale de l'interface graphique pour, par exemple, un studio audio-numérique ou le montage video.
    
    Pour ce dernier par exemple, kdenlive m'est très utile et Cinellera utile aussi.
    
    En ce sens, je veux avoir des garanties, Ces garanties ont été cassées par Ubuntu donc je passe ailleurs. Ce n'est pas idéologique, mais pratique.
    - [^] # Re: Bien...bien...bien
      
      Posté par freem le 08 février 2014 à 23:05. Évalué à 4.
      
      La seule chose qui m'ait fait utiliser des sessions multiples à l'heure actuelle, c'était pour tester à quel point un jeu porté sous linux ( qui était censé empêcher à quelqu'un sur un même PC de lancer plusieurs sessions simultanément ) était sécurisé.
      Comme je m'y attendais, je n'ai eu aucun souci :)
      Pour faire plus que joujou, je préfère utiliser ssh -X, c'est plus utilisable, justement parce que le multi-session, c'est lent. Rien qu'entre le serveur graphique et une TTY, ça me prend près de 4s pour qu'un de mes écrans se rallume, l'autre étant plus long encore.
      
      Pour le reste… je ne sais pas, je serai trop a poil sans gestionnaire de fenêtre, ou sans une résolution digne de ce nom. Donc je me vois mal travailler avec screen sous TTY. Et je n'ai même jamais entendu parler de dual screen via une TTY.
      - [^] # Re: Bien...bien...bien
        
        Posté par med le 09 février 2014 à 20:03. Évalué à 2.
        
        Rien qu'entre le serveur graphique et une TTY, ça me prend près de 4s pour qu'un de mes écrans se rallume, l'autre étant plus long encore.
        
        Je viens de tester, c'est immédiat chez moi. À tout hasard, je subodore que tu n'utilises pas KMS (voire que tu utilises le pilote propriétaire nvidia) ?
        
        [^] # Re: Bien...bien...bien
        
        Posté par ariasuni le 09 février 2014 à 21:42. Évalué à 2.
        
        Et le pire, c’est que le pilote non-libre nvidia était plus rapide sur le changement de TTY avant… Ils ont saboté ce qui était déjà horrible avant!
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Bien...bien...bien
        
        Posté par freem le 12 février 2014 à 11:51. Évalué à 1.
        
        dkms n'est pas installé sur mes machines en général, quoique peut-être que si pour celle qui a une CG nvidia, vu que c'est un paquet recommandé, c'est possible, a vérifier. Sinon, ce n'est instantané sur ma machine de boulot* si sur mes 2 autres machines, l'une tournant avec le blob proprio nvidia, l'autre étant sur un chipset intel.
        Mais c'était aussi "rapide" de mémoire avec nouveau…
        
        Dkms permets d'accélérer ça? J'admets avoir une assez ( très ) mauvaise compréhension du kernel linux ( et de tous les autres en fait, il me faudrait vraiment y pallier un jour, sauf que voila, je n'ai jamais trouvé de truc très accessibles à ce sujet. Logique en même temps je dirais )
        
        *:
        $ lspci |grep -i vga
        00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
        
        [^] # Re: Bien...bien...bien
        
        Posté par BAud (site web personnel) le 12 février 2014 à 15:05. Évalué à 5.
        
        Il ne s'agit pas de DKMS qui est Dynamic_Kernel_Module_Support permettant de charger des modules hors sources du noyau (pour virtualbox, pour nvidia effectivement…) mais de KMS qui est Kernel-based_mode-setting. Tu l'utilises sans doute déjà, à moins d'avoir une distro très ancienne.
        
        [^] # Re: Bien...bien...bien
        
        Posté par freem le 13 février 2014 à 14:03. Évalué à 1. Dernière modification le 13 février 2014 à 14:04.
        
        Debian est réputée pour son âge, mais il ne faut pas pousser je dirais, surtout que j'utilise les versions plus récentes ou aussi récentes que "stable".
        
        A la louche, j'ai bien 5s sur mon desktop quand je passe d'une TTY à un Xorg ( ou vice-versa).
      - [^] # Re: Bien...bien...bien
        
        Posté par xcomcmdr le 10 février 2014 à 09:19. Évalué à 1.
        
        Rien qu'entre le serveur graphique et une TTY, ça me prend près de 4s pour qu'un de mes écrans se rallume, l'autre étant plus long encore.
        
        C'était le cas sur une nvidia avant (GeForce 9300M GS, pilotes proprios). Depuis que je suis sur une intel 4000HD, le passage TTY <-> Xorg est instantané ! :o
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
  - [^] # Re: Bien...bien...bien
    
    Posté par reno le 10 février 2014 à 10:18. Évalué à 2.
    
    A mon avis, l'utilisateur final ne verras pas de grande différence entre wayland et Xorg. Voire même, il n'en verra pas du tout.
    
    Ça dépend, sur les petites configurations, l’amélioration en efficacité en local pourra se ressentir, d'autant plus que dans certains cas le compositeur Wayland sera + optimisé que ne l'est le compositeur X (Raspberry Pi).
    
    Après dans des configurations "normales" effectivement ça m'étonnerait que ça se ressente beaucoup, mis à part les nouveaux bugs (nouveau code --> nouveaux bugs) et pire les problèmes de conception/d'écosystème qui vont mettre pas mal de temps à se résoudre: un exemple si un compositeur A a un backend pour faire X (RDP par exemple), ça n'implique en rien qu'un compositeur B va supporter aussi cette backend (sauf si A et B sont 2 plugins d'un même compositeur bien sûr), je pense que les utilisateurs vont bien s'arracher les cheveux au début pour choisir quel compositeur prendre, après quand la poussière sera retombée ça ira beaucoup mieux.
    
    C'est une transition, donc comme toute transition ça dépendra beaucoup de la stratégie utilisée pour la distribution..
    - [^] # Re: Bien...bien...bien
      
      Posté par ariasuni le 10 février 2014 à 11:54. Évalué à 2.
      
      La fluidité lors des déplacements et de changement de taille de fenêtres sera quand même bien supérieure. Et j'ai l'impression que ça va régler de vieux bugs graphiques.
      
      Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: Bien...bien...bien
        
        Posté par reno le 10 février 2014 à 15:02. Évalué à 2.
        
        La fluidité lors des déplacements et de changement de taille de fenêtres sera quand même bien supérieure.
        
        Tu met les 2 ensemble, mais je pense que tu ne devrais pas:
        -Déplacement de fenêtre: OK, ça sera bien sûr plus fluide car la gestion du déplacement sera faite uniquement par le serveur.
        
        -Pour le changement de taille, ce n'est pas le cas..
        Le comportement dépend en fait des choix d'implémentation du compositeur et le problème est en fait qu'il y a un compromis à faire entre la fluidité et le rendu visuel.
        A l'heure actuelle X privilégie la fluidité (le corps de la fenetre est redimensionné par le serveur) au rendu (si le client n'envoit pas le contenu à temps, c'est moche), Weston|Gnome/Wayland vont faire le choix opposé: le rendu: on affiche une nouvelle fenetre redimensionné que quand le client l'envoie (donc pas de glitch visuel) au détriment potentiel de la fluidité (si le client n'arrive pas à suivre le rythme le redimensionnement de la fenêtre sera 'saccadé'), KWin va rester sur la gestion des décorations coté serveur donc je pense qu'il aura le même "défaut" qu'X.
        
        [^] # Re: Bien...bien...bien
        
        Posté par ariasuni le 10 février 2014 à 15:22. Évalué à 2.
        
        Je me trompe peut-être. Toutes les vidéos de démonstration de weston montrent une fluidité à couper de souffle lors du changement de taille.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Bien...bien...bien
        
        Posté par reno le 10 février 2014 à 16:02. Évalué à 3.
        
        Bah, les démos sont souvent faites:
        1) sur le matériel du développeur donc un truc plutôt puissant.
        2) avec uniquement le code lié à la démo qui tourne
        les problèmes (que ce soit les glitchs visuels ou les effets de saccades) vont apparaitre quand la machine sera "à genoux"
        donc pas dans une démo "normale"..
        
        [^] # Re: Bien...bien...bien
        
        Posté par ariasuni le 10 février 2014 à 18:21. Évalué à 2.
        
        Euh pas besoin d’avoir une machine à genoux pour avoir des bugs visuels… Il suffit d’essayer de se déconnecter de KDE avec un autre thème de Plasma que celui par défaut et sans activer l’effet de fondu lors de la déconnexion (testé avec pilote nouveau, nvidia et intel).
        
        Écrit en Bépo selon l’orthographe de 1990
# Gestionnaire de fenêtres léger

Posté par erdnaxeli (site web personnel) le 08 février 2014 à 18:58. Évalué à 5. Dernière modification le 08 février 2014 à 19:02.

Une très bonne nouvelle pour les utilisateurs de gestionnaires de fenêtres légers, il sera possible de migrer vers Wayland sans écrire un compositeur complet grâce à SWC, une bibliothèque qui fait moins de 6 000 lignes de code et qui « a pour but d’embarquer le strict minimum pour afficher des fenêtres sur l’écran. »

C'est en effet une très bonne nouvelle (surtout quand je lis « It has been designed primary with tiling window managers in mind. » sur le github du projet). Ça m'a l'air assez accessible, bien plus que l'écriture d'un WM pour X11. Pour avoir essayé, c'est assez affreux, le pire étant la gestion du clavier (je me suis arrêté dans mon projet au moment de gérer les raccourci clavier).

Bref, très bonne nouvelle, c'était le dernier point qui m'inquiétait concernant Wayland, je suis content de voir que ça existe enfin.

Cela dit je me demande combien de petits WM vont survivre au moment de la migration vers Wayland, vu que ça demande quand même un travail plus que conséquent de portage.

Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
- [^] # Re: Gestionnaire de fenêtres léger
  
  Posté par anaseto le 08 février 2014 à 20:02. Évalué à 1.
  
  Cela dit je me demande combien de petits WM vont survivre au moment de la migration vers Wayland, vu que ça demande quand même un travail plus que conséquent de portage.
  
  Ça ne se fera pas en un jour, mais dès que Wayland deviendra installé par défaut un peu partout j'imagine qu'en quelques années on aura de nouveau tout plein de petits wms pour répondre aux goûts de tout un chacun, et entre-temps il y aura toujours Xorg, au pire en le faisant tourner sous Wayland, ce qui apparemment ne sera pas un problème.
  - [^] # Re: Gestionnaire de fenêtres léger
    
    Posté par ariasuni le 08 février 2014 à 20:34. Évalué à 5.
    
    Non justement, c’est un cas particulier: il n’est pas possible d’utiliser des gestionnaires de fenêtres prévus pour X.org sous Wayland pour une histoire de coordonnées. Je laisse les experts le soin de te répondre de façon plus précise.
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Gestionnaire de fenêtres léger
      
      Posté par anaseto le 08 février 2014 à 21:18. Évalué à 1.
      
      Ah, c'est moins marrant du coup.
      
      Pour se remonter le moral, un lien sur lequel je suis tombé vers l'annonce du projet swc, où l'auteur met un lien vers une démo sur youtube, on dirait qu'on arrive déjà a faire pas mal de chose avec, même s'il manque des trucs assez vitaux encore, du type pouvoir redimensionner une fenêtre à la souris, qui même si pas courant avec un tiling wm, c'est pratique pour certains logiciels comme gimp, xsane, feh,….
- [^] # Re: Gestionnaire de fenêtres léger
  
  Posté par freem le 08 février 2014 à 20:16. Évalué à 8.
  
  Je pense que pas mal de petits wm ne survivront pas. Mais d'autres naîtront, donc ce n'est peut-être pas si problématique.
  Les plus "gros" par contre seront probablement portés au bout d'un moment, je pense à awesome ou i3, je serai surpris qu'ils ne finissent pas par être portés.
  
  Sinon d'accord avec toi, c'est une bonne nouvelle, je me vois mal implémenter un WM moi-même (bien que j'y aie songé, mais quelques lectures sur wayland m'ont fait abandonner. Je vais peut-être jeter un oeil à cette lib…), et l'absence de TWM pour wayland m'empêche clairement de l'utiliser. Je ne reviendrai pas aux fenêtres jolies qu'il faut placer à la main…
  
  Quand je dois toucher un Windows je me sens handicapé, avoir ce même sentiment sous un autres OS me semble inacceptable.
  Que les fenêtres soient transparentes, aux coins arrondis, avec des fenêtres qui s'enroulent, brûlent, sautillent à l'écran est plus une gêne qu'une qualité pour moi, je préfère les gros blocs noirs avec une fine bordure et une simple barre de titre, sans animation qui me font perdre mon temps pour rien, dans lesquelles l'information recherchée me saute aux yeux, avec ou sans esthétique. ( est esthète qui le souhaite après tout )
  - [^] # Re: Gestionnaire de fenêtres léger
    
    Posté par Loïc Ibanez le 11 février 2014 à 10:14. Évalué à 4.
    
    Que les fenêtres soient transparentes, aux coins arrondis, avec des fenêtres qui s'enroulent, brûlent, sautillent à l'écran est plus une gêne qu'une qualité pour moi, je préfère les gros blocs noirs avec une fine bordure et une simple barre de titre, sans animation qui me font perdre mon temps pour rien, dans lesquelles l'information recherchée me saute aux yeux, avec ou sans esthétique. ( est esthète qui le souhaite après tout )
    
    Je me fais le défenseur de Compiz-fusion qui est attaqué. Beaucoup d'options sont eye-candy et inutiles je suis d'accord ( je désactivais systématiquement toutes les options de transition de fenêtres évoquées ici ), mais beaucoup sont ergonomiques. Pour certaines personnes une fenêtre qui se ferme brutalement c'est un bug ou une erreur. Alors qu'un fondu de 2s c'est ok. Ca semble hallucinant pour un développeur mais certaines cervelles d'utilisateurs sont ainsi faites.
    
    Et puis l'intérêt de compiz-fusion est ailleurs : c'est de faire bosser le GPU pour l'affichage. Et de ce côté je n'ai jamais été déçu : mon CPU travaille moins qu'avec blackbox ! Donc moins de ventilation pour un portable, donc durée de vie augmentée, etc etc…
    - [^] # Re: Gestionnaire de fenêtres léger
      
      Posté par Albert_ le 12 février 2014 à 10:50. Évalué à 2.
      
      L'effet qui me manque le plus sous kwin c'est le zoom interactif ca c'etait cool. Mais bon compiz c'etait trop buggue.
      - [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Loïc Ibanez le 12 février 2014 à 11:51. Évalué à 1.
        
        La dernière version est stable mais il a fallut attendre longtemps pour qu'elle le devienne. La faute probablement au fork entre compiz et fusion qui a fait perdre beaucoup de temps. Les rares gros problèmes qui restaient se concentraient sur le gestionnaire de fenêtre Emerald. Surtout parce qu'il y a souvent plusieurs gestionnaires de fenêtres différents sur la même distrib. Mais à partir du moment où l'on installe QUE compiz-fusion et emerald ça marche sans souci.
      - [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par ariasuni le 12 février 2014 à 12:17. Évalué à 2.
        
        Nan mais l'effet de feu? Je paierais cher pour l'avoir dans KWin.
        
        Faudrait que j'essaie de m'y atteler un jour, ça doit pas être ultra-difficile de reprendre le code de Compiz et de le traduire en js pour faire un effet KWin.
        
        Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Gestionnaire de fenêtres léger
      
      Posté par freem le 12 février 2014 à 12:11. Évalué à -1.
      
      J'ai en effet cité 2 ou 3 fonctionnalités de compiz-fusion, mais franchement, j'en ai autant à ce sujet pour aero de Windows vista+ ou les divers gestionnaires de fenêtres que je peux voir dans les diverses démo. ( je n'ai pas juste parlé des effets de flamme, mais aussi des coins arrondis, de la transparence, etc )
      Après, je suis aussi conscient du fait que je sois un utilisateur ayant un usage très différent de la moyenne qui utilise un paradigme différent de la moyenne. Et j'accepte volontiers ma bizarrerie, loin de moi l'idée d'imposer à quiconque les TWM. Je n'ose en parler qu'aux gens ayant un minimum de culture informatique ET libre, d'ailleurs, pour garder une réputation de mecs un peu cinglé mais pas complètement ;)
      
      Pour le fait d'utiliser le GPU plutôt que le CPU, ce n'est pas bête, sauf que je préfère un logiciel qui utilise disons, 10k cycles CPU à la seconde* que 15k cycles GPU à la seconde, d'autant que toutes mes machines n'ont pas nécessairement de GPU et que j'aime avoir un environnement très semblable d'une machine à l'autre.
      Et puis, très franchement, ce que je vois quand mon gestionnaire de fenêtre bosse, j'ai plutôt l'impression que ce sont des calculs sur entiers ( genre 1920/2, pas besoin de float ni de double pour ça ). Après, c'est le rendu lui-même qui peut utiliser potentiellement opengl ( j'en vois bien l'intérêt pour claws, tiens… oupa ) en fonction de l'application ( par contre, pour redeclipse, vu que je joue en fenêtré… pourquoi pas, sauf qu'ici aussi ,le gestionnaire de fenêtre à peu de travail à effectuer: le mode fenêtré en question prend un de mes écrans en entier ;) on peut presque dire qu'il s'agit d'un mode fullscreen, au final. Presque. )
      
      Maintenant, à voir. J'ai une certaine affinité avec l'idée derrière wayland, qui est un projet que je vois d'un très bon oeil:
      _ plus spécialisé que Xorg ( ne fait qu'une chose, on peut donc espérer qu'il la fera bien. )
      _ portable ( avec un peu de bol, quelqu'un finira peut-être par en faire serveur pour windows, histoire d'enrichir nos kits de survie en environnement hostile /me rêve )
      _ pas de code historique oublié de tous, donc simplicité de maintenance. Moins de bugs et meilleures perfs ( mais la perf se mesure pas uniquement au sujet de la fluidité: la batterie aussi est affectée ) en seront probablement les conséquences.
      _ de la diversité ( n'avoir aucune alternative est maintenant quelque chose qui me trouble… avant, c'était d'en avoir trop, mais j'y ai vite pris goût je crois. Il faut que j'aille tester debian kfreebsd un de ces 4 d'ailleurs :p )
      _ avec un peu de bol, moins pénible a configurer que Xorg? je verrai quand je m'y pencherais je suppose :)
      
      C'est juste que je me demande vraiment si l'utilisateur verra une différence, d'autant que la mode des logiciels finaux est aux bloatwares selon moi.
      - [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Loïc Ibanez le 12 février 2014 à 15:05. Évalué à 2.
        
        ( mais la perf se mesure pas uniquement au sujet de la fluidité: la batterie aussi est affectée )
        
        Exactement. Sachant qu'un gestionnaire de fenêtre est actif h24 et que 70% du parc informatique est mobile (smartphone+tablettes+notebook), le fait de solliciter le composant le plus juste (performance/consommation) pour réaliser une opération est essentiel. On a longtemps utilisé le cpu pour faire tout sauf ce pour quoi il a été conçu : du calcul séquentiel. D'ailleurs je trouve qu'on devrait trouver une solution moins coûteuse énergétiquement pour faire des i/o quitte à sortir de la sacro-sainte archi historique d'IBM. Vous trouvez normal que le ventilo de votre portable se déclenche lorsque vous copiez des gigas d'un disque usb externe à un autre disque usb externe ? Moi non.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par navaati le 12 février 2014 à 17:18. Évalué à 4.
        
        Heu, pour les IO, ça existe déjà depuis des lustres et c'est déjà mis en place un peu partout, ça s'appelle la Direct_Memory_Access. Après, peut-être que l'usb ne le permet pas.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par ariasuni le 12 février 2014 à 19:55. Évalué à 1.
        
        70% du parc informatique est mobile (smartphone+tablettes+notebook)
        
        + ordinateurs portables
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 13 février 2014 à 02:37. Évalué à 2.
        
        Exactement. Sachant qu'un gestionnaire de fenêtre est actif h24 et que 70% du parc informatique est mobile (smartphone+tablettes+notebook), le fait de solliciter le composant le plus juste (performance/consommation) pour réaliser une opération est essentiel. On a longtemps utilisé le cpu pour faire tout sauf ce pour quoi il a été conçu : du calcul séquentiel.
        
        Si la vie etait si simple :-) Le CPU est plus efficace que le GPU quand tu dois mettre a jour qu'une petite partie de l'ecran (genre curseur qui clignote). Cas d'utilisation le plus courant. Il n'y a que quand une surface tres importante de l'ecran devient anime, que le GPU devient plus efficace (cout des transferts de donnees et des calculs supplementaires necessaires compense par la puissance brute necessaire a accomplir l'ensemble de la tache). Resultat, tu as envie d'avoir un rendu CPU la majorite du temps, avec un petit boost par GPU de temps en temps.
        
        Sauf que la vie, elle a decide de t'embeter. L'initialisation et les transferts initiaux rendent impossible le dit scenario (Par exemple, meme si tu utilises une memoire partage entre CPU et GPU, il n'est pas possible pour le GPU d'utiliser directement la memoire d'une tache utilisateur et reciproquement en fait). Tu te retrouves donc a devoir faire un choix. Etre plus efficace en batterie de maniere general et avoir une interface qui lag un peu de temps en temps, ou utiliser plus de batterie et ne pas avoir de lag. Il est donc impossible de solliciter automatiquement le composant le plus juste.
        
        L'approche d'Android qui propose un mode basse consomation, consiste exactement en cela. L'utilisateur choisit alors le rendu CPU qui statistiquement est plus efficace que le rendu GPU.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par ariasuni le 13 février 2014 à 15:20. Évalué à 2.
        
        L'approche d'Android qui propose un mode basse consomation, consiste exactement en cela. L'utilisateur choisit alors le rendu CPU qui statistiquement est plus efficace que le rendu GPU.
        
        Ça ne semble pas exister dans AOSP mais être un ajout par les constructeurs (je ne trouve pas même pas l’option sous CyanogenMod).
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 13 février 2014 à 15:49. Évalué à 8. Dernière modification le 13 février 2014 à 15:51.
        
        Par exemple, meme si tu utilises une memoire partage entre CPU et GPU, il n'est pas possible pour le GPU d'utiliser directement la memoire d'une tache utilisateur et reciproquement en fait.
        
        Hmm hmm, bien sûr que c'est possible. Tu peux mmaper des buffers graphiques et y acceder depuis le CPU. Inversement, les GPUs font du DMA depuis la VM de la tâche utilisateur. Tu peux critiquer que ce soit pas fait, pas que ce soit pas faisable.
        
        Je viens de faire des tests sur mon laptop (carte graphique Intel):
        
        Idle
        
        rendu CPU: 8.9W
        
        rendu GPU: 8.8W
        
        En faisant bouger une fenêtre
        
        rendu CPU (sans effets): 19W
        
        rendu GPU (sans effets): 14.9W
        
        rendu GPU (transparent): 15.1W
        
        rendu GPU (wobbly + transparent): 15.8W
        
        Tu pourrais refaire des tests sur ton ordi? Essaye de faire durer chaque test environ 10 secondes et dans les mêmes conditions.
        
        Quand KDE supportera wayland, il pourrait même faire usage des KMS planes ce qui ferait que bouger une fenêtre consommerait ~0W coté rendu. Comme y'aura aussi moins de changement de contextes, le temps CPU sera aussi plus faible ce qui diminuera aussi la conso.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 13 février 2014 à 16:06. Évalué à 2.
        
        Je précise, "idle" équivaut à un terminal avec l'affichage de la conso qui change, rien de plus. C'est pas entièrement "idle", mais c'est rarement le cas sur une machine.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par navaati le 13 février 2014 à 16:10. Évalué à 1.
        
        Quand KDE supportera wayland, il pourrait même faire usage des KMS planes
        
        Ya des planes sur les cartes graphiques desktop ? Je croyais que c'était que dans l'embarqué.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 13 février 2014 à 16:22. Évalué à 2.
        
        Tu as raison, les planes sont généralement utilisés dans l'embarqué. Cependant, toutes les cartes ont au moins un plane pour le curseur. Ensuite, ça dépend des GPUs.
        
        En général, y'a aussi des planes pour les vidéos, mais le format est limité au YUV. Sur les cartes NVIDIA, on a une plane par CRTC. C'est pas énorme mais c'est déjà pas mal ;)
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 14 février 2014 à 03:48. Évalué à 3.
        
        Hmm hmm, bien sûr que c'est possible. Tu peux mmaper des buffers graphiques et y acceder depuis le CPU. Inversement, les GPUs font du DMA depuis la VM de la tâche utilisateur.
        
        Si tu le fais, tu te retrouves avec un buffer cote GPU qui n'est pas dans son format interne et tu perds en performance (Cela se sent pas mal sur les GPU ARM, moins sur Intel). De plus dans toutes les implementations que j'ai vu sur ARM, celui-ci forcait un stall du pipeline cote GPU (Theoriquement non necessaire, si on a des texture double bufferises mais je n'ai jamais vu d'implementation qui faisait cela (je n'ai pas regarder ce que faisait mon intel)). Il ne faut pas oublier qu'un compositeur a la difference d'un jeu, va updater ses textures quasiment a chaque frame. Ceux sont donc des problemes que seul les compositeurs voient. Le fait est que les drivers sont pour l'instant optimise pour les jeux pleines ecran lorsque le compositeur est desactive et qu'il y a encore beaucoup de boulot de ce cote la.
        
        Tu pourrais refaire des tests sur ton ordi ?
        
        Je referais le test dimanche, mais tu as teste avec quoi ? Perso mon test, c'est de lancer emacs dans Terminology sous Enlightenment et avoir un powertop dans un second tab dans Terminology pour voir la consomation. Je coupe aussi le Wifi/Bluetooth/Ethernet pour pas avoir de variation du a un quelconque traffic.
        
        Il pourrait même faire usage des KMS planes ce qui ferait que bouger une fenêtre consommerait ~0W coté rendu.
        
        L'utilisation des planes pourra effectivement aider enormement. Et pas uniquement lorsqu'on utilise OpenGL, car tres souvent le hardware qui gere les plans graphiques est decorele de celui qui fait l'acceleration OpenGL. Ceux-la ouvre des trucs tres interressant. Par exemple avec 5 plans graphiques pour une application full screen, tu peux parfaitement imaginer gerer une liste verticale a 60fps en software. Tu utilises 3 plans pour la liste, un pour l'overlay, un pour le background. A tout moment, tu n'affiches jamais que 2 plan pour la liste, le 3eme etant en preparation. Avec des plans de la bonne taille, tu as le temps de mettre a jour le 3eme avant que celui ne soit affiche et tu peux le faire dans un thread separe qui ne bloquera pas l'animation des autres plans en mouvement qui ne necessite pas de rendu. Ca demande beaucoup de logique dans le toolkit (identique que ce soit avec le GPU ou en soft qu'on remplisse les dit plan). C'est aussi quelque chose qui s'applique tres bien pour les navigateurs web.
        
        Par contre Wayland n'expose pas encore un moyen pour les applications de savoir combien de plan son disponible et si c'est une bonne idee de les utiliser (Par exemple oui pour l'application qui a le focus, moins pour celle en background). Clairement la standardisation de l'API pour manipuler les plans ouvrent un certain nombre de chose tres interressante cote toolkit, mais il y a du boulot !
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 14 février 2014 à 08:48. Évalué à 3.
        
        Si tu le fais, tu te retrouves avec un buffer cote GPU qui n'est pas dans son format interne et tu perds en performance (Cela se sent pas mal sur les GPU ARM, moins sur Intel). De plus dans toutes les implementations que j'ai vu sur ARM, celui-ci forcait un stall du pipeline cote GPU (Theoriquement non necessaire, si on a des texture double bufferises mais je n'ai jamais vu d'implementation qui faisait cela (je n'ai pas regarder ce que faisait mon intel)). Il ne faut pas oublier qu'un compositeur a la difference d'un jeu, va updater ses textures quasiment a chaque frame. Ceux sont donc des problemes que seul les compositeurs voient. Le fait est que les drivers sont pour l'instant optimise pour les jeux pleines ecran lorsque le compositeur est desactive et qu'il y a encore beaucoup de boulot de ce cote la.
        
        Je suppose que tu parles de perdre le tiling sur le BO. T'es pas obligé de le perdre si tu le refais avec ton CPU. Mais bon, tu peux tjs rendre la différence sur ton CPU et demander à la carte de faire le blit sur le buffer actuel. Pas besoin de faire un accès direct ni de re-rendre toute l'image.
        
        Je referais le test dimanche, mais tu as teste avec quoi ?
        
        J'étais sous KDE. Yakuake de lancé et qui prenait le quart haut de l'écran. Dedans y'avais une appli qui me donne la conso toute les secondes (qui avait été dev par un pote, c'est pas public).
        
        Pour le test idle, je ne faisais rien de plus que regarder la conso une fois qu'elle s'était stabilisée.
        Pour le test en bougeant une fenêtre, je faisais juste bouger une fenêtre dans les 3/4 d'écran qu'il reste.
        
        Clairement la standardisation de l'API pour manipuler les plans ouvrent un certain nombre de chose tres interressante cote toolkit, mais il y a du boulot !
        
        C'est pas au toolkit de gérer ça. Y'a que le compositeur qui peut les utiliser ou, au moins, les attribuer à des clients graphiques. Ces clients n'ont jamais à gérer l'affichage dans Wayland, ils ne font que rendre des buffers. C'est pour ça qu'à terme, ils devront uniquement utiliser des render nodes.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 14 février 2014 à 13:17. Évalué à 1.
        
        Mais bon, tu peux tjs rendre la différence sur ton CPU et demander à la carte de faire le blit sur le buffer actuel. Pas besoin de faire un accès direct ni de re-rendre toute l'image.
        
        Ce qui revient donc a une copie :-)
        
        J'étais sous KDE.
        
        Hum, je ne connais pas trop kde, mais je ne savais pas qu'ils avaient un rendu CPU. Intéressant. Je vais voir si je me motive pour faire un benchmark croisé ce weekend, ou si je teste juste avec enlightenment. Pour gagner un peu de temps, tu peux me décrire comment activer le rendu CPU ?
        
        C'est pas au toolkit de gérer ça. Y'a que le compositeur qui peut les utiliser ou, au moins, les attribuer à des clients graphiques. Ces clients n'ont jamais à gérer l'affichage dans Wayland, ils ne font que rendre des buffers.
        
        Ah, mais si, c'est au toolkit de gérer ça ! Il faut a terme que le protocole indique aux applications le nombre de layer disponible pour que celui ci prenne la meilleur décision possible concernant le nombre de buffer a utiliser. Ensuite le serveur wayland devra juste programmer kms pour placer les dis buffer dans les bons plans.
        
        Il ne faut pas oublier que certaines machine peuvent gérer de l'ordre de la dizaine de plans simultanées (exemples la raspberry pi ). Il serait dommage de ne pas en tirer partie (cela demande certe beaucoup d'infrastructure dans les toolkit, mais pour gagner niveau consommation comme rien d'autres !).
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par ariasuni le 14 février 2014 à 13:56. Évalué à 1.
        
        Pour gagner un peu de temps, tu peux me décrire comment activer le rendu CPU ?
        
        Configuration du système → Effets de bureau → Options avancées → Mode d’affichage composite → choisir «XRender».
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 14 février 2014 à 14:49. Évalué à 7.
        
        Ce qui revient donc a une copie :-)
        
        Tu sais, écrire direct dans la VRAM, c'est faire une copie d'un registre à une adresse mémoire. Là, je te parle pas de faire une copie de tout l'écran, je te parle de copier les différences. Que ce soit le CPU qui fasse ça ou le GPU, c'est pareil.
        
        Pour gagner un peu de temps, tu peux me décrire comment activer le rendu CPU ?
        
        Ctrl + alt + F12
        
        XRender est tjs accéléré par le GPU, donc c'est pas la solution.
        
        Ah, mais si, c'est au toolkit de gérer ça !
        
        Et comment tu fais ton protocole de réservation de plane? Si tu veux utiliser plusieurs planes dans Wayland, tu utilises les subsurfaces. Les fenêtres et les sub-surfaces seront mappées sur les différents planes sans que l'application ait besoin de connaitre quoi que ce soit. Donne moi un cas où ça ne marcherait pas?
        
        Comme je disais, l'application doit donner ses buffers graphiques et indiquer comment faire la composition interne de ses subsurfaces. Ensuite, c'est au compositeur de faire de son mieux.
        
        Un exemple de cas qui marcherait pas si on faisait comme tu le dis, les screenshots. Quand on fait un screenshot, les planes sont pas visibles, donc il faut temporairement faire le rendu totalement en GL. Tu proposes de gérer ça comment si c'est les applications qui font le travail?
        
        Au final, le compositing doit être fait dans le compositeur. Ça sonne bien et ça un sens ;)
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 14 février 2014 à 15:24. Évalué à 0.
        
        Et comment tu fais ton protocole de réservation de plane? Si tu veux utiliser plusieurs planes dans Wayland, tu utilises les subsurfaces.
        
        Nop, il faut une "négociations", sinon tu te retrouve a devoir gérer plus d'information côté compositer que nécessaire ! De plus les sub surface ne gèrent pas le clipping de manière suffisante si je me souviens bien pour cette tâche. Il sera nécessaire d'étendre le protocole.
        
        Un exemple de cas qui marcherait pas si on faisait comme tu le dis, les screenshots.
        
        Je ne vois pas pourquoi. Tu as de toute façon accès a tous les buffer. Mais je n'ai pas regarder cette aspect plus que de manière théorique pour l'instant.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 14 février 2014 à 15:55. Évalué à 4.
        
        Nop, il faut une "négociations", sinon tu te retrouve a devoir gérer plus d'information côté compositer que nécessaire ! De plus les sub surface ne gèrent pas le clipping de manière suffisante si je me souviens bien pour cette tâche. Il sera nécessaire d'étendre le protocole.
        
        Euh, même si tu faisais de la négociation, tu seras toujours obligé de supporter l'upload des BO sur planes et le compositing GL du reste. Du coup, je vois pas ce que ça t'apporte en terme de complexité si ce n'est de rendre l'exécution des applications plus complexe (imagine les cas où 3 planes seront dispo, ça marche et quand y'en a 4 ou 6, ça marche plus, va debugger ça!).
        
        Pour les subsurfaces qui supportent mal le clipping, faut étendre le protocole.
        
        Je ne vois pas pourquoi. Tu as de toute façon accès a tous les buffer. Mais je n'ai pas regarder cette aspect plus que de manière théorique pour l'instant.
        
        Au final, ce que tu proposes, c'est de faire exactement ce que je propose avec en plus une phase de négociation pour le nombre de plane. Ça n'a de sens que si tu veux garantir des performances GL. Ça me semble vraiment pas utile vu le coup du compositing.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 16 février 2014 à 13:42. Évalué à 1.
        
        Du coup, je vois pas ce que ça t'apporte en terme de complexité si ce n'est de rendre l'exécution des applications plus complexe (imagine les cas où 3 planes seront dispo, ça marche et quand y'en a 4 ou 6, ça marche plus, va debugger ça!).
        
        La question du test n'est pas un vrai probleme, car la logique de gestion des plans cote toolkit est quelque chose de similaire quelque soit le backend (software ou GL). Il est donc envisageable de simuler le fonctionnement sans dependre du protocol Wayland (Et rendre le debuggage tout a fait jouable). Pour ce qui de l'avantage, plus tu demandes de travail au serveur alors que ce n'est pas necessaire. Tu augmentes la charge de travail et donc la consomation d'energie. Probablement aussi reduit les performances du systeme. Mais il est vrai qu'il faudra faire le test pour en etre certain.
        
        Pour les subsurfaces qui supportent mal le clipping, faut étendre le protocole.
        
        Oui.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 16 février 2014 à 15:00. Évalué à 5.
        
        La question du test n'est pas un vrai probleme, car la logique de gestion des plans cote toolkit est quelque chose de similaire quelque soit le backend (software ou GL). Il est donc envisageable de simuler le fonctionnement sans dependre du protocol Wayland (Et rendre le debuggage tout a fait jouable). Pour ce qui de l'avantage, plus tu demandes de travail au serveur alors que ce n'est pas necessaire. Tu augmentes la charge de travail et donc la consomation d'energie. Probablement aussi reduit les performances du systeme. Mais il est vrai qu'il faudra faire le test pour en etre certain.
        
        Au final, si une application a différentes surfaces, elle n'a qu'à les envoyer en suivant le protocole des sub-surfaces et le compositer dispatchera sur les planes dispo et compositera le reste avec des shaders. C'est exactement ce que je disais avant et pas besoin de négociation. Ça n'apporte rien et au contraire, le toolkit fera une décision merdique quoi qu'il arrive car le compositeur peut à chaque image choisir comment dispatcher les surfaces alors qu'avec ta négociation, il sera bloqué (les applis n'ont pas à savoir quelle partie de leur fenêtre est présentement visible et ne peuvent donc pas "libérer" des planes). Je ne parle même pas du cas du screenshot/screen capture.
        
        Cite moi des cas pratiques où la négociation apporte des avantages et on verra si ça a vraiment un sens (je suis vraiment sceptique).
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 18 février 2014 à 10:39. Évalué à 2.
        
        Cite moi des cas pratiques où la négociation apporte des avantages et on verra si ça a vraiment un sens (je suis vraiment sceptique).
        
        L'exemple le plus simple, c'est une application qui n'a plus le focus et donc n'a plus d'activiter. En forcant l'utilisation permanente de buffer, tu augmentes la consomation de memoire de tes applications en tache de fond. Certe on pourrait juste eviter la negociation et se dire que des qu'une application est en tache de fond, alors on peut juste droper les buffers et faire un rendu flat.
        
        Autre exemple, ou on aurait un benefice, tu as une application avec deux listes qui necessites donc normalement 2+3*2 plans. Or ton systeme ne les fournit pas. Hors une seule des deux listes est activement anime. Si tu as une negociation dynamique, l'application va utiliser des buffers pour une seule des listes et droper les buffers asap pour l'autre liste. Par contre, sans negociation, le compositeur doit determiner quel sont les buffers qu'il vaut mieux mettre dans un plan et ceux qu'il vaut mieux "compositer". Or il va avoir du mal a le faire en avance, car il ne sait pas quel buffer va etre bouge lors de la prochaine frame. Il se retrouve a prendre une decision au hazard et peut etre faire un compositing de trop. Alternativement, le toolkit peut en permanence minimiser le nombre de plan qu'il utilise. Mais auquel cas, meme lorsque tu as un hardware capable de gerer le nombre maximum, tu te retrouves a avoir un risque de frame drop lors du debut de l'animation de la seconde liste.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 18 février 2014 à 13:02. Évalué à 2.
        
        L'exemple le plus simple, c'est une application qui n'a plus le focus et donc n'a plus d'activiter. En forcant l'utilisation permanente de buffer, tu augmentes la consomation de memoire de tes applications en tache de fond. Certe on pourrait juste eviter la negociation et se dire que des qu'une application est en tache de fond, alors on peut juste droper les buffers et faire un rendu flat.
        
        Avec le compositing, une appli ne sait jamais si elle est visible ou pas, et c'est très bien comme ça sinon ça pose d'autres problèmes.
        
        Autre exemple, ou on aurait un benefice, tu as une application avec deux listes qui necessites donc normalement 2+3*2 plans.
        
        Pourquoi une liste serait dans un plan différent, ça apporte quoi? Ne pas avoir à re-rendre la liste? Typiquement, les plans doivent être utilisés quand tu as des sources de données de format différent. Par exemple, un lecteur vidéo: Un plan pour la vidéo et un plan pour les overlays. Ensuite, si une appli n'a plus besoin d'une sub-surface, alors elle n'a qu'à la libérer. Je vois vraiment pas en quoi le fait de savoir quels plans sont disponibles va aider les applis, elle peuvent utiliser les sub-surface qui sont une abstraction des plans qui seront rendus en matériel ou en shader, suivant le matos.
        
        Je sais pas à quel vitesse on peut allouer un plan, mais ça devrait pas être trop lent.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 18 février 2014 à 14:38. Évalué à 3.
        
        Avec le compositing, une appli ne sait jamais si elle est visible ou pas, et c'est très bien comme ça sinon ça pose d'autres problèmes.
        
        Pas sous X. Sous X lorsqu'une application est iconifie, sa fenetre n'est plus mappe et il est donc possible pour le toolkit de le detecter. Et pour le focus, c'est pareil, on peut parfaitement le detecter et agir en consequence. Savoir comment une fenetre est utilise, est tres pratique pour pas mal de cas. Pense par exemple que tu as un pager qui affiche une miniature d'une fenetre ouverte sur un desktop virtuel que tu ne vois pas autrement, a quoi cela sert-il de rafraichir son contenu en haute resolution a 60fps ? Est-ce que ca ne vaudrait pas le cout de ne negocier qu'une mini version avec une mise a jour plus lente ? Il y a plein d'effet exigeant pour le CPU et le GPU sur un desktop qui s'y ils avaient a manipuler des fenetres plus adapte a la sortie sur l'ecran, consommerait nettement moins de ressource (et donc pourrer tourner sur des machines plus limite).
        
        Pourquoi une liste serait dans un plan différent, ça apporte quoi? Ne pas avoir à re-rendre la liste?
        
        Tu decoupes la liste en 3 morceaux de chacun 2/3 de la taille de la liste a l'ecran. Tu remplis chaque morceau en avance, puis tu ne fais que deplacer les elements. Quand tu depasses les 1/3 de la liste dans une direction ou dans l'autre, tu ne redessines en asynchrone qu'un des trois buffers. Ca limite grandement les chances de frame drop et tu as une tres faible utilisation CPU et GPU, donc basse consomation et fonctionne sur une plus grande gamme de materiel.
        
        Je sais pas à quel vitesse on peut allouer un plan, mais ça devrait pas être trop lent.
        
        En general, c'est tres lent et on est oblige (en tout cas sous X) de faire des caches pour ne pas en allouer trop souvent. Il ne faut pas obliger que entre deux images, on n'a que 16ms pour tout faire…
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par claudex le 18 février 2014 à 14:52. Évalué à 4.
        
        Et pour le focus, c'est pareil, on peut parfaitement le detecter et agir en consequence.
        
        Tu peux tout à fait avoir des fenêtre qui n'ont pas le focus mais qui sont visible et qui doivent donc être mise à jour.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 19 février 2014 à 03:20. Évalué à 2.
        
        Une application qui n'a plus le focus, n'a plus d'interaction avec l'utilisateur. Ce qui limite de maniere tres importante le domaine de ce qui va s'y passer. Il devient donc logique de dropper une bonne partie des donnees en cache (qui servent principalement pour reagir lors d'une interaction utilisateur). Et il est meme probable que de leger frame drop sont acceptable lors des animations imprevisibles qu'une application peut generer (Affichage de log dans une liste, ou resultat de traffic reseau).
        
        Du cote des experiences mene dans ce domaine, Enlightenment change dynamiquement la priorite des taches pour avoir toujours une plus grande priorite a la tache qui a le focus. Cela est le cas depuis deja 10 ans ou presque et aucun utilisateur n'y a trouve a redire. Donc accepter de perdre un peu de performance au benefice de la charge memoire est a mon sens completement acceptable dans ce scenario.
        
        Bon, on ne va pas non plus etre super aggressif dans le scenario de la perte de focus et on gardera donc plus de donnees pretes a l'utilisation. Mais dans le scenario ou une application n'est plus affiche du tout a l'ecran, la on va devenir tres aggressif sur notre usage memoire. Si c'est une application OpenGL, on va dropper le context. Si c'est une simple application en rendu software, on va juste dropper tous les buffers et la majeure partie des ressources graphiques. En supplement on travail aujourd'hui a compresser/defragmenter a la vole les structures de nos objets.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par devnewton 🍺 (site web personnel) le 27 mars 2014 à 15:51. Évalué à 3.
        
        Une application qui n'a plus le focus, n'a plus d'interaction avec l'utilisateur. Ce qui limite de maniere tres importante le domaine de ce qui va s'y passer
        
        Comme pour un lecteur de vidéos ou visualiseur d'image?
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 29 mars 2014 à 04:02. Évalué à 2.
        
        Exactement, dans le cas d'un lecteur vidéo, tu suivra le framerate de la vidéo et tu n'as probablement pas d'animation kikoolol durant la lecture. Il y a aussi probablement pas beaucoup d'objets affiché et il n'est plus nécessaire de garder en mémoire les menus et autres éléments graphique qui ne seront très probablement pas utilisé avant la fin de la vidéo.
        
        Pour le visualisateur d'image, c'est probablement encore mieux,vu que tu ne vas pas changer d'image a chaque frame. Il faut juste pouvoir près chargé l'image a venir… le seul cas,ou je vois un problème potentiel,c'est si tu veux faire l'effet mal de mer avec une animation a 60fps. La,il faudra forcer la main et ne pas laisser le toolkit descendre le framerate.
        
        Mais tu pensais probablement a un problème en prenant ces deux exemples, non ?
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 18 février 2014 à 18:36. Évalué à 2.
        
        Pense par exemple que tu as un pager qui affiche une miniature d'une fenetre ouverte sur un desktop virtuel que tu ne vois pas autrement, a quoi cela sert-il de rafraichir son contenu en haute resolution a 60fps ?
        
        Oui, c'est une remarque valable, il me semble que ça a déjà été proposé. La solution proposée était de faire du throttling coté compositeur. Le compositeur pourrait aussi envoyer un signal quand l'appli est ou n'est plus visible. L'appli pourra ensuite choisir de faire ce qu'elle veut (continuer à rendre à 60 fps ou se limiter à 1 fps).
        
        Pourquoi une liste serait dans un plan différent, ça apporte quoi? Ne pas avoir à re-rendre la liste?
        Tu decoupes la liste en 3 morceaux de chacun 2/3 de la taille de la liste a l'ecran. Tu remplis chaque morceau en avance, puis tu ne fais que deplacer les elements. Quand tu depasses les 1/3 de la liste dans une direction ou dans l'autre, tu ne redessines en asynchrone qu'un des trois buffers. Ca limite grandement les chances de frame drop et tu as une tres faible utilisation CPU et GPU, donc basse consomation et fonctionne sur une plus grande gamme de materiel.
        
        C'est sûr que si la liste est gigantesque, vaut mieux faire ça :) On est d'accord!
        
        Je sais pas à quel vitesse on peut allouer un plan, mais ça devrait pas être trop lent.
        En general, c'est tres lent et on est oblige (en tout cas sous X) de faire des caches pour ne pas en allouer trop souvent. Il ne faut pas obliger que entre deux images, on n'a que 16ms pour tout faire…
        
        Ce sera à tester, mais c'est en effet une raisonnement valide ;)
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par ariasuni le 14 février 2014 à 15:50. Évalué à 2.
        
        XRender est tjs accéléré par le GPU, donc c'est pas la solution.
        
        Ah oui je suis bête…
        
        Mais quelle est la différence entre XRender, Native et Raster?
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par wismerhill le 14 février 2014 à 19:55. Évalué à 9.
        
        Pour gagner un peu de temps, tu peux me décrire comment activer le rendu CPU ?
        
        Ctrl + alt + F12
        
        Non, ça c'est pour passer à la console virtuelle 12.
        Pour désactiver les effets de bureau c'est Shift+Alt+F12
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 14 février 2014 à 23:54. Évalué à 3.
        
        Damn, j'y étais presque, à une touche près ;) Merci pour la correction!
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par ZeroHeure le 14 février 2014 à 13:35. Évalué à 2.
        
        y'avais une appli qui me donne la conso toute les secondes (qui avait été dev par un pote, c'est pas public).
        
        y'a pas moyen d'avoir le code ? j'aimerai bien faire mumuse moi aussi!
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 14 février 2014 à 14:51. Évalué à 5.
        
        C'est pas à moi ce code. On me l'a donné sur #nouveau mais je me souviens plus qui l'a écrit. Enfin, c'est juste une lecture de l'indicateur de batterie et c'est super dépendant du matériel.
        
        Regarde dans /sys/class/power_supply/BAT0/, tu devrais trouver ton bonheur :)
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par ZeroHeure le 14 février 2014 à 17:57. Évalué à 2.
        
        merci!
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 16 février 2014 à 07:24. Évalué à 2.
        
        Alors sur mon PC (Samsung Series 9 13" de 2012) avec Enlightenment et Terminology, j'obtiens les chiffres suivant :
        
        en idle :
        
        rendu CPU : 9.99 W
        
        rendu GPU : 10.9 W
        
        en faisant bouger une fenetre :
        
        rendu CPU : 11.1 W
        
        rendu GPU : 11.5 W
        
        En activant le canal alpha sur la fenetre de terminology :
        
        en idle :
        
        rendu CPU : 10.7 W
        
        rendu GPU : 10.9 W
        
        en faisant bouger une fenetre :
        
        rendu CPU : 11.7 W
        
        rendu GPU : 11.6 W
        
        Ca correspond a ce que j'attendais et c'est completement logique. Le cas de la figure transparente qui bouge consomme plus avec le CPU que le GPU, car on a passe la limite entre le surcout d'utiliser le GPU et celui du CPU.
        
        J'ai fais tous les tests avec une version git des efl et en utilisant powertop pour mesurer la consomation (Wifi et Ethernet desactive, luminosite ecran au minimum). Par contre, j'ai une regression quelque part dans mon systeme, car je descendais a 8 ou 7W, il y a 3 mois. Mais je ne pense pas que ca ait un impact sur les resultats.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par Martin Peres (site web personnel) le 16 février 2014 à 10:41. Évalué à 2.
        
        Ok, merci pour les résultats. Quelle carte graphique as-tu dans ton ordi?
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 16 février 2014 à 13:31. Évalué à 2.
        
        C'est un systeme Ivy-Bridge i7-3517U.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par lasher le 18 février 2014 à 04:56. Évalué à 2.
        
        (Par exemple, meme si tu utilises une memoire partage entre CPU et GPU, il n'est pas possible pour le GPU d'utiliser directement la memoire d'une tache utilisateur et reciproquement en fait).
        
        C'est vrai aussi sur les archis de type Fusion d'AMD? Ou bien sur les prochains processeurs d'Intel qui auront le MIC/Xeon Phi et les multicœurs sur le même die ?
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 18 février 2014 à 06:48. Évalué à 2.
        
        Pour AMD, ca fait des annees que j'ai arrete de m'interresser a leur plateforme du fait des problemes de stabilites de leur driver proprio qui ne peut servir globalement qu'a faire des jeux… et encore ! Nous recevons la majorite de nos rapports de bug driver en provenance de leur plateforme, donc je ne suis pas pres de changer d'avis tout de suite (Meme si apparement le driver radeon semble avoir moins de probleme que le driver proprio).
        
        Pour ce qui est de Intel, ce n'est pas une question d'etre sur le meme die, mais bien d'utiliser le meme format interne que le GPU. Celui-ci est souvent tile (en gros un espece de pavage avec un ordre plus ou moins bizarre en fonction du GPU) et necessite donc quelques manipulations de pixels d'un cote ou de l'autre. Si ce n'est pas fait, la manipulation des dites ressources devient plus lente et consomme donc plus d'energie.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par lasher le 19 février 2014 à 05:09. Évalué à 2.
        
        Je ne connais absolument pas les GPU Intel, et je suppose que ce que tu me dis s'y applique aussi. Pour le MIC, il s'agit de « bêtes » x86 avec AVX + 4 hyperthreads, le tout avec un système de caches cohérents (c'est l'ancien Larrabee). Donc ma question sur le MIC était sans doute hors sujet vu que c'est surtout censé servir d'accélérateur pour le calcul (mais après tout, si l'accélérateur se retrouve sur le même die, ça peut p'tet servir à faire du « rendu via CPU » ;-) ), et il aurait fallu plutôt la poser à proposer des GPU intégrés sur Ivy Bridge/Sandy Bridge…
      - [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 13 février 2014 à 02:29. Évalué à 2.
        
        pourquoi pas, sauf qu'ici aussi ,le gestionnaire de fenêtre à peu de travail à effectuer: le mode fenêtré en question prend un de mes écrans en entier ;) on peut presque dire qu'il s'agit d'un mode fullscreen, au final. Presque. )
        
        Sauf que pas de bol, mais X ne peut pas gerer les ecrans individuellements et faire un rendu direct (en evitant une copie) dans ce scenario la. Avec Wayland, si les deux surfaces matchs, il est possible d'avoir un chemin raccourci et de pouvoir utiliser directement le buffer de l'application pour la sortie lie a l'ecran en question.
        
        plus spécialisé que Xorg ( ne fait qu'une chose, on peut donc espérer qu'il la fera bien. )
        
        Ca par contre, c'est un peu faux. Il y a beaucoup plus de boulot dans une implementation de Wayland que dans une implementation de X. Simplement parce que le windows manager, le composite manager et X ont ete merge ensemble.
        
        portable ( avec un peu de bol, quelqu'un finira peut-être par en faire serveur pour windows, histoire d'enrichir nos kits de survie en environnement hostile /me rêve )
        
        Ca aussi, c'est assez mal informe. Il n'y a pas de bibliotheque d'abstraction du systeme de buffer. Ce qui veut dire qu'il faut se taper la dite manipulation par cible potentiel (Et le projet Wayland n'est pour l'instant pas interresse par une telle bibliotheque). Et oui la gestion des buffers video sous Linux, Android, RPi, … est differente. Donc la portabilite est aussi complique que celle de X, sauf qu'il faut penser a porter CHAQUE implementation de Wayland completement…
        
        de la diversité … kfreebsd …
        
        Et bien justement, vu qu'on parle de portabilite, tu vas avoir quelques restrictions pour Wayland sur Freebsd. Avec un peu de chance tu auras un backend fbdev.
        
        avec un peu de bol, moins pénible a configurer que Xorg?
        
        Ca, ca dependra de chaque implementation. Avec un peu de chance, sous GNOME, ils n'auront meme pas mis d'option de configuration :-D
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par freem le 13 février 2014 à 13:58. Évalué à 1.
        
        Sauf que pas de bol,
        
        Serait-ce pour ça que j'ai dit "on peut presque dire " ? Ce que je voulais dire, c'est que point de vue utilisateur, ça y ressemble ( surtout s'il s'agit d'un jeu qui a implémenté correctement la capture de la souris ), alors qu'en terme de fonctionnement interne, je sais que ça n'a rien à voir. Je ne suis pas bon, mais il y a des limites tout de même :)
        Et de toute façon, je crois avoir remarqué que X n'a pas été pensé avec l'optique du multi-écran. ( je parle du moment de sa création, je sais que c'est maintenant possible )
        
        Ca par contre, c'est un peu faux. … le windows manager, le composite manager et X ont ete merge ensemble.
        
        Dans la FaQ de Wayland, il est dit qu'un des problèmes de X est la surabondance de fonctionnalités qui ne sont plus utiles à l'heure actuelle, et qu'il est nécessaire d'implémenter si l'on veut prétendre au titre de serveur X.
        Le window manager, qui peut être composite ou non si je ne comprend pas trop mal les divers trucs que j'ai lus rapidement, est aussi un truc qui peut manifestement se coder en peu de lignes: dwm pèse moins de 2KLoC, je crois? ( Je n'émet aucun jugement quant au fait que ce soit une bonne ou une mauvaise chose, hein, je dis juste que c'est possible en peu de lignes. )
        
        Du coup je m'imagine qu'il y a moyen que ça prenne moins de lignes de code de faire un serveur Wayland qu'un serveur X.
        
        Ca aussi, c'est assez mal informe. Il n'y a pas de bibliotheque d'abstraction du systeme de buffer.
        
        Et y a t-il une quelconque raison technique qui rendrait ça impossible avec le présent protocole?
        Je me trompe peut-être, mais Wayland est bien un protocole d'échange entre le serveur graphique et les applications, non? A partir de la, qu'est-ce qui empêcherait d'avoir un mécanisme d'IPC? Ce genre de choses existe depuis bien longtemps, et si Wayland finit par être réellement adopté, je doute que personne ne fera de serveur Wayland sur les autres systèmes.
        En fait, je doute que Wayland ne sera implémenté que pour linux sur amd64 ( puisque tu parles du rPI notamment, je serai surpris qu'il n'y ait pas un port dans plus ou moins longtemps ) et à force d'avoir diverses implémentations, peut-être qu'une lib se dégagera?
        
        Et bien justement, vu qu'on parle de portabilite, tu vas avoir quelques restrictions pour Wayland sur Freebsd. Avec un peu de chance tu auras un backend fbdev.
        
        Je n'ai pas creusé très loin, mais il semble que certains essaient.
        En plus, même de la diversité non portable, c'est une bonne chose. Je ne vois aucun inconvénient à avoir une alternative à X, qu'elle soit portable ou non.
        Pour BSD, vu qu'il y a moyen de faire tourner Wayland sur X je crois, il y aura au minimum cette solution la, même si la personne qui à fait quelques patchs à lâché l'affaire depuis ( je n'ai pas creusé, comme je l'ai dit. ).
        
        Je pense que Wayland est un protocole, et qu'en tant que tel, il est possible de coder ( que ce soit plus ou moins simple en fonction de la cible, c'est évident ) un serveur Wayland sur n'importe quel OS qui ait des périphériques d'entrée pointage+saisie et un périphérique de sortie type écran. Je me trompe peut-être.
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par cedric le 14 février 2014 à 04:58. Évalué à 4.
        
        Et de toute façon, je crois avoir remarqué que X n'a pas été pensé avec l'optique du multi-écran.
        
        Tout a fait.
        
        Le window manager, qui peut être composite ou non si je ne comprend pas trop mal les divers trucs que j'ai lus rapidement, est aussi un truc qui peut manifestement se coder en peu de lignes: dwm pèse moins de 2KLoC, je crois?
        
        Pour un Window Manager simple oui. Pour un compositeur, meme simple, c'est deja un peu plus gros. Mais le probleme va se poser des que tu vas vouloir supporter un peu plus que juste les machines x86 (genre un backend specifique pour RPi ou n'importe laquelle des plateforme ARM en fait). La complexite explose tres rapidement de ce cote la. Ensuite si tu veux avoir des perfs decentes, tu vas devoir aussi optimiser pas mal ton compositeur, et forcement le nombre de ligne va augmenter. Au final, il sera tres difficile de refaire des tres petits WM comme sous X (Normal vu qu'il faut implementer une bonne partie de ce qui est dans X aujourd'hui).
        
        Ca aussi, c'est assez mal informe. Il n'y a pas de bibliotheque d'abstraction du systeme de buffer.
        
        Et y a t-il une quelconque raison technique qui rendrait ça impossible avec le présent protocole?
        
        Principalement une volonte du mainteneur de Wayland/Weston qui ne voit pas d'utiliter a cela. Il pourrait changer d'avis un jour…
        
        [^] # Re: Gestionnaire de fenêtres léger
        
        Posté par freem le 14 février 2014 à 10:47. Évalué à 1.
        
        Ca aussi, c'est assez mal informe. Il n'y a pas de bibliotheque d'abstraction du systeme de buffer.
        
        Et y a t-il une quelconque raison technique qui rendrait ça impossible avec le présent protocole?
        
        Principalement une volonte du mainteneur de Wayland/Weston qui ne voit pas d'utiliter a cela. Il pourrait changer d'avis un jour…
        
        Compte tenu du fait qu'on parle d'un ~~logiciel~~ protocole libre, ce n'est pas à la seule volonté de l'équipe de ~~weston~~ wayland.
    - [^] # Re: Gestionnaire de fenêtres léger
      
      Posté par barmic le 12 février 2014 à 12:49. Évalué à 5.
      
      Je dirais aussi qu'il fallait des fois simplement configurer les options correctement. La souplesse des fenêtres pouvait devenir plus vivables avec un paramétrage fin, de même pour toutes les animations en les rendant plus courtes.
      
      Certaines options étaient ergonomiques comme le changement de bureau que ce soit par glissement ou autre, ça permet de mettre quelque chose de visuel sur une action, le zoom n'importe où dans l'écran aussi.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Pilotes propriétaires

Posté par azmeuk (site web personnel) le 10 février 2014 à 01:15. Évalué à 1.

Une question me turlupine, et pardonnez moi si elle est profane. Y aura-t-il un besoin pour les éditeurs de drivers propriétaires de les adapter à Wayland, ou bien sont-ils indépendants du serveur graphique ?
- [^] # Re: Pilotes propriétaires
  
  Posté par ariasuni le 10 février 2014 à 08:31. Évalué à 3.
  
  En effet, il faudra que les éditeurs de pilotes non-libres modifient leurs pilotes, car leur architecture n'utilise pas KMS (et il y a peut-être d'autre choses à prendre en compte?).
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Pilotes propriétaires
    
    Posté par claudex le 10 février 2014 à 21:06. Évalué à 5.
    
    Il me semble que KMS n'est pas du tout nécessaire. C'est EGL qui est nécessaire.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Pilotes propriétaires
      
      Posté par ariasuni le 10 février 2014 à 22:27. Évalué à 0.
      
      En fait, il semblerait que ça soit les deux qui soient nécessaires…
      
      Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: Pilotes propriétaires
        
        Posté par freem le 13 février 2014 à 14:01. Évalué à 1.
        
        A l'heure de cet article ( celui auquel tu fais référence ) la confusion existait entre Wayland le protocole, et Wayland l'implémentation de référence.
        
        Weston, le nouveau nom de Wayland l'implémentation de référence, dépend de KMS. Mais je ne suis pas sûr que ce soit le cas du protocole.
        Pour OpenGL & co, c'est différent puisque le but de Wayland semble être de justement d'optimiser son usage en réduisant la quantité de fois ou les données sont transférées d'un élément (processus, driver, serveur graphique, etc) à l'autre.
        
        Mais je peux me tromper.
# Déjà en production

Posté par romu le 10 février 2014 à 09:44. Évalué à 10.

Bonjour,
Il aurait été sympa que l'article mentionne que Wayland est déjà en production sur un produit disponible à la vente : le smartphone Jolla.
- [^] # Re: Déjà en production
  
  Posté par khertan le 15 février 2014 à 23:59. Évalué à 2.
  
  Il faut préciser que seul Wayland est utilisé sur SailfishOS.
# c'est bien joli ...

Posté par coucou78 le 16 février 2014 à 10:16. Évalué à -5.

Mais a quand l'equivalent intégré d'un terminal server sous linux , protocole rdp ?
Wayston a t-il cela dans ses cartons ?
- [^] # Re: c'est bien joli ...
  
  Posté par ariasuni le 16 février 2014 à 11:54. Évalué à 4.
  
  Est-ce que ça réponds à ta question?
  
  Écrit en Bépo selon l’orthographe de 1990