reno a écrit 3886 commentaires

Le but? Faire communiquer 2 LAN dont je ne peux pas changer les VLAN ID sans devoir utiliser un routeur..
Mais j'ai l'impression qu'avec 802.1Q on ne peut qu'ajouter ou retirer des tags de VLANs pas passer d'un tag à un autre, je me demande bien pourquoi ils ont choisi ceux qui ont fait cette norme ont fait ce choix étrange.

Non plus: Weston n'est pas une API, donc remplacer Wayland par Weston dans son post ne le rend pas beaucoup plus correct.

Je me demande si ça serait possible d'ajouter un mode combat?
Dans un premier temps, ce serait juste des "lasers" qui tirent tout droit et un système de score.
Après ça pourrait être améliorer progressivement: des balles qui ont une vitesse finie, puis qui subissent la gravité, et ensuite qui ont un effet de "recul" et enfin un modèle de dommage sur les avions(!)..

Je n'ai jamais trouvé que voler seulement dans la campagne était intéressant, avoir un mode de combat avec des avions réalistes c'est plus amusant (enfin surtout les vieux coucous, les avions récents c'est trop compliqué).

Ils donnent un exemple pour appeler des librairies C ou Fortran: http://julialang.org/manual/calling-c-and-fortran-code/

Oui, enfin on pourrait dire de la même chose pour d'autres divisions des logiciels libres: deb/rpm je n'ai jamais compris l'intérêt,
par contre Julia a une syntaxe proche de Matlab ce qui peut être un plus pour les utilisateurs,
pareil pour KDE/Gnome avoir plusieurs options cotés interfaces graphique ça apporte un bénéfice aux utilisateurs..

Je retiens surtout qu'il faudra à terme que je me débarrasse de ma carte graphique pour une autre qui ne soit pas "propriétaire".

Note qu'AMD n'est pas vraiment libre: le mode d'accélération vidéo d'AMD est propriétaire aussi, avec Intel je ne sais pas..

Désolé mais associé l'opinion "Perl est has been" n'a rien à voir avec la notion cool ou pas, je fais parti de ceux qui pensent que Perl est has been(*) car pour moi d'autre langages de scripts ont une syntaxe supérieure, ce n'est pas une question d'âge ou de mode..

*: de la même manière que Cobol est has been, utile grâce au poids de l'existant, à la taille des librairies mais has been pour tout les projets où on ce ne sont pas les facteurs déterminants.

Enfin pas les versions récentes (une histoire d'ARMv6 vs ARMv7):
http://linuxfr.org/nodes/89652/comments/1326013

Relis la partie sur les logiciels de l'annonce: ça y était: "il s'agit d'une architecture ARM avec son lot d'inconvénients : pas d'auto-détection du matériel, quelques binaires opaques, une partie des spécifications gardée secrète…" et "il faut cependant noter que la partie bootloader et toute la partie GPU (OpenGL et accélération vidéo) ne sera fournie que sous forme binaire et reste propriétaire."

Ça me parait clair, non?

Bah, comme ça quand il y aura le prochain "batch" les logiciels auront été bien testés par ceux qui ont la première version.

Sinon il y a aussi une nouveauté: la version a 25$ devrait avoir 256Mo de RAM comme la version à 35$ (avec port Ethernet) alors qu'au début seulement 128Mo étaient prévu pour cette version:
http://arstechnica.com/gadgets/news/2012/02/raspberry-pi-retailers-toppled-by-demand-as-35-linux-computer-launches.ars

Amusant: le journal le mieux noté "Un journaliste menacé de mort pour blasphème interpellé avec l'aide d'interpol" a un titre faux : Interpol a démenti..
Je sens que je vais faire des journaux bien racoleurs, moi: ça a l'air encouragé!

Mon prochain journal: Toute la viande d’Ile de France est halal!!

Mais pour moi, il est temps de dire “stop! A partir de 2013, les enfants à naitre n’ouvriront plus droit à des allocations”.
Il est même, pour moi, temps de favoriser les foyers ayant peu d’enfants, à l’inverse de ce qui se pratique depuis des décennies en France.

Ces deux phrase se contredisent, puisque si tu n'a plus d'allocation tu ne favorise pas les foyer ayant peu d'enfants (à moins que pour toi, peu inclue 0).
Pour favoriser les foyers ayant peu d’enfants, plutôt que de supprimer les allocations, tu peux "plafonner" le niveau des allocations à 3 enfants par exemple.
Après pour les hommes qui veulent beaucoup d'enfant, ça encourage au divorce non?
Bon ça devrait quand même être un cas assez rare..

Bon depuis DRI(DRI2?) X peut passer des adresses de buffer GPU en local donc rayons ce point là, par contre Wayland a le serveur d'affichage, gestionnaire de fenêtre et le compositeur dans le même processus (Weston) ce qui semble être un changement intéressant.

Hum, dommage qu'on ne puisse pas s'auto-moinsser: la partie augmentation des performances en local est fausse depuis qu'X peut fournir un buffer du GPU (DRI) a son client..

Donc effectivement la question de l'intérêt de Wayland se pose.

Avec Wayland c'est le client qui alloue la surface en mémoire du GPU, puis passe son adresse au serveur d'affichage Weston, j'étais tellement focalisé sur ce mode là que j'oubliais que le client X pouvais demander au serveur X d'allouer la surface et de te retourner son adresse (enfin je crois que c'est ça: la doc est horrible), ce qui d'un point de vue copie mémoire pour les communications client/serveur revient strictement au même.

Bon bah, je comprends de moins en moins l'intérêt de Wayland..

Pour la situation c), il me semble que le serveur wayland exisant sait déjà quasiment le faire puisque il peut s'utiliser en tant que client X.

