gasche a écrit 1151 commentaires

Merci pour l'avis, ça fait plaisir. Merci aussi pour avoir rédigé une réponse sur la différence entre MAC et capacités, j'espère que ton explication passera mieux que ce que j'ai essayé de faire dans la dépêche.

Pour répondre à ta question, on peut utiliser les sockets unix pour passer des descripteurs de fichiers. Cf. cette question ou ce billet. Bien sûr, si on voulait implanter un système de capacités complet, on ajouterait sans doute des facilités de passage de message pour rendre plus directe cette opération extrêmement courante.

Déjà, il est faux de dire (comme le faisait un post plus haut) que les interfaces de Go sont "équivalents" aux templates de C++. Équivalent, ça veut dire qu'on peut remplacer l'un par l'autre, et réciproquement. Mais il est absolument impossible d'utiliser les interfaces (concept relativement simple et à l'usage bien délimité) pour remplacer tous les usages des templates C++ (gros tas de fonctionnalité extrêmement complexe, sous-langage Turing-complet exécuté à la compilation).

Ensuite, votre préoccupation pour les performances de la résolution des méthodes est déplacée dans la majorité des cas. Les efforts d'implémentation du langage Self ont montré qu'on pouvait obtenir d'excellentes performances en optimisant un langage où toutes les résolutions sont dynamiques.

La description de l'implémentation actuelle des interfaces de Go est décrite par exemple dans ce billet (trouvé il y a 5 minutes sur Google). Si j'ai bien compris après lecture rapide, les tables sont calculées au moment de l'initialisation des objets, et ensuite les appels sont de simples appels indirects. On peut imaginer de nombreuses optimisations (des heuristiques pour faire des paris statiques sur la table à initialiser), mais il n'y en a sans doute pas besoin pour avoir des performances tout à fait raisonnables.

Et je ne joue pas l'air de flûte bien connu "les ordinateurs sont plus rapide, on peut avoir des langages plus lents". Mais à force de se focaliser sur des détails bas niveau sans grand intérêt, on se fossilise dans des conceptions dépassées qui sont au final moins performantes. Par exemple on a beau dire que la gestion manuelle de la mémoire en C ou C++ c'est top génial, et hurler dès qu'un langage se prétendant rapide intègre un GC, au final les gens qui codent en C ou C++ mais ne veulent pas des bugs absurdes liés à la gestion de la mémoire doivent se servir de bibliothèques de gestion de mémoire (shared_ptr, Boehm GC...) qui sont beaucoup plus lentes que ce qu'on fait dans un langage haut niveau bien compilé, parce que la sémantique du langage ne permet pas de faire ça de façon précise et performante.

je n'ai pas dis que je ne comprenais pas le langage, mais qu'il me piquait les yeux.

D'accord, c'était plus un jugement sur la syntaxe. Dans ce cas, c'est tout à fait normal : personne n'est familier avec une syntaxe ou une autre à la naissance, on s'y habitude. Pour les points qui sont proches des langages que tu connais, ça ne pose pas de problème, mais dès que c'est différent il y a une réaction initiale de rejet¹, et il faut du temps et de la pratique pour s'y habituer, mais au bout d'un moment ça vient.

¹: le rejet est facile à expliquer. L'important pour un programmeur est de comprendre rapidement la structure du code et sa signification, sans avoir à tout lire linéairement dans le détail. Quand on est habitué à la syntaxe on peut faire ça, mais sinon on a l'impression de voir du "bruit" et il faut faire bien soin de tout lire pour avoir une chance de dégager la structure d'ensemble. C'est donc une difficulté supplémentaire à l'abord d'un nouveau langage qui explique ce déplaisir du programmeur.

Je trouve cependant que les commentaires sur cette dépêche sont trop portés sur la syntaxe. La syntaxe ça compte, mais ce n'est pas non plus le plus important dans un langage, parce qu'à part certains choix extrêmes (whitespace, etc.) au final on s'y habitue et on ne s'en soucie plus. Je préfère discuter de la sémantique d'un langage, ses fonctionnalités, son expressivité; je regrette que la plupart des gens ici parlent beaucoup plus de la forme que du fond.

Dans la plupart des langages, les concepts "dans le langages" peuvent exploiter des informations et des outils auxquelles les bibliothèques externes n'ont pas accès. Les langages où ça ne se voit pas trop sont les langages dont le cœur est extrêmement minimaliste (je pense à Forth par exemple, où on a l'impression que rien n'est "dans le langage") et les langages qui insistent énormément sur l'extensibilité (comme Scheme; l'approche Racket est exemplaire dans le style "tout implémenter sous forme de bibliothèque", mais ça demande un travail considérable).

Concrètement, l'intérêt des slices "dans le langage" c'est d'avoir une syntaxe agréable pour gérer ça. Les opérations peuvent très bien être écrites de façon externe dans une bibliothèque, mais si on voulait une bibliothèque qui apporte ce sucre syntaxique il faudrait ajouter une facilité générale de sucre syntaxique dans le langage (par exemple une forme de surcharge des opérateurs), c'est tout de suite plus compliqué, il faut réfléchir, on risque de se planter et de faire des choix de conceptions qui plombent le langage pendant des années, etc.

Même topo pour les maps : c'est une structure de donnée indispensable dans un langage, car extrêmement utilisée, comme les listes et les tableaux; d'ailleurs une fois abstraites les considérations bas-niveau un tableau est essentiellement une map avec des clés entières au domaine restreint à être de la forme [0..N-1]. Pour l'ajouter sous forme de bibliothèque il faudrait ajouter une paramétrisation des types par les types, comme les types paramétriques des langages fonctionnels ou les "generics" des langages objet (essentiellement la même chose sous deux noms différents, si l'on exclu la template madness). Tu notes que ces types paramétrés sont les grands absents du langage de type de Go, puisqu'aujourd'hui tous les langages statiquement typés sont d'accord pour dire que c'est utile (on arrête avec les conneries Object ou void*). Pourquoi ? Parce que les concepteurs de Go n'ont pas d'expérience dans ce domaine, pensent que c'est délicat et ont préféré ne rien mettre que mettre un truc cassé qui les engage dans le futur. Donc on ajoute les map en dur dans le langage parce qu'il y a un fort besoin et ont dit que pour le reste, on verra plus tard.

C'est en cela que Go est un langage "minimaliste dans le style C" : pas de fonctionnalités compliquées qui pourraient poser des problèmes, on n'ajoute que des trucs utilisés depuis des années et bien maîtrisés, et si ça demande de faire des choix pragmatiques (inclusion des map en dur), on le fait.

J'aime bien quand tu mets le point d'ironie.

J'espère ne pas être blessant ou vexant en disant ça, ce n'est pas du tout mon intention, mais je pense effectivement que c'est un manque de connaissances de ton côté. En connaissant C et un peu Lisp, Scala et Erlang, il ne devrait pas y avoir grand chose qui pose vraiment problème dans Go.

Peut-être que ton problème c'est que les langages que tu connais bien ne sont en fait pas tellement différents. Ce sont des langages objets, ce qui n'est le cas¹ de Go, et python et {action,java}script sont très proches sémantiquement (il y a la différence entre l'OO à classes et l'OO à prototypes, mais bon...).

¹: en tout cas il ne propose pas d'héritage avec late binding, c'est-à-dire récursion ouverte.

Le mieux pour pouvoir apprendre facilement un nouveau langage est de se confronter à des langages plus variés comme par exemple Lisp, Prolog, OCaml, Haskell, Factor, Smalltalk, Erlang, ATS, Oz, etc.

Non, Go n'est pas complexe; en tout cas il est sensiblement moins complexe que C++, D ou même Java, qui sont pourtant considérés comme des langages utilisables par tout le monde. C'est plutôt un langage relativement "simple" dans la tradition de C.

Après, ça ne veut pas dire que tous les programmes écrits en Go sont simples, évidemment. En particulier tout ce qui touche à la concurrence comporte son lot de complexité, car c'est fondamentalement un domaine assez délicat.

Non, ce n'est pas 24 contre 60, c'est 24 contre une infinité organisée selon 60 modes opératoires différents.

Un processus donné peut gérer 24 (enfin plutôt 30 je crois mais bon) 'POSIX capabilities' différentes, par exemple CAP_CHOWN qui lui permet d'appeler chown sur n'importe quel fichier.
Un processus peut avoir accès à un nombre non borné de descripteurs de fichiers (et plus généralement de ressources : mémoire partagée, sockets, etc.) différentes. Chaque ressource donne accès à un objet du système, et à cet accès sont associé, en mode capsicum, un petit nombre de droits (idéalement, un seul). Par exemple un descripteur de fichier enrichi du flag CAP_FCHOWN représente le droit d'appeler fchown sur le fichier en question, et pas un autre.

Quand je parle de finesse ce n'est pas seulement plus d'appels systèmes pris en compte, ou le fait de tenir compte aussi des autres espaces de noms globaux. C'est la possibilité que chaque ressource tenue par le programme représente un droit différent. Il s'agit d'autoriser la modification des droits de tel et tel fichier et aucun autre (tant que, pendant le déroulement du programme, un autre programme ne lui transfère pas dynamiquement le droit vers des fichiers supplémentaires), au lieu de choisir entre "accès à chown ou non".

Les 'POSIX capabilities' sont beaucoup plus grossières que ce qu'on considère comme une capacité dans les "systèmes à capacités". Cf. par exemple la section à ce sujet de ce document :

At the level of detail that we typically care about (individual files, programs, and so on) resources are created and destroyed all the time. There is a bounded set of POSIX capability flags only because they do not express authorities at this level of detail. For example, one of the POSIX capability flags is CAP_CHOWN, which represents the power to change the ownership of any file on the entire system. Just as with the granularity of subjects, we can consider this a granularity issue with respect to resources, where the ability to dynamically create new resources is the clear dividing line betwen "fine-grained" and "coarse-grained".

Bref, on peut voir ça comme un pas dans la bonne direction, mais le niveau de finesse de gestion des droits (et donc le respect du POLA, et donc la sécurité) est nettement moins bon.

Un programme en mode capacité ne peut pas "récupérer des droits" de lui-même. La seule façon d'acquérir des droits qu'il n'a pas (ou "plus"), c'est si un autre programme (qui a des droits pour le faire) lui passe des capacités supplémentaires.

Pour un exemple concret, l'exemple du "choix de fichier" : le programme en mode capacité envoie un message à un outil système (ou plutôt de l'environnement de bureau) nommé PowerBox (ou, dans Capsicum, "user rights angel") pour lui demander de proposer un choix de fichier à l'utilisateur. Il lui indique aussi quels droits il réclame sur le fichier ouvert (lecture, écriture, etc.). La PowerBox tourne déjà avec les droits d'accès au système de fichiers, que le programme n'a pas; il propose le choix du fichier à ouvrir à l'utilisateur (en essayant de lui indiquer clairement quels droits il concède sur le fichier choisi), ouvre un descripteur de fichier avec les droits demandés (ce descripteur est précisément une "capacité"), et passe cette capacité au programme initial, qui peut continuer son travail en ayant acquis ce "nouveau droit".

