Merci pour ce (contre-)point de vue intéressant. Tu dis
Cependant, le plus/moins va bien dans un système qui tend vers un certain élitisme (haha), justement parce que s'il récompense "les meilleurs", il punit aussi "les moins bons", ce qui amène un écrémage plus intense, où restent ceux avec le cœur bien accroché. Ou les plus cyniques. Enfin bref, la culture de l'excellence dans ce qu'elle a de plus fanatique. Et je dois être honnête, c'est aussi ce que je viens chercher sur ce site […].
Je comprends ton point de vue, si tu remplaces "les meilleurs" par "les mieux adaptés à ce style de discussion". Par contre je suis en désaccord sur le fait que la sélection par le cynisme et la tolérance de la violence verbale est une bonne façon de maximiser l'intérêt du contenu du site¹. Je pense que LinuxFr aurait beaucoup à gagner à être une communauté plus ouverte, plus accueillante, plus tolérante aux débutants, et donc plus diversifiée.
¹: bien sûr tu parles d'intérêt "pour toi", c'est certainement vrai. Je connais des gens qui prennent plaisir à lire les disputes sur le bistrot de wikipédia, chacun ses goûts. Ici je parle plutôt d'intérêt d'un point de vue purement technique: je pense que faire des efforts pour favoriser une forme plus généreuse (et pas seulement purement la technique) peut rendre le site fréquentable à des gens qui en sont exclus aujourd'hui, et donc indirectement augmenter l'intérêt technique.
Les engueulade et les trolls c'est aussi linuxfr !
Je ne suis pas d'accord (pour moi c'est le même argument que "ah mais les blagues de cul, ça fait partie de notre culture !"). Et puis on peut troller gentiment, ou être en désaccord et rester courtois.
Ontologiae a déjà fait une très bonne réponse à ton post, du coup je vais zapper l'argumentation d'ensemble (aller lire la sienne) et essayer de t'expliquer pourquoi ton post est symptomatique du problème que je décris.
J'essaie d'insister (et je pense que ton post est un bon exemple) sur le fait que:
Un post n'a pas besoin d'être bourré d'insultes, de mépris et de méchanceté crasse pour être problématique. Il suffit qu'il soit légèrement passif-agressif pour donner une mauvaise impression (légère), et si une majorité de posts dans une discussion est comme ça, l'effet d'ensemble est bien pire qu'un unique post qui dépasse les bornes. Ton post est tout à fait problématique dans ce cadre.
La réponse à mes questions n'est pas "les gens sur LinuxFr sont des connards"; participent à ce comportement d'ensemble désagréable des gens qui, pris individuellement, sont au-dessus de tout soupçon d'être bêtes ou méchants.
C'est pour cela à mon avis que la réponse n'est pas "les modérateurs vont sauver l'affaire". Ils peuvent exciser les abus manifestes, mais (en tout cas dans la façon dont ils fonctionnent aujourd'hui) ne vont pas faire passer l'ambiance d'une conversation de "désagréable" à "sympa".
Je peux donc penser qu'une affirmation est "absurde" sans que cela implique quoi que ce soit de dépréciateur sur celui qui a lancé cette affirmation. Il me semble que c'est ça qui différencie un post acceptable d'un post corrosif.
Non, en plus du fond (ce qui est visé par le terme "absurde"), la forme participe à donner une ambiance désagréable. Dire que quelque chose est absurde, à part une démonstration (et même, vive les mathématiques constructives), est fondamentalement une forme de violence. Pour maintenir une bonne ambiance il faut trouver un autre terme moins fort. Tu aurais pu dire par exemple "Je ne suis pas du tout d'accord avec ce point de vue, ça rappelle la vision post-68 dont on a vu qu'elle ne résolvait pas vraiment les problèmes qu'elle combattait.". Même contenu, mais ça ne fait pas monter la température.
Le second point de mon post (ENS vs X) est purement factuel. Je fais remarquer à keyser que ce qu'il a écrit est factuellement faux et cela implique qu'il ne connaît pas le monde de la recherche en mathématiques. Tu penses que ce n'est pas gentil de faire remarquer qu'une affirmation est factuellement fausse ? Est-ce que le fait de relever une erreur est considéré comme corrosif ?
Oui, dire à quelqu'un qu'il ne connaît "strictement rien" à quelque chose, c'est corrosif. Et quelque soit le sujet. Tu peux dire "En l'occurence il ne s'agirait pas de polytechnique mais de l'ENS qui a formé tous les médaillés Fields français.". Le reste du message est de l'acide bien concentré.
Au passage excuse-moi, mais qu'est-ce qu'on en a à cirer des différences fines entre les grandes écoles françaises ? Tu apportes quoi à la discussion en montrant que toi, tu connais bien le milieu des maths (merci, on a lu ta (formidable) dépêche, on le sait) et que l'autre ne le connaît pas (on s'en fout ?). À part un micro-monde fermé, tout le monde comprend l'usage de "polytechnicien-ne" pour dire "(ancien-ne) élève d'une grande école" de même qu'on peut dire "énarque" pour parler (d'une façon souvent anti-parlementaire et méprisante mais c'est un autre débat) de la classe politique. Indépendamment de la forme de la remarque, le contenu lui-même n'apporte en gros rien à la conversation, et donne l'impression de quelqu'un de méprisant (que ce soit ton intention ou non).
Je participe pas mal à des sous-communauté de reddit (ocaml et haskell en particulier) qui sont très agréables. La mailing-list OCaml est aussi très agréable. Je connais moins bien les communautés techniques francophones, mais je suis sur Progdupeupl et Zeste de savoir qui sont agréables.
Maintenant que j'y pense je dois modérer mon commentaire sur "la pire et de loin", il y a une exception : les commentaires sur LWN.net ne sont pas terribles, c'est peut-être à peu près le même niveau d'agressivité que LinuxFr—mais je ne les lis pas du tout sur LWN.net, donc je ne peux pas vraiment juger. Leurs articles sont tellement excellents que je ne ressens jamais le besoin de lire des commentaires en plus.
Enfin je discute avec des gens directement par IRC ou blogs (ou, pour les mécréants, Google Plus) interposés, et le ton des discussions y est là encore très agréable.
C'est l'éternel débat de la forme "ce n'est pas ce que j'ai dit, c'est comment toi tu l'interprètes, de quel côté est la responsabilité ?". Pour moi la doctrine Unix c'est "be liberal in what you accept, and strict in what you send" : la personne qui écrit a aussi la responsabilité de réfléchir non seulement à ce qu'il veut dire, mais comment ça va être interprété par les autres.
Ça ne veut pas dire que tout le monde est soumis à la personne maximalement sensible qui va être offensée par absolument tout. Mais il faut trouver un compromis, et les personnes de bonnes volontés peuvent facilement converger vers un compromis très favorables aux récepteurs plutôt qu'aux émetteurs (ne serait-ce que parce qu'un message est écrit par une personne et lu par N, et que donc favoriser les récepteurs est du bon sens).
(Par ailleurs je pense Zenitram que tu conviendras que ton ressenti personnel et la façon dont toi tu te comportes sur LinuxFR n'ont pas vocations à s'appliquer à tous les membres. C'est bien que tu aies la carapace dure, ça ne justifie pas le fait qu'on se limite aux gens comme toi.)
C'est vrai que les commentaires sur les quotidiens nationaux ou (gasp!) Youtube sont encore pires. Ceci dit je pense que ton idée que LinuxFr est dans le haut du panier n'est pas vraie : parmi les communautés (d'intérêt ou de personnes, qu'importe ?) auxquelles je participe, c'est la pire et c'est très net.
Tu fais bien de signaler que c'est meilleur sur le forum (je ne sais pas, je n'y vais plus depuis longtemps). Peut-être que cela se passe mieux quand il y a un but clair d'aider des personnes. Mais je pense qu'on devrait pouvoir être sympas entre nous sans ça.
Merci d'avoir pris le temps d'écrire ce commentaire. Je suis assez d'accord dans les grandes lignes. Je me pose la question depuis longtemps : pourquoi les discussions sur LinuxFr sont-elles si corrosives ? Il y a quelque chose de vicié dans la communauté ou plutôt (car quand on prend chaque membre individuellement, ce sont des gens intéressants qu'on est content d'avoir sur le site) dans la façon de communiquer ensemble, qui rend les discussions très désagréables à lire au bout d'un temps.
Mais je n'ai jamais suggéré que la communauté Linux devrait passer à des micro-noyaux (c'est un autre débat), seulement qu'elle fasse des efforts pour adopter des outils d'analyse statique et les méthodes formelles en général.
C'est vrai que la mémoire partagée est très difficile à gérer (formellement, mais aussi quand on programme) et que l'état de l'art ne gère pas bien cet aspect là. Est-ce une bonne raison de ne pas faire d'efforts pour intégrer les outils existants dans nos pratiques de développement, là où ils peuvent apporter quelque chose ?
et tu réponds
Même mon téléphone est multicœur, donc je maintiens: seL4 est un jouet (à l'heure actuelle).
J'ai le sentiment que tu t'accroches à "bouh seL4 ne gère pas le multicœur" comme un argument pour… quoi ?
Ce que je reproche à la communauté Linux n'est pas un manque de compétences techniques, mais un manque d'intérêt pour les méthodes formelles pour le logiciel. C'est une culture qui s'acquiert, qui est présente dans certains environnement (par exemple Mozilla a fait des choses très louables dans cette direction, et surtout Microsoft a su intégrer ça étonnamment bien en production, y-compris pour le développement kernel), mais absente en grande majorité du milieu du libre—qui aurait pourtant aujourd'hui la "puissance", en terme d'argents et de ressource, pour faire des choses très intéressantes dans ce domaine.
Il y a beaucoup de choses intéressantes à faire avant d'essayer de faire des preuves de correction complètes. Par exemple, garantir l'absence de comportements indéfinis dans une partie la plus grande possible du code serait déjà un très bon pas en avant; et ACSL par exemple peut servir à spécifier ce genre de propriétés de sûreté (un pointeur reste dans la bonne région mémoire).
Les gens de Microsoft ont développé des annotations formelles pour les drivers et le code noyau, qui peuvent être vérifiées par des outils d'analyse statique. Ça demande que les développeurs acceptent de s'en servir—et il y a sans doute des faux négatifs qui sont parfois casse-pieds—mais ça marche bien et ça a eu de bons effets. Ça existe depuis une décennie environ maintenant.
Je ne comprends pas trop le sens de ta (deuxième) remarque sur le multi-cœur dans SeL4. C'est vrai que la mémoire partagée est très difficile à gérer (formellement, mais aussi quand on programme) et que l'état de l'art ne gère pas bien cet aspect là. Est-ce une bonne raison de ne pas faire d'efforts pour intégrer les outils existants dans nos pratiques de développement, là où ils peuvent apporter quelque chose ?
J'en ai discute avec un chercheur et effectivement, cela soulèverait d'autres problèmes: cela prend du temps de rendre tout disponible, il faut l’héberger, ce n'est pas vraiment le boulot d'un chercheur, etc.
Je pense que ce sont des arguments à la con. Les gens qui ne publient pas leurs sources/données/preuves font mal leur boulot, et il est tout à fait légitime de leur reprocher.
(Par contre je fais une distinction entre "publier" et "mettre sous licence libre". Certains chercheurs insistent pour mettre des restrictions "pas d'utilisation commerciale" sur ce qu'ils diffusent, je ne suis pas de cet avis mais ça ne rentre pas pour autant dans ce que j'appelle "faire mal son boulot".)
Je comprends bien l'argument "c'est comme ça", et c'est justement ce qui est chouette avec Capsicum : il s'agit d'un essai très honnête de faire du bon travail non pas en re-partant de zéro (facile d'avoir un bon design, mais voué à l'échec côté adoption) mais en améliorant incrémentalement l'existant. J'applaudis des deux mains, mais il ne faut pas non plus se voiler la face en s'imaginant que ça suffit—comme des gens se sont à mon avis fourvoyés pendant bien trop longtemps en pensant que other-group-user était un modèle de droits d'accès satisfaisant.
Si ce genre de choses t'intéressent, tu peux aussi regarder le projet Bedrock; ce n'est pas présenté comme un OS, mais ça va quand même de l'assembleur à un petit serveur web, le tout entièrement vérifié (au niveau fonctionnel).
Ce qui est dommage c'est que la communauté Linux s'intéresse très peu à ces sujets-là. L'université (et l'armée) australienne a financé SeL4, Microsoft finance largement la recherche en méthodes formelles (le meilleur SMT solver vient chez eux, tout le monde s'en sert, mais il est propriétaire…), mais côté Linux, à part encourager mollement le travail sur Coccinelle et se plaindre des lint-like qui font trop de faux négatifs, il n'y a pas grand chose. Qui a essayé Cylone ou ATS ne serait-ce que 5 minutes, ou d'encoder des propriétés du kernel avec des descriptions ACSL?
Je fais la gueule à Sel4 parce qu'ils auraient dû donner les sources (et surtout la preuve !) dès les premières publications. Je trouve plus que discutable de ne pas l'avoir fait dès le début et, même si c'est mieux de le faire maintenant que pas du tout, je ne vais pas pour autant m'empresser de leur faire de la pub auprès du grand public.
Je pense qu'aujourd'hui la sécurité d'un système utilisateur est déplorable, en raison d'une combinaison de choix de conception (du contrôle d'accès) qui ne font de chaque possibilité d'exécuter du code arbitraire une faille de sécurité globale du système (tout ce qui est donnée utilisateur est compromis), et de choix techniques (utiliser le langage C) qui font qu'on continue à avoir plusieurs failles d'exécution de code arbitraire par semaine dans des programmes que tout le monde utilise. Le principe fondamental de "moindre privilège" n'est pas respecté et en plus les outils de développement favorisent les trous.
Capsicum permet d'améliorer la conception des programmes utilisateurs pour être plus comportementalisés, et de rendre (dans les processus qui ont abandonné leurs privilèges superflus) des exécutions de code arbitraire beaucoup moins efficaces, ou plutôt sensiblement plus difficiles à exploiter (il faut aussi une faille en espace noyau). Le problème est que "plus difficile" ne veut pas dire impossible et que le modèle d'attaque aujourd'hui (et dans le futur) est très différent de celui des années 90. Ce n'est plus deux virtuoses motivés qui veulent soit se marrer soit siphonner des numéros de carte bleue, mais des criminels très riches (forcément, ça rapporte) et des agences gouvernementales qui collectionnent les attaques dans une course à l'armement ou pour faire de l'espionnage de grande échelle.
Si tu veux un système le plus sûr, la seule approche raisonnable est de supposer qu'il y a des failles partout; le nombre de bugs/failles est en gros proportionnel au nombre de lignes de code, selon un facteur qui dépend du degré de qualité de l'application (et donc du temps et de l'argent investi). Plus un système est gros, plus il a de failles; un système aussi gros que le noyau Linux a mécaniquement un grand nombre de failles; sa "surface d'attaque" est très large.
Pour la réduire, deux solutions:
- diminuer la surface d'attaque : revoir la conception du système pour restreindre la taille de la partie privilégiée (la base de confiance)
- rendre plus robuste le code de la base de confiance : audit régulier, mais surtout méthodes formelles pour prouver l'absence de la plus grande classe de bugs possible et prouver les propriétés de correction les plus fortes possibles
Aujourd'hui l'argent qui va dans le développement du kernel Linux ne va (à ma connaissance) dans aucune de ces directions, et les bénévoles ne font pas grand chose non plus. Linux est un système non-sûr, et la dynamique semble indiquer qu'il va le rester pour un bon moment.
Capsicum reste, malgré tout cela, un gain mesurable en sécurité puisque ça permet de faire passer la surface d'attaque de "absolument titanesque" (tout le code qui tourne avec les droits utilisateurs et le droit (SELinux etc.) de lire ce qui est dans mon $HOME) à juste "complètement énorme" (le noyau Linux). En plus du gain immédiat de cette réduction de surface d'attaque, il pousse les développeurs d'application à réfléchir aux privilèges dont ils ont besoin, et ça c'est un changement de culture qui peut révolutionner la sécurité des applications userland.
Oui enfin il ne faut pas se leurrer, toute méthode de sécurité comme Capsicum ou LXC/Docker qui repose sur le noyau Linux est dans la catégorie "pas secure" pour les gens sérieux, puisque la surface d'attaque est l'ensemble du noyau—c'est énorme.
Les containers ont une utilité claire pour faciliter le déploiement et l'administration, mais les utiliser pour la sécurité est inconscient aujourd'hui. Capsicum a aussi ce problème, et il faut plus le voir comme une mesure complémentaire d'autres techniques (par exemple la virtualisation) avec une surface d'attaque plus réduite mais moins expressives (genre Qube-OS), et surtout comme une façon de pousser les développeurs d'application à reconcevoir leur conception pour faciliter la compartementalisation et la sécurité—ce qui ne peut sur le long-terme qu'apporter des gains réels en sécurité, mais aussi en robustesse.
Je pense que tu mets le doigt sur le problème qui est la "communication". La virtualisation donne une façon de séparer les processus—qui est sans doute plus robuste que des solutions internes au noyau comme les process groups, puisque la surface d'attaque est plus petite. Séparer c'est bien mais il faut aussi communiquer, et c'est sur cet aspect que les approches par capacités apportent un point de vue intéressant—qui est applicable même par-dessus des solutions à base de virtualisation, même si la réalisation technique ne sera pas exactement Capsicum.
Les applications qui peuvent être complètement séparées (le client-mail boulot et le lecteur de musique) ne posent pas de problème. La difficulté est sur celles qui doivent collaborer, par exemple le navigateur-web-boulot et le client-mail-boulot (on veut télécharger un document du web et l'envoyer ensuite par pièce-jointe). Tu ne peux pas complètement isoler ces deux processus (pour qu'ils répondent à ton besoin il faut qu'ils puissent échanger de l'information). Mais si tu te contentes de les mettre sur la même machine virtuelle, sans essayer de les protéger l'un de l'autre, tu laisses la porte ouverte à des attaques (par exemple une faille dans le décodeur PNG du browser permet d'exécuter du code arbitraire et donc de lire le carnet d'adresse du client mail). Il faut soit re-isoler au sein de la VM (en utilisant Capsicum par exemple), soit les mettre sur deux VMs mais avec des outils de partage de données entre les deux.
Pour ce partage, les solutions de virtualisation comme Qube-OS proposent des solutions spécialisées selon le type d'objet à partager (fichier, texte…); à chaque fois, le système fait une médiation entre les VMs en demandant à l'utilisateur (dans un processus privilégié) de désigner la donnée à faire traverser. Ce sont des cas particuliers de l'"approche capacités", où c'est la désignation des ressources qui contient/transmet les droits sur ces ressources. On peut donc voir Capsicum comme (une implémentation pour Linux d') une généralisation de ce mode d'échange.
L'idée fondamentale de Capsicum est que les droits que l'on a sur un objet dépendent de la façon dont y accède et pas de l'objet lui-même: si A envoie à B une description de l'objet O, il choisit lesquels de ses droits sur O lui transférer dans cette description. Concrètement ces droits sont véhiculés par des descripteurs de fichiers (étendus avec des informations de droit d'accès et plus généralement d'appels systèmes utilisables sur l'objet pointé par le descripteur), et non les fichiers eux-mêmes. On peut avoir deux descripteurs différents vers le même objet et utiliser l'un ou l'autre qui donnent des droits différents (un peu comme en Role-Based Security à un niveau moins fin).
Cette approche d'attacher des droits aux descripteurs ne correspond pas du tout au design de LSM qui est une interface générale pour les solutions de type "mandatory access control": étant donné un sujet A et un objet O, A a-t-il le droit d'effectuer une opération donnée sur O ? C'est une façon très différente de concevoir le contrôle d'accès¹, et il n'est pas à ma connaissance possible d'implémenter Capsicum comme un module LSM --- du moins sans un surcoût important, moralement il faudrait un label différent pour chaque paire d'objet et de sujet.
Le patch actuel communique un peu avec l'interface LSM (par exemple il appelle des hooks LSM si un module de sécurité est déjà chargé), et cela lui a été reproché—on préfère une solution soit complètement dans le moule LSM, soit complètement en dehors.
¹: Capabilities: je ne connais qu'une petite partie du monde et c'est cette connaissance qui limite intrinsèquement mes droits, et que je peux transmettre. MAC: tout le monde peut parler avec tout le monde, mais un oracle externe décide d'interdire certains accès selon les identités des sujets/objets.
.
Sur l'avis de Linus : il ne s'est pas exprimé de nouveau sur ces séries de patches, donc je ne sais pas quel est son avis et s'il est toujours le même. Je crois que comme toujours les mainteneurs Linux reprochent aux gens qui veulent intégrer un gros morceau de l'extérieur de ne pas assez se reposer sur ce qui existe déjà dans le noyau, et que les premières versions des patches se font toujours rejeter pour cette raison. Je ne serais pas surpris qu'il ait senti Capsicum à l'époque comme un "gros bousin repris en bloc de FreeBSD" et réagi fortement à cause de cela—les premiers prototypes développés en 2011 avaient probablement ce défaut. Les patches actuels semblent plus Linux-centriques et ont sans doute de meilleures chances—même si rien n'est joué pour l'instant. Il s'agit d'un comrpomis à trouver, et il va certainement y avoir encore pas mal de changements.
Browserscope donne les performances du backend Javascript sur différent browsers, mais il manquait les comparaisons avec la bibliothèque C de départ. Je viens de m'en occuper.
J'ai tapé "sqlite python tutorial" dans Google, choisi le premier lien venu, et adapté le code pour reproduire le code SQL utilisé sur la page JSperf. Ça donne ça:
#!/usr/bin/python#-*-coding:utf-8-*-importsqlite3asliteimportsyscon=None#commentoneoranother#test="insert"test="select"try:con=lite.connect(':memory:')cur=con.cursor()cur.execute("DROP TABLE IF EXISTS t1")cur.execute("CREATE TABLE t1(a,b);")cur.execute("INSERT INTO t1 VALUES(?,?)",(1,'hello'))if(test=="insert"):foriinrange(250*1347):cur.execute("INSERT INTO t1 VALUES(?,?)",(1,'hello'))if(test=="select"):foriinrange(50*6795):cur.execute("SELECT * FROM t1").fetchall()print(cur.execute("SELECT COUNT(*) FROM t1").fetchall())exceptlite.Error,e:print"Error %s:"%e.args[0]sys.exit(1)finally:ifcon:con.close()
J'ai pris les valeurs 1347 et 6795 qui correspondent au meilleur nombre d'opération par seconde dans le JsPerf (Firefox 30.0), et regardé par combien de fois il faut multiplier le nombre d'opération pour que le programme Python tourne en une seconde. J'ai laissé les valeurs que j'ai obtenues expérimentalement sur ma machine (en comparaison j'obtiens 1175 INSERT/s et 2542 SELECT/s sur le JsPerf):
le programme Python fait 250 fois plus d'itérations de INSERT en une seconde
le programme Python fait 50 fois plus d'itérations de SELECT en une seconde
Ça laisse à penser qu'utiliser la lib C compilée sur ma machine, avec un frontend Python, est entre 50 et 250 fois plus rapide que d'utiliser la version compilée vers Javascript, avec un frontend Javascript—pour l'instant, on peut espérer que emscripten et les moteurs Javascript continuent à s'améliorer.
Le benchmark pourrait être faussé par le coût de récupération des données (entre le retour de SQLite et la présentation des résultats au programme Javascript appelant). Il vaudrait mieux faire des tests sur des requêtes qui demandent plus de calcul à la base de donnée qu'au client. lovasoa, si tu es motivé…
Je parle de faire une requête à un dataset et afficher le résultat à l'utilisateur d'un côté en C, Python ou whatever langage qui permet d'utiliser la bibliothèque SQLite directement, et de l'autre en Javascript (exécuté sur le browser ou à travers node.js, ça m'est un peu égal).
Un use-case pourrait être de vouloir faire un peu d'exploration des données, et d'hésiter à utiliser Javascript dans une REPL, parce qu'on connaît mieux le langage mais on se demande si ça ne va pas être beaucoup plus lent.
En réalité je suis juste curieux de savoir quel est le surcoût de la traduction llvm->javascript avec les implémentations actuelles. Et je trouve curieux que cette question ne soit pas du tout abordée par ce projet.
Je gère un site web statique et j'utilise effectivement Disqus pour les commentaires. Je regrette les problèmes de vie privée (et le fait que ce ne soit pas du logiciel libre), mais je n'ai pas trouvé de solution qui:
ne me demande pas de maintenance de mon côté
filtre efficacement le spam pour moi
permette à mes lecteurs de poster un commentaire facilement (genre le login qu'ils ont l'habitude d'utiliser va marcher, et pas leur demander de s'inscrire d'abord à Twitter ou Wordpress)
Je suis intéressé par l'approche "par commentaires" que tu proposes, mais sur ton blog montré en exemple… personne n'a posté de commentaire. Je me pose donc un peu des questions sur comment ça fonctionne, et qu'est-ce que ça donne en pratique pour les utilisateurs.
Je me pose aussi des questions sur l'utilisabilité du "lien mail" pour les personnes qui n'utilisent pas de client mail, mais un webmail. Est-ce qu'ils peuvent être envoyés vers leur webmail quand ils cliquent sur le lien ? (J'imagine que sur les téléphones ça marche ?)
On s'attendrait à des comparaisons de performances, soit dans la dépêche soit sur la page github du projet. C'est quoi le facteur de ralentissement par rapport à utiliser SQLite directement ?
(Je trouve le terme de "port en Javascript" assez discutable pour ce projet, qui compile le code de SQLite en Javascript. Pour moi, un port ce serait une récriture du code de SQLite en Javascript, ce qui n'a pas été fait ici—un projet aussi intéressant mais certainement très difficile. Pourquoi ne pas simplement dire "compilation Javascript de SQLite" ?)
À mon avis une "mémoire collective" ne peut pas se construire par des moyens techniques, mais d'abord par des actions collectives: chacun peut mettre un petit lien "oui il y a des informations pertinentes sur la dépêche/journal machin", et à mon avis c'est une responsabilité partagée.
Il y a des solutions techniques qui pourraient aider ce processus. Si les tags marchaient (dans le sens où on est aidé pour mettre des tags pertinents sur le contenu qu'on écrit), on pourrait suggérer automatiquement aux producteurs de contenu des liens "lié à …" qui reposent sur les tags—un peu comme les liens "If you found this post interesting, you might like …" ajoutés à la main sur le blog programming in the 21st century. En l'absence de tags efficaces, il faudrait se tourner vers des technologies d'analyse de langue naturelle (champs thématiques ou distances entre textes), qui pourraient donner d'excellents résultats mais demandent une bonne expertise pour être mises en place.
[^] # Re: Réponse
Posté par gasche . En réponse au journal Pourquoi LinuxFr sent-il le vitriol?. Évalué à 2.
Merci pour ce (contre-)point de vue intéressant. Tu dis
Je comprends ton point de vue, si tu remplaces "les meilleurs" par "les mieux adaptés à ce style de discussion". Par contre je suis en désaccord sur le fait que la sélection par le cynisme et la tolérance de la violence verbale est une bonne façon de maximiser l'intérêt du contenu du site¹. Je pense que LinuxFr aurait beaucoup à gagner à être une communauté plus ouverte, plus accueillante, plus tolérante aux débutants, et donc plus diversifiée.
¹: bien sûr tu parles d'intérêt "pour toi", c'est certainement vrai. Je connais des gens qui prennent plaisir à lire les disputes sur le bistrot de wikipédia, chacun ses goûts. Ici je parle plutôt d'intérêt d'un point de vue purement technique: je pense que faire des efforts pour favoriser une forme plus généreuse (et pas seulement purement la technique) peut rendre le site fréquentable à des gens qui en sont exclus aujourd'hui, et donc indirectement augmenter l'intérêt technique.
[^] # Re: Une communauté ?
Posté par gasche . En réponse au journal Pourquoi LinuxFr sent-il le vitriol?. Évalué à 3.
Je ne suis pas d'accord (pour moi c'est le même argument que "ah mais les blagues de cul, ça fait partie de notre culture !"). Et puis on peut troller gentiment, ou être en désaccord et rester courtois.
[^] # Re: Réponse
Posté par gasche . En réponse au journal Pourquoi LinuxFr sent-il le vitriol?. Évalué à 3. Dernière modification le 16 août 2014 à 16:36.
Ontologiae a déjà fait une très bonne réponse à ton post, du coup je vais zapper l'argumentation d'ensemble (aller lire la sienne) et essayer de t'expliquer pourquoi ton post est symptomatique du problème que je décris.
J'essaie d'insister (et je pense que ton post est un bon exemple) sur le fait que:
Un post n'a pas besoin d'être bourré d'insultes, de mépris et de méchanceté crasse pour être problématique. Il suffit qu'il soit légèrement passif-agressif pour donner une mauvaise impression (légère), et si une majorité de posts dans une discussion est comme ça, l'effet d'ensemble est bien pire qu'un unique post qui dépasse les bornes. Ton post est tout à fait problématique dans ce cadre.
La réponse à mes questions n'est pas "les gens sur LinuxFr sont des connards"; participent à ce comportement d'ensemble désagréable des gens qui, pris individuellement, sont au-dessus de tout soupçon d'être bêtes ou méchants.
C'est pour cela à mon avis que la réponse n'est pas "les modérateurs vont sauver l'affaire". Ils peuvent exciser les abus manifestes, mais (en tout cas dans la façon dont ils fonctionnent aujourd'hui) ne vont pas faire passer l'ambiance d'une conversation de "désagréable" à "sympa".
Non, en plus du fond (ce qui est visé par le terme "absurde"), la forme participe à donner une ambiance désagréable. Dire que quelque chose est absurde, à part une démonstration (et même, vive les mathématiques constructives), est fondamentalement une forme de violence. Pour maintenir une bonne ambiance il faut trouver un autre terme moins fort. Tu aurais pu dire par exemple "Je ne suis pas du tout d'accord avec ce point de vue, ça rappelle la vision post-68 dont on a vu qu'elle ne résolvait pas vraiment les problèmes qu'elle combattait.". Même contenu, mais ça ne fait pas monter la température.
Oui, dire à quelqu'un qu'il ne connaît "strictement rien" à quelque chose, c'est corrosif. Et quelque soit le sujet. Tu peux dire "En l'occurence il ne s'agirait pas de polytechnique mais de l'ENS qui a formé tous les médaillés Fields français.". Le reste du message est de l'acide bien concentré.
Au passage excuse-moi, mais qu'est-ce qu'on en a à cirer des différences fines entre les grandes écoles françaises ? Tu apportes quoi à la discussion en montrant que toi, tu connais bien le milieu des maths (merci, on a lu ta (formidable) dépêche, on le sait) et que l'autre ne le connaît pas (on s'en fout ?). À part un micro-monde fermé, tout le monde comprend l'usage de "polytechnicien-ne" pour dire "(ancien-ne) élève d'une grande école" de même qu'on peut dire "énarque" pour parler (d'une façon souvent anti-parlementaire et méprisante mais c'est un autre débat) de la classe politique. Indépendamment de la forme de la remarque, le contenu lui-même n'apporte en gros rien à la conversation, et donne l'impression de quelqu'un de méprisant (que ce soit ton intention ou non).
[^] # Re: Une communauté ?
Posté par gasche . En réponse au journal Pourquoi LinuxFr sent-il le vitriol?. Évalué à 3.
Je participe pas mal à des sous-communauté de reddit (ocaml et haskell en particulier) qui sont très agréables. La mailing-list OCaml est aussi très agréable. Je connais moins bien les communautés techniques francophones, mais je suis sur Progdupeupl et Zeste de savoir qui sont agréables.
Maintenant que j'y pense je dois modérer mon commentaire sur "la pire et de loin", il y a une exception : les commentaires sur LWN.net ne sont pas terribles, c'est peut-être à peu près le même niveau d'agressivité que LinuxFr—mais je ne les lis pas du tout sur LWN.net, donc je ne peux pas vraiment juger. Leurs articles sont tellement excellents que je ne ressens jamais le besoin de lire des commentaires en plus.
Enfin je discute avec des gens directement par IRC ou blogs (ou, pour les mécréants, Google Plus) interposés, et le ton des discussions y est là encore très agréable.
[^] # Re: Réponse
Posté par gasche . En réponse au journal Pourquoi LinuxFr sent-il le vitriol?. Évalué à 10.
C'est l'éternel débat de la forme "ce n'est pas ce que j'ai dit, c'est comment toi tu l'interprètes, de quel côté est la responsabilité ?". Pour moi la doctrine Unix c'est "be liberal in what you accept, and strict in what you send" : la personne qui écrit a aussi la responsabilité de réfléchir non seulement à ce qu'il veut dire, mais comment ça va être interprété par les autres.
Ça ne veut pas dire que tout le monde est soumis à la personne maximalement sensible qui va être offensée par absolument tout. Mais il faut trouver un compromis, et les personnes de bonnes volontés peuvent facilement converger vers un compromis très favorables aux récepteurs plutôt qu'aux émetteurs (ne serait-ce que parce qu'un message est écrit par une personne et lu par N, et que donc favoriser les récepteurs est du bon sens).
(Par ailleurs je pense Zenitram que tu conviendras que ton ressenti personnel et la façon dont toi tu te comportes sur LinuxFR n'ont pas vocations à s'appliquer à tous les membres. C'est bien que tu aies la carapace dure, ça ne justifie pas le fait qu'on se limite aux gens comme toi.)
[^] # Re: Une communauté ?
Posté par gasche . En réponse au journal Pourquoi LinuxFr sent-il le vitriol?. Évalué à 4.
C'est vrai que les commentaires sur les quotidiens nationaux ou (gasp!) Youtube sont encore pires. Ceci dit je pense que ton idée que LinuxFr est dans le haut du panier n'est pas vraie : parmi les communautés (d'intérêt ou de personnes, qu'importe ?) auxquelles je participe, c'est la pire et c'est très net.
Tu fais bien de signaler que c'est meilleur sur le forum (je ne sais pas, je n'y vais plus depuis longtemps). Peut-être que cela se passe mieux quand il y a un but clair d'aider des personnes. Mais je pense qu'on devrait pouvoir être sympas entre nous sans ça.
[^] # Re: Elitisme
Posté par gasche . En réponse au journal Médailles Fields en vue. Évalué à 2.
Merci d'avoir pris le temps d'écrire ce commentaire. Je suis assez d'accord dans les grandes lignes. Je me pose la question depuis longtemps : pourquoi les discussions sur LinuxFr sont-elles si corrosives ? Il y a quelque chose de vicié dans la communauté ou plutôt (car quand on prend chaque membre individuellement, ce sont des gens intéressants qu'on est content d'avoir sur le site) dans la façon de communiquer ensemble, qui rend les discussions très désagréables à lire au bout d'un temps.
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 2.
Mais je n'ai jamais suggéré que la communauté Linux devrait passer à des micro-noyaux (c'est un autre débat), seulement qu'elle fasse des efforts pour adopter des outils d'analyse statique et les méthodes formelles en général.
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 0.
J'ai demandé
et tu réponds
J'ai le sentiment que tu t'accroches à "bouh seL4 ne gère pas le multicœur" comme un argument pour… quoi ?
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 4.
Ce que je reproche à la communauté Linux n'est pas un manque de compétences techniques, mais un manque d'intérêt pour les méthodes formelles pour le logiciel. C'est une culture qui s'acquiert, qui est présente dans certains environnement (par exemple Mozilla a fait des choses très louables dans cette direction, et surtout Microsoft a su intégrer ça étonnamment bien en production, y-compris pour le développement kernel), mais absente en grande majorité du milieu du libre—qui aurait pourtant aujourd'hui la "puissance", en terme d'argents et de ressource, pour faire des choses très intéressantes dans ce domaine.
Il y a beaucoup de choses intéressantes à faire avant d'essayer de faire des preuves de correction complètes. Par exemple, garantir l'absence de comportements indéfinis dans une partie la plus grande possible du code serait déjà un très bon pas en avant; et ACSL par exemple peut servir à spécifier ce genre de propriétés de sûreté (un pointeur reste dans la bonne région mémoire).
Les gens de Microsoft ont développé des annotations formelles pour les drivers et le code noyau, qui peuvent être vérifiées par des outils d'analyse statique. Ça demande que les développeurs acceptent de s'en servir—et il y a sans doute des faux négatifs qui sont parfois casse-pieds—mais ça marche bien et ça a eu de bons effets. Ça existe depuis une décennie environ maintenant.
Je ne comprends pas trop le sens de ta (deuxième) remarque sur le multi-cœur dans SeL4. C'est vrai que la mémoire partagée est très difficile à gérer (formellement, mais aussi quand on programme) et que l'état de l'art ne gère pas bien cet aspect là. Est-ce une bonne raison de ne pas faire d'efforts pour intégrer les outils existants dans nos pratiques de développement, là où ils peuvent apporter quelque chose ?
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 10.
Je pense que ce sont des arguments à la con. Les gens qui ne publient pas leurs sources/données/preuves font mal leur boulot, et il est tout à fait légitime de leur reprocher.
(Par contre je fais une distinction entre "publier" et "mettre sous licence libre". Certains chercheurs insistent pour mettre des restrictions "pas d'utilisation commerciale" sur ce qu'ils diffusent, je ne suis pas de cet avis mais ça ne rentre pas pour autant dans ce que j'appelle "faire mal son boulot".)
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 7.
Je comprends bien l'argument "c'est comme ça", et c'est justement ce qui est chouette avec Capsicum : il s'agit d'un essai très honnête de faire du bon travail non pas en re-partant de zéro (facile d'avoir un bon design, mais voué à l'échec côté adoption) mais en améliorant incrémentalement l'existant. J'applaudis des deux mains, mais il ne faut pas non plus se voiler la face en s'imaginant que ça suffit—comme des gens se sont à mon avis fourvoyés pendant bien trop longtemps en pensant que other-group-user était un modèle de droits d'accès satisfaisant.
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 4.
Si ce genre de choses t'intéressent, tu peux aussi regarder le projet Bedrock; ce n'est pas présenté comme un OS, mais ça va quand même de l'assembleur à un petit serveur web, le tout entièrement vérifié (au niveau fonctionnel).
Ce qui est dommage c'est que la communauté Linux s'intéresse très peu à ces sujets-là. L'université (et l'armée) australienne a financé SeL4, Microsoft finance largement la recherche en méthodes formelles (le meilleur SMT solver vient chez eux, tout le monde s'en sert, mais il est propriétaire…), mais côté Linux, à part encourager mollement le travail sur Coccinelle et se plaindre des lint-like qui font trop de faux négatifs, il n'y a pas grand chose. Qui a essayé Cylone ou ATS ne serait-ce que 5 minutes, ou d'encoder des propriétés du kernel avec des descriptions ACSL?
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 3.
Je fais la gueule à Sel4 parce qu'ils auraient dû donner les sources (et surtout la preuve !) dès les premières publications. Je trouve plus que discutable de ne pas l'avoir fait dès le début et, même si c'est mieux de le faire maintenant que pas du tout, je ne vais pas pour autant m'empresser de leur faire de la pub auprès du grand public.
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 6.
Je pense qu'aujourd'hui la sécurité d'un système utilisateur est déplorable, en raison d'une combinaison de choix de conception (du contrôle d'accès) qui ne font de chaque possibilité d'exécuter du code arbitraire une faille de sécurité globale du système (tout ce qui est donnée utilisateur est compromis), et de choix techniques (utiliser le langage C) qui font qu'on continue à avoir plusieurs failles d'exécution de code arbitraire par semaine dans des programmes que tout le monde utilise. Le principe fondamental de "moindre privilège" n'est pas respecté et en plus les outils de développement favorisent les trous.
Capsicum permet d'améliorer la conception des programmes utilisateurs pour être plus comportementalisés, et de rendre (dans les processus qui ont abandonné leurs privilèges superflus) des exécutions de code arbitraire beaucoup moins efficaces, ou plutôt sensiblement plus difficiles à exploiter (il faut aussi une faille en espace noyau). Le problème est que "plus difficile" ne veut pas dire impossible et que le modèle d'attaque aujourd'hui (et dans le futur) est très différent de celui des années 90. Ce n'est plus deux virtuoses motivés qui veulent soit se marrer soit siphonner des numéros de carte bleue, mais des criminels très riches (forcément, ça rapporte) et des agences gouvernementales qui collectionnent les attaques dans une course à l'armement ou pour faire de l'espionnage de grande échelle.
Si tu veux un système le plus sûr, la seule approche raisonnable est de supposer qu'il y a des failles partout; le nombre de bugs/failles est en gros proportionnel au nombre de lignes de code, selon un facteur qui dépend du degré de qualité de l'application (et donc du temps et de l'argent investi). Plus un système est gros, plus il a de failles; un système aussi gros que le noyau Linux a mécaniquement un grand nombre de failles; sa "surface d'attaque" est très large.
Pour la réduire, deux solutions:
- diminuer la surface d'attaque : revoir la conception du système pour restreindre la taille de la partie privilégiée (la base de confiance)
- rendre plus robuste le code de la base de confiance : audit régulier, mais surtout méthodes formelles pour prouver l'absence de la plus grande classe de bugs possible et prouver les propriétés de correction les plus fortes possibles
Aujourd'hui l'argent qui va dans le développement du kernel Linux ne va (à ma connaissance) dans aucune de ces directions, et les bénévoles ne font pas grand chose non plus. Linux est un système non-sûr, et la dynamique semble indiquer qu'il va le rester pour un bon moment.
Capsicum reste, malgré tout cela, un gain mesurable en sécurité puisque ça permet de faire passer la surface d'attaque de "absolument titanesque" (tout le code qui tourne avec les droits utilisateurs et le droit (SELinux etc.) de lire ce qui est dans mon $HOME) à juste "complètement énorme" (le noyau Linux). En plus du gain immédiat de cette réduction de surface d'attaque, il pousse les développeurs d'application à réfléchir aux privilèges dont ils ont besoin, et ça c'est un changement de culture qui peut révolutionner la sécurité des applications userland.
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 7.
Oui enfin il ne faut pas se leurrer, toute méthode de sécurité comme Capsicum ou LXC/Docker qui repose sur le noyau Linux est dans la catégorie "pas secure" pour les gens sérieux, puisque la surface d'attaque est l'ensemble du noyau—c'est énorme.
Les containers ont une utilité claire pour faciliter le déploiement et l'administration, mais les utiliser pour la sécurité est inconscient aujourd'hui. Capsicum a aussi ce problème, et il faut plus le voir comme une mesure complémentaire d'autres techniques (par exemple la virtualisation) avec une surface d'attaque plus réduite mais moins expressives (genre Qube-OS), et surtout comme une façon de pousser les développeurs d'application à reconcevoir leur conception pour faciliter la compartementalisation et la sécurité—ce qui ne peut sur le long-terme qu'apporter des gains réels en sécurité, mais aussi en robustesse.
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 9.
Je pense que tu mets le doigt sur le problème qui est la "communication". La virtualisation donne une façon de séparer les processus—qui est sans doute plus robuste que des solutions internes au noyau comme les process groups, puisque la surface d'attaque est plus petite. Séparer c'est bien mais il faut aussi communiquer, et c'est sur cet aspect que les approches par capacités apportent un point de vue intéressant—qui est applicable même par-dessus des solutions à base de virtualisation, même si la réalisation technique ne sera pas exactement Capsicum.
Les applications qui peuvent être complètement séparées (le client-mail boulot et le lecteur de musique) ne posent pas de problème. La difficulté est sur celles qui doivent collaborer, par exemple le navigateur-web-boulot et le client-mail-boulot (on veut télécharger un document du web et l'envoyer ensuite par pièce-jointe). Tu ne peux pas complètement isoler ces deux processus (pour qu'ils répondent à ton besoin il faut qu'ils puissent échanger de l'information). Mais si tu te contentes de les mettre sur la même machine virtuelle, sans essayer de les protéger l'un de l'autre, tu laisses la porte ouverte à des attaques (par exemple une faille dans le décodeur PNG du browser permet d'exécuter du code arbitraire et donc de lire le carnet d'adresse du client mail). Il faut soit re-isoler au sein de la VM (en utilisant Capsicum par exemple), soit les mettre sur deux VMs mais avec des outils de partage de données entre les deux.
Pour ce partage, les solutions de virtualisation comme Qube-OS proposent des solutions spécialisées selon le type d'objet à partager (fichier, texte…); à chaque fois, le système fait une médiation entre les VMs en demandant à l'utilisateur (dans un processus privilégié) de désigner la donnée à faire traverser. Ce sont des cas particuliers de l'"approche capacités", où c'est la désignation des ressources qui contient/transmet les droits sur ces ressources. On peut donc voir Capsicum comme (une implémentation pour Linux d') une généralisation de ce mode d'échange.
[^] # Re: Qu'est ce qui a changé?
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 10.
L'idée fondamentale de Capsicum est que les droits que l'on a sur un objet dépendent de la façon dont y accède et pas de l'objet lui-même: si A envoie à B une description de l'objet O, il choisit lesquels de ses droits sur O lui transférer dans cette description. Concrètement ces droits sont véhiculés par des descripteurs de fichiers (étendus avec des informations de droit d'accès et plus généralement d'appels systèmes utilisables sur l'objet pointé par le descripteur), et non les fichiers eux-mêmes. On peut avoir deux descripteurs différents vers le même objet et utiliser l'un ou l'autre qui donnent des droits différents (un peu comme en Role-Based Security à un niveau moins fin).
Cette approche d'attacher des droits aux descripteurs ne correspond pas du tout au design de LSM qui est une interface générale pour les solutions de type "mandatory access control": étant donné un sujet A et un objet O, A a-t-il le droit d'effectuer une opération donnée sur O ? C'est une façon très différente de concevoir le contrôle d'accès¹, et il n'est pas à ma connaissance possible d'implémenter Capsicum comme un module LSM --- du moins sans un surcoût important, moralement il faudrait un label différent pour chaque paire d'objet et de sujet.
Le patch actuel communique un peu avec l'interface LSM (par exemple il appelle des hooks LSM si un module de sécurité est déjà chargé), et cela lui a été reproché—on préfère une solution soit complètement dans le moule LSM, soit complètement en dehors.
¹: Capabilities: je ne connais qu'une petite partie du monde et c'est cette connaissance qui limite intrinsèquement mes droits, et que je peux transmettre. MAC: tout le monde peut parler avec tout le monde, mais un oracle externe décide d'interdire certains accès selon les identités des sujets/objets.
.
Sur l'avis de Linus : il ne s'est pas exprimé de nouveau sur ces séries de patches, donc je ne sais pas quel est son avis et s'il est toujours le même. Je crois que comme toujours les mainteneurs Linux reprochent aux gens qui veulent intégrer un gros morceau de l'extérieur de ne pas assez se reposer sur ce qui existe déjà dans le noyau, et que les premières versions des patches se font toujours rejeter pour cette raison. Je ne serais pas surpris qu'il ait senti Capsicum à l'époque comme un "gros bousin repris en bloc de FreeBSD" et réagi fortement à cause de cela—les premiers prototypes développés en 2011 avaient probablement ce défaut. Les patches actuels semblent plus Linux-centriques et ont sans doute de meilleures chances—même si rien n'est joué pour l'instant. Il s'agit d'un comrpomis à trouver, et il va certainement y avoir encore pas mal de changements.
[^] # Re: Mais donc les performances ?
Posté par gasche . En réponse à la dépêche Retour d'expérience sur sql.js. Évalué à 5.
Browserscope donne les performances du backend Javascript sur différent browsers, mais il manquait les comparaisons avec la bibliothèque C de départ. Je viens de m'en occuper.
J'ai tapé "sqlite python tutorial" dans Google, choisi le premier lien venu, et adapté le code pour reproduire le code SQL utilisé sur la page JSperf. Ça donne ça:
J'ai pris les valeurs 1347 et 6795 qui correspondent au meilleur nombre d'opération par seconde dans le JsPerf (Firefox 30.0), et regardé par combien de fois il faut multiplier le nombre d'opération pour que le programme Python tourne en une seconde. J'ai laissé les valeurs que j'ai obtenues expérimentalement sur ma machine (en comparaison j'obtiens 1175 INSERT/s et 2542 SELECT/s sur le JsPerf):
INSERTen une secondeSELECTen une secondeÇa laisse à penser qu'utiliser la lib C compilée sur ma machine, avec un frontend Python, est entre 50 et 250 fois plus rapide que d'utiliser la version compilée vers Javascript, avec un frontend Javascript—pour l'instant, on peut espérer que emscripten et les moteurs Javascript continuent à s'améliorer.
Le benchmark pourrait être faussé par le coût de récupération des données (entre le retour de SQLite et la présentation des résultats au programme Javascript appelant). Il vaudrait mieux faire des tests sur des requêtes qui demandent plus de calcul à la base de donnée qu'au client. lovasoa, si tu es motivé…
[^] # Re: Plus d'information sur la gestion des commentaires ?
Posté par gasche . En réponse au journal éClaircie : un moteur de blog et de site personnel statique et sans nuage. Évalué à 2.
J'ai pu rater le commentaire, c'est où ? Ça apparaît chez toi ?
[^] # Re: Mais donc les performances ?
Posté par gasche . En réponse à la dépêche Retour d'expérience sur sql.js. Évalué à 4.
Je parle de faire une requête à un dataset et afficher le résultat à l'utilisateur d'un côté en C, Python ou whatever langage qui permet d'utiliser la bibliothèque SQLite directement, et de l'autre en Javascript (exécuté sur le browser ou à travers node.js, ça m'est un peu égal).
Un use-case pourrait être de vouloir faire un peu d'exploration des données, et d'hésiter à utiliser Javascript dans une REPL, parce qu'on connaît mieux le langage mais on se demande si ça ne va pas être beaucoup plus lent.
En réalité je suis juste curieux de savoir quel est le surcoût de la traduction llvm->javascript avec les implémentations actuelles. Et je trouve curieux que cette question ne soit pas du tout abordée par ce projet.
# Plus d'information sur la gestion des commentaires ?
Posté par gasche . En réponse au journal éClaircie : un moteur de blog et de site personnel statique et sans nuage. Évalué à 2.
Je gère un site web statique et j'utilise effectivement Disqus pour les commentaires. Je regrette les problèmes de vie privée (et le fait que ce ne soit pas du logiciel libre), mais je n'ai pas trouvé de solution qui:
Je suis intéressé par l'approche "par commentaires" que tu proposes, mais sur ton blog montré en exemple… personne n'a posté de commentaire. Je me pose donc un peu des questions sur comment ça fonctionne, et qu'est-ce que ça donne en pratique pour les utilisateurs.
Je me pose aussi des questions sur l'utilisabilité du "lien mail" pour les personnes qui n'utilisent pas de client mail, mais un webmail. Est-ce qu'ils peuvent être envoyés vers leur webmail quand ils cliquent sur le lien ? (J'imagine que sur les téléphones ça marche ?)
# Mais donc les performances ?
Posté par gasche . En réponse à la dépêche Retour d'expérience sur sql.js. Évalué à 4.
On s'attendrait à des comparaisons de performances, soit dans la dépêche soit sur la page github du projet. C'est quoi le facteur de ralentissement par rapport à utiliser SQLite directement ?
(Je trouve le terme de "port en Javascript" assez discutable pour ce projet, qui compile le code de SQLite en Javascript. Pour moi, un port ce serait une récriture du code de SQLite en Javascript, ce qui n'a pas été fait ici—un projet aussi intéressant mais certainement très difficile. Pourquoi ne pas simplement dire "compilation Javascript de SQLite" ?)
[^] # Re: Segmentation et dé-segmentation dans le développement mobile
Posté par gasche . En réponse au journal Apple annonce Swift, son nouveau langage de programmation. Évalué à 2.
Ne pas donner les sources d'une implémentation d'un langage parce que les versions suivantes risquent de casser la compatibilité ? Comment dire…
[^] # Re: Le retour de seccomp
Posté par gasche . En réponse à la dépêche Les journaux LinuxFr.org les mieux notés du mois de mai 2014. Évalué à 4.
À mon avis une "mémoire collective" ne peut pas se construire par des moyens techniques, mais d'abord par des actions collectives: chacun peut mettre un petit lien "oui il y a des informations pertinentes sur la dépêche/journal machin", et à mon avis c'est une responsabilité partagée.
Il y a des solutions techniques qui pourraient aider ce processus. Si les tags marchaient (dans le sens où on est aidé pour mettre des tags pertinents sur le contenu qu'on écrit), on pourrait suggérer automatiquement aux producteurs de contenu des liens "lié à …" qui reposent sur les tags—un peu comme les liens "If you found this post interesting, you might like …" ajoutés à la main sur le blog programming in the 21st century. En l'absence de tags efficaces, il faudrait se tourner vers des technologies d'analyse de langue naturelle (champs thématiques ou distances entre textes), qui pourraient donner d'excellents résultats mais demandent une bonne expertise pour être mises en place.