Et ils étaient obligés de mettre ça uniquement sur Google Plus, évidemment… Super l'URL à la con aussi, vachement sémantique. Bon, je ne me plains pas, au moins ça ne demande pas de compte spécifique pour lire cette annonce.
Le fait que l'auteur du journal pointe uniquement vers un lien G+ ne signifie pas que c'est la seule annonce publiée, je suppose qu'ils publient à plusieurs endroits pour augmenter l'audience.
C'est un fait, je n'ai pas cherché particulièrement loin ( bookmark, quoi ). J'ai vu une MaJ de mes RSS, suivi 2 liens exactement, et je me suis dit que, peut-être, linuxfr serait intéressé. Mea culpa si je me suis trompé?
Le sujet est intéressant, mais l'auteur du commentaire (et moi-même) aurait sans doute préférer avoir l'annonce originelle et pas une reprise.
C'est moi qui ait posté l'annonce sur Google+. Étant un des directeurs de la foundation X.Org, je peux te dire que cette source a autant de valeur que le lien vers la ML, mais permet en plus de s'exprimer dessus ;) Du coup, je suis content que ce soit ce lien qui ait été publié!
Faire une annonce officielle via une société tierce, dont le business est de traçer les utilisateurs. J'ai un peu de mal avec ce fonctionnement, je dois viellir ;-(
Il y a eu une annonce officielle via deux canaux: la mailing list annonce de X.Org (auquel peu de monde est abonné) et Google+, où beaucoup de hackers connus sont capables de relayer l'information et d'y réagir.
Qu'est ce qu'il vaut mieux? Que personne ne soit au courant ou qu'on utilise les outils à notre disposition pour faire passer le message? ;)
Non, ce qu'il veut dire, c'est que si tu es un vrai Libriste, alors au lieu d'utiliser G+, tu aurais d'abord dû coder ta plate-forme de réseau social, ensuite faire migrer l'ensemble des hackers connus sus-mentionnés dessus, et enfin poster ton annonce dans un environnement vraiment Libre et respectueux de la vie privée qui aurait tout autant permis au plus grand nombre de s'exprimer en retour.
Nous admettons que ça aurait pu très légèrement retarder la diffusion de l'annonce…
Ce n'est pas un logiciel mais un protocole. Je comparerais plutôt ça à des choses comme TCP ou comme le shell Unix, qui peuvent avoir plusieurs mises en œuvres.
Oui, RMS a commencé à le développer quand les essais nucléaires se sont montrés de plus en plus fréquents. Avec sagesse, il a compris qu'une nouvelle génération d'informaticiens pleins de doigts allait naître et auraient soifs de logiciels capables d'exploiter leurs particularités.
Il devrait le vendre aux japonnais. Pour les ukrainiens, c'est trop tard et ils ne se gênent pas pour utiliser un logiciel libre sans en demander la permission.
En protocole, tu n'es pas prêt d'abandonner IPv4 (v6 n'étant pas encore grandement déployé), 33 ans et encore plus diffusé que X.
IPv1, l'idée d'IP (non déployée), a 40 ans.
Petit joueur X!
D’après les détracteurs de X je pense à Wayland, X c’est tout pourris, alors je me demande comment il est possible qu’un truc si pourri puisse durer si longtemps…
C'est un peu plus complexe que ça. Le problème de X, c'est de devoir garder la compatibilité avec des trucs d'il y a 30 ans qui ne sont plus d'actualité sur les machines récentes. Cela empêche le développement d'interfaces adaptées au matériel récent et d'avoir une meilleure expérience utilisateur et aussi une meilleure sécurité. X n'est pas si pourri que ça, sinon les développeurs actuels de Wayland n'auraient pas passer beaucoup de temps à développer X, mais ils ont bien compris que si on voulait faire les choses proprement, il fallait repartir de zéro (l'expérience de X12 le montre).
« 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
Et deux choses sont fondamentalement différentes entre X et Wayland. X, qu'on le veuille ou non, c'est du rendu d'application déporté. Les clients envoient leurs requêtes de dessin (dessine un rectangle là, un rond ici, un trais là et ce texte ici). GTK et Qt ont arrêté de faire ça car c'était trop lent, ils font le rendu en OpenGL ou sur le CPU eux même. Dans Wayland, les clients font leur propre rendu de la façon qu'ils trouvent la plus adéquate (cool, c'est ce que font déjà GTK et Qt) puis partagent le rendu final avec le compositeur qui ne fait qu'afficher les fenêtres à l'écran, au bon endroit.
La deuxième chose fondamentalement différente entre X et Wayland, c'est que dans Wayland, chaque image est parfaite. Plus de clignotement, plus de fenêtre qui s'affiche avec rien dedans, plus de fenêtre qui se lance avec un ancien contenu affiché pendant un bref instant. C'est pas une bonne raison de dégager X?
La deuxième chose fondamentalement différente entre X et Wayland, c'est que dans Wayland, chaque image est parfaite. Plus de clignotement, plus de fenêtre qui s'affiche avec rien dedans, plus de fenêtre qui se lance avec un ancien contenu affiché pendant un bref instant. C'est pas une bonne raison de dégager X?
Je voyais bien ce phénomène au lancement de mon Xfce (genre le tableau de bord qui se peuple peu à peu, mais avec plein de "bugs" graphiques du genre dont tu parles).
KDE affichant un splashscreen lors de l'ouverture de session (plus longtemps que le fait Xfce en tout cas), ça ne se voit pas.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Et deux choses sont fondamentalement différentes entre X et Wayland.
Tu as oublié la transparence réseau, qui, si j'ai bien compris, permets de faire tourner une application d'une machine en déportant ses entrées/sorties sur une autre.
C'était plus intéressant à l'époque ou les machines coûtaient la peau du cul j'imagine, mais ça reste à mon avis une raison de ne jamais qualifier X de pourri, ou merdique. Obsolète, éventuellement, mais ce n'est pas pareil: je connais une société qui fait des logiciels pourris et merdiques modernes et les vends à énormément de gens, qui régulièrement leur préfèrent les versions obsolète de la même société ^
X, qu'on le veuille ou non, c'est du rendu d'application déporté. Les clients envoient leurs requêtes de dessin […] ont arrêté de faire ça car c'était trop lent,
Du coup, petite question: pourquoi est-ce trop lent? Que l'image soit créée par une application qui fait le travail "directement" (en envoyant à OpenGL en fait?) ou que les requêtes soient envoyées à une application spécialisée qui fasse le rendu ne devrait pas avoir une énorme surcharge, dans l'absolu?
Est-ce à cause du fait que la plupart des ressources graphiques soient matricielles? Si on utilisait majoritairement du vectoriel, ce problème se résorberait-il? Parce qu'au final, le fonctionnement que tu décris me semble particulièrement adapté à du rendu vectoriel, même si l'on garde une légère surcharge ( le serveur faisant le rendu, probablement via OpenGL, on garde un intermédiaire ) je doute que la différence de vitesse soit flagrante, surtout de nos jours. Par contre, oui, sur du matriciel, envoyer 4*1024*768 ( soit 3 Mio, tout rond en plus! ) pour dessiner un écran entier de faible résolution, ça doit bouffer, surtout s'il n'est pas possible d'utiliser une compression sans perte efficace ( genre des photos ).
Du coup, petite question: pourquoi est-ce trop lent?
En fait pour la lenteur ça dépend pas mal. Comme indiqué au dessus, kde/gtk calcul un rendu localement puis envoie la bitmap au serveur X (donc potentiellement) sur le réseau. Du coup, sur un système centralisé comme il y a 30 ans, c'est le serveur d'application où tourne le client X (l'application) qui fait le calcul du rendu. Du coup, ça à un impact sur la charge du serveur d'application. Sur des machines individuelles où le client et le serveur X sont en local, ça ne change pas grand chose.
L'autre solution, c'est ce que fait/faisait (je n'ai pas retesté récemment) acroread, qui envoie des ordres de dessins de lignes pour chaque caractère. C'est le serveur X qui fait le rendu. Mais dans le cas d'applications distantes, la charge du réseau augmente énormément en cas de scroll rapide du document (à la molette) on avait mesuré plus de 200Mb/s. Là où okular n'envoyant qu'un gros bitmap charge moins le réseau.
Pour moi, ça dépend des usages, X avait l'avantage de permettre les deux cas.
kde/gtk calcul un rendu localement puis envoie la bitmap au serveur X (donc potentiellement) sur le réseau.
Ca me parait bizarre comme fonctionnement. C'est comme si tu disais qu'un serveur web calculait le rendu de la page pour envoyer un bitmap au navigateur. On tape tout le temps sur X, mais ne serai-ce pas plutôt KDE et GTK qui s'y prennent de la mauvaise manière pour le rendu ?
Non pas du tout. Un site web c'est fait pour fonctionner sur internet. Qt et GTK+ sont principalement fait pour faire fonctionner des applications locale. Les toolkits s'y prennent de la bonne manière pour faire ce pourquoi ils sont conçu. C'est la seule façon d'avoir de jolis thèmes avec des ombres, des gradients et des animations comme que que l'on demande aux toolkits aujourd'hui.
Ben, fin année 90 début 2000, les machines, surtout les cartes graphiques ont commencées à pouvoir faire des effets jolis pour l'interface. Notamment des transitions, des fondus… En essayant de faire la même chose sous X, on explose la bande passante, et encore, quand le réseau n'est pas trop lent. Cette culture du joli effet, a montré des limitations de X. Du coup, les framework ont cherché à résoudre le problème de cette manière qui en plus se mixe bien à la façon de faire de Windows (il me semble)
En 2004 ou 2005, j'avais fait un test :
Je lançais un navigateur sur mon PC chez moi depuis le boulot en exportant le DISPLAY à travers internet (enfin en tunnel ssh). Le dessin du bouton page précédent quand on clique dessus on avait l'impression qu'il s'enfonçait.
2 cas :
firefox a l'époque, et via mon ADSL en upload, je voyais le bouton redessinner son contour, ça prenais plusieurs secondes. Là où konqueror, passais directement à bouton enfoncé. Je pense que le temps d'envoyer le bitmap et l'afficher, il voyait que c'était fini et passait directement à la dernière image.
Personnellement, j'apprécie X pour sa souplesse, j'aimais bien MOTIF pour la personnalisation individuelle des applications. Aujourd'hui passer par une interface 100% locale comme wayland puis lancer un serveur X pour faire du distant (comme sous Windows) n'est pas forcément déconnant. Ce que je trouve le plus dommage, c'est que l'application dessine le contour de la fenêtre, qu'il n'y ait pas de WM réellement séparé.
Ce que je trouve le plus dommage, c'est que l'application dessine le contour de la fenêtre, qu'il n'y ait pas de WM réellement séparé.
Espérons que des solutions standardisées émergeront. Je ne sais pas comment les logiciels KDE vont négocier ça avec Kwin, mais il y a de fortes chances que ça devienne le standard de fait. Espérons alors que les autres logiciels hors de KDE suivront. Il serait dommage que Wayland tue les gestionnaires de fenêtre pavant, ou à onglets et autres gestions de fenêtres avancées.
Il serait dommage que Wayland tue les gestionnaires de fenêtre pavant, ou à onglets et autres gestions de fenêtres avancées.
Ça n'arrivera pas. Je préfère rester sous un X retardé et non maintenu plutôt que de revenir à un gestionnaire de fenêtre stacking. D'un autre côté, je pense qu'il doit être possible d'implémenter un serveur wayland minimaliste donnant la main à un WM externe, pourquoi pas via un mécanisme de plug-in.
Sincèrement, je vois d'un bon œil l'idée de Wayland ( je suis de ceux qui pensent que se débarrasser d'un truc implémentant des choses qui ne sont plus utilisées est une bonne chose, quitte à casser la compat. Reste à définir "plus utilisées" ), et j'aurai bien aimé jouer avec, mais je n'ai pas trouvé de code pour booter mon cerveau dessus. Weston est trop complet ( en même temps, c'est une démo technique ) alors que ce qu'il me faudrait ce serait un serveur minimal. J'avoue ne pas avoir cherché des masses aussi, mais… si quelqu'un connaît un projet dans ce style en cours de dev, je serai curieux de tenter de voir à quoi ça ressemble, et pourquoi pas de coder pour.
J'avoue ne pas avoir cherché des masses aussi, mais… si quelqu'un connaît un projet dans ce style en cours de dev, je serai curieux de tenter de voir à quoi ça ressemble, et pourquoi pas de coder pour.
Tu peux partir de Weston et retirer ce qui te dérange.
« 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
Dans une dépêche précédente, il y avait swc de mentionné, je ne sais pas trop où ça en est, mais ça ne semble pas abandonné non plus. C'est sensé devenir une librairie pour les créateurs de wm de type pavant.
# Google Plus
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Et ils étaient obligés de mettre ça uniquement sur Google Plus, évidemment… Super l'URL à la con aussi, vachement sémantique. Bon, je ne me plains pas, au moins ça ne demande pas de compte spécifique pour lire cette annonce.
[^] # Re: Google Plus
Posté par Renault (site web personnel) . Évalué à 10.
Ou alors tu recherches un peu avant et tu tombes sur l'annonce officielle sur leur liste de diffusion publique des annonces : http://lists.x.org/archives/xorg-announce/2014-June/002447.html
Le fait que l'auteur du journal pointe uniquement vers un lien G+ ne signifie pas que c'est la seule annonce publiée, je suppose qu'ils publient à plusieurs endroits pour augmenter l'audience.
[^] # Re: Google Plus
Posté par freem . Évalué à 1.
C'est un fait, je n'ai pas cherché particulièrement loin ( bookmark, quoi ). J'ai vu une MaJ de mes RSS, suivi 2 liens exactement, et je me suis dit que, peut-être, linuxfr serait intéressé. Mea culpa si je me suis trompé?
[^] # Re: Google Plus
Posté par Adrien . Évalué à 4.
Le sujet est intéressant, mais l'auteur du commentaire (et moi-même) aurait sans doute préférer avoir l'annonce originelle et pas une reprise.
C'est une habitude à avoir : prendre l'info à la source permet d'éviter les manipulations ou erreurs, on voit de suite qui a fait l'information, etc.
[^] # Re: Google Plus
Posté par Martin Peres (site web personnel) . Évalué à 10.
C'est moi qui ait posté l'annonce sur Google+. Étant un des directeurs de la foundation X.Org, je peux te dire que cette source a autant de valeur que le lien vers la ML, mais permet en plus de s'exprimer dessus ;) Du coup, je suis content que ce soit ce lien qui ait été publié!
[^] # Re: Google Plus
Posté par deasy . Évalué à 2.
Et tu as bien fait car la ML c'est pas très convivial :)
[^] # Re: Google Plus
Posté par Adrien . Évalué à 8.
Mille excuse alors !
Faire une annonce officielle via une société tierce, dont le business est de traçer les utilisateurs. J'ai un peu de mal avec ce fonctionnement, je dois viellir ;-(
[^] # Re: Google Plus
Posté par Martin Peres (site web personnel) . Évalué à 6.
Il y a eu une annonce officielle via deux canaux: la mailing list annonce de X.Org (auquel peu de monde est abonné) et Google+, où beaucoup de hackers connus sont capables de relayer l'information et d'y réagir.
Qu'est ce qu'il vaut mieux? Que personne ne soit au courant ou qu'on utilise les outils à notre disposition pour faire passer le message? ;)
[^] # Re: Google Plus
Posté par Maclag . Évalué à 10.
Non, ce qu'il veut dire, c'est que si tu es un vrai Libriste, alors au lieu d'utiliser G+, tu aurais d'abord dû coder ta plate-forme de réseau social, ensuite faire migrer l'ensemble des hackers connus sus-mentionnés dessus, et enfin poster ton annonce dans un environnement vraiment Libre et respectueux de la vie privée qui aurait tout autant permis au plus grand nombre de s'exprimer en retour.
Nous admettons que ça aurait pu très légèrement retarder la diffusion de l'annonce…
# 30 ans
Posté par reno . Évalué à 2.
C'est impressionnant comme durée de vie!
Je me demandes quel autres logiciels ont >30 ans et sont toujours utilisés..
[^] # Re: 30 ans
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Ce n'est pas un logiciel mais un protocole. Je comparerais plutôt ça à des choses comme TCP ou comme le shell Unix, qui peuvent avoir plusieurs mises en œuvres.
[^] # Re: 30 ans
Posté par Christophe Merlet (site web personnel) . Évalué à 6.
Est-ce que le X d'aujourd'hui est compatible avec le X d'il y a 30 ans ? et vice-versa ?
[^] # Re: 30 ans
Posté par THE_ALF_ . Évalué à 10.
emacs, 38 ans.
[^] # Re: 30 ans
Posté par Cyprien (site web personnel) . Évalué à 10.
Il parlait des logiciels toujours utilisés :)
[^] # Re: 30 ans
Posté par KiKouN . Évalué à 3.
Non, il parlait de logiciel pas des OS.
[^] # Re: 30 ans
Posté par Xinul . Évalué à 5.
Ah tiens, c'est aussi vieux que vi
[^] # Re: 30 ans
Posté par Troy McClure (site web personnel) . Évalué à 5.
aussi vieux mais plus mieux
[^] # Re: 30 ans
Posté par Michaël (site web personnel) . Évalué à 3.
ni moins bien!
[^] # Re: 30 ans
Posté par woopla . Évalué à 1.
C'est vrai avant c'était mieux, maintenant ça ne l'est plus.
[^] # Re: 30 ans
Posté par Maclag . Évalué à 10.
Oui, RMS a commencé à le développer quand les essais nucléaires se sont montrés de plus en plus fréquents. Avec sagesse, il a compris qu'une nouvelle génération d'informaticiens pleins de doigts allait naître et auraient soifs de logiciels capables d'exploiter leurs particularités.
Quelle belle époque!
--------------> [ ]
[^] # Re: 30 ans
Posté par KiKouN . Évalué à 0.
Il devrait le vendre aux japonnais. Pour les ukrainiens, c'est trop tard et ils ne se gênent pas pour utiliser un logiciel libre sans en demander la permission.
[^] # Re: 30 ans
Posté par Zenitram (site web personnel) . Évalué à 5.
En protocole, tu n'es pas prêt d'abandonner IPv4 (v6 n'étant pas encore grandement déployé), 33 ans et encore plus diffusé que X.
IPv1, l'idée d'IP (non déployée), a 40 ans.
Petit joueur X!
# 30 ans de X
Posté par Sufflope (site web personnel) . Évalué à 10.
Merci Jacquie et Michel !
[^] # Re: 30 ans de X
Posté par Arthur Geek (site web personnel) . Évalué à 3.
On parle de logiciel libre ici, pas libertin.
Prochainement, je vous proposerai peut-être un commentaire constructif.
[^] # Re: 30 ans de X
Posté par papap (site web personnel) . Évalué à 3.
Ah oui, je pensais qu'on parlait de films…
# Comment c’est possible ?
Posté par Anthony Jaguenaud . Évalué à -5.
D’après les détracteurs de X je pense à Wayland, X c’est tout pourris, alors je me demande comment il est possible qu’un truc si pourri puisse durer si longtemps…
[^] # Re: Comment c’est possible ?
Posté par xcomcmdr . Évalué à 9.
Rien à voir. Un logiciel dont tout le monde dépend, ça s'enlève pas tout seul, même si c'est tout pourri.
Regarde le cas Windows, par exemple… ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Comment c’est possible ?
Posté par claudex . Évalué à 5.
C'est un peu plus complexe que ça. Le problème de X, c'est de devoir garder la compatibilité avec des trucs d'il y a 30 ans qui ne sont plus d'actualité sur les machines récentes. Cela empêche le développement d'interfaces adaptées au matériel récent et d'avoir une meilleure expérience utilisateur et aussi une meilleure sécurité. X n'est pas si pourri que ça, sinon les développeurs actuels de Wayland n'auraient pas passer beaucoup de temps à développer X, mais ils ont bien compris que si on voulait faire les choses proprement, il fallait repartir de zéro (l'expérience de X12 le montre).
« 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: Comment c’est possible ?
Posté par Martin Peres (site web personnel) . Évalué à 8.
Bien dit!
Et deux choses sont fondamentalement différentes entre X et Wayland. X, qu'on le veuille ou non, c'est du rendu d'application déporté. Les clients envoient leurs requêtes de dessin (dessine un rectangle là, un rond ici, un trais là et ce texte ici). GTK et Qt ont arrêté de faire ça car c'était trop lent, ils font le rendu en OpenGL ou sur le CPU eux même. Dans Wayland, les clients font leur propre rendu de la façon qu'ils trouvent la plus adéquate (cool, c'est ce que font déjà GTK et Qt) puis partagent le rendu final avec le compositeur qui ne fait qu'afficher les fenêtres à l'écran, au bon endroit.
La deuxième chose fondamentalement différente entre X et Wayland, c'est que dans Wayland, chaque image est parfaite. Plus de clignotement, plus de fenêtre qui s'affiche avec rien dedans, plus de fenêtre qui se lance avec un ancien contenu affiché pendant un bref instant. C'est pas une bonne raison de dégager X?
Et je parle même pas de la sécurité désastreuse de X.
[^] # Re: Comment c’est possible ?
Posté par xcomcmdr . Évalué à 3.
Je voyais bien ce phénomène au lancement de mon Xfce (genre le tableau de bord qui se peuple peu à peu, mais avec plein de "bugs" graphiques du genre dont tu parles).
KDE affichant un splashscreen lors de l'ouverture de session (plus longtemps que le fait Xfce en tout cas), ça ne se voit pas.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Comment c’est possible ?
Posté par freem . Évalué à 3.
Tu as oublié la transparence réseau, qui, si j'ai bien compris, permets de faire tourner une application d'une machine en déportant ses entrées/sorties sur une autre.
C'était plus intéressant à l'époque ou les machines coûtaient la peau du cul j'imagine, mais ça reste à mon avis une raison de ne jamais qualifier X de pourri, ou merdique. Obsolète, éventuellement, mais ce n'est pas pareil: je connais une société qui fait des logiciels pourris et merdiques modernes et les vends à énormément de gens, qui régulièrement leur préfèrent les versions obsolète de la même société ^
Du coup, petite question: pourquoi est-ce trop lent? Que l'image soit créée par une application qui fait le travail "directement" (en envoyant à OpenGL en fait?) ou que les requêtes soient envoyées à une application spécialisée qui fasse le rendu ne devrait pas avoir une énorme surcharge, dans l'absolu?
Est-ce à cause du fait que la plupart des ressources graphiques soient matricielles? Si on utilisait majoritairement du vectoriel, ce problème se résorberait-il? Parce qu'au final, le fonctionnement que tu décris me semble particulièrement adapté à du rendu vectoriel, même si l'on garde une légère surcharge ( le serveur faisant le rendu, probablement via OpenGL, on garde un intermédiaire ) je doute que la différence de vitesse soit flagrante, surtout de nos jours. Par contre, oui, sur du matriciel, envoyer 4*1024*768 ( soit 3 Mio, tout rond en plus! ) pour dessiner un écran entier de faible résolution, ça doit bouffer, surtout s'il n'est pas possible d'utiliser une compression sans perte efficace ( genre des photos ).
[^] # Re: Comment c’est possible ?
Posté par Anthony Jaguenaud . Évalué à 2.
En fait pour la lenteur ça dépend pas mal. Comme indiqué au dessus, kde/gtk calcul un rendu localement puis envoie la bitmap au serveur X (donc potentiellement) sur le réseau. Du coup, sur un système centralisé comme il y a 30 ans, c'est le serveur d'application où tourne le client X (l'application) qui fait le calcul du rendu. Du coup, ça à un impact sur la charge du serveur d'application. Sur des machines individuelles où le client et le serveur X sont en local, ça ne change pas grand chose.
L'autre solution, c'est ce que fait/faisait (je n'ai pas retesté récemment) acroread, qui envoie des ordres de dessins de lignes pour chaque caractère. C'est le serveur X qui fait le rendu. Mais dans le cas d'applications distantes, la charge du réseau augmente énormément en cas de scroll rapide du document (à la molette) on avait mesuré plus de 200Mb/s. Là où okular n'envoyant qu'un gros bitmap charge moins le réseau.
Pour moi, ça dépend des usages, X avait l'avantage de permettre les deux cas.
[^] # Re: Comment c’est possible ?
Posté par totof2000 . Évalué à 2.
Ca me parait bizarre comme fonctionnement. C'est comme si tu disais qu'un serveur web calculait le rendu de la page pour envoyer un bitmap au navigateur. On tape tout le temps sur X, mais ne serai-ce pas plutôt KDE et GTK qui s'y prennent de la mauvaise manière pour le rendu ?
[^] # Re: Comment c’est possible ?
Posté par Gof (site web personnel) . Évalué à 4.
Non pas du tout. Un site web c'est fait pour fonctionner sur internet. Qt et GTK+ sont principalement fait pour faire fonctionner des applications locale. Les toolkits s'y prennent de la bonne manière pour faire ce pourquoi ils sont conçu. C'est la seule façon d'avoir de jolis thèmes avec des ombres, des gradients et des animations comme que que l'on demande aux toolkits aujourd'hui.
[^] # Re: Comment c’est possible ?
Posté par Anthony Jaguenaud . Évalué à 3.
Ben, fin année 90 début 2000, les machines, surtout les cartes graphiques ont commencées à pouvoir faire des effets jolis pour l'interface. Notamment des transitions, des fondus… En essayant de faire la même chose sous X, on explose la bande passante, et encore, quand le réseau n'est pas trop lent. Cette culture du joli effet, a montré des limitations de X. Du coup, les framework ont cherché à résoudre le problème de cette manière qui en plus se mixe bien à la façon de faire de Windows (il me semble)
En 2004 ou 2005, j'avais fait un test :
Je lançais un navigateur sur mon PC chez moi depuis le boulot en exportant le DISPLAY à travers internet (enfin en tunnel ssh). Le dessin du bouton page précédent quand on clique dessus on avait l'impression qu'il s'enfonçait.
2 cas :
firefox a l'époque, et via mon ADSL en upload, je voyais le bouton redessinner son contour, ça prenais plusieurs secondes. Là où konqueror, passais directement à bouton enfoncé. Je pense que le temps d'envoyer le bitmap et l'afficher, il voyait que c'était fini et passait directement à la dernière image.
Personnellement, j'apprécie X pour sa souplesse, j'aimais bien MOTIF pour la personnalisation individuelle des applications. Aujourd'hui passer par une interface 100% locale comme wayland puis lancer un serveur X pour faire du distant (comme sous Windows) n'est pas forcément déconnant. Ce que je trouve le plus dommage, c'est que l'application dessine le contour de la fenêtre, qu'il n'y ait pas de WM réellement séparé.
[^] # Re: Comment c’est possible ?
Posté par jyes . Évalué à 2.
Espérons que des solutions standardisées émergeront. Je ne sais pas comment les logiciels KDE vont négocier ça avec Kwin, mais il y a de fortes chances que ça devienne le standard de fait. Espérons alors que les autres logiciels hors de KDE suivront. Il serait dommage que Wayland tue les gestionnaires de fenêtre pavant, ou à onglets et autres gestions de fenêtres avancées.
[^] # Re: Comment c’est possible ?
Posté par freem . Évalué à 3.
Ça n'arrivera pas. Je préfère rester sous un X retardé et non maintenu plutôt que de revenir à un gestionnaire de fenêtre stacking. D'un autre côté, je pense qu'il doit être possible d'implémenter un serveur wayland minimaliste donnant la main à un WM externe, pourquoi pas via un mécanisme de plug-in.
Sincèrement, je vois d'un bon œil l'idée de Wayland ( je suis de ceux qui pensent que se débarrasser d'un truc implémentant des choses qui ne sont plus utilisées est une bonne chose, quitte à casser la compat. Reste à définir "plus utilisées" ), et j'aurai bien aimé jouer avec, mais je n'ai pas trouvé de code pour booter mon cerveau dessus. Weston est trop complet ( en même temps, c'est une démo technique ) alors que ce qu'il me faudrait ce serait un serveur minimal. J'avoue ne pas avoir cherché des masses aussi, mais… si quelqu'un connaît un projet dans ce style en cours de dev, je serai curieux de tenter de voir à quoi ça ressemble, et pourquoi pas de coder pour.
[^] # Re: Comment c’est possible ?
Posté par claudex . Évalué à 1.
Tu peux partir de Weston et retirer ce qui te dérange.
« 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: Comment c’est possible ?
Posté par anaseto (site web personnel) . Évalué à 3.
Dans une dépêche précédente, il y avait swc de mentionné, je ne sais pas trop où ça en est, mais ça ne semble pas abandonné non plus. C'est sensé devenir une librairie pour les créateurs de wm de type pavant.
[^] # Re: Comment c’est possible ?
Posté par antistress (site web personnel) . Évalué à 4.
Salut!
D'ailleurs je me demandais si tu avais pu faire passer un maximum de tes idées d'amélioration de la sécurité de Wayland ?
# 30e commentaire
Posté par feth . Évalué à -6.
Tout est dans le titre.
Excellent vendredi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.