On peut imaginer la même chose, non dans le cadre d'une interface graphique, mais pour un shell. Actuellement le programme cp a besoin pour fonctionner de l'accès à tout le système de fichier, en lecture comme en écriture; en effet, quand on invoque cp foo bar, il doit transformer le chemin foo en fichier ouvert en lecture et le chemin bar en fichier ouvert en écriture. Plus généralement toutes les commandes qui prennent en argument un chemin doivent avoir les même droits que l'utilisateur sur le système de fichier.
Mais on peut mettre en place une organisation des programme plus économe en droit. Quand on écrit cat foo > bar, ce n'est plus le programme qui ouvre bar en lecture, mais le shell, qui s'en occupe et passe le descripteur vers bar en sortie standard quand il invoque cat. On peut imaginer une commande cp$ qui prenne en paramètres non pas deux chemins, mais deux descripteurs (un en lecture et un en fermeture). Pour invoquer cette commande il faudrait un shell au courant de cette spécificité, qui aurait par exemple la convention que les arguments de la forme =path et +path (par exemple +/tmp/foo.txt) ne sont pas envoyées sous forme de chaîne de caractères au programme, mais sous forme de descripteurs ouverts respectivement en lecture et en écriture. On invoquerait alors cp$ =foo +bar. Dans ce cas de figure, c'est le shell qui joue le rôle de "programme privilégié transmettant ses droits" (powerbox), et qui permet aux programmes invoqués de mieux respecter le Principle of Least Authority, en étant organisés de façon à nécessiter moins de droits.

