Comment crois-tu que les simulateurs type VHDL/Verilog fonctionnent ? C'est comme tout, il y a juste un pas de temps qui peut être supérieur à la transmission la plus rapide, il n'y a rien d'extraordinaire à calculer.
Il n'y a pas de transmission plus rapide dans un réseau de neurones. Un message de A à C passant par B donc A -> B -> C peut aller plus vite qu'un message A -> B. (Non non il n'y a pas d'erreur le chemin par trois points va plus vite que le chemin à deux.) Et ceci pour le même message (stimulation noradrénaline par exemple).
En message du neurone A vers le neurone B peut être reçu en premier par le neurone Z etc.
En plus il n'y a pas de notion d'horloge donc les messages sont en constante circulation, ça peut s’échantillonner raisonnablement mais au niveau simulation c'est pas gagné.
Un cpu voir pire un GPU, non plus. Cela n’empêche pas d'être simulable.
GNI ? Informatique analogique non déterministe ? Je t'assure que toute puce est un automate à état (et même un automate fini). Et que dans une puce, une propagation désordonnée c'est soit un bug silicium soit un court circuit et ça n'est pas franchement souhaitable.
Je ne comprends pas pourquoi tu veux faire puissance 1011, et pas *1011?
Parce qu’il faut soit stocker l'influence des neurones les un sur les autres, soit la réévaluer constamment avec un calcul d'une complexité démentielle. Dans 5000 bits tu ne stockes "que" l'état du neurone et les interactions des 25 neurotransmetteurs au niveau des synapses de ce neurone. Il te faut également stocker (ou calculer) les interactions des 25 neurotransmetteurs sur chacune des synapses qui sont connectés à ce neurone en provenance d'axones d'autres neurones. Certes un neurone ne peux jamais produire 25 neurotransmetteurs ni être connecté à tous les autres ce qui fausse l'ordre de grandeur du facteur puissance, mais on sort très vite de ce qui est calculable ou stockable. En plus il y a des problèmes de vitesse de transmission (un message qui va de A à B puis à C peut aller plus vite qu'un message qui va directement de A à C) en fonction des inhibitions et des amplifications de tel ou tel message. Le cerveau humain n'est pas un automate complexe avec des états qui se propagent de façon ordonnées.
De plus il y a des boucles dans tous les sens, dans un réseau de neurones, si un neurone influe très fréquemment sur un autre, une connexion finira par être créée entre les deux.
C'est pour cela que considérer l'état d'un neurone indépendamment de l'état du reste du cerveau n'a pas vraiment de sens.
2000 bits, soit juste 250 octets. on multiplie par 25 neurotransmetteurs et 1011 neurones
Sauf que les neurotransmetteurs interagissent les uns sur les autres. Pas tous, pas tout le temps certes, mais suffisamment pour que ce soit un problème. Donc soit on recalcule l'état final du neurone à chaque itération, soit on stocke les différentes interactions
Si on décide de stocker les interactions entre neurotransmetteurs, on a plus affaire à des multiplications mais à des puissances.
Si on décide de refaire les calculs, on un système en O(n²) par neurone avec n le nombre de neurotransmetteurs émis et reçus par le neurone. (avec un n a 25 max c'est lourd mais jouable)
Toujours pareil au niveau des interactions entre neurones. Soit on stocke les interactions soit on recalcule. Et toujours pareil avec une complexité en O(N²) avec N le nombre de neurones interconnectés dans le réseau. Comme les neurones peuvent interagir sur les neurotransmetteurs (et même quasiment que comme çà) on a au final une complexité de O(N²n²). Ouille.
Car en plus il ne faut pas prendre en compte les neurones un par un, mais tous en même temps vu qu'ils interagissent quasi instantanément les un sur les autres (par quasi instantanément j'entends le fait qu'un message d'un neurone A à un neurone B peut être inhibé par un neurone C avant même que le signal ne soit interprétable par le neurone A)
En plus bis les récepteurs d'un neurone sont stimulés ou inhibés par l'activation d'autres récepteurs voisins. On est donc obligé d'avoir l'état complet du cerveau (ou en tout cas du réseau de neurones concerné) à l'instant T pour pouvoir calculer l'état d'un neurone à l'instant T+1
Si on décide de stocker :
Tous les neurones ne peuvent pas émettre et recevoir l'ensemble des neurotransmetteurs, si c'était le cas on aurait
(10600 )25 possibilité par neurones. Donc 10600x25 = 1015000 soit (103 )5000 donc environ (210 )5000 donc 50 000 bits par neurone. Et encore une fois à la puissance 1011 pour le cerveau tout entier. le Pio est loin derrière.
Par ailleurs, je précise aussi que utiliser du brute force pour simuler chaque neurone est une approche très naïve. On comprends de mieux en mieux le fonctionnement de chaque partie de cerveaux, on arrivera sans doute bientôt à les modéliser avec des modèles bien plus simples.
Qu'on comprenne de mieux en mieux soit, mais on est encore loin du compte, et déjà avec ce que l'on sait la modélisation est loin d'être possible même sur des réseaux de quelques millions de neurones. Le coté analogique qui oblige à prendre en compte chaque paramètre en fonction de tous les autres (comme par exemple en climatologie) amène des problèmes d'une complexité démentielle que l'on choisisse une approche calculatoire ou une approche stockage de données.
1,9175x1065 possibilités par neurones, ça ce code juste en 28 octets. c'est pas grand chose
Il y a 22500 possibilités par neurones, soit 1,9175x1065 états différents pour l'ensemble du réseau.
(ce qui me semble beaucoup, je comprends pas bien ton calcul)
Ca tu peux remercier le markup lfr qui n'a pas l'air d'aimer qu'il y ait plusieurs puissances sur la même ligne. on va utiliser le e à l'avenir pour les puissances de 10 (oui c'est moche). Donc 1056 équivaut à e56. Et en plus étant fatigué j'ai un poil merdé à certains endroits. (Genre j'ai oublié qu'une synapse n'est pas forcément en train de transmettre, qu'un récepteur n'est pas forcément occupé etc.)
Le truc c'est que la liste des états n'a aucun intérêt pour une machine virtuelle, ce qui lui faut c'est la capacité à évaluer à partir de l'état N plus les commandes éventuellement passées, quel sera l'état N+1.
Et c'est là que se trouve l'erreur. Car si normalement l'espace mémoire ne sert que très peu en informatique classique, l'état du cerveau influence en quasi intégralité les états suivants.
On va dire que le monde extérieur (ici le dev) peut influer sur l'ensemble des paramètres neuronaux (état de fatigue, neurotransmetteur, inhibition) ce qui est le cas dans la vraie vie. De plus on va prendre la captation/libération des récepteurs comme étant une fonction aléatoire dépendante de la concentration relative de chaque neurotransmetteur.
La machine doit donc posséder pour chaque neurone à un instant T
- son état complet
- la concentration des différents neurotransmetteurs
- les changements induits par l'extérieur pour l'état suivant.
On refait les calculs :
3 états de fatigue (3 possibilités)
3 récepteurs qui peuvent accueillir chacun 1 des 5 neurotransmetteurs ou aucun (6x6x6 possibilités)
15 synapses connectés au neurone qui peuvent être chacune dans 4 états de stimulation différents et être en train de soumettre un message ou non. (15x4x2 possiblités)
Ca qui fait 3x6x6x6x15x4x2 possibilités soit 77 760 possibilités par neurone.
Donc au total pour l'ensemble du réseau 77 776015 possibilités soit 2,298e73. (En considérant que chaque neurone peut avoir un état indépendamment de l'état des autres neurones)
Chaque possibilité pour un neurone peut être stocké sur 17 bits. Raisonnablement en attribuant des bits séparés pour chaque segment de l'état on arrive à
2 bits pour la fatigue +
8 bits pour l'occupation des récepteurs +
7 bits pour l’état des synapses.
Il faut donc consacrer 17 bits à un état soit 255 bits pour l'ensemble du réseau.
Après il faut ajouter quelques bits pour la concentration des différents neurotransmetteurs ( au choix suivant la précision voulue) on va dire 24 bits (4 bits de précision pour la concentration d'un neurotransmetteur)
Maintenant la machine virtuelle doit être capable de déterminer en fonction de l'état N un état N+1 en prenant en compte tous les paramètres y compris l'influence extérieure. En force brute, en partant d'un système déterministe (1 etat -> 1 etat et un seul) il y a 2,298e73 possibilités pour le réseau de neurones, 2,298e73 possibilités d'interactions extérieurs (influence sur tous les paramètres) et 224 concentration en neurotransmetteurs différentes. Soit au final 2,298e73 états x (2,298e73 changements x 224 concentrations différentes en neurotrans) soit 8,860e153 cases de 279 bits chacune. Soit 3,090e155 octets de stockage pour avoir toutes les possibilités de changement possible.
Alors bien sur aucune machine virtuelle ne va s'amuser à stocker dans un coin toutes les transitions d'états, on s'attend à ce qu'elle puisse les calculer à partir des informations données. Néanmoins l'information primordiale à retenir et que l'ensemble des paramètres peut influer sur un nombre absolument délirant de neurones qui à leur tour vont influer etc.
Dans le cerveau toutes les infos sont à la fois données (stockage mémoire), message (signal) et vecteurs (registre).
En prenant un calcul pour des valeurs génériques, mais dans la vraie vie avec 1011 neurones ayant chacun en moyenne 104 connexions plusieurs centaines de récepteurs pour les neurotransmetteurs, environ 25 neurotransmetteurs connus (et plusieurs centaines de poisons qui passent la barrière hémato-encéphalique) et des centaines de paliers d'émission par synapse (avec inhibition ou non). on arrive rapidement à des nombres absolument gigantesques quand il s'agit d'évaluer le nombre d'états différents d'un neurone.
Par exemple il existe plusieurs neurotransmetteurs qui favorisent ou inhibent la transmission de certains autres neurotransmetteurs depuis la synapse jusqu'au neurone dans certaines conditions mais pas dans d'autres.
Par exemple le GABA inhibe le glutamate SAUF si il y a aussi de l'adrénaline SAUF si les cathécolamines sont déjà saturés SAUF si il y a défaut de sérotonine SAUF sur un cerveau "jeune" ou encore en développement. En donnant des paliers d'influence et de rétro-influence des différents neurotransmetteurs sur seulement une synapse et l'influence d'un seul neurotransmetteur sur un autre neurone on arrive déjà à des centaines de possibilités, si ce n'est des milliers. Donc déjà rien que sur le GABA on arrive à 1000S possibilités (avec S le nombre de synapses susceptibles de produire du GABA).
Sans compter qu'un neurotransmetteur peut se balader un peu (via la glia) et finir par se fixer sur un neurone autre que celui qui était visé par la synapse. Là on arrive à des millions de possibilités, pour un neurotransmetteur, pour une synapse.
Si un neurone a 1000 synapses susceptibles de produire du GABA on a déjà plusieurs centaines de milliards de milliards de cas possibles dans les interactions synapses - récepteurs. (Calcul : Par exemple 1000 synapses ayant chacun 1 000 000 de possibilités ca fait 1000000103 soit 10600 possibilités, près de 2000 bits pour un neurone pour un neurotransmetteur)
Après si tu prends tous les neurotransmetteurs et tours les neurones en sachant qu'à chaque ajout le nombre de possibilités croit de façon exponentielle ça devient délirant.
C'est très difficile à calculer "pour de vrai" compte tenu du nombre de paramètres qui sont encore inconnus au niveau du cerveau (le rôle de la glia dans la transmission des info c'est assez neuf par exemple). Mais même en sortant les poisons de l'équation (drogues, alcools, métaux lourds etc.) l'état du cerveau à un instant T est quasiment impossible à sauvegarder. C'est pour cela que j’étais parti sur un exemple simple.
Pour représenter tout ça, il faudrait une capacité de stockage d'au moins 10 Pio. Il serait alors possible d'émuler le cerveau un peu comme une machine virtuelle.
Supposons qu'on veuille juste couvrir tous les états possible d'un cerveau simplifié.
Par exemple un cerveau 15x15 (15 neurones tous interconnectés)
On prend trois états naturels pour les neurones (en forme, normal, fatigué)
On prend cinq neurotransmetteurs au niveau du neurone (symboliquement : angoisse, panique, plaisir, concentration, calme)
On met trois récepteurs à la surface de chaque neurone
On prend quatre états pour chaque axone (normal 100%, inhibé 50%, bloqué 0%, favorisé 150%)
On a donc un total de 3x53x4x15 états différent possible pour chaque neurone. Soit 22500.
Donc au final pour un réseau de 15 neurones simplistes : 2250015 possibilités. Soit au final 1,9175x1065 possibilités.
Il faut 2+7+2x15 = 39 bits minimum pour stocker de façon un peu utilisable l'état d'un neurone. Donc 39x15 bits pour stocker l'état de tous les neurones soit au final 1,9175x1065 x3915 octets pour stocker tous les différents états possibles.
Je vous laisse le soin de faire le calcul vous même pour 1013 neurones avec plus de 25 neurotransmetteurs et pas loin de 200 niveaux de transmissions analogiques possibles par axone. Ensuite il faudra prendre en compte le fait que la glia (qui a longtemps été considérée comme juste une gelée de soutien des neurones qui de temps en temps fait le ménage) joue un rôle dans la transmission et la stimulation des neurones (notamment des neurones miroirs) et un taux d'interconnexion pouvant dépasser 250 000 sur certains neurones du cortex préfrontal.
En plus s'ajoute à cela une différence fondamentale majeure : l'ordinateur est une machine à calculer, le cerveau est une machine à reconnaitre.
Bref la simulation de cerveau humain est quasiment impossible avec les techniques actuelles (j'entends par techniques actuelles puces électroniques avec des transistors dedans).
Attention cela ne veut en aucun cas dire que l'on ne pourra pas créer des formes de vie auto-conscientes avec des systèmes basés sur transistor, ni même que ces formes de vie ne pourrons pas se faire passer pour humaine. Mais fondamentalement elles n'auront jamais un comportement intrinsèque comparable au cerveau humain.
Ça me rappelle une scène du neuromancien de Gibson. Grosso-modo un des hackers essaye d'expliquer la différence entre une super IA et un humain et qui expliquait que lui était humain mais par exemple qu'il n'écrivait pas de poêmes, alors que si ca se trouve l'IA elle écrivait des poêmes mais pour autant n'était pas humaine.
Après la notion d'horizon informatique (que les anglais appellent "the singularity"), à savoir le moment ou un ordinateur devient capable de concevoir tout seul un ordinateur plus performant que lui même dans au moins un domaine, se rapproche clairement à grande vitesse. On devrait pouvoir l'atteindre d'ici 10 à 25 ans. Cependant il y a deux blocages majeurs :
a) Le prix des matières premières et la crise font que les budgets R&D se réduisent comme peau de chagrin sur les projets théoriques, ce qui risque de retarder pas mal les évolutions des processeurs (le rythme a déjà bien baissé récemment avec la démocratisation du multi-coeur)
b) On arrive aux limites de l'architecture transistor, à savoir que bientôt on ne pourra plus miniaturiser plus ce produit. En effet si on commence à rentrer dans des situations ou le nombre d'atomes en regard est trop petit pour que la loi des grands nombres s'applique, on est pas beau. (Explication : si on a 2 000 000 d'électron qui ont chacun 99 999 chances sur 100 000 de bouger si on les soumets à une tension électrique tout va bien, par contre si on en a 500 et sur une machine qui commute à 3Ghz…)
Il faudrait rapidement diminuer les frais fixes : 50€/mois pour la banque, la vache!!
Oui enfin en presta ça représente une heure de travail par mois. C'est quand même difficile de faire moins, sauf à diminuer le service, les sécurités, le support. Je connais pas beaucoup de commerçants qui n'ont pas au moins un problème par mois avec leur système de paiement (carte qui ne passe pas, carte volée, problème de mise à jour des certifs etc.)
Maintenant si les ventes sont très faibles ça fait mal, mais la société qui en est à 50€/mois près pour son système de vente est uen société qui ne va pas bien.
Oui ben entre les vrais jumeaux (ou plus si affinités) et les collisions de hash ça risque de pas le faire. En plus à moins de faire les prises de sang toi-même tu ne peux pas garantir que le mec ne va pas modifier la séquence génétique qu'il t'envoie pour créer un multi.
En plus il va falloir gérer à part les cas médicaux spéciaux, jumeaux siamois, cancers, chimères (mosaicisme) etc.
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.
Il n'a pas besoin de le faire. Il n'y a pas de composing. X a créé une surface de rendu via une des extensions pré-citées, l'application l'a bindé. Il n'y a rien besoin de faire d'autre.
Je ne suis pas sur de comprendre ou est le problème.
Via DRM/DRI, EXA, XAA l'appli travaille directement en mémoire GPU et le rendu ne passera jamais par la mémoire centrale. C'est bien ce que tu cherches non ?
Les seules API non compatibles sont les APIs qui permettaient d'aller chipoter directement dans les entrailles de X11.
Oui, et les bind ou les create de display sans compter un certain nombre de périphériques un peu exotiques qui sont pour l'instant laissés de coté. On ne parlera pas non plus de cairo-gl qui nécessite encore aujourd'hui que l'on fasse les includes qui vont bien à la main.
De façon générale tout le code de rendu de GTK est en pleine phase de nettoyage, donc si ca se trouve il y aura moyen de faire d'une pierre deux coups, à savoir à partir de de GTK 3.x, avec x à définir, toutes les applis pourront utiliser aussi bien du Wayland que du X11. Mais pour les applications existantes je n'y crois pas une seule seconde.
et elles ne sont pas accessibles directement sous win32 par exemple...
Certes, mais si il suffisait de ne pas se servir des API XLib ou du namespace X pour que ça fonctionne nickel sous tous les systèmes, il n'y aurait pas besoin d'autant d'efforts de portage pour faire fonctionner des applis comme Gimp ou Abiword sous divers systèmes. Même si les disparités sont connues et que GTK évolue pour les réduire, il reste des différences structurelles qui font qu'on est obligé de mettre les mains dans le code de temps en temps.
Ce sont ces différences qui vont casser les pieds entre Wayland et X.Org.
Je suis au courant de tout celà, mais ce n'est pas la question. La question est faut-il oui ou non nécessairement aller modififer du code ailleurs que dans la lib pour que les applications GTK fonctionnent correctement.
Tous les exemples que j'ai donné sont donc dans le cadre "comment peut-on faire pour que ce soit fait automagiquement et qu'il n'y ait qu'à mettre à jour la lib et recompiler".
Évidemment si on passe mon post dans le contexte générique "comment fonctionner avec Wayland" il ne veut plus rien dire.
Pour résumer ce que je disais :
X envoyait du prémaché comme message. Wayland devrait envoyer des trucs un peut plus bruts de fonderie, et certaines API ne sont pas compatibles. Il va falloir porter les applis sous Wayland et pas seulement recompiler.
Pardon pour la réponse en deux temps, j'ai voulu aller trop vite.
Hum comme X11R6 ne fait pas de composing, tes équivalents ne me paraissent pas équivalent coté performance..
Non ils sont souvent meilleurs niveau performance.
Sous Wayland (ou autre compositor) ca donne ça :
Travail dans un buffer dédié -> copie dans le buffer de composition -> copie dans le buffer affichage (ou switch buffer en cas de back buffer/triple buffer)
Sous X11R6 en DRI ca donne ça Travail dans un buffer dédié -> copie dans le buffer affichage (ou dans un back buffer)
La seule différence c'est qu'il n'y a pas d'étape de composing, donc on peut pas faire de trucs rigolos (comme des icones qui se réduisent en continuant à mettre à jour la 3D) mais niveau perf on est plutôt mieux.
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?
Si la mémoire est en off screen (généralement c'est le cas) plusieurs solutions :
a) mode m'en fous, je m'affiche. Le pilote via X indique à la carte graphique que quoi qu'il arrive c'est le contenu de tel buffer qui doit être copié à tel endroit de l'affichage. (très utile en fullscreen)
b) mode subtil : X garde en mémoire la zone ou la partie accélérée devrait se trouver, en fonction de cela il regarde si il y a d'autres fenêtres par dessus et indique à la CG les partie non recouverte et donc à copier.
c) triple buffer le composing du pauvre et du bourrin. On rend les contenus accélérés dans leur buffers respectifs, X copie tout en masse dans un backbuffer et peint ses fenêtres par dessus, on échange le back buffer et le front buffer.
Comme tu vois il n'y a à chaque fois qu'une seule copie.
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..
Sur les systèmes à changement de GPU, il y a un buffer video dédié pour le passage d'une carte graphique à l'autre. On met tout ce dont on a besoin dans ce buffer (résolution, profondeur de couleurs, les diverses zones de travail et leur contenu) et on utilise tout ça pour initialiser la nouvelle carte graphique.
A ma connaissance on a pas les specs de ce buffer, ni les specs pour initialiser les cartes graphiques à partir de ce buffer. De fait Linux (le Kernel) n'a rien implémenté pour que l'on puisse changer de pilote en cours de route (désactiver DRI, désactiver EXA et consors, rediriger vers le nouveau pilote, réactiver DRI etc.)
Si on avait les specs et si la partie pilote kernel suivait on pourrait créer une extension X11R6 et la coder dans Xorg pour faire ce switch. Tant qu'on a pas....
Peux-tu expliquer en quoi XLib pose un problème vis à vis de gérer plusieurs GPU?
Même si le protocole X11R6 est assynchrone à 99%, la XLib ne fonctionne quasiment qu'en mode synchrone. Donc pour tout un tas d'opérations elle ne peut gérer qu'une seule carte à la fois et bloque tout le reste tant qu'elle n'a pas reçu de réponse. 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é.
Si c'était vraiment le cas alors avec XCB on n'aurait pas ce problème non
Avec XCB il n'y a pas le problème en effet. De façon générale on peut parfaitement gérer plusieurs rendus/GPU/surfaces/écrans en mélangeant allègrement en X11.
Je croyais que c'était un problème d'implémentation de X.Org..
Je n'ai jamais dit que c'était un problème d'implémentation X.Org. Mon seul message est que tout ce qui est possible avec Wayland est possible avec X11R6. Si on était en langage de programmation on dirait que X11R6 et Wayland sont tous les deux turing-complet mais ne relèvent pas du même paradigme.
Je suis d'accord avec nud et Kaane
Le problème est que Kaane n'était pas complètement d'accord avec nud et que je suis Kaane. Donc soit j'ai encore réussit à faire comprendre exactement l'inverse du message que je ne voulais pas donner, soit il y a un soucis.
je pense que les décorations clients seront gérées par les toolkits
CF mon post, ça pose de nombreux problèmes. Le premier et que l'on peut cascader les compositor et donc créer un compsitor pour les décorations (un wm quoi). Le second est que certaines applis ont déjà de décorations gérées par le client (les applis compiz et les applis Gnome3 au moins), charge donc au toolkit de reconnaitre ces applis pour ne pas recoller une couche de déco par dessus. Charge ensuite au wm si il y en a un de reconnaitre tout ça pour ne pas faire de même. Sinon une appli gtk/compiz sous un wayland avec un compositor wm va se retrouver avec 3 décos...
Se pose ensuite le problème de la gestion des évènements sur ces décos. C'est pas insoluble du tout, mais comme je l'ai dit précédemment il y aura des lignes de code à corriger dans quasiment toutes les applis.
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.
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. On lui signale juste qu'on les prend et on dessine dedans. Pour les plus courant on peut citer les extensions overlay(un peu morte),DBE(pas toutes les implémentations), XAA, EXA, DRM, DRI (et dans une certaine mesure XRender même si c'est une surcouche). Toutes ces extensions vont faire mumuse directement avec la mémoire de la carte graphique, et sont donc très rapide en local.
mais sous windows lorsque le driver de la carte graphique part en couille il ne se passe rien de spécial
Ca dépend beaucoup de comment le driver part en couille, et de pourquoi.
Grosso modo on peut définir trois grands cas :
Le pilote se vautre tout seul comme un grand, il y a un bug quelconque dans le pilote, il envoie une série de commande à la carte graphique, la carte graphique répond "beurk", mais reste dans un état parfaitement valable et initialisé, l'application qui est à l'origine de la série de commande fautive se prend une notification d'erreur et suivant les cas réessaye, se vautre ou se ferme proprement. Sous Linux si c'est X11 l'application fautive il va y avoir une série de lignes dans le log et peut-être une fenêtre qui n'aura plus de père. Sous Windows si c'est explorer desktop, il va gentiment mémoriser les fenêtres et les params, se fermer et se relancer. Pas de clignotement écran dans ce cas là, juste la fermeture et la réouverture de la barre des taches et de certaines infobulle et autres icônes de notifications
La carte graphique envoie une réponse qui n'a rien à voir avec ce qui a été demandé. Défaut du pilote ou de la carte, difficile à savoir sans mettre les mains dans le cambouis, toujours est-il qu'il y a un problème. Soit l'erreur est minime et on ferme l'appli, soit l'erreur est plus grave et on tente le double context switch à la sauce windows :
1 - On passe la carte graphique dans un mode non accéléré, éventuellement avec une résolution moindre. (l'écran s'éteint et se rallume)
2 - On valide qu'en mode non accéléré le système graphique repart bien (généralement c'est le cas)
3 - On décharge tout ou partie du pilote de la carte graphique (c'est la partie que Linux ne sait pas faire, X11 peut mais l'archi au niveau kernel ne suit pas)
4 - On recharge un pilote propre et on réinitialise la carte graphique (l'écran s'éteint)
5 - On repasse en mode graphique précédent avec accélération (l'écran se rallume dans).
Parfois il y a des étapes en plus, notamment si il faut décharger tout le pilote, pas juste la partie accélération (comme dans une mise à jour) dans ce cas windows Vista/7 vont passer par un pilote de compatibilité ce qui peut pousser le nombre d'extinction/rallumage à quatre.
La carte graphique a loupé une marche lors d'un context-switch (par exemple passage en plein écran avec d'autres paramètres d'accélération) et attend toujours une info qu'elle ne recevra jamais. En attendant elle est locké en exclusif par une appli et si on tue l'appli il faut aussi refaire le switch de contexte en sens inverse avant de pouvoir repasser en mode graphique. Généralement quand un switch de contexte est demandé sous Windows Vista ou 7, on se prend un message de type "Le mode de couleur des désormais windows 7 de base". ce qui se traduit par "Il y a une appli qui a demandé un type de format de pixels, ou d'accélération que je ne peut pas lui fournir dans le mode graphique actuel. Donc je range mes affaires et je lui passe la main."
Si la carte part en vrille à ce moment là, c'est quasiment écran bleu assuré. Windows 7 va tenter de refaire le coup du passage par un mode non accéléré et reprise, mais si la carte est en attente d'infos de contexte ça a peut de chance de marcher. Sous linux c'est l'équivalent de tenter de passer sous la console, tuer l'appli qui casse les pieds et repasser en X en priant pour que l'affichage fonctionne. Des fois ça marche, souvent ça marche pas. La carte est mal initialisé, et les modes graphiques sont inaccessibles.
Sauf que les choses en question sont normalement gérées par le toolkit.
Tout à fait, GTK intercepte les messages X11 et les retransmet sous forme d'events. Sauf que là on aura plus de message X11, donc deux solutions :
- a) On créé un "serveur" dont le but est de passer générer les évènements attendus par l'appli. En d'autres termes on fait un mini serveur de messages dans chaque appli. C'est ce qui est conforme à l'architecture Wayland après tout. Mais la ce pose un problème avec les plugins. Supposons que mon appli principale ai besoin demande à accéder seulement à certains évènements - je ne vais pas compiler mon appli pour capter tous les messages possibles et imaginables - Sauf que si j'ai un plugin qui a besoin d'évènements en plus que l'appli principale, je fais quoi ? Je compile un second serveur pour chopper les évènements "en plus", au risque d'avoir des incohérences (par exemple des raccourcis clavier qui ne marchent plus si le plugin a le focus) ?
- b) On rajoute quelques lignes de codes, notamment dans les callback des plugins pour éviter à gimp de se fader 27 serveurs de messages au bout de deux heures d'utilisation ? On modifie légèrement la portée de certaines RPC pour qu'elle puisse surcharger le serveur d'évènements ?
Il y a aussi une branche pour les "client-side decorations"
Plusieurs même, une qui est utilisée principalement par Compiz, et une autre par Gnome 3. Or toutes les applications GTK ne sont pas des applis soit Compiz soit gnome 3. Et comme des décorations de fenêtre coté client existe, on peut difficilement la rajouter d'office sur toutes les applis GTK qui trainent (en fait il faudrait que le compilo s’assure du besoin ou non de rajouter des décoration fenêtre par fenêtre - c'est pas impossible, mais ça peut être complexe). En plus les solutions de décorations client s'appuient massivement sur GConf (donc Gnome) pour chopper les éléments graphiques dont elles ont besoins (on pourrait inclure les éléments en dur dans l'application, mais bonjour les changements de thème). Donc sur ce point là je ne vois pas comment on peut se passer de réécrire, au moins en partie le code.
Après on peut imaginer un serveur RPC qui traine dans un coin et qui gère à la fois la création des messages et les décoration de fenêtres. Le code pour se rattacher à ce serveur serait inclus de base dans les libs et limiterait pas mal le code à réécrire pour fonctionner complètement sous Wayland. Mais là aussi ça demande un gros effort et ca ferait double emploi avec pas mal de fonctionnalités de Gnome. Wait and see donc, mais je parie sur de la réécriture de code dans toutes les applis ou presque.
euh... Moui donc les utilisateurs de soft 3D doivent utiliser Windows. Mauvaise réponse.
Euh, ils peuvent aussi acheter des cartes pro. Et là ça marche très bien. Les cartes graphiques grand public n'ont qu'une seule idée en tête faire plus de fps que la concurrente sous le dernier jeu à la mode. Mes vieilles FireGL font très bien framebuffer + bi écran+switch fullscreen/fenetre+rendu video dans une texture en même temps. Sans plantage.
Suffit pour les maceux, de faire fonctionner un soft OpenGL sous X ( par exemple la version Linux via XWine ) et le même soft nativement sous Quartz pour voir que le problème n'est pas matériel " lié à Windows ".
Tu as déjà vu Quartz accepter un context switch ? Et si oui le reveil a pas fait trop mal à la tête le lendemain ?
Il est impossible de bypasser quartz, tous les rendus de Xquartz/X11.app se font dans des textures avec 0 ou presque accélération. Et malgré tout il y a quand même des carte ATI qui vont te geler ton mac quand tu vas passer l'application X11 en fullscreen. Sous Mac OSX si tu veux faire de l'OpenGL accéléré tu es obligé de faire appel à quartz et d'utiliser le context de quartz tel quel.
Ah, et donc le plantage de X , c'est aussi la perte de toutes les applis ouvertes
Comme sous tous les autres systèmes. Et encore sous X les applis ont une "seconde chance" si elles n'utilisent pas une lib synchrone comme XLib, une appli qui utilise XCB et qui ne voit pas revenir ses tokens peut encore lancer des sauvegardes d'etat en urgence. Sous Windows un context switch qui foire et rend la carte graphique instable c'est ecran bleu direct, sous Mac c'est freeze ad vitam, sous Linux si tu as un autre contexte prêt (par exemple une console qui n'est pas en frame buffer) ton système peut être récupérable.
Et sous Wayland , le problème existera-t-il toujours ou " pas " ?
Oui le problème sera toujours là, ou pour être exact quand il sera résolu sous Wayland, on pourra le résoudre aussi sous X11 et réciproquement. Il ne s'agit pas du tout de l'architecture X11, mais bien de la carte graphique qui sort de l'etat 1 sans parvenir à rentrer dans l'etat 2. Ca peut être un problème de pilote, d'ACPI, de concurrence entre plusieurs contextes etc. Mais la seule façon d'éviter le soucis avec wayland c'est de faire comme quartz : on interdit tout context switch. Si le mec veut passer en plein écran dans une résolution différente on zoom sa texture dans le contexte existant et c'est marre.
Mais rien dans la XLib ne permet une réservation de mémoire divisée par GPU. Rien. Et ça sera jamais fait. ( Et ça, c'est pas moi qui le dit, ce sont les dev Xorg ).
Oui la XLib est une bouse. On est d'accord. 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. En XCB on a accès à tout le protocole X11 sous-jacent, et donc faire tout ce que tu annonce.
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. Pas la gestion de mémoire, ni X11 ni même l'implémentation xorg.
Euh non, ça fait 100% du parc existant.
Je parlais bien entendu des applis écrites directement en XLib ou en TK ou en XMotif. Ces applis représentent aujourd'hui encore l'écrasante majorité des applis métier.
Mais combien de logiciels " sont à réécrire " , en dehors des libs comme GTK et Qt ?
Mais même les applis codées en GTK ou en QT parfait sont à réécrire. Wayland fait moins de chose que X11, toutes les choses qui ne sont pas faites par Wayland doivent désormais être faites au sein de l'appli. Ca implique nécessairement de revoir tout le code, à moins de vouloir lancer un émulateur X complet avec gestion des inputs + un décorateur de fenêtre qui fait mini-wm avec chaque fenêtre.
de toutes façons ces logiciels n'auraient pas passé sans heurts le passage à XCB.
Oui mais on aurait changé un truc. A savoir le système de messagerie entre les applis et le serveur X. Là on se retrouve à tout changer et à tout devoir recoder. Et quand je vois le mal qu'a eu Rasterman pour migrer les EFL sous XCB. Ca a pris quatre ans ! Pour une lib qui n'était utilisée par quasiment personne, qui pouvait très largement se permettre de tout casser et qui avait l'objectif de passer en XCB dans ses priorités. (Et en plus Rasterman est loin d'être un manchot quand il s'agit de gérer le protocole X11 à la mano, On peut pas en dire autant de tous les devs d'applis graphiques). Ceci étant si les grosses libs avaient vraiment suivi (i.e fait du XCB pur) on aurait pu avoir un système plus faible aujourd'hui, avec pour les applis qui utilisent ces libs des recettes sur "comment faire ci ou ça dans la nouvelle version de la lib." Mais même ça, ça n'a pas marché.
Avec Wayland on fout à la poubelle les libs de haut niveau, les libs de bas niveau, le système de message, le paradigme d'affichage tout entier etc. C'est cent fois plus dur.(Ce qui ne veut pas dire que ça ne se fera pas, tout dépend une fois de plus du degré d'implication des grands acteurs, et aussi de la qualité de la doc)
Mais Wayland ne permet rien que X11R6 ne puisse faire. Il promet de dégraisser le mammouth et de passer sur un paradigme plus adapté aux besoins d'aujourd'hui. Ce n'est pas une mauvaise chose, et ça peut même être très positif. Mais ça demande un effort colossal de l'ensemble de la communauté.
En fait non, je ne retrouve plus l'article qui expliquait qu'avec mission control venait un gestionnaire de composition repensé sauce GCD. Maintenant que Google est noyé sous les "comment changer la couleur de fond quand on est sous mission control kikoo lol" ca va être plus dur à retrouver.
Pour les applications normale il me semble que c'est (1) qui est utilisé, pourquoi WebGL serait différent?
C'est la solution la plus facile et la plus simple. Mais c'est aussi celle qui a le pire rendement niveau perf. On se retrouve à rendre la frame, à la mettre de coté, à la placer dans le buffer wayland, et à attendre le composing avant de finalement arriver jusqu'à l'affichage.
Dans les autres méthodes on fait un rendu que la carte graphique affiche directement quand il est fini.
_Quid des applications qui plantent sous X obligeant à relancer le serveur X ? _
Elles claqueront pareil sous Wayland, a moins que l'on modifie complètement toute l'architecture sous-jacente DRI/Pilote graphique. Ce n'est pas un problème de Xorg/XFree, encore moins un problème de X11R6 - c'est juste que les cartes graphiques grand public ne sont pas prévue pour gérer les switch de context autrement qu'à la sauce windows. Après la carte graphique se bloque, et X ne peut plus rien y faire.
Est ce que l'adressage mémoire actuel est capable de gérer 2 applis qui utilisent chacun une carte graphique ? Non ! Est-ce que ça sera implanté sous X ? " incompatible par nature "
X11R6 incompatible par nature avec la gestion de plusieurs applis chacune sur carte graphique différente, voire plusieurs machine différentes ? Faut le dire vite à SGI. La force de X11R6 est justement qu'on peut gérer chaque sous fenêtre d'une appli depuis une source différente, du moment que ça peut pondre un "drawable" ça marche. Et sinon c'est pas les extensions de bypass et d’accès direct qui manquent.
Mais, non, en fait, manque de pot, dans 4 heures, tes distributions favorites vont te forcer la mise à jour vers Wayland en virant X. T'as plus que 4 heures à utiliser ssh -X .
Tu es passé à coté du problème. Bien sur la mise à jour ne vas pas se faire en trente secondes, mais il y a quand même un vrai problème : si il est acceptable que Wayland puisse pendant une période de transition utiliser un wrapper X11, c'est un luxe que ne vont pas trop pouvoir se payer les logiciels de prise de main à distance, à moins de vouloir rendre leur code très complexe. Donc soit on lance un serveur Wayland complet pour chaque prise de main, soit il faut que les applis elle même soient bi-compatibles X/Wayland. J'y crois moyen. Pendant tout un temps on aura des prises de main à distance sauce wayland pour lancer des applis wayland et des prises de main à distance sauce X11 pour lancer des applis X11. Ca me fait saliver d'avance.
mmh, les biblio GTK, Qt, les EFL sont en cours de portage pour Wayland. Si les dev ont travaillés avec les bibliothèques concernés, normalement, ça devrait être transparent, exactement comme quand on est passé de XAA à EXA, ou comme lorsque XRender est arrivé, ou comme quand DBus est arrivé.
Ou comme quand Fleury Michon a mis moins de sel dans son jambon à l'os ou comme quand Pluton n'a plus été considéré comme une planète...
Tu as idée de la différence de surface qu'il y a entre X11R6 et ses différentes révisions/implémentation et le EXA ? Tu ne vois pas la différence qu'il y a entre "certains pilote libre n'auront plus d’accélération graphique" et "Il faut recompiler toutes les applications graphiques en mettant à jour toutes les libs grpahiques et en priant pour qu'il n'y ait pas trop de code à réécrire."
Non sincèrement. Toutes les autres applications que tu cites sont optionnelles. Si je ne veux pas m'en servir, ben je m'en sers pas et ça roule pareil qu'avant. Si vraiment je veux absolument utiliser DBus au lieu de /proc ou EXA au lieu de XAA j'ai un endroit dans le code à modifier pour le faire (si mon code est propre).
Avec Wayland, une application graphique doit gérer la souris, la saisie, les décorations de fenêtres, les buffers Wayland etc. Le tout en cassant tout le code d'affichage précédent. Je n'ai pas vu de système de gestion de souris ou de gestion de décoration de fenêtre dans GTK. Donc même si mon code GTK aujourd'hui est très très propre (grosso-modo je n'ai pas un seul widget perso, pas une surcharge de (pseudo)classe, pas un accès direct à des buffers vidéos), il faudra quand même que je recode le tout. Et personnellement je doute fort que GTK2 et QT3 passe à Wayland, et pourtant j'ai pleins d'applis GTK2 et QT3 que j'aime bien.
Certaines applis utilisent encore la XLib
Oui quelques unes. XLib, XMotif ou TK, ca doit faire quoi 75/80% du parc existant grand maximum. Une paille. Il y a pas que le Desktop de hobbyiste dans la vie.
moui quelle perte de temps. 10 ans que les applis OpenGL plantent
Et 20 ans que SGI ne s'en est pas rendu compte.
4 ans que les premiers ordis OPTIMUS sont sortis
Ca c'est l'argument qui tue. C'est clair, dès que le Desktop Linux va passer sous Wayland, NVidia va libérer les specs des hold buffers. Mais attention elle ne va les libérer que pour Wayland, interdiction de les utiliser pour xorg.
2 ans que des dev X11 disent qu'il faut passer à Wayland, et toujours rien
C'est clair que Wayland a reçu le soutien massif des devs X11 et du X consortium en général. Bon la plupart des devs X11 et des membres du X Consortium sont chez Intel c'est pour ça que ça se voit pas trop. Mais c'est massif comme mouvement.
De ce que je comprends, il n'y a pas "d'envoi" de buffer avec Wayland.
Pour un rendu OpenGL/WebGL "accéléré" il faut travailler dans un espace spécial. Donc soit cet espace est fourni par Wayland (solution 3 de mon post), soit le rendu est effectué par Wayland à partir de pseudo-code (solution 2) soit on travaille dans un espace non affiché et on copie le rendu dans le buffer Wayland à la fin (solution 1 que j'ai appelé "envoi de buffer" parceque s'en est un même si je me rend compte que ça peut porter à confusion)
Mais dans l'état actuel des choses, on utilise seulement un seul compositeur
On en utilise même souvent 0. A l'heure actuelle on peut parfaitement se passer des différents "display compositors" et avoir un système qui marche très bien. Sauf que là la règle va changer, on va en fait avoir des cascades de compositors.
Déjà le compositor final Wayland, ensuite probablement au moins un des clients (ou plugins du serveur wayland ?) sera un composite window manager.
Ensuite se pose les problèmes de tout ce qui utilise les backbuffers, l'accès direct ou l'overlay (video, 2D/3D accéléré etc.) Parceque ça fait pas forcément très bon ménage avec les compositors. Bien sur il existe des solutions qui marchent, mais il va falloir faire des choix et définir des priorités. Par exemple que se passe-t-il sur un contenu webGL dans firefox ? Est-ce que l'on fait un rendu complet de tout le WebGL et qu'on l'envoi à Wayland ? Est-ce qu'on créé un hook dans Wayland pour qu'il fasse le rendu webGL lui-même (avec ou sans aide de Firefox qui peut prémacher une partie du boulot) ou est-ce qu'on définit une zone buffer dans Wayland dans laquelle il n'y a pas de composing et ou le rendu se fait en direct ? Ou alors est-ce qu'on multiplie les API pour garder la compatibilité (et dans ce cas je sens qu'on va encore jouer à "ou qu'elle est la doc ? D T Code !")
Chez OSX, qui est un peu le leader sur les techniques de composing dans les ordis grand public, ils ont été amenés a créer un chef d'orchestre pour mettre un peu d'ordre dans toutes les priorités des différentes applis de composing (mission control). Et pourtant eux ils avaient plus ou moins table rase de l'historique. Chose que Linux va avoir du mal à faire.
Donc plusieurs compositors c'est à peu près obligatoire, reste à savoir si on pourra avoir plusieurs moteurs de composing en même temps. Si oui, comment vont-ils dialoguer ensemble pour pas se taper sur la gueule (pas DBus, pitié pas DBus), sinon est-ce que le moteur "officiel" de Gnome sera compatible avec celui de KDE ou avec celui d'enlightenment...
_Question con: Pourquoi voudrais-tu avoir deux compositeurs différents dans un même gestionnaire de fenêtres ? _
Réponse : parce que je peux ? (enfin si je peux)
Il y a pleins de raisons de vouloir avoir des écrans séparés gérés par des compositors différents. Par exemple avoir un écran de dev et un écran de rendu, que ce soit pour la photo, le dessin, le montage video ou même simplement le développement de sites webs.
Et puis je ne sais pas comment Wayland va gérer les écrans multiples non identiques (comme un écran en mode portrait, un autre plus petit pour les infos critiques et le debug).
De toute façon ce qui m'intéresse se sont les cas particuliers, et comment ils vont être pris en compte. Parce que ce qui fait le succès d'une appli open source c'est tous les trucs bizarres qu'on ne pouvait pas faire avant qu'elle arrive. Les cas ultra généraux seront traités convenablement je pense.
Et puis aussi il ne faut pas oublier la loi des 90/90. En informatique 90% des utilisateurs veulent faire au moins un truc dont 90% des autres utilisateurs n'ont strictement rien à foutre.
Vu la diversité des gestionnaires de fenêtres sous X, et vu ce qu'utilisent pas mal de barbus (Window Maker, le défunt Ion3, wmii, awesome et compagnie), la résistance à Wayland promet d'être féroce.
Et si encore il y avait que les barbus.
Déjà il y a tous les scripts d'init et d'autoconfig à réécrire, donc les distribs vont super bien le vivre.
Ensuite tous les logiciels de prise de main à distance, que ce soit par export du display ou par pseudo serveur X sont à réécrire, à moins de se palucher des couches et des couches de compatibilité.
Après il y aura les cas à la con, genre la fenêtre à cheval sur deux écrans en Opengl avec chacun des deux écrans qui utilisent un compositor différent. Ou alors une appli web HTML5 en full screen sur deux écrans avec du webgl et du flash dedans.
Avec un peu de chances on aura même des API noyeau ou des programmes de config qui étaient utilisés principalement par X et qui vont être deprecated pendant 10, 15 ans (on en est à 9 ans pour OSS, 13 pour ifconfig)
Avec un peu de chance peut-être même que L.P finira par écrire une surcouche de gestion userland.
Bienvenue en 2012 ? Y a quoi comme distro aujourd'hui qui n'active pas CONFIG_ADVANCED_ROUTER ? Mis à part les distros orienté embarqué ou vielles machines, je vois pas ...
Je ne sais pas si Linux le fait par défaut. Je sais que ça s'active par défaut si tu mets deux prefix dans ton RAD. Je sais aussi que la plupart des gens qui s'essayent à faire du advanced router oublient généralement un ou deux trucs, sont surpris que ça marche pas et finissent par passer en DHCP6 qui est une horreur.
Bien sûr que ça marche...
C'est contraire à la norme, un jour tu vas tomber sur un router/switch/firewall ou autre qui va juste t'envoyer balader, ou qui refusera carrément de dialoguer avec toi. Il y a pas que du Linux sur un réseau.
Et bien tu prend le cas du premier post du fil : Un utilisateur arrive derrière, s'assure que dhclient est mort, puis fait un ip address add 192.168.1.42/24 dev eth0. Avahi va t'il gicler l'adresse ? ah ben non ... t'aura du link-local ipv4 et une adresse administrée localement. Et ça marche.
Le script qui est donné sur la home page de avahi.org n'utilise pas les pseudo-scopes, il est en scope link (donc le prefered de l'interface). Donc si tu fais ip address add sans scope tu vas gicler l'adresse avahi-autoipd CF :
However it has the disadvantage of breaking existing TCP connections to IPv4LL hosts if suddenly a routable address is configured. Nonetheless we decided to make this behaviour the default.
Si tu repasses le script à la main (qui est toujours en scope link) tu vas regicler ta nouvelle adresse et remettre une adresse en 169.x à la place. Fais le test si tu ne me crois pas (avec le script de la home page d'avahi hein).
Maintenant si ta distrib a décidé de lancer quoi qu'il arrive un script autoipd avec un pseudo-scope local, ça la regarde. Mais bon a part du du zero conf à la sauce Apple je vois pas l’intérêt.
Non ?
Si, si.
Non plus. Avahi-autoipd va directement taper sur netlink et observer les interfaces voulues en regardant si elles deviennent up ou pas.
Avahi-autoipd il est aveugle et sourd. Tu l'invoque et il s’exécute, tu l'invoques pas et il ne bouge pas. (En tout cas c'était le cas la dernière fois que j'ai regardé et c'est aussi ce qui est marqué dans la doc, maintenant c'est vrai qu'avec Linux ça a pu changer trois fois depuis sans que la donc bouge d'un iota).
La bonne façon de l'invoquer c'est en fin de script dhclient suite à un echec. Maintenant tu peux aussi l'invoquer sur des événements DBus lié à netlink j'imagine. Je ne vois pas ce que ça apporterait une fois de plus.
Pas du tout, c'est plutôt le contraire : les mécanismes d'alias sont utilisés pour rendre ifconfig compatible avec ip.
Ca fait 10 ans que ifconfig est "deprecated", il fait la course avec OSS.
Maintenant mettons les choses à plat sur ce qui se passe :
ifconfig utilise inet. Quand on créé un alias avec ifconfig, il y a un hint qui est fichu dans un socket inet, le noyau reçoit le message et créé un alias. Quand ifconfig SOUS LINUX interroge une interface physique, il interroge en fait les sockets inet rattachés à cette interface et récupère les alias des sockets inet.
iproute faisait exactement la même chose avec les sockets netlink.
Donc au niveau noyau les alias étaient en place, mais iproute ne voyait pas les alias créé par ifconfig et réciproquement.
Après moults trolls et autre combats pour que Linux fasse comme le reste du monde (à savoir demander au noyau plutôt qu'aux sockets, mais ça a un cout en terme de perfs et ça aurait entrainé la réécriture d'une partie de la pile IP), il a été décidé qu'iproute lirait aussi les infos d'ifconfig , mais qu'ifconfig étant deprecated il pouvait aller se faire voir (on est alors en 2001).
Dans la plus pure tradition linux, 11 plus tard les scripts d'init réseau n'ont toujours pas été réécrit et utilisent toujours ifconfig. Il a donc bien fallu trouver des gruikeries pour que les sockets inet et les sockets netlink représentent à peu près la même chose.
C'est juste que ifconfig affichait seulement la première adresse IP que le noyau trouvait
Non, en fait le format de socket inet ne permettait pas au noyau de donner une réponse complète, à savoir toute les alias sur iptables nommées partaient à la poubelle. Faut dire que la dernière mise à jour de ifconfig sous linux ca date de 1999...
Mauvaise configuration, changer configuration ?
J'ai déjà changé, je suis sous BSD maintenant pour toutes ces sortes de choses. Avec un ifconfig qui est mis à jour régulièrement et qui marche très bien (cf mon tout premier post). Sous les différents Unix Like ifconfig a évolué pas mal au court des 14 dernières années contrairement à Linux. Maintenant si tu veux je peux te donner une série de commandes à passer sous un linux, qui utilise iproute2 sur une machine qui a deux interfaces physiques et qui ont pour effet de péter en morceau l'arbre de recherche ARP de tous les switchs un peu cheap du marché. Bonne ou mauvaise chose ça se discute, mais les BSD ne te laissent pas faire ce genre de clowneries.
Ça doit être génial pour les performances, non ?
De quoi de passer par une règle firewall pour les forwards de paquets depuis une autre IP ou une autre interface que l'IP ou l'interface naturelle ? Non pas du tout.
Et tant bien même ça aurait un impact, il serait toujours nettement plus faible que celui que pourrait générer un logiciel de configuration qui créé une règle firewall nommée par alias et par route comme le fait iproute2.
Le seul défaut est de devoir les palucher à la main là ou iproute2 les créé en automatique, mais vu les dommages collatéraux potentiels je fais partie des gens qui pensent que ce genre de config doivent être faite par un être humain avec un niveau de connaissance assez élevé sur ce qu'il est en train de bidouiller. Mais après ça se discute.
[^] # Re: Légère erreur de calcul
Posté par Kaane . En réponse au journal See the World in True Colors.. Évalué à 2.
Comment crois-tu que les simulateurs type VHDL/Verilog fonctionnent ? C'est comme tout, il y a juste un pas de temps qui peut être supérieur à la transmission la plus rapide, il n'y a rien d'extraordinaire à calculer.
Il n'y a pas de transmission plus rapide dans un réseau de neurones. Un message de A à C passant par B donc A -> B -> C peut aller plus vite qu'un message A -> B. (Non non il n'y a pas d'erreur le chemin par trois points va plus vite que le chemin à deux.) Et ceci pour le même message (stimulation noradrénaline par exemple).
En message du neurone A vers le neurone B peut être reçu en premier par le neurone Z etc.
En plus il n'y a pas de notion d'horloge donc les messages sont en constante circulation, ça peut s’échantillonner raisonnablement mais au niveau simulation c'est pas gagné.
Un cpu voir pire un GPU, non plus. Cela n’empêche pas d'être simulable.
GNI ? Informatique analogique non déterministe ? Je t'assure que toute puce est un automate à état (et même un automate fini). Et que dans une puce, une propagation désordonnée c'est soit un bug silicium soit un court circuit et ça n'est pas franchement souhaitable.
[^] # Re: Légère erreur de calcul
Posté par Kaane . En réponse au journal See the World in True Colors.. Évalué à 2.
Je ne comprends pas pourquoi tu veux faire puissance 1011, et pas *1011?
Parce qu’il faut soit stocker l'influence des neurones les un sur les autres, soit la réévaluer constamment avec un calcul d'une complexité démentielle. Dans 5000 bits tu ne stockes "que" l'état du neurone et les interactions des 25 neurotransmetteurs au niveau des synapses de ce neurone. Il te faut également stocker (ou calculer) les interactions des 25 neurotransmetteurs sur chacune des synapses qui sont connectés à ce neurone en provenance d'axones d'autres neurones. Certes un neurone ne peux jamais produire 25 neurotransmetteurs ni être connecté à tous les autres ce qui fausse l'ordre de grandeur du facteur puissance, mais on sort très vite de ce qui est calculable ou stockable. En plus il y a des problèmes de vitesse de transmission (un message qui va de A à B puis à C peut aller plus vite qu'un message qui va directement de A à C) en fonction des inhibitions et des amplifications de tel ou tel message. Le cerveau humain n'est pas un automate complexe avec des états qui se propagent de façon ordonnées.
De plus il y a des boucles dans tous les sens, dans un réseau de neurones, si un neurone influe très fréquemment sur un autre, une connexion finira par être créée entre les deux.
C'est pour cela que considérer l'état d'un neurone indépendamment de l'état du reste du cerveau n'a pas vraiment de sens.
[^] # Re: Légère erreur de calcul
Posté par Kaane . En réponse au journal See the World in True Colors.. Évalué à 1.
2000 bits, soit juste 250 octets. on multiplie par 25 neurotransmetteurs et 1011 neurones
Sauf que les neurotransmetteurs interagissent les uns sur les autres. Pas tous, pas tout le temps certes, mais suffisamment pour que ce soit un problème. Donc soit on recalcule l'état final du neurone à chaque itération, soit on stocke les différentes interactions
Si on décide de stocker les interactions entre neurotransmetteurs, on a plus affaire à des multiplications mais à des puissances.
Si on décide de refaire les calculs, on un système en O(n²) par neurone avec n le nombre de neurotransmetteurs émis et reçus par le neurone. (avec un n a 25 max c'est lourd mais jouable)
Toujours pareil au niveau des interactions entre neurones. Soit on stocke les interactions soit on recalcule. Et toujours pareil avec une complexité en O(N²) avec N le nombre de neurones interconnectés dans le réseau. Comme les neurones peuvent interagir sur les neurotransmetteurs (et même quasiment que comme çà) on a au final une complexité de O(N²n²). Ouille.
Car en plus il ne faut pas prendre en compte les neurones un par un, mais tous en même temps vu qu'ils interagissent quasi instantanément les un sur les autres (par quasi instantanément j'entends le fait qu'un message d'un neurone A à un neurone B peut être inhibé par un neurone C avant même que le signal ne soit interprétable par le neurone A)
En plus bis les récepteurs d'un neurone sont stimulés ou inhibés par l'activation d'autres récepteurs voisins. On est donc obligé d'avoir l'état complet du cerveau (ou en tout cas du réseau de neurones concerné) à l'instant T pour pouvoir calculer l'état d'un neurone à l'instant T+1
Si on décide de stocker :
Tous les neurones ne peuvent pas émettre et recevoir l'ensemble des neurotransmetteurs, si c'était le cas on aurait
(10600 )25 possibilité par neurones. Donc 10600x25 = 1015000 soit (103 )5000 donc environ (210 )5000 donc 50 000 bits par neurone. Et encore une fois à la puissance 1011 pour le cerveau tout entier. le Pio est loin derrière.
Par ailleurs, je précise aussi que utiliser du brute force pour simuler chaque neurone est une approche très naïve. On comprends de mieux en mieux le fonctionnement de chaque partie de cerveaux, on arrivera sans doute bientôt à les modéliser avec des modèles bien plus simples.
Qu'on comprenne de mieux en mieux soit, mais on est encore loin du compte, et déjà avec ce que l'on sait la modélisation est loin d'être possible même sur des réseaux de quelques millions de neurones. Le coté analogique qui oblige à prendre en compte chaque paramètre en fonction de tous les autres (comme par exemple en climatologie) amène des problèmes d'une complexité démentielle que l'on choisisse une approche calculatoire ou une approche stockage de données.
[^] # Re: Légère erreur de calcul
Posté par Kaane . En réponse au journal See the World in True Colors.. Évalué à 4.
1,9175x1065 possibilités par neurones, ça ce code juste en 28 octets. c'est pas grand chose
Il y a 22500 possibilités par neurones, soit 1,9175x1065 états différents pour l'ensemble du réseau.
(ce qui me semble beaucoup, je comprends pas bien ton calcul)
Ca tu peux remercier le markup lfr qui n'a pas l'air d'aimer qu'il y ait plusieurs puissances sur la même ligne. on va utiliser le e à l'avenir pour les puissances de 10 (oui c'est moche). Donc 1056 équivaut à e56. Et en plus étant fatigué j'ai un poil merdé à certains endroits. (Genre j'ai oublié qu'une synapse n'est pas forcément en train de transmettre, qu'un récepteur n'est pas forcément occupé etc.)
Le truc c'est que la liste des états n'a aucun intérêt pour une machine virtuelle, ce qui lui faut c'est la capacité à évaluer à partir de l'état N plus les commandes éventuellement passées, quel sera l'état N+1.
Et c'est là que se trouve l'erreur. Car si normalement l'espace mémoire ne sert que très peu en informatique classique, l'état du cerveau influence en quasi intégralité les états suivants.
On va dire que le monde extérieur (ici le dev) peut influer sur l'ensemble des paramètres neuronaux (état de fatigue, neurotransmetteur, inhibition) ce qui est le cas dans la vraie vie. De plus on va prendre la captation/libération des récepteurs comme étant une fonction aléatoire dépendante de la concentration relative de chaque neurotransmetteur.
La machine doit donc posséder pour chaque neurone à un instant T
- son état complet
- la concentration des différents neurotransmetteurs
- les changements induits par l'extérieur pour l'état suivant.
On refait les calculs :
3 états de fatigue (3 possibilités)
3 récepteurs qui peuvent accueillir chacun 1 des 5 neurotransmetteurs ou aucun (6x6x6 possibilités)
15 synapses connectés au neurone qui peuvent être chacune dans 4 états de stimulation différents et être en train de soumettre un message ou non. (15x4x2 possiblités)
Ca qui fait 3x6x6x6x15x4x2 possibilités soit 77 760 possibilités par neurone.
Donc au total pour l'ensemble du réseau 77 776015 possibilités soit 2,298e73. (En considérant que chaque neurone peut avoir un état indépendamment de l'état des autres neurones)
Chaque possibilité pour un neurone peut être stocké sur 17 bits. Raisonnablement en attribuant des bits séparés pour chaque segment de l'état on arrive à
2 bits pour la fatigue +
8 bits pour l'occupation des récepteurs +
7 bits pour l’état des synapses.
Il faut donc consacrer 17 bits à un état soit 255 bits pour l'ensemble du réseau.
Après il faut ajouter quelques bits pour la concentration des différents neurotransmetteurs ( au choix suivant la précision voulue) on va dire 24 bits (4 bits de précision pour la concentration d'un neurotransmetteur)
Maintenant la machine virtuelle doit être capable de déterminer en fonction de l'état N un état N+1 en prenant en compte tous les paramètres y compris l'influence extérieure. En force brute, en partant d'un système déterministe (1 etat -> 1 etat et un seul) il y a 2,298e73 possibilités pour le réseau de neurones, 2,298e73 possibilités d'interactions extérieurs (influence sur tous les paramètres) et 224 concentration en neurotransmetteurs différentes. Soit au final 2,298e73 états x (2,298e73 changements x 224 concentrations différentes en neurotrans) soit 8,860e153 cases de 279 bits chacune. Soit 3,090e155 octets de stockage pour avoir toutes les possibilités de changement possible.
Alors bien sur aucune machine virtuelle ne va s'amuser à stocker dans un coin toutes les transitions d'états, on s'attend à ce qu'elle puisse les calculer à partir des informations données. Néanmoins l'information primordiale à retenir et que l'ensemble des paramètres peut influer sur un nombre absolument délirant de neurones qui à leur tour vont influer etc.
Dans le cerveau toutes les infos sont à la fois données (stockage mémoire), message (signal) et vecteurs (registre).
En prenant un calcul pour des valeurs génériques, mais dans la vraie vie avec 1011 neurones ayant chacun en moyenne 104 connexions plusieurs centaines de récepteurs pour les neurotransmetteurs, environ 25 neurotransmetteurs connus (et plusieurs centaines de poisons qui passent la barrière hémato-encéphalique) et des centaines de paliers d'émission par synapse (avec inhibition ou non). on arrive rapidement à des nombres absolument gigantesques quand il s'agit d'évaluer le nombre d'états différents d'un neurone.
Par exemple il existe plusieurs neurotransmetteurs qui favorisent ou inhibent la transmission de certains autres neurotransmetteurs depuis la synapse jusqu'au neurone dans certaines conditions mais pas dans d'autres.
Par exemple le GABA inhibe le glutamate SAUF si il y a aussi de l'adrénaline SAUF si les cathécolamines sont déjà saturés SAUF si il y a défaut de sérotonine SAUF sur un cerveau "jeune" ou encore en développement. En donnant des paliers d'influence et de rétro-influence des différents neurotransmetteurs sur seulement une synapse et l'influence d'un seul neurotransmetteur sur un autre neurone on arrive déjà à des centaines de possibilités, si ce n'est des milliers. Donc déjà rien que sur le GABA on arrive à 1000S possibilités (avec S le nombre de synapses susceptibles de produire du GABA).
Sans compter qu'un neurotransmetteur peut se balader un peu (via la glia) et finir par se fixer sur un neurone autre que celui qui était visé par la synapse. Là on arrive à des millions de possibilités, pour un neurotransmetteur, pour une synapse.
Si un neurone a 1000 synapses susceptibles de produire du GABA on a déjà plusieurs centaines de milliards de milliards de cas possibles dans les interactions synapses - récepteurs. (Calcul : Par exemple 1000 synapses ayant chacun 1 000 000 de possibilités ca fait 1000000103 soit 10600 possibilités, près de 2000 bits pour un neurone pour un neurotransmetteur)
Après si tu prends tous les neurotransmetteurs et tours les neurones en sachant qu'à chaque ajout le nombre de possibilités croit de façon exponentielle ça devient délirant.
C'est très difficile à calculer "pour de vrai" compte tenu du nombre de paramètres qui sont encore inconnus au niveau du cerveau (le rôle de la glia dans la transmission des info c'est assez neuf par exemple). Mais même en sortant les poisons de l'équation (drogues, alcools, métaux lourds etc.) l'état du cerveau à un instant T est quasiment impossible à sauvegarder. C'est pour cela que j’étais parti sur un exemple simple.
# Légère erreur de calcul
Posté par Kaane . En réponse au journal See the World in True Colors.. Évalué à 5. Dernière modification le 04 mars 2012 à 20:35.
Pour représenter tout ça, il faudrait une capacité de stockage d'au moins 10 Pio. Il serait alors possible d'émuler le cerveau un peu comme une machine virtuelle.
Supposons qu'on veuille juste couvrir tous les états possible d'un cerveau simplifié.
Par exemple un cerveau 15x15 (15 neurones tous interconnectés)
On prend trois états naturels pour les neurones (en forme, normal, fatigué)
On prend cinq neurotransmetteurs au niveau du neurone (symboliquement : angoisse, panique, plaisir, concentration, calme)
On met trois récepteurs à la surface de chaque neurone
On prend quatre états pour chaque axone (normal 100%, inhibé 50%, bloqué 0%, favorisé 150%)
On a donc un total de 3x53x4x15 états différent possible pour chaque neurone. Soit 22500.
Donc au final pour un réseau de 15 neurones simplistes : 2250015 possibilités. Soit au final 1,9175x1065 possibilités.
Il faut 2+7+2x15 = 39 bits minimum pour stocker de façon un peu utilisable l'état d'un neurone. Donc 39x15 bits pour stocker l'état de tous les neurones soit au final 1,9175x1065 x3915 octets pour stocker tous les différents états possibles.
Je vous laisse le soin de faire le calcul vous même pour 1013 neurones avec plus de 25 neurotransmetteurs et pas loin de 200 niveaux de transmissions analogiques possibles par axone. Ensuite il faudra prendre en compte le fait que la glia (qui a longtemps été considérée comme juste une gelée de soutien des neurones qui de temps en temps fait le ménage) joue un rôle dans la transmission et la stimulation des neurones (notamment des neurones miroirs) et un taux d'interconnexion pouvant dépasser 250 000 sur certains neurones du cortex préfrontal.
En plus s'ajoute à cela une différence fondamentale majeure : l'ordinateur est une machine à calculer, le cerveau est une machine à reconnaitre.
Bref la simulation de cerveau humain est quasiment impossible avec les techniques actuelles (j'entends par techniques actuelles puces électroniques avec des transistors dedans).
Attention cela ne veut en aucun cas dire que l'on ne pourra pas créer des formes de vie auto-conscientes avec des systèmes basés sur transistor, ni même que ces formes de vie ne pourrons pas se faire passer pour humaine. Mais fondamentalement elles n'auront jamais un comportement intrinsèque comparable au cerveau humain.
Ça me rappelle une scène du neuromancien de Gibson. Grosso-modo un des hackers essaye d'expliquer la différence entre une super IA et un humain et qui expliquait que lui était humain mais par exemple qu'il n'écrivait pas de poêmes, alors que si ca se trouve l'IA elle écrivait des poêmes mais pour autant n'était pas humaine.
Après la notion d'horizon informatique (que les anglais appellent "the singularity"), à savoir le moment ou un ordinateur devient capable de concevoir tout seul un ordinateur plus performant que lui même dans au moins un domaine, se rapproche clairement à grande vitesse. On devrait pouvoir l'atteindre d'ici 10 à 25 ans. Cependant il y a deux blocages majeurs :
a) Le prix des matières premières et la crise font que les budgets R&D se réduisent comme peau de chagrin sur les projets théoriques, ce qui risque de retarder pas mal les évolutions des processeurs (le rythme a déjà bien baissé récemment avec la démocratisation du multi-coeur)
b) On arrive aux limites de l'architecture transistor, à savoir que bientôt on ne pourra plus miniaturiser plus ce produit. En effet si on commence à rentrer dans des situations ou le nombre d'atomes en regard est trop petit pour que la loi des grands nombres s'applique, on est pas beau. (Explication : si on a 2 000 000 d'électron qui ont chacun 99 999 chances sur 100 000 de bouger si on les soumets à une tension électrique tout va bien, par contre si on en a 500 et sur une machine qui commute à 3Ghz…)
# Malheureusement
Posté par Kaane . En réponse au message GW-Basic sur Linux ?. Évalué à 1.
Sur Linux, peut-on écrire des programmes en GW-Basic ?
Non, ça ne marche pas non plus sous Linux.
[^] # Re: Combien ça coûterait ?
Posté par Kaane . En réponse au journal Arrêt d'Elveos.org. Évalué à 5.
Il faudrait rapidement diminuer les frais fixes : 50€/mois pour la banque, la vache!!
Oui enfin en presta ça représente une heure de travail par mois. C'est quand même difficile de faire moins, sauf à diminuer le service, les sécurités, le support. Je connais pas beaucoup de commerçants qui n'ont pas au moins un problème par mois avec leur système de paiement (carte qui ne passe pas, carte volée, problème de mise à jour des certifs etc.)
Maintenant si les ventes sont très faibles ça fait mal, mais la société qui en est à 50€/mois près pour son système de vente est uen société qui ne va pas bien.
[^] # Re: hash de l'ADN
Posté par Kaane . En réponse au journal Donner un accès unique aux internautes. Évalué à 6.
Oui ben entre les vrais jumeaux (ou plus si affinités) et les collisions de hash ça risque de pas le faire. En plus à moins de faire les prises de sang toi-même tu ne peux pas garantir que le mec ne va pas modifier la séquence génétique qu'il t'envoie pour créer un multi.
En plus il va falloir gérer à part les cas médicaux spéciaux, jumeaux siamois, cancers, chimères (mosaicisme) etc.
Non le hash ADN c'est pas le pied.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
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.
Il n'a pas besoin de le faire. Il n'y a pas de composing. X a créé une surface de rendu via une des extensions pré-citées, l'application l'a bindé. Il n'y a rien besoin de faire d'autre.
Je ne suis pas sur de comprendre ou est le problème.
Via DRM/DRI, EXA, XAA l'appli travaille directement en mémoire GPU et le rendu ne passera jamais par la mémoire centrale. C'est bien ce que tu cherches non ?
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 0.
Les seules API non compatibles sont les APIs qui permettaient d'aller chipoter directement dans les entrailles de X11.
Oui, et les bind ou les create de display sans compter un certain nombre de périphériques un peu exotiques qui sont pour l'instant laissés de coté. On ne parlera pas non plus de cairo-gl qui nécessite encore aujourd'hui que l'on fasse les includes qui vont bien à la main.
De façon générale tout le code de rendu de GTK est en pleine phase de nettoyage, donc si ca se trouve il y aura moyen de faire d'une pierre deux coups, à savoir à partir de de GTK 3.x, avec x à définir, toutes les applis pourront utiliser aussi bien du Wayland que du X11. Mais pour les applications existantes je n'y crois pas une seule seconde.
et elles ne sont pas accessibles directement sous win32 par exemple...
Certes, mais si il suffisait de ne pas se servir des API XLib ou du namespace X pour que ça fonctionne nickel sous tous les systèmes, il n'y aurait pas besoin d'autant d'efforts de portage pour faire fonctionner des applis comme Gimp ou Abiword sous divers systèmes. Même si les disparités sont connues et que GTK évolue pour les réduire, il reste des différences structurelles qui font qu'on est obligé de mettre les mains dans le code de temps en temps.
Ce sont ces différences qui vont casser les pieds entre Wayland et X.Org.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 0.
Je suis au courant de tout celà, mais ce n'est pas la question. La question est faut-il oui ou non nécessairement aller modififer du code ailleurs que dans la lib pour que les applications GTK fonctionnent correctement.
Tous les exemples que j'ai donné sont donc dans le cadre "comment peut-on faire pour que ce soit fait automagiquement et qu'il n'y ait qu'à mettre à jour la lib et recompiler".
Évidemment si on passe mon post dans le contexte générique "comment fonctionner avec Wayland" il ne veut plus rien dire.
Pour résumer ce que je disais :
X envoyait du prémaché comme message. Wayland devrait envoyer des trucs un peut plus bruts de fonderie, et certaines API ne sont pas compatibles. Il va falloir porter les applis sous Wayland et pas seulement recompiler.
Et je ne suis pas le seul à le dire :
http://wayland.freedesktop.org/gtk.html
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 1.
Pardon pour la réponse en deux temps, j'ai voulu aller trop vite.
Hum comme X11R6 ne fait pas de composing, tes équivalents ne me paraissent pas équivalent coté performance..
Non ils sont souvent meilleurs niveau performance.
Sous Wayland (ou autre compositor) ca donne ça :
Travail dans un buffer dédié -> copie dans le buffer de composition -> copie dans le buffer affichage (ou switch buffer en cas de back buffer/triple buffer)
Sous X11R6 en DRI ca donne ça Travail dans un buffer dédié -> copie dans le buffer affichage (ou dans un back buffer)
La seule différence c'est qu'il n'y a pas d'étape de composing, donc on peut pas faire de trucs rigolos (comme des icones qui se réduisent en continuant à mettre à jour la 3D) mais niveau perf on est plutôt mieux.
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?
Si la mémoire est en off screen (généralement c'est le cas) plusieurs solutions :
a) mode m'en fous, je m'affiche. Le pilote via X indique à la carte graphique que quoi qu'il arrive c'est le contenu de tel buffer qui doit être copié à tel endroit de l'affichage. (très utile en fullscreen)
b) mode subtil : X garde en mémoire la zone ou la partie accélérée devrait se trouver, en fonction de cela il regarde si il y a d'autres fenêtres par dessus et indique à la CG les partie non recouverte et donc à copier.
c) triple buffer le composing du pauvre et du bourrin. On rend les contenus accélérés dans leur buffers respectifs, X copie tout en masse dans un backbuffer et peint ses fenêtres par dessus, on échange le back buffer et le front buffer.
Comme tu vois il n'y a à chaque fois qu'une seule copie.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
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..
Sur les systèmes à changement de GPU, il y a un buffer video dédié pour le passage d'une carte graphique à l'autre. On met tout ce dont on a besoin dans ce buffer (résolution, profondeur de couleurs, les diverses zones de travail et leur contenu) et on utilise tout ça pour initialiser la nouvelle carte graphique.
A ma connaissance on a pas les specs de ce buffer, ni les specs pour initialiser les cartes graphiques à partir de ce buffer. De fait Linux (le Kernel) n'a rien implémenté pour que l'on puisse changer de pilote en cours de route (désactiver DRI, désactiver EXA et consors, rediriger vers le nouveau pilote, réactiver DRI etc.)
Si on avait les specs et si la partie pilote kernel suivait on pourrait créer une extension X11R6 et la coder dans Xorg pour faire ce switch. Tant qu'on a pas....
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 0.
Qt5 devrait aussi supporter XCB.
Ca serait une excellente chose.
Peux-tu expliquer en quoi XLib pose un problème vis à vis de gérer plusieurs GPU?
Même si le protocole X11R6 est assynchrone à 99%, la XLib ne fonctionne quasiment qu'en mode synchrone. Donc pour tout un tas d'opérations elle ne peut gérer qu'une seule carte à la fois et bloque tout le reste tant qu'elle n'a pas reçu de réponse. 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é.
Si c'était vraiment le cas alors avec XCB on n'aurait pas ce problème non
Avec XCB il n'y a pas le problème en effet. De façon générale on peut parfaitement gérer plusieurs rendus/GPU/surfaces/écrans en mélangeant allègrement en X11.
Je croyais que c'était un problème d'implémentation de X.Org..
Je n'ai jamais dit que c'était un problème d'implémentation X.Org. Mon seul message est que tout ce qui est possible avec Wayland est possible avec X11R6. Si on était en langage de programmation on dirait que X11R6 et Wayland sont tous les deux turing-complet mais ne relèvent pas du même paradigme.
Je suis d'accord avec nud et Kaane
Le problème est que Kaane n'était pas complètement d'accord avec nud et que je suis Kaane. Donc soit j'ai encore réussit à faire comprendre exactement l'inverse du message que je ne voulais pas donner, soit il y a un soucis.
je pense que les décorations clients seront gérées par les toolkits
CF mon post, ça pose de nombreux problèmes. Le premier et que l'on peut cascader les compositor et donc créer un compsitor pour les décorations (un wm quoi). Le second est que certaines applis ont déjà de décorations gérées par le client (les applis compiz et les applis Gnome3 au moins), charge donc au toolkit de reconnaitre ces applis pour ne pas recoller une couche de déco par dessus. Charge ensuite au wm si il y en a un de reconnaitre tout ça pour ne pas faire de même. Sinon une appli gtk/compiz sous un wayland avec un compositor wm va se retrouver avec 3 décos...
Se pose ensuite le problème de la gestion des évènements sur ces décos. C'est pas insoluble du tout, mais comme je l'ai dit précédemment il y aura des lignes de code à corriger dans quasiment toutes les applis.
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.
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. On lui signale juste qu'on les prend et on dessine dedans. Pour les plus courant on peut citer les extensions overlay(un peu morte),DBE(pas toutes les implémentations), XAA, EXA, DRM, DRI (et dans une certaine mesure XRender même si c'est une surcouche). Toutes ces extensions vont faire mumuse directement avec la mémoire de la carte graphique, et sont donc très rapide en local.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 9.
mais sous windows lorsque le driver de la carte graphique part en couille il ne se passe rien de spécial
Ca dépend beaucoup de comment le driver part en couille, et de pourquoi.
Grosso modo on peut définir trois grands cas :
Le pilote se vautre tout seul comme un grand, il y a un bug quelconque dans le pilote, il envoie une série de commande à la carte graphique, la carte graphique répond "beurk", mais reste dans un état parfaitement valable et initialisé, l'application qui est à l'origine de la série de commande fautive se prend une notification d'erreur et suivant les cas réessaye, se vautre ou se ferme proprement. Sous Linux si c'est X11 l'application fautive il va y avoir une série de lignes dans le log et peut-être une fenêtre qui n'aura plus de père. Sous Windows si c'est explorer desktop, il va gentiment mémoriser les fenêtres et les params, se fermer et se relancer. Pas de clignotement écran dans ce cas là, juste la fermeture et la réouverture de la barre des taches et de certaines infobulle et autres icônes de notifications
La carte graphique envoie une réponse qui n'a rien à voir avec ce qui a été demandé. Défaut du pilote ou de la carte, difficile à savoir sans mettre les mains dans le cambouis, toujours est-il qu'il y a un problème. Soit l'erreur est minime et on ferme l'appli, soit l'erreur est plus grave et on tente le double context switch à la sauce windows :
1 - On passe la carte graphique dans un mode non accéléré, éventuellement avec une résolution moindre. (l'écran s'éteint et se rallume)
2 - On valide qu'en mode non accéléré le système graphique repart bien (généralement c'est le cas)
3 - On décharge tout ou partie du pilote de la carte graphique (c'est la partie que Linux ne sait pas faire, X11 peut mais l'archi au niveau kernel ne suit pas)
4 - On recharge un pilote propre et on réinitialise la carte graphique (l'écran s'éteint)
5 - On repasse en mode graphique précédent avec accélération (l'écran se rallume dans).
Parfois il y a des étapes en plus, notamment si il faut décharger tout le pilote, pas juste la partie accélération (comme dans une mise à jour) dans ce cas windows Vista/7 vont passer par un pilote de compatibilité ce qui peut pousser le nombre d'extinction/rallumage à quatre.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 1.
Sauf que les choses en question sont normalement gérées par le toolkit.
Tout à fait, GTK intercepte les messages X11 et les retransmet sous forme d'events. Sauf que là on aura plus de message X11, donc deux solutions :
- a) On créé un "serveur" dont le but est de passer générer les évènements attendus par l'appli. En d'autres termes on fait un mini serveur de messages dans chaque appli. C'est ce qui est conforme à l'architecture Wayland après tout. Mais la ce pose un problème avec les plugins. Supposons que mon appli principale ai besoin demande à accéder seulement à certains évènements - je ne vais pas compiler mon appli pour capter tous les messages possibles et imaginables - Sauf que si j'ai un plugin qui a besoin d'évènements en plus que l'appli principale, je fais quoi ? Je compile un second serveur pour chopper les évènements "en plus", au risque d'avoir des incohérences (par exemple des raccourcis clavier qui ne marchent plus si le plugin a le focus) ?
- b) On rajoute quelques lignes de codes, notamment dans les callback des plugins pour éviter à gimp de se fader 27 serveurs de messages au bout de deux heures d'utilisation ? On modifie légèrement la portée de certaines RPC pour qu'elle puisse surcharger le serveur d'évènements ?
Il y a aussi une branche pour les "client-side decorations"
Plusieurs même, une qui est utilisée principalement par Compiz, et une autre par Gnome 3. Or toutes les applications GTK ne sont pas des applis soit Compiz soit gnome 3. Et comme des décorations de fenêtre coté client existe, on peut difficilement la rajouter d'office sur toutes les applis GTK qui trainent (en fait il faudrait que le compilo s’assure du besoin ou non de rajouter des décoration fenêtre par fenêtre - c'est pas impossible, mais ça peut être complexe). En plus les solutions de décorations client s'appuient massivement sur GConf (donc Gnome) pour chopper les éléments graphiques dont elles ont besoins (on pourrait inclure les éléments en dur dans l'application, mais bonjour les changements de thème). Donc sur ce point là je ne vois pas comment on peut se passer de réécrire, au moins en partie le code.
Après on peut imaginer un serveur RPC qui traine dans un coin et qui gère à la fois la création des messages et les décoration de fenêtres. Le code pour se rattacher à ce serveur serait inclus de base dans les libs et limiterait pas mal le code à réécrire pour fonctionner complètement sous Wayland. Mais là aussi ça demande un gros effort et ca ferait double emploi avec pas mal de fonctionnalités de Gnome. Wait and see donc, mais je parie sur de la réécriture de code dans toutes les applis ou presque.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 7.
euh... Moui donc les utilisateurs de soft 3D doivent utiliser Windows. Mauvaise réponse.
Euh, ils peuvent aussi acheter des cartes pro. Et là ça marche très bien. Les cartes graphiques grand public n'ont qu'une seule idée en tête faire plus de fps que la concurrente sous le dernier jeu à la mode. Mes vieilles FireGL font très bien framebuffer + bi écran+switch fullscreen/fenetre+rendu video dans une texture en même temps. Sans plantage.
Suffit pour les maceux, de faire fonctionner un soft OpenGL sous X ( par exemple la version Linux via XWine ) et le même soft nativement sous Quartz pour voir que le problème n'est pas matériel " lié à Windows ".
Tu as déjà vu Quartz accepter un context switch ? Et si oui le reveil a pas fait trop mal à la tête le lendemain ?
Il est impossible de bypasser quartz, tous les rendus de Xquartz/X11.app se font dans des textures avec 0 ou presque accélération. Et malgré tout il y a quand même des carte ATI qui vont te geler ton mac quand tu vas passer l'application X11 en fullscreen. Sous Mac OSX si tu veux faire de l'OpenGL accéléré tu es obligé de faire appel à quartz et d'utiliser le context de quartz tel quel.
Ah, et donc le plantage de X , c'est aussi la perte de toutes les applis ouvertes
Comme sous tous les autres systèmes. Et encore sous X les applis ont une "seconde chance" si elles n'utilisent pas une lib synchrone comme XLib, une appli qui utilise XCB et qui ne voit pas revenir ses tokens peut encore lancer des sauvegardes d'etat en urgence. Sous Windows un context switch qui foire et rend la carte graphique instable c'est ecran bleu direct, sous Mac c'est freeze ad vitam, sous Linux si tu as un autre contexte prêt (par exemple une console qui n'est pas en frame buffer) ton système peut être récupérable.
Et sous Wayland , le problème existera-t-il toujours ou " pas " ?
Oui le problème sera toujours là, ou pour être exact quand il sera résolu sous Wayland, on pourra le résoudre aussi sous X11 et réciproquement. Il ne s'agit pas du tout de l'architecture X11, mais bien de la carte graphique qui sort de l'etat 1 sans parvenir à rentrer dans l'etat 2. Ca peut être un problème de pilote, d'ACPI, de concurrence entre plusieurs contextes etc. Mais la seule façon d'éviter le soucis avec wayland c'est de faire comme quartz : on interdit tout context switch. Si le mec veut passer en plein écran dans une résolution différente on zoom sa texture dans le contexte existant et c'est marre.
Mais rien dans la XLib ne permet une réservation de mémoire divisée par GPU. Rien. Et ça sera jamais fait. ( Et ça, c'est pas moi qui le dit, ce sont les dev Xorg ).
Oui la XLib est une bouse. On est d'accord. 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. En XCB on a accès à tout le protocole X11 sous-jacent, et donc faire tout ce que tu annonce.
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. Pas la gestion de mémoire, ni X11 ni même l'implémentation xorg.
Euh non, ça fait 100% du parc existant.
Je parlais bien entendu des applis écrites directement en XLib ou en TK ou en XMotif. Ces applis représentent aujourd'hui encore l'écrasante majorité des applis métier.
Mais combien de logiciels " sont à réécrire " , en dehors des libs comme GTK et Qt ?
Mais même les applis codées en GTK ou en QT parfait sont à réécrire. Wayland fait moins de chose que X11, toutes les choses qui ne sont pas faites par Wayland doivent désormais être faites au sein de l'appli. Ca implique nécessairement de revoir tout le code, à moins de vouloir lancer un émulateur X complet avec gestion des inputs + un décorateur de fenêtre qui fait mini-wm avec chaque fenêtre.
de toutes façons ces logiciels n'auraient pas passé sans heurts le passage à XCB.
Oui mais on aurait changé un truc. A savoir le système de messagerie entre les applis et le serveur X. Là on se retrouve à tout changer et à tout devoir recoder. Et quand je vois le mal qu'a eu Rasterman pour migrer les EFL sous XCB. Ca a pris quatre ans ! Pour une lib qui n'était utilisée par quasiment personne, qui pouvait très largement se permettre de tout casser et qui avait l'objectif de passer en XCB dans ses priorités. (Et en plus Rasterman est loin d'être un manchot quand il s'agit de gérer le protocole X11 à la mano, On peut pas en dire autant de tous les devs d'applis graphiques). Ceci étant si les grosses libs avaient vraiment suivi (i.e fait du XCB pur) on aurait pu avoir un système plus faible aujourd'hui, avec pour les applis qui utilisent ces libs des recettes sur "comment faire ci ou ça dans la nouvelle version de la lib." Mais même ça, ça n'a pas marché.
Avec Wayland on fout à la poubelle les libs de haut niveau, les libs de bas niveau, le système de message, le paradigme d'affichage tout entier etc. C'est cent fois plus dur.(Ce qui ne veut pas dire que ça ne se fera pas, tout dépend une fois de plus du degré d'implication des grands acteurs, et aussi de la qualité de la doc)
Mais Wayland ne permet rien que X11R6 ne puisse faire. Il promet de dégraisser le mammouth et de passer sur un paradigme plus adapté aux besoins d'aujourd'hui. Ce n'est pas une mauvaise chose, et ça peut même être très positif. Mais ça demande un effort colossal de l'ensemble de la communauté.
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 1.
Mission control? Tu es certain de ça?
En fait non, je ne retrouve plus l'article qui expliquait qu'avec mission control venait un gestionnaire de composition repensé sauce GCD. Maintenant que Google est noyé sous les "comment changer la couleur de fond quand on est sous mission control kikoo lol" ca va être plus dur à retrouver.
Donc à prendre avec des pincettes.
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 0.
Pour les applications normale il me semble que c'est (1) qui est utilisé, pourquoi WebGL serait différent?
C'est la solution la plus facile et la plus simple. Mais c'est aussi celle qui a le pire rendement niveau perf. On se retrouve à rendre la frame, à la mettre de coté, à la placer dans le buffer wayland, et à attendre le composing avant de finalement arriver jusqu'à l'affichage.
Dans les autres méthodes on fait un rendu que la carte graphique affiche directement quand il est fini.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 4.
_Quid des applications qui plantent sous X obligeant à relancer le serveur X ? _
Elles claqueront pareil sous Wayland, a moins que l'on modifie complètement toute l'architecture sous-jacente DRI/Pilote graphique. Ce n'est pas un problème de Xorg/XFree, encore moins un problème de X11R6 - c'est juste que les cartes graphiques grand public ne sont pas prévue pour gérer les switch de context autrement qu'à la sauce windows. Après la carte graphique se bloque, et X ne peut plus rien y faire.
Est ce que l'adressage mémoire actuel est capable de gérer 2 applis qui utilisent chacun une carte graphique ? Non ! Est-ce que ça sera implanté sous X ? " incompatible par nature "
X11R6 incompatible par nature avec la gestion de plusieurs applis chacune sur carte graphique différente, voire plusieurs machine différentes ? Faut le dire vite à SGI. La force de X11R6 est justement qu'on peut gérer chaque sous fenêtre d'une appli depuis une source différente, du moment que ça peut pondre un "drawable" ça marche. Et sinon c'est pas les extensions de bypass et d’accès direct qui manquent.
Mais, non, en fait, manque de pot, dans 4 heures, tes distributions favorites vont te forcer la mise à jour vers Wayland en virant X. T'as plus que 4 heures à utiliser ssh -X .
Tu es passé à coté du problème. Bien sur la mise à jour ne vas pas se faire en trente secondes, mais il y a quand même un vrai problème : si il est acceptable que Wayland puisse pendant une période de transition utiliser un wrapper X11, c'est un luxe que ne vont pas trop pouvoir se payer les logiciels de prise de main à distance, à moins de vouloir rendre leur code très complexe. Donc soit on lance un serveur Wayland complet pour chaque prise de main, soit il faut que les applis elle même soient bi-compatibles X/Wayland. J'y crois moyen. Pendant tout un temps on aura des prises de main à distance sauce wayland pour lancer des applis wayland et des prises de main à distance sauce X11 pour lancer des applis X11. Ca me fait saliver d'avance.
mmh, les biblio GTK, Qt, les EFL sont en cours de portage pour Wayland. Si les dev ont travaillés avec les bibliothèques concernés, normalement, ça devrait être transparent, exactement comme quand on est passé de XAA à EXA, ou comme lorsque XRender est arrivé, ou comme quand DBus est arrivé.
Ou comme quand Fleury Michon a mis moins de sel dans son jambon à l'os ou comme quand Pluton n'a plus été considéré comme une planète...
Tu as idée de la différence de surface qu'il y a entre X11R6 et ses différentes révisions/implémentation et le EXA ? Tu ne vois pas la différence qu'il y a entre "certains pilote libre n'auront plus d’accélération graphique" et "Il faut recompiler toutes les applications graphiques en mettant à jour toutes les libs grpahiques et en priant pour qu'il n'y ait pas trop de code à réécrire."
Non sincèrement. Toutes les autres applications que tu cites sont optionnelles. Si je ne veux pas m'en servir, ben je m'en sers pas et ça roule pareil qu'avant. Si vraiment je veux absolument utiliser DBus au lieu de /proc ou EXA au lieu de XAA j'ai un endroit dans le code à modifier pour le faire (si mon code est propre).
Avec Wayland, une application graphique doit gérer la souris, la saisie, les décorations de fenêtres, les buffers Wayland etc. Le tout en cassant tout le code d'affichage précédent. Je n'ai pas vu de système de gestion de souris ou de gestion de décoration de fenêtre dans GTK. Donc même si mon code GTK aujourd'hui est très très propre (grosso-modo je n'ai pas un seul widget perso, pas une surcharge de (pseudo)classe, pas un accès direct à des buffers vidéos), il faudra quand même que je recode le tout. Et personnellement je doute fort que GTK2 et QT3 passe à Wayland, et pourtant j'ai pleins d'applis GTK2 et QT3 que j'aime bien.
Certaines applis utilisent encore la XLib
Oui quelques unes. XLib, XMotif ou TK, ca doit faire quoi 75/80% du parc existant grand maximum. Une paille. Il y a pas que le Desktop de hobbyiste dans la vie.
moui quelle perte de temps. 10 ans que les applis OpenGL plantent
Et 20 ans que SGI ne s'en est pas rendu compte.
4 ans que les premiers ordis OPTIMUS sont sortis
Ca c'est l'argument qui tue. C'est clair, dès que le Desktop Linux va passer sous Wayland, NVidia va libérer les specs des hold buffers. Mais attention elle ne va les libérer que pour Wayland, interdiction de les utiliser pour xorg.
2 ans que des dev X11 disent qu'il faut passer à Wayland, et toujours rien
C'est clair que Wayland a reçu le soutien massif des devs X11 et du X consortium en général. Bon la plupart des devs X11 et des membres du X Consortium sont chez Intel c'est pour ça que ça se voit pas trop. Mais c'est massif comme mouvement.
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 1.
De ce que je comprends, il n'y a pas "d'envoi" de buffer avec Wayland.
Pour un rendu OpenGL/WebGL "accéléré" il faut travailler dans un espace spécial. Donc soit cet espace est fourni par Wayland (solution 3 de mon post), soit le rendu est effectué par Wayland à partir de pseudo-code (solution 2) soit on travaille dans un espace non affiché et on copie le rendu dans le buffer Wayland à la fin (solution 1 que j'ai appelé "envoi de buffer" parceque s'en est un même si je me rend compte que ça peut porter à confusion)
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
Mais dans l'état actuel des choses, on utilise seulement un seul compositeur
On en utilise même souvent 0. A l'heure actuelle on peut parfaitement se passer des différents "display compositors" et avoir un système qui marche très bien. Sauf que là la règle va changer, on va en fait avoir des cascades de compositors.
Déjà le compositor final Wayland, ensuite probablement au moins un des clients (ou plugins du serveur wayland ?) sera un composite window manager.
Ensuite se pose les problèmes de tout ce qui utilise les backbuffers, l'accès direct ou l'overlay (video, 2D/3D accéléré etc.) Parceque ça fait pas forcément très bon ménage avec les compositors. Bien sur il existe des solutions qui marchent, mais il va falloir faire des choix et définir des priorités. Par exemple que se passe-t-il sur un contenu webGL dans firefox ? Est-ce que l'on fait un rendu complet de tout le WebGL et qu'on l'envoi à Wayland ? Est-ce qu'on créé un hook dans Wayland pour qu'il fasse le rendu webGL lui-même (avec ou sans aide de Firefox qui peut prémacher une partie du boulot) ou est-ce qu'on définit une zone buffer dans Wayland dans laquelle il n'y a pas de composing et ou le rendu se fait en direct ? Ou alors est-ce qu'on multiplie les API pour garder la compatibilité (et dans ce cas je sens qu'on va encore jouer à "ou qu'elle est la doc ? D T Code !")
Chez OSX, qui est un peu le leader sur les techniques de composing dans les ordis grand public, ils ont été amenés a créer un chef d'orchestre pour mettre un peu d'ordre dans toutes les priorités des différentes applis de composing (mission control). Et pourtant eux ils avaient plus ou moins table rase de l'historique. Chose que Linux va avoir du mal à faire.
Donc plusieurs compositors c'est à peu près obligatoire, reste à savoir si on pourra avoir plusieurs moteurs de composing en même temps. Si oui, comment vont-ils dialoguer ensemble pour pas se taper sur la gueule (pas DBus, pitié pas DBus), sinon est-ce que le moteur "officiel" de Gnome sera compatible avec celui de KDE ou avec celui d'enlightenment...
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 8.
_Question con: Pourquoi voudrais-tu avoir deux compositeurs différents dans un même gestionnaire de fenêtres ? _
Réponse : parce que je peux ? (enfin si je peux)
Il y a pleins de raisons de vouloir avoir des écrans séparés gérés par des compositors différents. Par exemple avoir un écran de dev et un écran de rendu, que ce soit pour la photo, le dessin, le montage video ou même simplement le développement de sites webs.
Et puis je ne sais pas comment Wayland va gérer les écrans multiples non identiques (comme un écran en mode portrait, un autre plus petit pour les infos critiques et le debug).
De toute façon ce qui m'intéresse se sont les cas particuliers, et comment ils vont être pris en compte. Parce que ce qui fait le succès d'une appli open source c'est tous les trucs bizarres qu'on ne pouvait pas faire avant qu'elle arrive. Les cas ultra généraux seront traités convenablement je pense.
Et puis aussi il ne faut pas oublier la loi des 90/90. En informatique 90% des utilisateurs veulent faire au moins un truc dont 90% des autres utilisateurs n'ont strictement rien à foutre.
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 10.
Vu la diversité des gestionnaires de fenêtres sous X, et vu ce qu'utilisent pas mal de barbus (Window Maker, le défunt Ion3, wmii, awesome et compagnie), la résistance à Wayland promet d'être féroce.
Et si encore il y avait que les barbus.
Déjà il y a tous les scripts d'init et d'autoconfig à réécrire, donc les distribs vont super bien le vivre.
Ensuite tous les logiciels de prise de main à distance, que ce soit par export du display ou par pseudo serveur X sont à réécrire, à moins de se palucher des couches et des couches de compatibilité.
Après il y aura les cas à la con, genre la fenêtre à cheval sur deux écrans en Opengl avec chacun des deux écrans qui utilisent un compositor différent. Ou alors une appli web HTML5 en full screen sur deux écrans avec du webgl et du flash dedans.
Avec un peu de chances on aura même des API noyeau ou des programmes de config qui étaient utilisés principalement par X et qui vont être deprecated pendant 10, 15 ans (on en est à 9 ans pour OSS, 13 pour ifconfig)
Avec un peu de chance peut-être même que L.P finira par écrire une surcouche de gestion userland.
Moi j'ai déjà commandé du pop-corn.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Kaane . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 2.
Bienvenue en 2012 ? Y a quoi comme distro aujourd'hui qui n'active pas CONFIG_ADVANCED_ROUTER ? Mis à part les distros orienté embarqué ou vielles machines, je vois pas ...
Je ne sais pas si Linux le fait par défaut. Je sais que ça s'active par défaut si tu mets deux prefix dans ton RAD. Je sais aussi que la plupart des gens qui s'essayent à faire du advanced router oublient généralement un ou deux trucs, sont surpris que ça marche pas et finissent par passer en DHCP6 qui est une horreur.
Bien sûr que ça marche...
C'est contraire à la norme, un jour tu vas tomber sur un router/switch/firewall ou autre qui va juste t'envoyer balader, ou qui refusera carrément de dialoguer avec toi. Il y a pas que du Linux sur un réseau.
Et bien tu prend le cas du premier post du fil : Un utilisateur arrive derrière, s'assure que dhclient est mort, puis fait un ip address add 192.168.1.42/24 dev eth0. Avahi va t'il gicler l'adresse ? ah ben non ... t'aura du link-local ipv4 et une adresse administrée localement. Et ça marche.
Le script qui est donné sur la home page de avahi.org n'utilise pas les pseudo-scopes, il est en scope link (donc le prefered de l'interface). Donc si tu fais ip address add sans scope tu vas gicler l'adresse avahi-autoipd CF :
Si tu repasses le script à la main (qui est toujours en scope link) tu vas regicler ta nouvelle adresse et remettre une adresse en 169.x à la place. Fais le test si tu ne me crois pas (avec le script de la home page d'avahi hein).
Maintenant si ta distrib a décidé de lancer quoi qu'il arrive un script autoipd avec un pseudo-scope local, ça la regarde. Mais bon a part du du zero conf à la sauce Apple je vois pas l’intérêt.
Avahi-autoipd il est aveugle et sourd. Tu l'invoque et il s’exécute, tu l'invoques pas et il ne bouge pas. (En tout cas c'était le cas la dernière fois que j'ai regardé et c'est aussi ce qui est marqué dans la doc, maintenant c'est vrai qu'avec Linux ça a pu changer trois fois depuis sans que la donc bouge d'un iota).
La bonne façon de l'invoquer c'est en fin de script dhclient suite à un echec. Maintenant tu peux aussi l'invoquer sur des événements DBus lié à netlink j'imagine. Je ne vois pas ce que ça apporterait une fois de plus.
Non le problème est là en fait :
https://bugzilla.redhat.com/show_bug.cgi?id=132925
https://bugzilla.redhat.com/show_bug.cgi?id=65114
Ca fait 10 ans que ifconfig est "deprecated", il fait la course avec OSS.
Maintenant mettons les choses à plat sur ce qui se passe :
ifconfig utilise inet. Quand on créé un alias avec ifconfig, il y a un hint qui est fichu dans un socket inet, le noyau reçoit le message et créé un alias. Quand ifconfig SOUS LINUX interroge une interface physique, il interroge en fait les sockets inet rattachés à cette interface et récupère les alias des sockets inet.
iproute faisait exactement la même chose avec les sockets netlink.
Donc au niveau noyau les alias étaient en place, mais iproute ne voyait pas les alias créé par ifconfig et réciproquement.
Après moults trolls et autre combats pour que Linux fasse comme le reste du monde (à savoir demander au noyau plutôt qu'aux sockets, mais ça a un cout en terme de perfs et ça aurait entrainé la réécriture d'une partie de la pile IP), il a été décidé qu'iproute lirait aussi les infos d'ifconfig , mais qu'ifconfig étant deprecated il pouvait aller se faire voir (on est alors en 2001).
Dans la plus pure tradition linux, 11 plus tard les scripts d'init réseau n'ont toujours pas été réécrit et utilisent toujours ifconfig. Il a donc bien fallu trouver des gruikeries pour que les sockets inet et les sockets netlink représentent à peu près la même chose.
Non, en fait le format de socket inet ne permettait pas au noyau de donner une réponse complète, à savoir toute les alias sur iptables nommées partaient à la poubelle. Faut dire que la dernière mise à jour de ifconfig sous linux ca date de 1999...
J'ai déjà changé, je suis sous BSD maintenant pour toutes ces sortes de choses. Avec un ifconfig qui est mis à jour régulièrement et qui marche très bien (cf mon tout premier post). Sous les différents Unix Like ifconfig a évolué pas mal au court des 14 dernières années contrairement à Linux. Maintenant si tu veux je peux te donner une série de commandes à passer sous un linux, qui utilise iproute2 sur une machine qui a deux interfaces physiques et qui ont pour effet de péter en morceau l'arbre de recherche ARP de tous les switchs un peu cheap du marché. Bonne ou mauvaise chose ça se discute, mais les BSD ne te laissent pas faire ce genre de clowneries.
De quoi de passer par une règle firewall pour les forwards de paquets depuis une autre IP ou une autre interface que l'IP ou l'interface naturelle ? Non pas du tout.
Et tant bien même ça aurait un impact, il serait toujours nettement plus faible que celui que pourrait générer un logiciel de configuration qui créé une règle firewall nommée par alias et par route comme le fait iproute2.
Le seul défaut est de devoir les palucher à la main là ou iproute2 les créé en automatique, mais vu les dommages collatéraux potentiels je fais partie des gens qui pensent que ce genre de config doivent être faite par un être humain avec un niveau de connaissance assez élevé sur ce qu'il est en train de bidouiller. Mais après ça se discute.