reno a écrit 3886 commentaires

on voit que le "low turn est responsable d'environ 30% des accidents mortels

Je ne comprends pas pourquoi tu sors cette statistique alors qu'apparemment c'était une turbulence et non pas un virage bas?

Ada pas ADA, mais merci pour l'info j'ignorais qu'Ada avait un binding Qt et en plus il y a la programmation par contrat maintenant, mmmh, tentant!

j'ai utilisé wxWidgets pendant des années et j'ai essayé Qt avec le changement de licence. Et honnêtement il n'y a pas photo.

Hum, encore faut-il qu'il y ai un bon binding pour Qt dans le langage que tu veux utilisé!
Coté binding Qt ce n'est pas la joix: binding D pas très maintenu, binding Nimrod inexistant..

Je n'ai jamais utilisé kinect, mais il me semble qu'il y a une grosse différence dans la résolution du capteur entre kinect v1 et v2 ce qui à priori devrait améliorer le ressenti pour le joueur..

Il y a d'ailleurs eu une tentative avec le projet BlueEyedOS de porter la BeAPI sur un système à base de noyau Linux. Ce projet n'est malhereusement plus maintenu.

Si je me souviens bien l'auteur du projet a fait des louvoiements bizarre avec la licence du projet et le projet est mort assez vite.
C'était une bonne idée pourtant: la force de BeOS n'était pas vraiment dans son noyau (un Linux moderne est bien plus performant en multithreading que le noyeau BeOS) mais dans tout le reste (design, couche basse, intégration, etc)..

Message passing et la spécialisation en actor : le model d’acteur de scala ou les webworkers: aucune mémoire n’est partagée

en écriture.. En lecture uniquement en général ça ne pose pas de problème non?

La légèreté n'est plus un critère

J'aimerais bien que ça soit vrai..
Mais en fait ça dépend beaucoup du PC: avec un SSD et plein de RAM tout est fluide,
avec un portable avec de la RAM rachitique (4Go c'est peu a l'heure actuelle) et un disque dur lent, les appli rament à fond..
Et malheureusement je pense que c'est vrai quelque soit l'OS: des appli comme Chrome|Firefox super-gourmandes qui te bouffent plusieurs Go de RAM, est-ce ça change quelque chose que l'OS soit léger et bien multi-threadé?

J'aurais tendance à dire que non (et pourtant j'étais un fan de BeOS qui était beaucoup beaucoup plus fluide que Linux ou Windows a l'époque).. Quelqu'un a l'expérience de Haiku pour confirmer/infirmer?

On verra si Mir est bon ou pas. En tout cas depuis qu'il existe le projet Wayland s'est bien réveillé

N'importe quoi! Je suis la mailing list de Wayland depuis un certain temps et je n'ai pas du tout remarqué une différence entre l'avant et l'après Mir, tu as des preuves de ton affirmation?

Je pense que si Wayland parait "s'être réveillé" c'est surtout qu'il est en train de se finaliser et donc les autres projets commencent à l'utiliser et les utilisateursalpha-testeurs commencent a voir le résultat.

et les deux équipes derrière chaque projet semblent échanger régulièrement.

Vraiment? Pas remarqué.. Des sources?

Bah, il décrit juste un problème courant(*): la méthode la plus simple pour écrire un programme n'est pas la plus efficace, OpenGL te fournit les 2 méthodes, EGL te donne juste les API pour la méthode efficace, ce qui se défend: si tu ne cherches pas à faire efficace pourquoi utiliser EGL??
Tant qu'à faire autant utiliser un rendu logiciel..

*:C'est le cas pour OpenGL, le parallélisme, la gestion mémoire (GC vs pas de GC)..

Donc c'est une regle explicite de fonctionnement, ce qui n'est pas tellement différent des scripts de lancement en shell, si tu met la mauvaise regle ou si le shell teste le mauvais truc ça marche mal.

Au moins avec systemd, ce dernier n'essaie pas de lancer ntpd avec des interfaces réseau qui n'ont pas encore initialisées,

Ça m'étonne ce que tu dis: systemd "résout" les problèmes de dépendances locaux mais je ne vois pas trop comment il pourrait faire avec un serveur dhcp dans la boucle..

Je me demande si Scala/Swing ne serait pas une bonne alternative:
1) Scala est quand même plus sympa que Java
2) appeler des librairies Java a partir de Scala est courant.
Gros moins de Scala:la compatibilité d'une version à l'autre n'est pas assurée il me semble..

Je pense que tu as mal compris.
C'est un choix de Debian de ne pas avoir du NC par défaut mais
1) il y a debian-nonfree.
2) les autres distributions n'ont pas forcément fait les mêmes choix..

Référence?
Les seules critiques des dev Wayland que j'ai vu concernaient des erreurs des dev Mir dans la description de Wayland.

Et alors? Relis sa question, il parlait du respect de la législation, donc je ne vois pas le rapport.