J'en suis !

Je suis lent à la comprenette. Je viens de saisir, en lisant cette dépêche, la signification du mot "suivi". Il y a un onglet "Suivi" sur LinuxFR, auquel je n'ai jamais fait trop attention. Il n'y a pas longtemps je cherchais comment s'abonner au flux de syndication des commentaires d'une dépêche, et je me suis dit que "suivi" était peut-être une page sur la syndication du contenu. Il s'avère que c'est en fait une page de rapports de bugs et de demande de fonctionnalités.

Pourquoi "suivi" ? J'imagine (en tout cas c'est mon idée de la journée) que c'est la francisation de "tracker", comme dans "bug tracker" ou "issue tracker". On passe de "endroits qui recense les problèmes rencontrés" à "recense". On garde le verbe et on oublie l'objet qui portait le sens. Personnellement je n'y comprends rien.

La page "Dépêches" ne sert-elle pas aussi à "suivre" les dépêches du site ? On pourrait l'appeler "Suivi" aussi ? Ou "Suivies", pour faire la différence avec "Suivis", la page qui suit les journaux (bien sûr ici "suivi" est substantivé, donc ma blague tombe à plat).

On peut aussi faire la transformation inverse dans le cas où le verbe risquerait d'avoir du sens. Par exemple on aurait pu appeler Google "pages", parce qu'il sert à « chercher des pages web ».

