Coucou nal,
Je viens de découvrir un projet GSoC qui n’a bizarrement pas eu beaucoup d’écho : waypipe.
Si un reproche a fréquemment été fait à Wayland — comparativement à l’ancêtre X11 — depuis le départ, c’est bien qu’il ne prend pas en charge la « transparence réseau » chère à nos cours d’université (et jamais utilisée en vrai ; non non, ne pas se lancer là‑dessus…).
En effet, le protocole !techpro! ne fournit pas de sockets réseau, mais uniquement un socket local permettant d’initier un canal de négociation de mémoire partagée !/techpro!. Il y a bien des solutions basées sur RDP (voir ici ;-)) ou VNC, mais le reproche restait vu qu’il s’agissait d’autres protocoles établis et surtout que l’exportation était faite au niveau « bureau » — pas « fenêtre ».
Voici donc ce que donne waypipe :
J’utilise ici le compositeur Weston et lance des applications Wayland pures (l’éditeur de texte gedit et le lecteur vidéo celluloid) hébergées sur une machine distante via SSH.
Concrètement, c’est aussi simple que de lancer waypipe ssh (utilisateur)@(mdp) monprog entre deux machines équipées du binaire waypipe dans leur $PATH.
L’explication est un peu technique ; alors, en résumé : sur la machine distante, waypipe prétend être un compositeur et « sérialise » les messages Wayland vers un socket réseau UNIX établi en collaboration avec le waypipe de la machine locale. Le reste est du classique :).
Sont gérés :
- la compression réseau (via LZ4) ;
- la redirection de tampons opaques Mesa (OpenGL notamment) via le couple GBM/DRM (fonction DMABUF), ce qui permet à des applications 3D telles SuperTuxKart de tourner ;
- l’accélération de flux vidéo — non testée pour ma part — via le couple FFmpeg/libVA.
L’auteur fournit même une métrique : en désactivant la compression LZ4 et activant toutes les autres accélérations, un SuperTuxKart distant tourne à 40 images par seconde en consommant ~130 Mo/s de bande passante.
(Si l’on considère que la partie réseau « sérialisation/compression » qui est le vrai spécifique de waypipe fonctionne au niveau « buffer Wayland » plutôt que « compositeur complet » comme VNC/RDP, qu’elle est « auto‑contenue » — interne + LZ4 —, et que les autres dépendances — GBM, DRM et libVA — sont déjà trouvées dans les compositeurs tels Weston, on peut sans trop de problèmes dire que c’est natif)
Je vous encourage à tester !
# Status
Posté par ord . Évalué à 6.
et la partie interressante:
```
Status
This is usable, but still unstable right now[0]. The main development
location[1], command-line interface, wire format, and project name may
yet change completely. Bug reports and patches are always welcome.
Any of the following will crash waypipe:
Different local/client and remote/server versions
Differing byte orders
Applications using unexpected protocols that pass file descriptors; file
bug reports for these
```
Donc c'est pas vraiment utilisable au boulot. Mais ca promet ;-)
[^] # Re: Status
Posté par Tarnyko (site web personnel) . Évalué à 8. Dernière modification le 16 février 2020 à 20:16.
En fait, la principale conséquence de ça, c’est : si tu mets à jour l’outil sur une machine, il faut le mettre à jour partout.
J’ai posé la question à l’auteur de savoir si un versionnage de son protocole pourrait résoudre 90 % du problème, et si oui ce qui s’y oppose (j’attends la réponse).
# Rappel du principe
Posté par AlexTérieur . Évalué à 3.
Je suis d'accord sur ce qui a été dit dans le journal, j'ai trouvé ça classe la "transparence réseau", résultat, j'ai testé qu'une fois il y a longtemps, et je n'en ai jamais eu l'utilité. Je me rappelle simplement que la décoration était à la charge du "client" et non plus du côté serveur.
Cela dit, intéressant que Wayland finisse par y arriver (je n'ai pas trop testé le bureau à distance sous Wayland, mais j'imagine que ça marche sans plus), du coup je ne sais pas s'il y a un véritable intérêt.
[^] # Re: Rappel du principe
Posté par Sébastien Koechlin . Évalué à 10.
Le projet LTSP permet d'équiper beaucoup de salles de classes avec du vieux matériel qui sert de terminaux X banalisés et de concentrer tout le travail sur un ou quelques serveurs.
Cela fait quelques années que je l'utilise dans des associations, elles n'ont généralement pas les moyens de maintenir leur informatique, et moi je n'ai qu'un seul serveur à administrer, ce que je peux faire à distance et qui me simplifie considérablement la tache.
Donc l'auteur du journal n'utilise peut-être pas la transparence réseau; mais moi je connais des dizaines de personnes qui l'utilisent tous les jours et qui seront condamnés à un vieux ordi sous windows non administré si jamais cette transparence disparaît.
[^] # Re: Rappel du principe
Posté par Tarnyko (site web personnel) . Évalué à 4.
Il y a méprise :). Ce que je voulais dire, c'est que le forwarding "à poil" tel qu'expliqué dans les tutos n'est quasi-jamais utilisé. Ou plutôt si, mais pas tout seul.
Dans ma capture, il y a un lecteur vidéo, mais on n'entend pas le son; il faudrait créer un pipe PulseAudio.
Si je fais "Fichier"-"Ouvrir", je vois les répertoires du poste distant, mais pas les miens; il faudrait monter un sshFS distant et me positionner automatiquement dessus.
Etc…
waypipe est super-utile, mais en tant que "brique" d'un système plus complexe, un serveur d'application avec une interface de gestion et une DB d'utilisateurs. Un Terminal Server effectivement.
La vanne sur X11 vient surtout de sa lourdeur de base (pas de compression !) et qu'il faut installer plein d'autres outils pour avoir un vrai truc, genre la 3D que propose simplement waypipe avec DMABUF.
[^] # Re: Rappel du principe
Posté par zurvan . Évalué à 10.
en local la transparence réseau de X11 fonctionne bien, et je trouve ça très pratique, ça m'arrive régulièrement de l'utiliser. Je l'ai fait aussi via ssh, ça dépanne on va dire. Et c'est plus facile/rapide/pratique à mettre en place qu'un VNC.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Rappel du principe
Posté par Sébastien Le Ray . Évalué à 2.
apt-get install x11vncSur du WAN c'est utilisable contrairement à X…
[^] # Re: Rappel du principe
Posté par zurvan . Évalué à 3.
oui, et quand ça plante (c'est très fréquent avec x11vnc), il faut juste retourner sur la machine d'origine pour le relancer.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Rappel du principe
Posté par benoar . Évalué à 4.
X11 peut forwarder l'OpenGL sur le réseau depuis 20 ans à peu près…
[^] # Re: Rappel du principe
Posté par Anthony Jaguenaud . Évalué à 5.
Je n’arrive pas à trouver de lien, mais de mémoire, les stations silicon graphics dans les années 90 faisait déjà de l’opengl distant.
J’ai souvenir de GLUT, et de mémoire la transparence réseau fonctionnait déjà… dernière version 1998.
[^] # Re: Rappel du principe
Posté par Tarnyko (site web personnel) . Évalué à 5. Dernière modification le 18 février 2020 à 19:32.
Détails sur la transparence X11/GL .
En gros, ça ne fonctionne out-of-the-box qu'avec OpenGL 1.0 (mode soft) ou des drivers graphiques parfaitement aligés (mode hard). La faute à l'absence de gestion du mécanisme des extensions OpenGL par le code historique.
Pour de véritables applis utilisant OpenGL 2.x+, il faut installer p.ex. VirtualGL qui va rajouter sa couche d'abstraction ; c'était le fameux "autre outil" dont j'avais oublié le nom.
[^] # Re: Rappel du principe
Posté par benoar . Évalué à 4.
Ah, je ne savais pas pour les extensions.
Par contre, ton VirtualGL c'est autre chose : c'est utiliser l'accélération du client X11 pour envoyer des frames déjà rendues sur le client au serveur X11. Après, l'argument qu'ils avancent de la non-efficacité de faire de l'OpenGL à distance est peut-être vrai, mais du coup s'applique (de ce que je comprends) également à waypipe avec accélération 3D.
[^] # Re: Rappel du principe
Posté par Tarnyko (site web personnel) . Évalué à 1.
Intéressant. Là je tourne à la mémoire, et manque honnêtement de maîtrise récente du sujet (= il n'est pas impossible que tu aies raison). Il faudrait aussi que je fasse des benches pour comparer tout ça.
[^] # Re: Rappel du principe
Posté par ZeroHeure . Évalué à 5.
J'ai aussi beaucoup installé LTSP. Il y a d'autres projets libres similaires, pour lesquels on n'utilise pas la transparence réseau du serveur X mais les protocoles RDP, VNC ou NX (et leurs dérivés). (RDP a d'ailleurs beaucoup d'avantages pour la gestion du son, des périphériques locaux et des imprimantes.) Les utiliser efficacement demande un peu plus de ressources que X, mais avec la puissance des processeurs actuels ce n'est plus un problème.
J'ai oublié les noms de ces projets, mais ça se retrouve.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Rappel du principe
Posté par reno . Évalué à 5.
J'ai utilisé l'export de fenêtre pendant des années et c'était vraiment génial.
Maintenant je suis obligé d'utiliser VNC a cause de coupure réseau assez fréquente, mais exporter un bureau beurk c'est bien + pénible a utiliser que l'export de fenêtre (avoir a gérer plusieurs "barre des taches" :-( ) et la latence est vraiment pas terrible: un terminal "directe" est bien plus agréable a utiliser qu'un terminal par VNC.
Bah oui, du texte c'est bien moins couteux a envoyer que des bitmaps..
Ce genre de configuration est très, très fréquent pour les développeurs, dommage que ça marche si mal (non, je ne veux pas utiliser tmux et vim).
[^] # Re: Rappel du principe
Posté par dinomasque . Évalué à 5.
Utiliser la transparence réseau de X pour déporter un terminal ça fait pas un peu usine à gaz par rapport à juste une connexion SSH depuis un terminal local ?
BeOS le faisait il y a 20 ans !
[^] # Re: Rappel du principe
Posté par reno . Évalué à 2.
Je n'utilisais pas l'export de fenêtre pour déporter un terminal mais des applications.
Mon exemple sur le terminal, c'était juste une précaution/prévention car on me répond souvent que VNC c'est super: OK ça marche et j'apprécie beaucoup la persistence du contenu (je peux me déconnecter et me reconnecter une semaine plus tard: tant que le serveur n'a pas été rebooté le contenu est persisté) mais on sent vraiment la latence.
[^] # Re: Rappel du principe
Posté par dinomasque . Évalué à 2.
ah ! merci pour la précision; j'avais trébuché sur la sémantique de "terminal" ;-)
BeOS le faisait il y a 20 ans !
# déconnexion
Posté par ckiller . Évalué à 5.
Ca gère la déconnexion réseau ?
parce qu'en RDP, c'est quand même sympa de l'avoir
[^] # Re: déconnexion
Posté par Tarnyko (site web personnel) . Évalué à 7.
Excellente question :).
Alors, en n'oubliant pas que c'est basé sur le mode de transport choisi (ici, SSH); voici après avoir coupé la connexion :
La wl_shell_surface cesse de répondre au "ping" et le compositeur affiche donc le sablier. Ca reste comme ça pendant 15 secondes; je rétablis et après encore 10 secondes:
Je ne sais pas jusqu'à combien ça "tient" (je dirais : autant que la capacité de SSH à se reconnecter en mode texte selon le paramétrage) mais ça tourne !
# ça fait penser à xpra
Posté par Psychofox (Mastodon) . Évalué à 3.
Dans son fonctionnement (transport par ssh, nécessité d'avoir le binaire sur les deux hôtes cet outil fait beaucoup penser à xpra qui m'a paru bien plus performant et efficace que la transparence réseau X et vnc.
[^] # Re: ça fait penser à xpra
Posté par rzr (site web personnel) . Évalué à 3.
J ai tjr trouvé xpra sous estismé, peut etre une question d ergonomie, utilisez vous d autres outils plus orgonomiques utilisant ce dernier ?
Ce qui m'anene a la question wayland, pouvoir detacher et ratacher un display peut avoir certains use cases non ?
gpg:0x467094BC
[^] # Re: ça fait penser à xpra
Posté par Tarnyko (site web personnel) . Évalué à 2. Dernière modification le 17 février 2020 à 17:35.
Apparemment, même si ce n'est pas automatisé, la possibilité existerait :
It's possible to set up the local and remote processes so that, when the connection between the the sockets used by each end breaks, one can create a new forwarded socket on the remote side and reconnect the two processes. For a more detailed example, see the man page.
La formulation est un peu ambigue ; mais oui ce serait vraiment sympathique de retrouver sa fenêtre à partir d'un autre poste ! Il faut une petite infra quand même pour tester (deux machines avec Wayland en plus du "serveur") ; je regarde ça à l'occasion.
# mouarf
Posté par fearan . Évalué à 6.
Justement si! Se baser sur une expérience perso pour déterminer ce que les autres font, et décréter que ça sert à rien n'est pas une bonne idée.
Le forward X11, je m'en suis servi longtemps, et je continue de m'en servir
Et j'avais même fait le son déporté à l'époque ;)
j'ai même fait des trucs bizarres comme exécuter un éditeur de texte distant pour un fichier local (j'avais besoin d'un emacs récent, et la machine ne l'avait pas)
Ou tout simplement être comme sur la machine sans bouger son cul!
Notre service info demande qu'on leur laisse les portables pour la moindre manip (installation de vm par exemple), alors qu'ils pourraient tout faire en affichage déporté.
Ça c'est pour les usages standard ;)
Ensuite il y a les usages ludiques sur les écrans des collègues sans leur permission évidemment :
Et le corolaire, de ce qu'il est possible de faire quand un collègue ou camarade d'IUT ne protège pas bien :
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: mouarf
Posté par Tarnyko (site web personnel) . Évalué à 4.
Mais si ! C'est comme couper un serveur quand on te demande s'il sert encore : ça génère des appels, et après tu sais ;-).
Ca sent le xhost + lancé plus que de raison ça ;-).
Vous êtes sous quelles versions de distributions (à la louche, comme ça) ?
[^] # Re: mouarf
Posté par fearan . Évalué à 4. Dernière modification le 19 février 2020 à 17:12.
Oui mais il est guérit maintenant ;)
En IUT :
Les vieille DEC étaient très light, avec en plus le localhost autorisé (donc rsh demeter -c export DISPLAY=:0 ; xhost +" ), il n'y en avait que deux DEC qui ne l'avaient pas :D
À la fac (licence,maitrise) on avait que des terminaux X, sous un BSD il me semble.
En DESS on avait des PCs, mais je ne me souviens plus de la distribution ;)
Pour les poissons, c'était en milieu professionnel, un collègue avait la malheureuse habitude de faire des xhost + (centos 4 ou 5)
avec un pote on avait même fait un script qui tuait la session de l'indélicat qui aurait voulu lancer un mozilla sur la machine où on était loggué, ahh le bon vieux temps…
Si les anciens (2ème années ) nous avaient appris les bonne commande (xauth list, xauth add), plutôt que les mauvaises (xhost +machine), on aurait moins rigolé.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: mouarf
Posté par Tarnyko (site web personnel) . Évalué à 2. Dernière modification le 19 février 2020 à 17:46.
Wow ! On est bien loin de Wayland avec du matos de cet âge (ça démarre à RHEL 8).
Sur un tel parc, non seulement le forwarding X11 c'est le plus logique, mais sûrement tout ce qui est disponible aussi (j'imagine pas les versions modernes de freerdp, Xvnc… compiler sans patch sur DEC ou Tru64). Et pis, pas trop de contraintes de bande passante non plus sur un tel LAN.
waypipe permettra sûrement une migration sans douleur dans, disons, dix ans :-).
[^] # Re: mouarf
Posté par fearan . Évalué à 2.
Oui enfin l'IUT c'était y a 20 ans environ, j'ose espérer qu'ils ont du matos plus récent maintenant. Et puis qui sait peut être un jour on aura un compositeur wayland natif dans windows :)
Mais en attendant je reste avec mon serveur X sous windows - encore un autre usage de l'export DISPLAY ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# x2go
Posté par ted (site web personnel) . Évalué à 6.
Il y a aussi x2go qui marche pas mal. Les fonctionnalités intéressantes:
Je m'étais un peu amusé avec Blender et Gimp depuis des PC équipés de Pentium4 en client, c'était franchement utilisable. C'est bien utile pour tester une application depuis des machines normalement non compatibles.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: x2go
Posté par Tarnyko (site web personnel) . Évalué à 3.
waypipe serait typiquement une brique (centrale) d'une solution type x2go.
Il serait même possible de détecter automatiquement le protocole (X11 ou Wayland) en fonction de la présence/absence de sockets et variables d'environnment.
# Comble un manque...
Posté par lym . Évalué à 0.
… bien plus réel que l'auteur ne le laisse supposer, à titre personnel je vivrais très mal sans cela:
-En télétravail, je suis habituellement connecté à minimum une machine windows (en RDP) et 2 machines Linux (une saloperie dans le cloud et une physique en lab). Et qu'est-ce qui est le plus chiant: Ce RDP obligeant sous windows à tirer un foutu bureau complet (sans pouvoir avoir le même utilisateur utilisant le bureau en distant et local, + avec un win10 distant des polices généralement floues en distant si la définition de l'écran distant n'est pas identique au local) et d'en avoir au final 2 à gérer au lieu de fenêtres applicatives qui s'y intègrent en organisant ça par bureau virtuel.
Tirer un bureau complet distant, c'est au final de mon point de vue pas très pro, voir carrément très "tata Janine":
-A la maison, même un PI qui gère la baraque avec une raspbian minimale (sans bureau graphique complet, inutile, il est headless) fait du X11 forwarding via SSH, le combo idéal, avec juste le paquet xvfb (X11 frame-buffer) installé dessus: Si on évite les applicatifs issus de gnome/kde tirant des tétrachiées de dépendances, genre des terminaux light comme urxvt et éditeurs graphiques genre nedit, ca permet quand même de travailler dessus de manière bien plus confortable qu'avec des consoles. Avec wayland, je ne sais pas si le même genre de choses sera possible…
De ce point de vue, wayland était une regrettable régression sur l’ancêtre X11 qui fait que tant que X11 sera là, il restera sur mes machines… mais comme ça ne sera sans doute possible qu'un temps, tout ce qui va dans le sens de combler ce foutu manque va dans le bon sens, surtout si on gagne un support de l'accélération graphique au passage.
Le plus incroyable, c'est que cela n'ait pas été fait nativement. Il ne s'agit quand même pas de windows-clicodrome, mais d'un Unice construit depuis les débuts autour de la pile réseau, affichage compris.
Je pense que c'est lié au fait que la génération qui code cela, ne sachant pas vivre sans une IDE Eclipse (personnellement, je fuie), trouve que X11 via le réseau ne fonctionne pas forcément très bien avec des trucs trop complexes graphiquement (mais déjà un peu moins mal en activant la compression à la volée de SSH en plus du X11 forwarding : "ssh -XC toto@machineDistante") et non utilisatrice n'a même pas pensé à essayer de faire mieux de ce point de vue.
Merci en tout cas d'avoir fait connaître cet ajout, surtout en n'en éprouvant pas personnellement le besoin!
[^] # Re: Comble un manque...
Posté par Renault (site web personnel) . Évalué à 3.
Unix n'a jamais été conçu avec l'affichage et la pile réseau en tête. Cela a été ajouté bien après sa naissance et a donné lieu à de belles horreurs (dont X en est l'exemple le plus frappant).
Pas pour rien que ses concepteurs ont conçu Plan 9 pour faire un OS bâti avec tous ces éléments modernes en tête dans la conception d'origine.
L'architecture de X reste une belle horreur, et avec les besoins d'améliorer la sécurité de nos machines il est grand temps de s'en débarrasser. Bizarrement les amateurs de X sont souvent les premiers à vénérer la philosophie KISS et l'appel à la nostalgie des débuts d'Unix alors qu'en réalité il n'est pas conforme avec ces dogmes.
[^] # Re: Comble un manque...
Posté par lym . Évalué à 0.
Unix est traversé par la pile réseau depuis qu'il existe. Le reste a suivi cette philo et X aussi qui fait le job nativement. Un remplaçant qui retire des fonctionnalités pareilles ça n'aide pas à son adoption et d'ailleurs ça traîne depuis presque 10 ans (je m'étais d'ailleurs fait rembarrer en exposant ce gros manque aux développeurs il y a fort fort longtemps…). Maintenant que ca arrive enfin (pour les installations, pas les upgrades) avec même Debian qui s'y risque, ce qui manque et qui avait pu échapper a des utilisateurs pas forcément branchés sur le dessous du capot de l'affichage graphique va se voir. Et visiblement, certains commencent à y pallier.
Wayland et Gnome (3): Des projets un peu dogmatiques à mon goût et qui n'écoutent qu'eux mêmes… Au final, d'autres ayant des compétences sur les sujets qui fâchent font Cinnamon et waypipe, certes, mais ces attitudes n'aident pas le libre. Tout comme conchier X: Je préfère un truc qui marche à travers le réseau que gagner des FPS au jeu, même si les deux ce serait l'idéal.
Puis la sécurité, c'est un peu l'alibi du siècle. J'attends toujours les ennuis personnellement.
[^] # Re: Comble un manque...
Posté par jmiven . Évalué à 2. Dernière modification le 11 mars 2020 à 18:32.
Comme il t'a été indiqué au dessus, non, c'est incorrect. STREAMS ainsi que les sockets qu'on utilise aujourd'hui ne sont apparus qu'au milieu des années 80.
[^] # Re: Comble un manque...
Posté par Renault (site web personnel) . Évalué à 4.
Unix est né au début des années 70, il a fallu que BSD arrive 10 ans après pour que Unix voit du réseau. Ce n'est même pas les concepteurs d'Unix à l'origine qui ont travaillé à son intégration.
Donc non, le réseau n'est pas un concept fondamental dans Unix. Et quand tu vois comment le réseau est géré, tu vois que l'architecture derrière n'est pas conforme avec le reste. Ce n'est pas pour rien que Thompson a travaillé sur Plan 9, car Unix finalement a inclus des changements importants à la volée sans que l'architecture d'origine ne soit adaptée. Et il n'était pas possible d'y remédier par une mise à jour d'Unix pour des raisons de compatibilité.
Le remplaçant a été quand même conçu par… des développeurs de X.org. Bref ils connaissent le sujet. Et ils ont raison quant au fait que le gros du besoin peut être largement rempli par une solution type VNC.
Tu ne remplaces pas un composant aussi fondamental et avec une API aussi largement utilisée en trois jours. C'est normal que cela prenne du temps.
Mais ta position n'est pas dogmatique peut être ? ;)
Tu te méprends sur l'intention de Wayland qui n'est pas de gagner des FPS pour jouer, bien que cela soit un gain possible.
X a une mauvaise architecture. X fait trop de choses (il y a un gestionnaire de polices, affichage par le réseau, serveur d'impression, etc.), il a été conçu à une époque où les cartes graphiques ne fonctionnaient pas pareil, où très clairement tu n'en avais pas plusieurs sur une même machine, où la sécurité n'était pas un sujet important, etc.
En plus de tout cela, c'était difficile à maintenir et il y avait des bogues chiants insolubles.
Et malheureusement ce problème est trop fondamental pour juste mettre à jour X.org. La rupture de compatibilité était inévitable. D'où Wayland et libinput.
X.org requiert les droits super utilisateurs sur ta machine, toute application à accès à tous tes entrées claviers (en gros toute application graphique peut être un keylogger), toute application peut écrire dans le buffer d'affichage d'une autre fenêtre ce qui pose d'autres soucis, etc. Ce n'est pas très difficile à mettre en place.
Peut être que tu t'en fou toi, mais ce n'est pas le cas de tout le monde. Et il vaut mieux prévoir des solutions avant que les problèmes n'arrivent.
[^] # Re: Comble un manque...
Posté par Tarnyko (site web personnel) . Évalué à 1. Dernière modification le 12 mars 2020 à 13:03.
Assez d'accord sur GNOME ;-).
Mais en réalité le concepteur de Wayland (Kristian Høgsberg) avait fourni un PoC équivalent à Waypipe. C'est juste que la fonctionnalité était jugée "non-core" (l'objectif de Wayland était orthogonal) et n'intéressait pas de développeurs assez qualifiés pour la finaliser… jusqu'à maintenant.
L'écosystème Linux moderne (entre l'embarqué, les designers, les gamers/Steam/Valve…) , s'est clairement déplacé du premier besoin vers le second.
Personnellement, ça ne me choque pas qu'on considère que l'objectif d'un serveur d'affichage est… d'"afficher au mieux", le réseau étant une fonction annexe.
L'intérêt d'X aujourd'hui est historique, et consiste surtout à conserver la compatibilité avec les vieilles applications et OS legacy (les BSD notamment).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.