comment garantir la confidentialité des données ? Avec un chiffrement fort ?

Simple: c'est impossible!
L'accès physique au matériel te permet de contourner tout chiffrement fait sur la machine dans le cloud, à moins que tu te serves du cloud comme un disque dur chiffré (donnée déjà chiffrée avant de les envoyer sur le serveur du cloud) ce qui n'est pas l'utilisation la plus courante..
Après sans chiffrage, c'est très simple d'avoir tes données, avec chiffrage c'est beaucoup plus compliqué donc le chiffrage reste intéressant.

Quand on ne sait pas où les données sont physiquement hébergées, comment être sûr qu'on est conforme à la législation locale ?

Utiliser un cloud n'implique pas qu'on ne sache pas ou les données sont sont physiquement hébergées..

Mais c'est comme pretendre que Linux et le logiciel libre sont des echecs, il y a des personnes qui osent dire ce genre de conneries

Hum, exagérer les critiques pour les rendre caduques ça n'est pas terrible non plus: il y a des exceptions mais la plupart du temps, on fait remarquer que Linux est un échec sur le desktop.

;-)

"The threads library is implemented by time-sharing on a single processor. It will not take advantage of multi-processor machines. Using this library will therefore never make programs run faster. However, many programs are easier to write when structured as several communicating processes. "

Pfff, pourquoi utilise t'on le mot thread pour tout et n'importe quoi?
Ça serait quand même plus simple si le sens des mots était standardisé..
Une proposition:
-process: géré par l'OS, mémoire non partagée par défaut.
-task: géré par le langage/une librairie, mémoire non partagée par défaut.
-thread: géré par l'OS, mémoire partagée par défaut.
-fiber: géré par le langage/une librairie, mémoire partagée par défaut.

du OpenDocument qui ne rends pas pareil sur chaque version de chacune des suites ?

Hein? Le fait que le PDF1.4 soit un standard ne garantie pas que les lecteurs le rendent correctement: quand les devs de Firefox ont activés PDF.js par défaut, j'ai tenu 30s avant de désactiver le truc: le rendu des fontes était vraiment moche (après je ne sais pas si c'était des PDF conforme à la norme 1.4 ou pas qui avaient ce problème de rendu).

Dans ce cas, j’aurais dû dire «le langage offre les mêmes garanties de libération de mémoire qu’un ramasse-miettes, ce qui protège de la plupart des fuites de mémoire», ou quelque chose comme ça.

Amusant: c'était plus ou moins ma modif, en précisant que Rust devait offrir des meilleurs performances qu'un GC (sinon ça ne vaudrait pas la peine de s'enm… avec les n-types de pointeur).

Le problème, c'est de dire "il sera impossible de provoquer des fuites de mémoire", c'est faux: "fuite mémoire" c'est un terme générique et le restreindre aux fuites qu'un GC ou les fonctions de Rust peuvent résoudre est faux, un programmeur qui gère mal sa mémoire va provoquer des fuites mémoires et le GC/Rust n'y pourra rien.

L'avantage de Rust sur Go, c'est de ne pas ignorer les 40 dernières années de recherche en informatique (même si, comme dit dans la dépêche, les 15 dernières années ne sont pas reprises dedans).

C’est quand même hyper méprisant pour les concepteurs de Go

Bof, 40 ans c'est exagéré mais mon impression sur Go c'est que c'est Limbo renommé et Limbo date de 1995..

C’est vrai qu’il y a beaucoup de fonctionnalités dans le D. On peut effectivement faire de la programmation par contrat

Mauvais exemple, ça fait partie des trucs "pas finis" de D: il n'est pas possible d'associer un contrat a une interface les contrats font partie du corps des fonctions.

D n'est pas un compilateur!
Les compilateurs ldc et gdc sont libres!

C'est qu'il dit est vrai (DMD était jusqu'à récemment bien plus mature que LDC et GDC. Et la communauté DMD avec le coup Phobos vs Tango a probablement fait reculer l'adoption de D de plusieurs années) mais le problème c'est qu'il parle du passé de D alors que Rust n'en est qu'à la version 0.8..

Ton article essaye un peu trop d'écraser par ton seul propos un langage pour mettre un autre en avant!

Là aussi, je suis plutôt d'accord, j'avais essayé de corriger l'introduction sur la gestion mémoire de Rust pour que ça fasse moins "fanboy" mais bon ma modif s'est vu écrasée alors ça m'a plutôt découragé de contribuer.

J'ajouterai comme critique que les exemples de Rust auraient gagné a être compiler avant d'être mis dans l'article: abs mélangeant les int et uint, évidemment ça ne compile pas (ce qui d'ailleurs est un réel progrès par rapport au C/C++).

Pour avoir un article de bonne qualité et objectif entre D et Rust: http://versusit.org/rust-vs-d

Un article de bonne qualité?? Comparer des langages en se limitant à la syntaxe du Hello World (en gros), bof.