Pour donner un petit caractère constructif :

• suggestions
• alerter
• rapporter
• problèmes
• soucis (a l'avantage de la poésie)

J'avoue que pour une appli simple comme tcpdump, j'arrive à imaginer la chose, et le code que tu montres semble plutôt clair; maintenant sur un programme comme chromium, qui doit toucher des fichiers un peu partout, utiliser les interfaces réseau, lancer des processus, je pense que ça doit poser tout un tas d'autres soucis.

C'est vrai, mais en pratique le besoin de compartementalisation a été pris en compte dès la conception de chromium, et l'intégration de Capsicum s'en est retrouvée d'autant facilitée. L'article de Capsicum détaille un peu plus les modifications apportées à chromium; en substance, ils ont ajouté 100 lignes de lc_limitfd, comme les 6 que j'ai montrées pour tcpdump, et remplacé un morceau de leur impl. Linux par un morceau de leur impl OSX qui se prêtait mieux aux capacités sur ce point précis.

Leur comparaison aux autres méthodes de sandboxing utilisées pour Chromium est assez positive (bon après, évidemment, ce sont les auteurs de Capsicum, donc ce n'est pas une évaluation indépendante):

• d'après eux, mettre en place une sandbox sous Windows c'est assez galère, et ils se sont retrouvé à tout interdire ou presque, mais communiquer avec un process non sandboxé chargé d'implémenter lui-même le contrôle d'accès désiré. Plus de 22 000 lignes de code au total

• un peu le même problème (en moins pire) avec seccomp : plus de 11 000 lignes de code au total

• pour les deux approches MAC (Seatbelt de Mac OSX et SELinux), ils se plaignent d'un manque de flexibilité, d'une gestion de droits au final moins fine qu'avec Capsicum (par design pour Seatbelt, et par difficulté pour SELinux), et surtout d'un manque de flexibilité dynamique : les politiques d'accès doivent être fixées avant le lancement du programme et ne peuvent pas évoluer dynamiquement, contrairement à la gestion des droits dans un système à capacité.

J'ai une question: d'où viennent les 10% de pertes de performances? Est-ce qu'à chaque appel système la capacité du processus est checkée?

Oui, chaque appel système est affecté par le mode capacité. Les coûts sont variés et très détaillé dans l'article, que je t'incite à regarder si tu veux plus de détail : il y a des micro-benchmarks des principaux appels systèmes concernés, et des tests plus réalistes sur les programmes entiers (gzip). Le nombre de 10% que j'ai donné est le surcoût sur l'appel système fstat (il fallait bien choisir quelque chose pour donner un ordre d'idée...).

Dans le cas de gzip, le coût de capsicum ajoute seulement un surcoût constant, puisque le gros de l'application est de la compression qui se fait sans utilisation de droits particuliers. Avec l'implémentation actuelle ils ont mesuré un surcoût de 2.37 millisecondes, ce qui est non-négligeable (par rapport au temps total de gzip) pour de petites entrées. Pour des entrées de taille 512K, cela représente 5% du temps de calcul (dans leurs tests), et ensuite cela devient vite négligeable.

Les auteurs précisent qu'ils comptent travailler à optimiser un peu leur code. J'imagine qu'ils ont commencé par obtenir une version fonctionnellement satisfaisante au début, sans mettre l'accent sur les performances, et qu'il y a une marge de progrès à faire. Mais dans tous les cas, ce genre de vérifications supplémentaires aura toujours un coût; c'est au développeur de faire un compromis, selon la nature de son application, ses besoins en sécurité et en performance.

Si jamais un troublion décide de changer tous les appels vers cette librairie [..] on perd tout l'avantage de la solution.

Si un attaquant modifie un exécutable qui est lancé avec les droits utilisateurs (que l'exécutable ait prévu au départ d'utiliser capsicum ou pas), effectivement il peut faire ce qu'il veut dans les limites des droits de l'utilisateur. Capsicum ne change quelque chose que pour les processus qui tournent avec le 'capability flag', c'est à dire après l'appel de cap_enter, ou encore les processus fils lancés par des processus sous cap_enter.

En gros, si tu appelles un programme "foo" modifié par l'attaquant depuis ton shell, il peut faire un peu ce qu'il veut; par contre si un programme "bar" géré par capsicum appelle "foo", il sera restreint aux droits qu'à "bar". C'est justement l'intérêt du Principle of Least Authority: si les droits de "bar" sont minimaux, l'attaquant (ou simplement tout problème lié à un bug non intentionnel) est très limité.

Je ne connais pas kauth, mais un des chercheurs principaux du projet Capsicum, Robert Watson, le connaît relativement bien, puisqu'il expliquait en 2006 que kauth n'était pas assez flexible pour implémenter le modèle MAC sur lequel il travaillait à l'époque.

J'ai trouvé une discussion plus récente sur kauth, NetBSD et capsicum, c'est ce message de David Young, mais il n'est pas très explicite:

It is just my personal opinion that it's most desirable to have in NetBSD a capabilities framework such as Capsicum, which need not be and should not be implemented in terms of kauth.

Si tu veux plus d'informations à ce sujet, le mieux est sans doute d'aller poser la question sur la mailing-list Capsicum.

Ce n'est donc pas une protection contre les logiciels malicieux — que ce soit par conception ou suite à une modification volontaire par un pirate — mais contre les failles de sécurité.

Oui et non. Le but de Capsicum c'est de rendre facile pour une application honnête d'appliquer le Principle of Least Authority. Capsicum ne dit rien en soit des programmes malicieux.

Cependant, imaginons un instant que l'idée (de bon sens) de respecter le POLA venait à se généraliser (que ce soit à travers l'usage de Capsicum ou d'autres politiques de sécurité permettant aussi cela; tout le monde n'est pas forcé de se mettre d'accord sur un seul outil). Chaque programme annoncerait donc les droits dont il a besoin pour fonctionner, et on pourrait le forcer à ne rien utiliser d'autre (par exemple en le faisant tourner comme processus fils d'un processus ayant exécuté cap_enter). Dans ce cas, le champ d'action des logiciels malicieux est très réduit, puisque s'ils sont trop gourmand en droits, ils sont suspects et on risque de ne pas les lancer tout simplement.

Aujourd'hui, tous les programmes ou presque tournent avec tous les droits de l'utilisateur. Impossible de différencier les gentils programmes qui font comme ça parce qu'ils ont été codé sous cette hypothèse (par exemple ils incluent un widget "ouvrir un fichier" qui explore gentiment le système de fichier) des vilains programmes qui en profitent abusivement (par exemple ils copient le système de fichier et l'envoient sur le réseau). Si les "gentils" étaient plus économes en droits, on pourrait repérer les vilains plus facilement : l'amélioration des gentils permettrait donc, indirectement, de se protéger mieux de méchants.

Au risque d'être lourd en répétant la même chose pour la troisième fois (mais je pense que c'est utile car ça reste des idées pas forcément évidentes; par exemple de toute évidence ma remarque pourtant très explicite sur la complémentarité des approches MAC et par capacités n'est pas bien passée), un exemple concret: Windows, dès qu'on lance un programme ou presque qui ne vient pas de Microsoft, nous embête avec une boîte de dialogue pour nous demander si on est vraiment sûr de vouloir l'exécuter. Mais comme il y a ces boîtes tout le temps, on clique sur "oui" sans réfléchir. Si la majorité des programmes windows se mettaient à utiliser un style permettant au système de restreindre finement leurs droits sans nuire à leurs fonctionnalités, il n'aurait pas besoin d'afficher la boîte à chaque fois. Il pourrait se contenter de demander confirmation pour les cas "sensibles" (demande de lecture de fichiers systèmes, d'accès au réseau...), et ne rien dire pour la grande majorité des applications qui n'ont pas besoin de beaucoup de droits (accès à des fichiers temporaires propres à l'application, et c'est tout). La sécurité s'en trouverait alors améliorée, que ce soit pour les programmes "honnêtes" (moins de risque d'erreur) que pour les programmes malhonnêtes (champ d'action plus limité, et avertissements plus visibles).

Je suis d'accord avec toi sur le fait que le compromis, où une passe de "une capacité = une action" à 60 masques a augmenté la complexité. Mais en même temps, c'est assez naturel : il s'agit de coller à la programmation système UNIX et ce n'est pas de la nouvelle complexité qui est ajoutée, c'est la complexité existante avec laquelle on s'interface.

Tu as l'air de trouver que 60 masques c'est trop, mais sur cette page je vois 131 codes de retour d'erreur sur une distribution GNU/Linux classiques. Donc c'est bien l'ordre de grandeur de la complexité gérée aujourd'hui par les programmeurs systèmes.

Enfin, je t'invite à regarder la liste des capabilités présente dans la manpage de cap_new, sur la page du projet Capsicum. Elle colle essentiellement exactement au nom des appels systèmes tolérés par le système : tu veux appeler getsockname ? Il faut que le masque CAP_GETSOCKNAME soit mis. La plupart des masques de capacité ont ainsi une lecture directe, et c'est donc une forme de complexité où "tu paies à l'usage" : soit tu connais l'appel système correspondant et tu l'utilises dans ton programme, et alors oui tu dois te soucier de ce masque, soit tu n'en as jamais entendu parler et tu n'as pas besoin de t'en servir. Je ne pense pas que la complexité ajoutée soit donc si énorme.

De toute façon les responsables du projet Capsicum ne prétendent pas avoir inventé la recette miracle. Ce sont les premiers à reconnaître (dans un des messages de la mailing-list que j'ai mis en lien) qu'il reste des améliorations à faire sur la "programmabilité", le fait de rendre agréable à utiliser pour les programmeurs cette finesse de gestion des droits. Mais je pense (et clairement eux aussi) que ça reste une avancée intéressante dans le domaine, qui a des avantages que les solutions existantes n'ont pas su réunir.

Personne ne prétend que faire du logiciel parfaitement sûr est exactement aussi facile que faire du logiciel sans se soucier de la sécurité. Dans un système à autorité ambiante on n'a pas besoin de se préoccuper des droits, ils sont là quand on en a besoin. Dans un système qui essaie de respecter le Principle Of Last Privilege, cette gestion des droits est rendue explicite. Une personne qui ignorait totalement les problématiques avant va donc trouver qu'il doit s'occuper de plus de choses. Par contre, une personne qui avait déjà mené une réflexion sur la compartementalisation¹ pourra au contraire s'appuyer sur des outils pour la rendre plus concrète et en vérifier directement l'efficacité.

¹: je rappelle que la compartementalisation des logiciels ne sert pas que pour la sécurité, mais aussi pour la modularité, la maintenabilité, la fiabilité, etc. Par exemple, les gens qui mettent en avant les architectures avec micro-noyaux ne s'intéressent pas en premier à la sécurité en général. De même la raison de séparer les pages dans Chrome vient plus de considérations de fiabilité. Faire ce raisonnement plus fin, que ce soit au départ pour des raisons de sécurité ou pas, a donc des avantages dans de nombreux domaines.

Même une fois qu'on utilise des capacités, la finesse de la gestion des droits peut être décidée progressivement. En fait en général on ne respecte jamais absolument le Principle of Least Authority : on approxime (supérieurement, sinon ça ne marche pas) les droits nécessaires. On peut commencer par faire une approximation grossière, ce qui donne des bénéfices de sécurité moins importants, mais demande moins d'effort pour le programmeur. Selon le degré de criticité du logiciel ou de motivation des programmeurs, on peut ensuite affiner en considérant plus précisément le comportement et le besoin en autorité des différentes parties du programme et de ses sous-programmes. Ce n'est pas un choix binaire, tu es libre de décider la quantité d'effort que tu investis selon tes priorités. Mais ça ne veut pas dire qu'il faut rien faire; justement, avec peu d'efforts on peut obtenir un bénéfice important (passer de "rien" à "un truc grossier mais raisonnable").

J'ai joué avec le client Linux (évidemment, sinon je n'aurais pas joué) et je n'ai pas eu de problèmes. Les réglages graphiques n'étaient pas à fond, mais en même temps avec une carte graphique Intel intégrée... Il y avait un bug assez fun qui est que la surface de l'eau n'était pas rendue, mais je pense que c'était un problème de driver, et je n'ai eu aucun autre soucis.

Bref, utilisateur satisfait pour ma part.

Je suis un peu perdu dans les multiples forks de MySQL qui existent. Tout comme j'ai déjà intériorisé le "search-and-replace OpenOffice.org LibreOffice", j'aurais été ravi de me mettre à parler de MariaDB, Drizzle ou que sais-je encore à chaque fois que je veux dire « vous savez l'autre base libre qui est moins propre que PostGreSQL mais que tout le monde utilise ».

Mais comme il y a plusieurs possibilités, la situation est moins claire. Est-ce que MariaDB est considérée comme une continuation naturelle de MySQL, et les autres étant plus des projets expérimentaux ou orientés dans une optique différente ? Ou est-ce que la situation est plus compliquée encore et je vais devoir dire MariaDB/Drizzle/whatever ? Bref, que choisir ?

J'ai joué quelques dizaines d'heures à Ryzom cet été, dans le cadre du concours pour débutants. J'ai trouvé ça sympa, même si c'est vrai que ça manque un peu de joueurs. La douche froide quand on passe de l'île des débutants où on est très fort (mais quand même pas au point d'attaquer tous les bandits du fond tout seul..) au continent est excitante et laisse à penser qu'il reste beaucoup de choses à explorer. J'ai trouvé qu'il était par contre plus difficile de progresser en faisant des missions sur le continent (celles qui sont "scénarisées" progressent très vite en difficulté, et les autres sont un peu répétitives), mais je trouve toujours ça sympa de devoir prendre ses jambes à son cou quand on rencontre un monstre "grosses étoiles rouges".

Je n'ai pas du tout assez de temps pour jouer vraiment à un MMORPG (et j'ai donc arrêté, après m'être quand même abonné pour un mois, parce que bon payer tous les mois pour jouer une heure ou deux... le nouveau mode illimité pourrait changer ça), mais j'ai trouvé l'expérience bien sympa et j'espère que ce jeu va survivre, et surtout évoluer grâce au libre.

Je ne suis pas favorable à l'engloutissement des dépêches sous les blagues de la culture geek, mais quand même, quand on a 256 signataires, on peut garder ce beau nombre rond au lieu de dire « plus de 250 » !

J'apprécie l'idée, et je suis même aller faire une promesse de don. Dans l'absolu, je trouve tout ça un peu fumeux (si on donnait de l'argent à tous les gens qui promettent un Facebook libre et distribué...), mais j'ai confiance en Eben Moglen pour mener un projet et fédérer des gens compétents autour de lui. Je ne pense pas que le résultat final sera exactement à la hauteur des espérances, mais le projet est très ambitieux et une réussite partielle serait déjà une bonne chose.