C'était trop beau: je viens de lire un message d'un développeur Wayland que Weston était bien client X, mais uniquement en local.
Donc "presque" mais pas encore non.

Comme tu vois il n'y a à chaque fois qu'une seule copie.

Bah non, je ne vois toujours pas comment l'application peut donner l'adresse d'un buffer du GPU au serveur X plutôt que l'adresse d'un buffer en mémoire centrale.
Ça fait partie de quelle API/extension ça?

Donc forcément en cas de plantage d'un des pilotes avant que XLib n'ait eu sa réponse, tout le monde est gelé.

Euh le multi-GPU dont pas mal de gens se plaignent que X n'a pas ce n'est pas une histoire de robustesse, c'est pour pouvoir avoir le choix entre un GPU économe en énergie et un GPU puissant, je ne vois pas en quoi le plantage de pilote intervient ici..

[débat sur les modif à faire sur les applications] soit il y a un soucis.

J'avais mal lu ta réponse à nud, désolé. Mais je ne pense pas qu'il faille réécrire les applis: les devs GTK/Qt qui discutent parfois sur la mailing list Wayland ont l'air plutôt calme ;-)

Sous X11R6 il y a des tonnes d'équivalents. Je dis d'équivalents parce que comme X11R6 ne fait pas de composing, il n'y a aucun intérêt à lui retransmettre les buffers directs.

Hum comme X11R6 ne fait pas de composing, tes équivalents ne me paraissent pas équivalent coté performance..
Wayland te permet de faire: l'application rend sa fenêtre dans un buffer du GPU, donne l'adresse du buffer à Weston, Weston compose toutes les fenetre dans un autre buffer pour obtenir l'écran puis l'affiche, donc il y a une seule copie des fenêtres de la mémoire du GPU vers la mémoire du GPU avant d'afficher l'écran, comment tu fais ça aussi efficacement avec X11R6 en partant de la même situation de départ: l'application a rendu sa fenêtre dans la mémoire du GPU?

D'après linuxlibertine.org, la police offre le support d'OpenType et quantité de ligatures.

Le support, ça ne veux pas dire que les informations dans la police soient "correctes" pour autant.

Ça serait donc plutôt la faute à l'outil de composition utilisé pour les exemples inclus dans l'article.

Ça me parait surprenant puisque les brevets logiciels sur les méthodes de composition ont expiré il me semble, il n'y a donc plus de raison de brider les outils de composition..

http://xkcd.com/1015/

A ce sujet, j'avais vu dans le commentaire de cette épisode d'XKCD, un "jeux" pour voire si on était bon ou pas en crénage/kerning:
http://type.method.ac/

Note que le comportement de Windows dépend probablement de quelle partie du pilote de la carte a un problème: si c'est la partie intégré dans le noyau un écran bleu parait probable, si c'est la partie en espace utilisateur alors Windows peut redémarré le pilote.

Sous X, tout aurait été embarqué avec le driver au final, et tu perds toutes tes applications.

Actuellement oui, mais c'est un problème avec le protocole X ou un problème d'implémentation de Linux/du serveur X/des toolkits/des applications?
Je croit que c'est un problème d'implémentation de Linux&des couches basses(pas capable de redémarrer un pilote) et des toolkits (qui n'essayent pas de se reconnecter à un serveur X s'il redémarre), donc c'est un peu agaçant quand on dit que c'est un problème d'X.

Je ne réponds qu'à certains de tes points car ton post est un peu long:

