reno a écrit 3880 commentaires

C'était pareil avec X je crois mais les toolkit ne supportaient pas ça, j'ignore s'ils vont ajouter ce qu'il faut pour Wayland alors qu'ils n'ont pas fait le travail pour X.

Sinon une regarde pour ce qui est des performances: XMir baisse les performances de 10% par rapport à du X pur(benchmarké par Phoronix), XMir étant en gros un clone d'XWayland j'ai un gros doute sur cette potentielle amélioration des perfs d'XWayland par rapport à du X pur.

si t'es capable de livrer un produit qui consomme 4x moins de mémoire simplement par ce que tu as branché ton cerveau 5 minutes tu le fais de base.

Non!! Tu viens de contredire allègrement le principe de mesurer avant d'optimiser.
Encore récemment j'ai été surpris quand j'ai voulu optimiser un script: la fonction 'couteuse' n'était pas là ou je l'attendais.

Oui parce que c'est par l'intermédiaire du 'bookmark' que j'ai vu l'article, bon apparemment soit le sujet ne plait pas, soit c'est le "saut de trop" vu que le journal est moinssé.

OK, ça n'a pas de lien directe avec Linux, mais j'avais trouvé l'article intéressant..

Je pense que la plupart des auteurs de binding pensent que la doc des fonctions C dessous suffit.
N'ayant pas utilisé un des ces bindings, j'ignore s'ils ont raison où pas.

Non le plus gros problème de ces bindings, c'est qu'ils sont souvent incomplet et peu mis à jour..

Il faudrait déjà pouvoir détecter ces communications. L'Iran avait réussi un temps à le filtrer mais des corrections ont été apportées pour mieux brouiller le protocole et le traffic depuis ce pays est revenu à la normale.

Faire passer du traffic Tor comme du traffic chiffré normal est un début, mais bon ça reste hautement risqué à utiliser: si tu as obtenu l'adresse IP d'une gateway Tor, le gouvernement peut l'avoir aussi..

Et dans une application comme FTP (et bien d'autre), ton traffic contient ton adresse IP, donc si tu ne chiffre pas ton traffic, le noeud de sortie peut t'identifier.

S'il s'agit de publier des informations dans un pays répressif par exemple, l'objectif n'est pas de protéger le contenu, mais l'identité de celui qui en est à l'origine.

Soit dit en passant j'ai toujours été sceptique de l'intérêt dans le cas que tu décris, dans un pays répressif le gouvernement peut demander au FAI de lui indiquer qui utilise Tor, l'utilisation de Tor en elle-même est suspecte..

Et bien déjà, il faut que ton application puisse parler en chiffrer autrement ça n'a pas grand intérêt: le noeud de sortie peut capter ton traffic..

Probablement parce que développer quelque-chose sur une librairie stable est une bonne idée..
Et si je me souviens bien Qt5 est censé être source compatible avec Qt4, donc pourquoi pas?

Dans ses 20 dernières années, il n'a pas put trouver de financement pour ses recherches:
http://www.zdnet.com/the-shocking-truth-about-silicon-valley-genius-doug-engelbart-7000017660/

A garder à l'esprit quand on regarde la "démo mère".

Je pensais à thumb2 pour arm.

J'avais compris et je disais que Thumb/Thumb2 n'existe pas le mode 64bit d'ARM: ARMv8.

Tu noteras que
1) à la fin de mon poste j'ai noté que l’implémentation interne des RISC et des CISC était similaire.
2) Ça ne change rien vis à vis des jeux d'instructions externe.

Pour faire une analogie avec programmation, tu mélange l'API (RISC/CISC) et l'implémentation (moteur similaire derrière), les x86 ont changé leur moteur, ça ne change rien à leur API: ne pas surcharger inutilement les mots, ça aide a garder les idées claires.

La taille des instructions des nouveaux ARM est mixte 16/32 bits.

Des anciens ARM tu veux dire: ARMv8 a perdu le mode 16-bit..
MIPS a aussi une extension 16 bit si ma mémoire est bonne.

mais je pense surtout que les RISC sont devenus des CISC.