Oui, moi, je suis abonné au flux RSS des dépêches uniquement.

Tu as raison, 'let' est actuellement une extension spécifique à Mozilla. J'espère que ça va bientôt changer, parce que c'est quand même un atout indispensable pour la programmation civilisée en Javascript.

Ceci dit, c'était dans ECMAscript 4 (la proposition de standard abandonnée depuis, car trop réformiste), et ça a de bonnes chances d'aller dans Harmony (le nouveau standard) : Brendan Eich parle sur cette question d'un "strong consensus" :
http://wiki.ecmascript.org/doku.php?id=harmony:let

Il ne me semble pas que les règles de portée de Javascript soient si diaboliques. Les règles sur `this` sont un peu bizarre (mais ce n'est pas une règle de portée à proprement parler, c'est une règle sur le passage implicite d'un paramètre), et les règles sur `var` sont médiocres, mais honnêtement `var` ne me paraît pas plus mauvais que la méthode Coffeescript. Par ailleurs la bonne solution aux problèmes de portée a déjà été mise en place, c'est le `let` ajouté par Mozilla, qui se comporte tout à fait comme il faut (JavaScript 1.7 : we finally got variable binding right !). Évidemment IE6 ne le supporte pas...

Il me semble qu'il y a deux solutions différentes de celle choisie par CoffeeScript :
- accepter les limitations de JS<1.7 en proposant un mécanisme de définition de la portée d'une variable (règle le problème du shadowing) en précisant (par avertissement ou carrément erreur) qu'il ne peut être utilisé qu'en début de fonction, et pas de n'importe quel bloc; c'est honnête, simple et ça marche plutôt bien
- utiliser un préprocesseur pour générer "le bon comportement" dans chaque bloc même pas de fonction, ce qui revient à émuler le comportement de `let`; c'est plus compliqué mais plus puissant aussi

Dans le deuxième cas, si on met dans un bloc local `local x` (par exemple), l'implémentation pourrait par exemple choisir en interne un nom frais (du genre `x32`) et utiliserait ce nom à la place de `x` dans le bloc concerné. N'étant pas un spécialiste de Javascript, je ne peux pas garantir que ce soit la meilleur façon de faire, mais cela me semble très raisonnable pour commencer (un soucis que je vois est que la génération à la compilation de nouvelles variables locales étonner les gens qui font n'importe quoi avec l'introspection, comme afficher la liste des variables définie dans le bloc et leur valeur).


En fait fondamentalement je trouve que la solution de Coffeescript est pire que `var`. La plupart de leurs modifications se limitent à une sorte de sucre syntaxique local qui rend une construction donnée plus facile à utiliser. Là, ils empêchent l'accès à une construction déjà existante (var), et considèrent comme bénéfice ce qui est en fait un défaut important (impossibilité de name shadowing), qui a un effet global et non local sur la sémantique du programme. Dans la logique d'une surcouche légère, il serait bien plus cohérent de permettre aux gens d'utiliser localement la construction `var` explicitement, s'ils en ont envie, et d'inférer tout seul comme ils le font actuellement dans les autres cas.

Comme déjà discuté sur reddit [1], je trouve que les règles de Coffeescript sur la portée des variables sont mauvaises. C'est décrit dans la partie "Lexical scoping and variable safety" de leur site : http://jashkenas.github.com/coffee-script/#lexical_scope

Because you don't have direct access to the var keyword, it's impossible to shadow an outer variable on purpose, you may only refer to it. So be careful that you're not reusing the name of an external variable accidentally, if you're writing a deeply nested function.

En pratique, cela vient du fait qu'il n'y a pas de construction pour dire où une variable est déclarée/définie/liée : si j'ai bien compris, ils préprocessent le code ensuite, et choisissent la portée minimale relative à l'ensemble des occurences de la variable. Il est donc impossible d'utiliser deux variables ayant le même nom.

Je trouve que c'est un mauvais choix de conception, parce qu'il fait dépendre la signification de chaque bout de code de l'ensemble des variables qu'il a dans sa portée (et pas seulement de celles qui sont utilisées en pratique dans ce code). Comme déjà débattu au sujet d'Erlang [2], ça réduit la maintenabilité, rend plus difficile les déplacements de code et le raisonnement local sur le code.

[1] http://www.reddit.com/r/programming/comments/er0qj/coffeescr(...)
[2] http://linuxfr.org/comments/1193101.html#1193101

Bref : garder les bonnes parties, peut-être, mais ils rajoutent aussi des trucs douteux. Depuis la mort des bindings dynamiques de Lisp, je pensais qu'on avait atteint un consensus relativement global sur le comportement des déclaration de variables, mais on dirait que non.

Tu dis ça parce que tu n'y connais rien. Essaie de programmer en Prolog pendant une semaine, et tu verras bien que ton discours sur "une boucle est une boucle" résulte seulement de ton ignorance d'une grande partie des langages de programmation, qui sont vraiment différents de ce que tu connais.