reno a écrit 3880 commentaires

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.

Je veux bien, mais il y a une gestion de projet, un comité au-dessus, ils ne peuvent pas gérer les ressources ?

Les "ressources" étant des volontaires, non.

D'autant que des boîtes comme Red Hat payent des gens pour développer GNOME

Red Hat vendant du support aux grosses entreprises, s'ils développent GNOME c'est plutôt pour une utilisation type station de travail:
je pense qu'ils n'en ont rien à faire des jeux, de GNOME Music ou de GNOME Photos..

Et bien on attend tes contributions.

On a le droit de dire qu'une syntaxe est pourrie, par exemple GNU make vient d'implémenter l'opérateur d'affectation != pour affecter une variable de shell, c'est une syntaxe pourrie (pour être poli), dans la majorité des langages != ça veut dire "différent de", donc ça va être bien pénible à lire du code avec ça.
Bon je ne peux même pas taper sur GNU make: ça vient des makefiles BSD cette syntaxe m…

GNU Make est un projet à maturité et les nouveautés de cette version concernent surtout le confort.

Hum, le tracing ça n'est pas du confort, c'est le degré 0 du debugging, qu'il soit intégré seulement dans la V4 de GNU make me conforte dans tout le mal que je pense de ce truc.

Au sujet des choix de langage, ce blog est intéressant( http://roscidus.com/blog/blog/2013/06/20/replacing-python-round-2/ ) il voulait remplacer du Python, il a évalué plein de langages (dont Haskell qui ne lui a pas convenu trop différent du code actuel) et il a choisi OCaml en final.

Blague à part, autant pour la déclaration de variable, je suis plus ou moins d'accord, mais ça fait un tas de ligne en trop.

Euh, tu sais on est plus dans les années 80 avec déclaration séparée..
Maintenant dans les langages de bon gout, une déclaration de constante/variable c'est juste un mot clef: "def x = valeur' ou "var x = valeur" le type est inféré..
Et si tu as besoin de spécifier le type "def/var x : type = valeur": pas de ligne supplémentaire dans les 2 cas, ce qui évite que x soit déclaré mais pas initialisé.

Le typage statique n'a aucun intérêt en Python, parce que ce n'est pas dans sa philosophie

Pas d'accord, par exemple ça m'aurait permis de gagner pas mal de temps sur un script ou je passais sans m'en apercevoir un pointeur de fonction et non pas le résultat de la fonction (oubli d'un ())..
Note bien que le langage dont je parlais Groovy n'est pas uniquement statiquement typé: il a les deux!
Typiquement tu commence par faire un script sans préciser les types et si ça ne marche pas comme tu le voudrais ou si tu as besoin de perf, tu rajoute des annotations de type.