Oui la XLib est une bouse. On est d'accord.

Oui.

XCB est bien mieux, mais aucune des grosses bibliothèque n'a suivi, il y a vaguement pango comme appli en pur XCB, et les EFL.

Qt5 devrait aussi supporter XCB.

De toute les façons les libs GPGCU ont démontrés que Linux savait parfaitement gérer plusieurs GPU et demander des calculs différents à chacun d'eux avant de mélanger les résultats. Ce qui bloque c'est XLib.

Peux-tu expliquer en quoi XLib pose un problème vis à vis de gérer plusieurs GPU? Si c'était vraiment le cas alors avec XCB on n'aurait pas ce problème non?
Je croyais que c'était un problème d'implémentation de X.Org..

Mais même les applis codées en GTK ou en QT parfait sont à réécrire.

Je suis d'accord avec nud et Kaane: je pense que les décorations clients seront gérées par les toolkits, à moins que l'appli veuillent faire sa propre décoration ce qui n'est pas une bonne idée (l'appli apparaîtra différente des autres).

Mais Wayland ne permet rien que X11R6 ne puisse faire.

Pas 100% vrai ça: avec Wayland une application peut passer une adresse de buffer mémoire du GPU au serveur d'affichage (Weston) pour qu'il l'utilise, ce qui doit être très efficace en local (si le GPU a une mémoire séparée), X11R6 ne permet pas ça.
Changer totalement l'écosystème pour cette raison ne me parait pas justifié pour autant: une extension de X pourrait faire ça, mais bon ce n'est pas moi qui bosse sur Wayland..

Un gars s'est amusé de faire un test avec Windows7 dans le cas ou une application arrête de répondre ou est (très) lente à répondre: une fois que le gestionnaire de fenêtre a détecté que l'application ne répond plus, tu peux déplacer la fenêtre "zombie".

Weston pourrait faire la même chose.. Bon ce n'est même pas dans leur TODO list (ou je l'ai loupé) actuellement, mais ils en sont au début!

Avec la décoration coté client chaque affichage de la fenêtre est "parfait", même lors d'un redimensionnement, par contre comme le test le montre il faut que le client soit réactif autrement c'est pas terrible: c'est un compromis.

Ce qui serait bien, c'est si ce besoin de réactivité incitait a aller vers un design à la BeOS/Haiku avec une thread par fenêtre dédié à l'IHM..

Pour les applications normale il me semble que c'est (1) qui est utilisé, pourquoi WebGL serait différent?

Pour moi, Wayland est une connerie tout court. On réinvente la roue carré au lieu d'améliorer le pneu....

Plutôt on crée un système qui correspond à des préoccupations différente (uniquement le cas local), si ça reste juste une alternative il n'y a pas de problème, sinon effectivement ça lésera des utilisateurs.

Quid des applications qui plantent? On ne peut plus bouger la fenêtre......

Regarde 3 post plus haut: "Il y aura juste une API pour que le client indique ou se trouve le bouton pour fermer la fenêtre afin qu'un serveur puisse tuer un client non-réactif"

o Quid de l'optimisation des SPANS pour tracer les pixels dans la carte graphique de manière optimisée est en droppant les doublons?

J'ignore de quoi tu parles, chaque application doit maintenir une image complete de son application, par contre je crois qu'il est possible a l'application de dire au serveur "redessine tel partie du buffer".

Pour ce qui est de l'affichage: tout est rendu sur un buffer hors d'écran, puis composer par le compositeur et enfin afficher, il ne devrait pas y avoir de glitch graphique donc (enfin sauf si l'application/le toolkit en fait).

o Quid du remote display qui meme s'il est possible N'EXISTE PAS et RESTE A DEVELOPPER.

Wayland tout entier reste à développer.. Il n'y a qu'à voir leur dernier TODO il est plutôt conséquent, et il y a déjà de la compatibilité X..

o Quid de l'impact de travail ENORME reporté sur les développeurs d'application

Sur les developpeurs de toolkit ou de desktop tu veux dire, par ce il y a très peu d'application qui appellent X directement.

Tout ça me fait penser au projet Berlin......(http://sourceforge.net/projects/berlin/)
Quelle perte de temps!

Bah, vu le peu de gens qui se sont intéressé à Berlin/Fresco la perte de temps a été limitée et l'objectif était différent: obtenir un système "à la NeWS" qui fonctionne encore mieux en distant, mais tu as raison intégrer un "NX" à X aurait été bien plus utile..

Note que puisque tu parle d'iPad: Apple a aussi réinventer la roue: ils ont changer leur système d'affichage (Quartz) il y a déjà un certain temps..