Les RISCs se sont complexifiés OK, mais entre des instructions 16/32 bits et des instructions a longueurs très variable comme les x86 et VAX (d'un octet à plusieurs dizaines d'octets pour les cas pathologiques (qu'on ne trouve pas en pratique)), il y a quand même une grosse différence..
Et même si le PowerPC a beaucoup de modes d'adressages, ça reste quand même une architecture avec des instructions séparée pour accéder à la mémoire, je pense que le qualificatif load/store s'applique toujours.

Cela suppose d'avoir un langage assez pur pour permettre d'être absolument sûr de ce qu'on fait.

Tiens sur ce type de sujet, ce papier est intéressant ( http://people.csail.mit.edu/jrk/halide12/ ), il décrit un découplage entre les algorithmes et les "recettes" d'implémentations.

Je maintiens que "en pratique, chaque instruction est ensuite décomposée en micro-instructions qui suivent les principes de RISC." ne veut pas dire grand chose.

On a dit souvent n'importe quoi sur le RISC, pourtant Reduced Instruction Set Computer, c'est assez clair: il s'agit d'un type de jeu d'instruction pour les processeurs.
De quel jeu d'instruction parles t'on? Et bien de celui du CPU, et qu'a t'il de spécial? Il a été conçu pour être bien exploité par les compilateurs (avant c'était plutôt par les programmeurs).

Dire que le coeur x86 a derrière un RISC bof, ça n'a pas grand sens:
1) déjà c'est un jeu d'instruction qui est visible uniquement en interne: le compilateur n'y a pas accès.
Ce qui pose des contraintes par exemple pour l'accès aux registres: le compilateur peut-être obligé d'écrire un registre x86 en mémoire pour faire de la place alors que le CPU a bien assez de registres physiquement présent, mais ils sont cachés et inaccessible directement..

2) les micro instructions suivent-elle vraiment les principes du RISC: load-store, orthogonal (pour que le compilateur puisse l'utiliser efficacement), taille fixe des instructions (etc), peut-être, peut-être pas, vous avez la doc d'Intel vous?

L'implémentation interne des x86 et des RISC est-elle similaire?
Oui! Ca ne veut pas dire pour autant que les x86 ont derrière un RISC..

Parce que là c'est tellement moche que je vais venir moins souvent..

Récent utilisateur de Fedora, j'ai été surpris de constater que cette distribution intègre tout de suite le dernier cri.

Surpris? Tu aurais du te renseigner un peu mieux: Fedora est réputé pour ça..
En bien (c'est super pour les développeurs) et en mal (moins bien pour les utilisateurs).

Il ne faut pas prendre des SoC ARM de type Exynos leurs drivers ne sont pas libres

Voila, j'ai corrigé, il n'y pas d'ARM avec des drivers libres fournis par le constructeur (mis à part le Raspbery Pi ceux qui regardent la lettre et non l'esprit), il existe des efforts d'ingénieries inverses, aucun qui soit vraiment mature pour autant que je sache, spécialement pour lire des vidéos!

Il ne faut pas juste EGL, il faut EGL+l'extension (1 chacun).
M'enfin je pense que 99% du travail est dans EGL alors..

Ceci dits Wayland et Mir fonctionnent tous les deux au dessus de SurfaceFlinger grace à LibHybris, pour Wayland je ne crois pas que ça soit intégré dedans, pour Mir vu les objectifs de Canonical ça devrait y être de base.

Je crois que les 2 se basent sur OpenGL ES pour ce qui est de l'accès "accéléré" à la carte vidéo et que chacun ont leur extension de OpenGL ES.
En quoi ces 2 extensions diffèrent, pas la moindre idée..

XMir est la couche de compatibilité X11 donc je ne suis pas sûr de bien comprendre ta question.

Dans Ubuntu 13.10, tu auras matériel --> Mir --> XMir -(X11)-> Unity et applications,
dans le futur Unity et certains applications seront uniquement au dessus de Mir, mais XMir va rester pour les applications X11.

C'est exactement le même principe dans Wayland/XWayland d'ailleurs..

Juste une contribution à la traduction en Français de la documentation de Berlin/Fresco un serveur d'affichage mort il y a longtemps..
De manière amusante sa conception était diamétralement opposée à celle de Wayland, l'idée était d'envoyer des primitives de haut niveau du client vers le serveur.

J'ai utilisé ça (il y a longtemps), ça coûtait un rein mais comme traitement de texte j'ai trouvé que c'était bien au dessus de Word, LO.

quelqu'un sait pourquoi en c et autres, les déclarations de type sont dans cet ordre ?

Je pense que c'est parce qu'en mettant les noms des types d'abords tu évite un mot clef: 'int x' suffit par rapport à
'var x: int'.

Après avoir du code 'postfix' f(x) t[i] etc et des déclarations 'préfix', j'ai toujours trouvé ça peu lisible..

Si pour toi C-like c'est les accolades OK, mais bon ils ont quand même une grosse différence avec les syntaxe que je qualifie de C-like: leur déclaration des types est dans l'ordre 'Pascalien' donc lisible..
Rust: let monster_size: int = 50;
Scala: val arr = Array[Int]

Non, maintenant si c'est probablement un confort intéressant (jamais utilisé un langage qui a ça donc je ne peux pas parler en connaissance de cause), avoir le compilateur qui vérifie que je couvre bien tout les cas possible me parait beaucoup plus important pour faire évoluer un programme.