Moi quand quelqu'un me dit qu'une fonctionnalité que j'utilise n'existe pas ou que personne s'en sert, je vois pas pourquoi j'aurai de l'estime pour lui.
Il ne dit pas que X n'a pas de capacités réseau, ni que personne ne s'en sert.
Il dit que X n'a pas de transparence réseau.
Qu'il considère que la seule définition de transparence réseau est de la transparence pure et qu'il vienne claironner que c'est un mythe, c'est quand même de la putain de mauvaise foi. Personne ici n'a jamais claironné que tout les buffers passent dans une socket Unix ou que tout les appels de rendu OpenGL passent par X. Par contre tout ceux qui utilisent X en réseau sont d'accord pour parler de transparence réseau même si elle n'est pas pure. S'amuser à changer la définition de transparence réseau pour nous faire dire ce que personne n'a jamais dit, c'est de la stratégie de l'homme de paille et c'est prendre les gens pour des cons.
Il ne fait aucunement cela dans la vidéo ou le texte donné en lien de ce journal, c'est du pur délire de ta part.
Sinon, utiliser X sans DRI, c'est pas comme si il y avais pas une tétrachiée de personne qui l'ont fait, le font et le feront, et ce sans savoir ce qu'est X ou DRI. Il suffit juste qu'ils n'aient pas d'accélération matérielle qui marche pas hors de la boite, qui n'est pas ou mal installée ou qui n'est pas assez stable pour être utilisée par défaut,
C'est bien. Mais le problème de la non-transparence réseau ne se limite pas au direct rendering. Il y a aussi le fait que le protocole X11 est synchrone (mauvais pour l'usage en réseau), beaucoup trop bavard (mauvais pour l'usage en réseau), et que les fenêtres (thèmes, icônes, polices, décorations, animations) sont beaucoup plus lourdes (mauvais pour l'usage en réseau).
Trois gros points noirs qui font que la transparence réseau de X de fait n'est plus (ce qui n'empêche pas X d'être utilisable à distance, encore une fois ce n'est pas une histoire de capacité mais de transparence).
J'affirme pas le contraire. Si X correspond de moins en moins à un besoin desktop d'afficher des effets kikoolol 3D en utilisant une carte graphique bien gérée, surpuissante et directement branchée sur une prise de courant, je suis pas contre le casser.
C'est surtout que X en local introduit beaucoup trop de latence (le protocole fait que X n'attend pas par exemple qu'une fenêtre soit redimensionnée avant de la redessiner en permanence) et de bugs graphiques (ce n'est pas une histoire de pilote - pour chaque élément de la fenêtre, X considère que c'est aussi une fenêtre, et n'assure aucunement la cohérence entre les deux. D'ailleurs, parmis les développeurs de Xorg : "personne ne comprends la fonction de validation d'une fenêtre"). Essaie de redimensionner une fenêtre (ça n'arrive pas uniquement dans ce cas là, c'est juste là où c'est le plus visible), tu verras à quel point ça lag et c'est moche.
Mais si le remplacent ne supporte pas les usages moins desktop, il ne faut pas s'étonner que des gens viennent dire que le remplacent est totalement inutile pour eux, parce qu'ils ont parfaitement raison.
Ben si le remplacant le supporte : pour preuve Weston supporte RDP, et il y a un backend Weston-SPICE sur GitHub.
J'affirme que le cœur du protocole X était 'network transparent', et vu que tu affirme qu'il n'a pas changé, il l'est toujours.
Aucun toolkit graphique ne l'utilise. A moins d'utiliser des applications non-GTK/QT/EFL/Whatever, je doutes que tu utilises des applications qui utilisent encore la vieille API de dessin de X11, en plus des fenêtres très simples des années '80 (eh oui, la transparence réseau, qui n'était qu'un concours de circonstances, c'était à ce prix).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 5.
Il ne dit pas que X n'a pas de capacités réseau, ni que personne ne s'en sert.
Il dit que X n'a pas de transparence réseau.
Il ne fait aucunement cela dans la vidéo ou le texte donné en lien de ce journal, c'est du pur délire de ta part.
C'est bien. Mais le problème de la non-transparence réseau ne se limite pas au direct rendering. Il y a aussi le fait que le protocole X11 est synchrone (mauvais pour l'usage en réseau), beaucoup trop bavard (mauvais pour l'usage en réseau), et que les fenêtres (thèmes, icônes, polices, décorations, animations) sont beaucoup plus lourdes (mauvais pour l'usage en réseau).
Trois gros points noirs qui font que la transparence réseau de X de fait n'est plus (ce qui n'empêche pas X d'être utilisable à distance, encore une fois ce n'est pas une histoire de capacité mais de transparence).
C'est surtout que X en local introduit beaucoup trop de latence (le protocole fait que X n'attend pas par exemple qu'une fenêtre soit redimensionnée avant de la redessiner en permanence) et de bugs graphiques (ce n'est pas une histoire de pilote - pour chaque élément de la fenêtre, X considère que c'est aussi une fenêtre, et n'assure aucunement la cohérence entre les deux. D'ailleurs, parmis les développeurs de Xorg : "personne ne comprends la fonction de validation d'une fenêtre"). Essaie de redimensionner une fenêtre (ça n'arrive pas uniquement dans ce cas là, c'est juste là où c'est le plus visible), tu verras à quel point ça lag et c'est moche.
Ben si le remplacant le supporte : pour preuve Weston supporte RDP, et il y a un backend Weston-SPICE sur GitHub.
Aucun toolkit graphique ne l'utilise. A moins d'utiliser des applications non-GTK/QT/EFL/Whatever, je doutes que tu utilises des applications qui utilisent encore la vieille API de dessin de X11, en plus des fenêtres très simples des années '80 (eh oui, la transparence réseau, qui n'était qu'un concours de circonstances, c'était à ce prix).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)