Le probleme de wayland c'est que ca fait des annees que c'est cense arriver et que cela n'arrive pas
Pas sûr que tu sois bien renseigné: Wayland est en déjà en prod et l'a été avant Mir, d'autant plus que c'est XMir qui est utilisé en prod, ce qui n'est pas vraiment Mir (XWayland ce n'est pas vraiment Wayland non plus): je ne pense pas que XMir|XWayland fournissent des avantages en performance par rapport à X11(natif) puisqu'il y a une surcouche intermédiaire.
Wayland est considéré comme stable, le gros travail restant est le portage des logiciels (KDE, Gnome).
A mon avis Canonical a fait Mir pour des raisons de contrôle du projet, pas pour la date de livraison, en tout cas si c'était pour la date de livraison, ils se sont plantés en beauté car les deux vont arriver à maturité quasiment en même temps.
Pas crédible ton troll "Mir qui dominera Wayland et tout le monde retournera sa veste pour Mir qui sera plus performant et plus flexible.", je n'ai vu aucun argument technique en faveur de Mir par rapport à Wayland.
Les performances des deux devraient être équivalentes (ça peut varier d'un compositeur à l'autre pour Wayland donc c'est difficile de parler de performance 'Wayland')..
oui enfin y a pas que pour systemd que ça serait bénéfique.
Ça tombe bien, il ne semble pas avoir suggéré ça.
On peut mettre beaucoup de chose sur le dos de systemd mais faut pas tout mélanger non plus.
Quand je lis ça: http://lwn.net/Articles/580194/ ça me laisse à penser que l'implication des devs de systemd a quand même bien aidé pour cette nouvelle tentative d'avoir d-bus dans le kernel.
Oui enfin ça n'a pas l'air de déplaire les développeurs emblématiques de Linux car ils y participent eux mêmes!
Une question: pourquoi trouves-tu nécessaire d'ajouter ça?
Je n'ai en aucun cas critiqué l'intégration de KDBUS ou suggéré que ça dérangeait ou déplaisait à quelqu'un.
Il faut arrêter la parano: ce n'est pas parce que certains sont contre systemd que tout le monde l'est..
Oui enfin sur la discussion sur lkml systemd est évoqué. La raison principal de l'effort d'intégration de d-bus dans le noyau est parce que systemd l'utilise..
N'importe quoi.. Je remarque qu'on ne voit ou sont les boutons dans le style flat (il n'y a pas suffisamment de distinction entre le texte et les élements actifs menus/boutons) et tu me parles des panneaux de circulations qui n'ont pas de boutons, de menus donc comme contre exemple..
L'ésthétique (et non L'ésthétisme, barbare d'auteur) qui n'est ici, en passant, pas défini - participe de l'ergonomie.
Faux, ça peut être le cas mais au contraire il arrive que l'esthétique prime sur l'ergonomie: cas d'école le design flat si a la mode actuellement: on ne voit pas ou sont les boutons, du point de vue ergonomie c'est très mauvais..
Ce n'est pas la première fois que je lie ça donc j'imagine que ça doit être vrai, bon je trouve ça plutôt surprenant: la vectorisation 'automatique' c'est plutôt pour des boucles très régulières et dans ces cas là un compilateur intelligent (comme tu en donne un exemple) n'a même pas besoin d'introduire des check..
Ça c'est une réactions aux vidéos de Jonathan Blow sur Jai.
Pas mal, mais dans Jai, tu peux avoir un pointeur sur un objet que tu change de SOA à AOS (ou vice versa) sans modifier le code et je ne crois pas que ça soit le cas ici, je vais essayer d'avoir + d'infos..
Merci pour le lien, mais note que la version que je donne y est aussi dans le même chapitre 'x + (y - x)/2' ou
'x + ((y - x)>>1)' bonnet blanc et blanc bonnet..
La version '(x & y ) + ((x ^ y) >> 1)' ne s'exécute en 3 cycles que si tu peux faire 2 opérations en parallèle, donc dire que c'est mieux que 'x + ((y-x)>>1)', hum, d'un point de vue en mettre plein la vue ok, mais sinon pas vraiment non..
Et bien dans pas mal de langage si (a + b) dépasse l'entier maximum alors le résultat est indéfini ou tu as une exception, alors qu'avec (si a < b) milieu = a + (b - a)/2 il n'y a pas ce problème.
PS: Si a et b sont entiers alors ta formule (a + b)/2.0 est incorrecte: a + b a une valeur indéfinie AVANT la conversion en flottant, il aurait fallu écrire ((double)a + b)/2.0
et personnellement je n'aime pas l'utilisation des flottants pour des calculs entiers, c'est une source de bug bien vicieux.
Tu as probablement raison, mais je me souviens d'un livre ou un algorithme prouvé 'semi formellement' avait la perle suivant:
milieu de a,b = (a+b)/2.
J'avoue que quand j'ai vu ça j'étais mort de rire..
Well, I'm afraid that it all much too technical for me but thanks for your nice comment.
I didn't know that there were new formulation of QM under research.
Plus simple a utiliser..
Peut-être mais à titre personnel (et à mon grand regret) après avoir essayé de suivre des tutoriels sur Idris, ça me reste toujours hors de portée(1)!
Donc attention à ne pas sur-vendre non plus: programmer avec des preuve formelle ça reste beaucoup plus compliqué que programmer 'normalement'..
Après ce n'est pas une critique d'Idris ou des preuves formelles.
1: ou plus exactement quand je vois les efforts nécessaire rien que pour prouver des trucs simple, je n'en vois pas l'intérêt: je ne suis pas employé par Airbus..
Personnellement je ne pense pas que les gc posent vraiment problème.
Ça c'est de l'assertion! Parles en aux développeurs qui font des jeux: 60 images/sec (16ms par image), ça va les intéresser..
Personnellement je travaille sur des générateurs réseaux et l'idée d'avoir un GC qui me rajoute des latences aléatoires, beurk..
Ton poste me laisse penser que tu n'as pas bien lu ce qu'on a marqué..
Un exemple, si tu marque "let maVar = 5;" il faut choisir le type entier pour maVar (i32 maintenant), autrement tu peux imposer a l'utilisateur de spécifier toujours la taille du type mais ça devient rapidement lourd..
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 9.
Pas sûr que tu sois bien renseigné: Wayland est en déjà en prod et l'a été avant Mir, d'autant plus que c'est XMir qui est utilisé en prod, ce qui n'est pas vraiment Mir (XWayland ce n'est pas vraiment Wayland non plus): je ne pense pas que XMir|XWayland fournissent des avantages en performance par rapport à X11(natif) puisqu'il y a une surcouche intermédiaire.
Wayland est considéré comme stable, le gros travail restant est le portage des logiciels (KDE, Gnome).
A mon avis Canonical a fait Mir pour des raisons de contrôle du projet, pas pour la date de livraison, en tout cas si c'était pour la date de livraison, ils se sont plantés en beauté car les deux vont arriver à maturité quasiment en même temps.
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 7.
Pas crédible ton troll "Mir qui dominera Wayland et tout le monde retournera sa veste pour Mir qui sera plus performant et plus flexible.", je n'ai vu aucun argument technique en faveur de Mir par rapport à Wayland.
Les performances des deux devraient être équivalentes (ça peut varier d'un compositeur à l'autre pour Wayland donc c'est difficile de parler de performance 'Wayland')..
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 5.
Ça tombe bien, il ne semble pas avoir suggéré ça.
Quand je lis ça: http://lwn.net/Articles/580194/ ça me laisse à penser que l'implication des devs de systemd a quand même bien aidé pour cette nouvelle tentative d'avoir d-bus dans le kernel.
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
Une question: pourquoi trouves-tu nécessaire d'ajouter ça?
Je n'ai en aucun cas critiqué l'intégration de KDBUS ou suggéré que ça dérangeait ou déplaisait à quelqu'un.
Il faut arrêter la parano: ce n'est pas parce que certains sont contre systemd que tout le monde l'est..
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 4.
Oui enfin sur la discussion sur lkml systemd est évoqué. La raison principal de l'effort d'intégration de d-bus dans le noyau est parce que systemd l'utilise..
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 0.
Mais une "partie de systemd" va être dans le noyau: KDBUS, pour améliorer les perfs et la sécurité.
[^] # Re: Ergonomie
Posté par reno . En réponse au sondage Quelle importance a pour vous l’esthétisme de ce qui s'affiche sur votre écran ?. Évalué à 4.
N'importe quoi.. Je remarque qu'on ne voit ou sont les boutons dans le style flat (il n'y a pas suffisamment de distinction entre le texte et les élements actifs menus/boutons) et tu me parles des panneaux de circulations qui n'ont pas de boutons, de menus donc comme contre exemple..
[^] # Re: Ergonomie
Posté par reno . En réponse au sondage Quelle importance a pour vous l’esthétisme de ce qui s'affiche sur votre écran ?. Évalué à 3.
Faux, ça peut être le cas mais au contraire il arrive que l'esthétique prime sur l'ergonomie: cas d'école le design flat si a la mode actuellement: on ne voit pas ou sont les boutons, du point de vue ergonomie c'est très mauvais..
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par reno . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Ce n'est pas la première fois que je lie ça donc j'imagine que ça doit être vrai, bon je trouve ça plutôt surprenant: la vectorisation 'automatique' c'est plutôt pour des boucles très régulières et dans ces cas là un compilateur intelligent (comme tu en donne un exemple) n'a même pas besoin d'introduire des check..
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par reno . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Ah oui, je me suis loupé aussi, mince!
Merci de m'avoir corriger.
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par reno . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Ça c'est une réactions aux vidéos de Jonathan Blow sur Jai.
Pas mal, mais dans Jai, tu peux avoir un pointeur sur un objet que tu change de SOA à AOS (ou vice versa) sans modifier le code et je ne crois pas que ça soit le cas ici, je vais essayer d'avoir + d'infos..
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par reno . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 3.
Tu réponds trop vite à Enj0lras.
Pour s'assurer qu'un index non-signé est valide pour un accès à un tableau,
c'est une opération: index < longueur.
Pour s'assurer qu'un index signé est valide pour un accès à un tableau,
c'est deux opérations: index < longueur ET index >= 0.
[^] # Re: Gestion réseau ?
Posté par reno . En réponse au journal Raspberry Pi: la suite. Évalué à 3. Dernière modification le 03 février 2015 à 11:19.
Un avis sur phoronix d'un propriétaire d'Odroid C1:
http://www.phoronix.com/forums/showthread.php?113338-Raspberry-Pi-2-Launches-With-Quad-Core-ARM-SoC&p=468097#post468097
Pas très élogieux..
Le C1 a un connecteur 'direct' Ethernet pas par USB, mais si ça marche aussi uniquement en 100Mbs, est-ce que c'est plus intéressant que le Raspberry Pi? Je ne sais pas, il faudrait mesurer: débit atteint, utilisation CPU..
[^] # Re: Gestion réseau ?
Posté par reno . En réponse au journal Raspberry Pi: la suite. Évalué à 2.
J'ai lu sur un blog que c'était pour minimiser les risques liés aux changements, mais effectivement c'est dommage..
[^] # Re: Idris
Posté par reno . En réponse à la dépêche Sortie de Coq 8.5 bêta, un assistant de preuve formelle. Évalué à 2.
Merci pour ta réponse, en effet il faut connaître l'ordre pour la version simple, ça m'apprendra de survoler le PDF trop rapidement.
[^] # Re: Idris
Posté par reno . En réponse à la dépêche Sortie de Coq 8.5 bêta, un assistant de preuve formelle. Évalué à 4.
Non PAS "à vouloir chercher la performance"!
En pseudo-assembleur, la version 'sophistiquée':
xor Rx,Ry -> R1
and Rx,Ry -> R2
ushr R1,1 -> R1
add R1,R2 -> R1
4 instructions a décoder, 2 registres temporaires utilisés.
La version simple:
sub Ry,Rx -> R1
ushr R1,1 -> R1
add Rx,R1 -> R1
3 instructions a décoder, 1 registre temporaire utilisé.
Après ça peut dépendre du CPU..
[^] # Re: Idris
Posté par reno . En réponse à la dépêche Sortie de Coq 8.5 bêta, un assistant de preuve formelle. Évalué à 4.
Merci pour le lien, mais note que la version que je donne y est aussi dans le même chapitre 'x + (y - x)/2' ou
'x + ((y - x)>>1)' bonnet blanc et blanc bonnet..
La version '(x & y ) + ((x ^ y) >> 1)' ne s'exécute en 3 cycles que si tu peux faire 2 opérations en parallèle, donc dire que c'est mieux que 'x + ((y-x)>>1)', hum, d'un point de vue en mettre plein la vue ok, mais sinon pas vraiment non..
[^] # Re: Idris
Posté par reno . En réponse à la dépêche Sortie de Coq 8.5 bêta, un assistant de preuve formelle. Évalué à 5.
Et bien dans pas mal de langage si (a + b) dépasse l'entier maximum alors le résultat est indéfini ou tu as une exception, alors qu'avec (si a < b) milieu = a + (b - a)/2 il n'y a pas ce problème.
PS: Si a et b sont entiers alors ta formule (a + b)/2.0 est incorrecte: a + b a une valeur indéfinie AVANT la conversion en flottant, il aurait fallu écrire ((double)a + b)/2.0
et personnellement je n'aime pas l'utilisation des flottants pour des calculs entiers, c'est une source de bug bien vicieux.
[^] # Re: Idris
Posté par reno . En réponse à la dépêche Sortie de Coq 8.5 bêta, un assistant de preuve formelle. Évalué à 1.
Tu as probablement raison, mais je me souviens d'un livre ou un algorithme prouvé 'semi formellement' avait la perle suivant:
milieu de a,b = (a+b)/2.
J'avoue que quand j'ai vu ça j'étais mort de rire..
[^] # Re: "signed particle formulation of quantum mechanics"??
Posté par reno . En réponse au journal Un super nouveau logiciel GNU ! (je crois). Évalué à 2.
Well, I'm afraid that it all much too technical for me but thanks for your nice comment.
I didn't know that there were new formulation of QM under research.
[^] # Re: Idris
Posté par reno . En réponse à la dépêche Sortie de Coq 8.5 bêta, un assistant de preuve formelle. Évalué à 5.
Plus simple a utiliser..
Peut-être mais à titre personnel (et à mon grand regret) après avoir essayé de suivre des tutoriels sur Idris, ça me reste toujours hors de portée(1)!
Donc attention à ne pas sur-vendre non plus: programmer avec des preuve formelle ça reste beaucoup plus compliqué que programmer 'normalement'..
Après ce n'est pas une critique d'Idris ou des preuves formelles.
1: ou plus exactement quand je vois les efforts nécessaire rien que pour prouver des trucs simple, je n'en vois pas l'intérêt: je ne suis pas employé par Airbus..
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par reno . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 0.
Et bien c'est un peu agaçant de voire des réponses où l'auteur n'a pas lu le poste..
[^] # Re: Un langage complexe ?
Posté par reno . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 4.
Ça c'est de l'assertion! Parles en aux développeurs qui font des jeux: 60 images/sec (16ms par image), ça va les intéresser..
Personnellement je travaille sur des générateurs réseaux et l'idée d'avoir un GC qui me rajoute des latences aléatoires, beurk..
[^] # Re: Un langage complexe ?
Posté par reno . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 4.
Pas étonnant:
-Le C est simple a coder car le compilateur te laisse faire n'importe quoi, à débugger par contre..
-Ocaml et les autres langages fonctionnels ont un GC, ce qui simplifie beaucoup la programmation, mais tu en paye le prix à l'exécution..
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par reno . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à -9.
Ton poste me laisse penser que tu n'as pas bien lu ce qu'on a marqué..
Un exemple, si tu marque "let maVar = 5;" il faut choisir le type entier pour maVar (i32 maintenant), autrement tu peux imposer a l'utilisateur de spécifier toujours la taille du type mais ça devient rapidement lourd..
Toi y en a comprendre?