reno a écrit 3880 commentaires

  • # Les analyseurs ne sont pas non plus une panacee

    Posté par  . En réponse au journal Idée stupide sur la sécurité du code. Évalué à 8.

    Dans le cas d'openssl il y a eu des analyses, mais elles ont loupes ce bug, cf http://blog.regehr.org/.
    L'analyse ne fait pas tout, après il faut distinguer les faux positif des vrais bugs, corriger le bug sans en introduire un nouveau (Debian..)

  • [^] # Re: Please Put OpenSSL Out of Its Misery

    Posté par  . En réponse au journal journal bookmark : vers un fork d'OpenSSL ?. Évalué à 4.

    Je trouve que le titre de son message est mal choisi car il ne flingue pas que OpenSSL: il y a les CAs aussi dans le lot..
    Ce qui est amusant, c'est que ça fait pas mal de temps que je lis que nos mécanismes de sécurité sont ridicules, mais on ne se réveille qu'avec Heartbleed mais bon je ne suis pas optimiste: l'attention semble se focaliser sur l'implémentation alors que n'importe quel CA peut te trahir..

  • [^] # Re: ...

    Posté par  . En réponse à la dépêche Un projet de VM Python chez Dropbox et état des lieux des autres VM. Évalué à 3.

    car n'importe qui qui a déja utilisé la shm sait à quel point c'est pénible, contraignant et source d'erreurs ( deadlock entre autre ).

    Facepalm, mais tu le fait exprès ou quoi?
    Avec les threads en C toute tes variables globales sont en mémoire partagée (pas en D ou par défaut toute variable globale est en TLS ce qui est un bon changement) donc la source d'erreur des deadlock, ELLE EST OMNIPRESENTE AVEC LES THREADS!!
    Mais pas avec les processus ou tu utilise la mémoire partagée uniquement aux endroits où tu en as besoin pour des raisons de performances..

    J'ignore si tu trolle ou si c'est par pure ignorance, mais les processus étant plus sûr que les threads (pas d'état global partagé par défaut), pour privilégier la fiabilité, on devrait utiliser les processus par défauts sans shm, puis s'il y a un problème de perf les processus avec shm et seulement les threads si il y a encore un problème de performance..

    Ce n'est pas toujours le cas parce que malheureusement:
    - certains langages intègrent les threads mais pas les processus, donc c'est plus lourd pour les dev d'utiliser les processus.
    - Windows gère mal les processus.

  • [^] # Re: Rust vs Go

    Posté par  . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 5.

    Oui, enfin quand on conçoit un langage, ce sont surtout les header eux-même qui sont un bidouillage: si tu remarques bien, aucun des nouveaux langages n'impose des fichiers de header.

    Tu es habitué aux headers, OK, mais bon l’intérêt d'une violation aussi manifeste du DRY maintenant que les ordinateurs sont suffisamment puissant pour s'en passer, bof..

  • [^] # Re: Rust vs Go

    Posté par  . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 6.

    Bof, vu que tu peux générer un fichier d'entête automatiquement, c'est un "pour" très faible..

  • [^] # Re: ...

    Posté par  . En réponse à la dépêche Un projet de VM Python chez Dropbox et état des lieux des autres VM. Évalué à 3.

    • la création de processus est trop coûteuse comparé aux gains de la parallélisation.

    Les pools de process ça existe aussi, ce n'est pas réservé aux threads..

    Et pour qui est de la dangerosité de la mémoire partagée, explique en quoi c'est un argument contre les process??

    Et puis franchement ce genre d'argument philosophique n'a pas grande valeur du code ou un benchmark ok, sinon bof
    c'est du préjugé, de l'optimisation prématurée..

  • [^] # Re: ...

    Posté par  . En réponse à la dépêche Un projet de VM Python chez Dropbox et état des lieux des autres VM. Évalué à 4.

    et dire qu'une alternative au multi-threading sur un processeur multicore (qui est la norme aujourd'hui) est du multi-processus, c'est, comment dire, clairement de la mauvaise foi.

    Peut-tu expliquer pourquoi tu dis ça? Le non partage par défaut du multi-processus me parait plus sain, et si tu peux toujours utiliser la mémoire partagée si tu en as besoin..

  • [^] # Re: Rust vs Go

    Posté par  . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 6.

    Bof, ton argument est faiblard: dans un projet il est facile d'avoir comme règle de codage: pas de unsafe a moins qu'il y ait une justification.
    La règle "éviter toute les constructions foireuse du C++" est beaucoup plus compliquée a appliqué!

  • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

    Posté par  . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 3.

    Faux,
    1) il n'y a pas besoin de modéliser tout l'assembleur pour que ça soit utile dans le cas dont on parle

    2) ça existe déjà je pense:
    http://www.reddit.com/r/ReverseEngineering/comments/1jz3qv/formal_specification_of_the_x86_instruction_set/

  • [^] # Re: A ceux qui comme moi...

    Posté par  . En réponse au journal Sortie de GNU Guix 0.6. Évalué à 3.

    Quel avantage par rapport à Nix / Nixos ?

    Je crois que la différence principale est qu'ils utilisent Scheme au dessus de Nix.

  • [^] # Re: Remplacer l'assembleur par Ada ou Rust ?

    Posté par  . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 3.

    Je pense qu'une façon de faire serait de modéliser le comportement des fonctions utilisées et valider le fait que le code assembleur ne contient pas de buffer overflow.

    Ça ne marcherai pas avec tout les programmes assembleur, mais bon ça devrait marcher avec un nombre suffisant..

  • [^] # Re: Rust vs Go

    Posté par  . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 4.

    Le C++ n'est pas du C !

    Faux! Le C++ n'est pas que du C, mais quand tu regardes pas mal de projet soit-disant C++, en fait c'est principalement du C et donc on se retrouve avec tout les problèmes du C.

  • [^] # Re: Une analyse du bug.

    Posté par  . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à -3.

    Note que F# a un sacré handicap: Microsoft! Pas besoin de détailler je pense..

  • [^] # Re: Une analyse du bug.

    Posté par  . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 8.

    Dit autrement, a quand une implémentation d'openssl en rust ?

    Tu rêve: si la sécurité était vraiment prise au sérieux, le C ne serait pas utilisé sur ce genre de projet: Ada ça existe déjà depuis longtemps..
    Certes, Ada n’empêche pas de faire des erreurs de durée de vie des variable comme Rust, mais il a le mérite d'être mature et d'exister depuis longtemps et de résoudre 99% des problèmes du C ce qui
    est déjà un net progrès!

  • [^] # Re: Rust vs Go

    Posté par  . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 4.

    Avec ta définition, un vieux langage ne pourra jamais être un bon langage.

    Tel que la plupart des langages sont développés effectivement c'est le cas car quand les créateur cherchent a améliorer le langage (cf Python3) souvent les mises à jours ne prennent pas..

    Après il y a des degrés et C++ a une dette technique abyssale, Ada moins par exemple.

    La seule alternative potentielle ce serait le "go fmt": faire évoluer le langage en fournissant des outils pour simplifier le portage, problème: ça marche bien quand tu as du code simple, mais dès que tu utilise les macros, la reflection, un outil ne peut pas faire grand chose..

  • [^] # Re: Rust vs Go

    Posté par  . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 3.

    Parce qu'un bon langage ne devrait pas avoir des manuels de 700 pages et plus et des livres qui donnent les bonnes parties et les partie a éviter.

    C++ n'est donc pas un bon langage même s'il est très puissant.

  • [^] # Re: Dérangeant....

    Posté par  . En réponse au journal Journal bookmark. Évalué à 2.

    Lors du mariage, le maire ne demande et ne vérifie pas la sexualité du couple,

    Je le croyais aussi, mais (à Nice?) un mariage a été annulé car le femme se plaignait du manque de relation sexuelle: apparemment il existe une loi totalement obsolète sur le sujet mais qui a été appliquée dans ce cas là..

  • [^] # Re: Suis-je le seul à avoir l'impression de vivre dans un roman de science-fiction ?

    Posté par  . En réponse au journal Journal bookmark. Évalué à 7.

    Bof, pour préciser mon propos que l'homophobie est une forme de racisme: le racisme n'est pas à propos des races puisque biologiquement tout les hommes sont de la même race, donc le racisme devrait s’appeler "groupisme": la discrimination envers d'un groupe envers un autre.

    Les groupes étant défini suivant des critères variables et flous, c'est souvent le pays d'origine mais pas seulement par exemple le racisme anti-métisse, donc ça peut aussi être la couleur de peau, mais pas seulement cf la religion, etc.
    L'homophobie me parait donc être très clairement une forme de "groupisme".

    Je ne vois pas en quoi établir l'évidence "établis un schéma de pensé ou le déni d’humanité à l’égard de l’homosexuel est possible".

  • [^] # Re: Suis-je le seul à avoir l'impression de vivre dans un roman de science-fiction ?

    Posté par  . En réponse au journal Journal bookmark. Évalué à 3.

    Hum, remplace pédophile par raciste(*) et tu en pense quoi?

    *: L'homophobie est une "variante" du racisme..

  • [^] # Re: Suis-je le seul à avoir l'impression de vivre dans un roman de science-fiction ?

    Posté par  . En réponse au journal Journal bookmark. Évalué à 5.

    A partir du moment ou il a soutenu publiquement les anti-gay, je ne dirais pas que ça fait partie de sa vie privée mais de sa vie publique.
    C'est son droit de soutenir qui il veut, mais c'est aussi le droit des autres d'appeler a boycotter une entreprise l'ayant choisi comme représentant: la liberté va dans les 2 sens!

  • # Pas sympa le 'false sharing'

    Posté par  . En réponse à la dépêche OpenJDK 8, JEP 142 & False Sharing. Évalué à 2.

    J'ai entendu parler des recherches sur des algorithmes qui utilisent efficacement les caches quelque soit leur taille, mais je ne crois pas qu'ils tiennent compte du false sharing/

    Ça me rappelle une discussion sur les spinlock ( http://lwn.net/Articles/531254/ ) et leur impacts sur le comportement des caches, je m'étais demandé si ça ne vaudrait pas le coup de mettre les spinlock dans leur propre ligne de cache..

  • [^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)

    Posté par  . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 6.

    il ferait mieux d'apprendre à communiquer avec les développeurs pour faire entrer ses grosses modifications GRSecurity dans le noyau.

    YAQUAFAUQUON?
    Plus facile a dire qu'a faire.. Il y a eu plusieurs tentatives pour intégrer les modifications de sécurité de GRsecurity sur lesquelles il a travaillé dans Linux, mais seule une petite partie ont réussi a être intégrée.

  • # Intéressant les transients

    Posté par  . En réponse à la dépêche Sortie de Clojure 1.6. Évalué à 3.

    L'initialisation des constantes (*) est un problème sur lequel j'ai vu bien des débats, les transients ont l'air d'une solution intéressantes, ne nécessitant peut-être nécessairement une copie des données..

    *:je n'aime pas le mot immutable qui est verbeux et utilisé uniquement parce que le C++ a dénaturé le mot-clef const qui aurait du être read_only_view(view) au lieu de const.

  • [^] # Re: Vive le progrès!

    Posté par  . En réponse à la dépêche Java 8 et NetBeans 8 sont disponibles. Évalué à 2.

    Dans ce cas la, pourquoi tu mets Java dans la liste?
    Avec le procès que fait Oracle a Google sur les API..

  • [^] # Re: Bonne nouvelle

    Posté par  . En réponse au journal Nepomuk est mort, vive baloo. Évalué à 5.

    En suivant la même logique, les dévs de Fedora sont des guignols[coupé]

    Mais il y a des guignols dans le projet Fedora! Celui qui a écrit leur page web ( https://fedoraproject.org/ ) par exemple, ça commence par "Fedora is a fast, stable(??), and powerful operating system for everyday use(??)", je n'ai aucun problème avec le "bleeding edge", mais pas quand il prétend être autre chose.

    Ou alors on peut dire que c'est dans la logique de KDE d'introduire des nouveautés de façon agressive, et que du coup le KDE "vanilla" n'est pas destiné à l'utilisateur lambda

    Hum, avant KDE4.* je ne me souviens pas que c'était à ce point..