Buf a écrit 449 commentaires

  • [^] # Re: Retour

    Posté par  (Mastodon) . En réponse au journal linuxfr-solarized : nouvelle version. Évalué à 1.

    Pareil, mais j'ajouterais que j'aime bien la première pour les titres.

  • [^] # Re: Applet java

    Posté par  (Mastodon) . En réponse au journal Des virus multiplateformes grâce à Java ?. Évalué à 1.

    Java Web Start est sandboxé par défaut. C'est pareil que pour une applet, il faut que le code soit signé pour pouvoir supprimer les limitations de la sandbox (et l'utilisateur doit l'accepter, bien sûr)

  • [^] # Re: événementiel

    Posté par  (Mastodon) . En réponse au journal C'est quoi encore que ce délire ?. Évalué à 5.

    Trop tard

  • [^] # Re: Plusléger?

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à 2.

    Euh… je dois être stupide, mais je vois absolument pas le rapport entre ta réponse et mon commentaire…

  • [^] # Re: Plus léger ?

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à 3.

    La performance est quelque chose d'important pour tous les visiteurs, avoir du code lisible n'est utile qu'à une minorité. Clairement, pour moi, les perfs sont prioritaires, donc je n'hésite pas à minifier mon Javascript (les CSS également). Et si je veux permettre aux gens de jouer avec mon code, je fournis un lien vers le code source lisible et commenté.

    Au passage, c'est exactement ce qui est fait ici même, voici un bout du Javascript de linuxfr.org (j'ai ajouté les retours à la ligne) :

    (function(a,b){function h(a){var b=g[a]={},c,d;a=a.split(/\s+/);for(c=0,d=a.length;c<d;c++)b[a[c]]=!0;return b}
    function l(a,c,d){if(d===b&&a.nodeType===1){var e="data-"+c.replace(k,"-$1").toLowerCase();d=a.getAttribute(e);
    if(typeof d=="string"){try{d=d==="true"?!0:d==="false"?!1:d==="null"?null:f.isNumeric(d)?parseFloat(d):j.test(d)?f.parseJSON(d):d}
    catch(g){}f.data(a,c,d)}else d=b}return d}
    
    
  • [^] # Re: Ratio IPv4/IPv6

    Posté par  (Mastodon) . En réponse au journal Aujourd'hui c'est le « World IPv6 launch ». Évalué à 3.

    C'est le fond jaune.

  • [^] # Re: Plus léger ?

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à 2.

    Offusquer du code, ça témoigne rarement d'une bonne intention.

    Pour Javascript, dans pratiquement 100% des cas, c'est fait pour des questions de performances.

  • [^] # Re: Plus léger ?

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à 3.

    Documentation de l'extension : 6.1 Detected Free Licenses

  • [^] # Re: Plus léger ?

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à 1. Dernière modification le 06 juin 2012 à 11:53.

    à la limite, que l'extension indique si il y a du code libre ou pas sur un site, pourquoi pas, mais que ça bloque le code non libre, c'est du très grand n'importe quoi.

    Et ce qui est encore pire, c'est quand ça bloque du code parfaitement libre (exemple au hasard : linuxfr.org)

    Cette extension, ça revient à exiger de la part de tous les développeurs web de mettre un sceau "FSF approved" sur tout ce qu'ils codent.

  • [^] # Re: Plus léger ?

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à -3.

    Et pour ceux qui ne veulent pas exécuter du JS non libre, tu proposes quoi à la place ?

    Je propose de désactiver complètement Javascript. Ou mieux, de ne pas du tout utiliser le web (c'est souvent servi par du logiciel pas libre).

  • [^] # Re: Plus léger ?

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à 3.

    Oui, c'est exactement ça.

    Même si le but est légitime, c'est la façon dont c'est fait qui est absolument stupide, parce que ça va bloquer indifféremment :

    • le code non libre
    • le code libre avec une licence qui n'est pas dans la liste des licences considérées comme libre (WTFPL, par exemple)
    • et le pire de tout : le code libre écrit par quelqu'un qui ne connait pas cette extension et qui n'a jamais mis les commentaires sous la forme exigée

    En clair, à part ralentir le browser et détruire le fonctionnement de pratiquement tout site qui utilise js, cette extension ne sert à rien.

  • [^] # Re: Plus léger ?

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à 7.

    Si on veut un web utilisable, c'est à éviter aussi…

    Franchement, il y a des gens qui ont réellement envie d'utiliser ce truc ? Il me semble qu'on atteint des sommets dans le ridicule là…

  • [^] # Re: ArchLinux

    Posté par  (Mastodon) . En réponse au journal Arch Linux signe ses paquets !. Évalué à 4.

    rien ne l'y oblige.

    C'est une question de courtoisie, tout simplement.

    Tout comme je déteste avoir des liens pointant vers des urls raccourcies, j'ai horreur d'arriver sur une page qui me donne une erreur à cause d'un certificat moisi, surtout quand elle est également disponible en http.

  • [^] # Re: Précision

    Posté par  (Mastodon) . En réponse au journal Steam sur Linux après les supputations, la confirmation.. Évalué à 3.

    Oui mais bon, si c'est pour obtenir une réponse en Valve Time, l'intérêt est limité.

  • [^] # Re: Un point de plus

    Posté par  (Mastodon) . En réponse au journal La seule et unique raison de refuse le vote par Internet. Évalué à 3.

    En France, on est autour de 80% de participation sur certains scrutins

    En Suisse, 50% est considéré comme élevé, on est souvent plutôt autour de 40%. La fréquence des scrutins est certainement la cause principale, on vote minimum 4 fois par an, et souvent 6 ou 7 fois. D'où l'intérêt de chercher des compromis qui simplifient les choses (et effectivement, les cantons qui ont généralisé le vote par correspondance ont observé une légère hausse de la participation)

  • [^] # Re: Un point de plus

    Posté par  (Mastodon) . En réponse au journal La seule et unique raison de refuse le vote par Internet. Évalué à 1.

    Ça ne garantit pas grand chose, en fait, parce que ça implique de faire confiance à plusieurs intermédiaires (un facteur n'aurait pas grand mal à modifier le vote de quelqu'un)

    Le but du système n'est pas d'essayer d'éliminer tous les risques et toutes les "failles", mais de proposer un système le plus simple et le plus pratique possible aux électeurs, tout en évitant les fraudes massives. Ça implique de tolérer quelques fraudes ponctuelles et de ne pas avoir de garanties absolues sur le secret du vote.

    En pratique, les gens acceptent ce risque et apprécient le confort apporté par le vote par correspondance (je crois qu'on doit tourner autour de 80% des bulletins renvoyés par la poste)

  • [^] # Re: Ce dont on peut être sûr ...

    Posté par  (Mastodon) . En réponse au journal Qui par ici est anti-conspirationniste. Évalué à 7.

    Le problèmes des personnes qui sont du bord anti-conspiration c'est qu'elles se font traiter de paranoïaques, on les tourne en ridicule.

    Non, le problème, c'est qu'il est absolument impossible d'avoir une discussion rationnelle avec ce genre de personnes, tout argument "contre" pouvant être très facilement retourner en un argument "pour" (du genre : l'absence de preuve de l'existence d'un complot mondial est la preuve que le complot est si puissant qu'il arrive à faire disparaitre toute preuve)

    En fait, les conspirations mondiales, c'est un peu les dieux actuels :

    • ça permet d'expliquer tout et n'importe quoi (malheureusement, sans permettre de prédire quoi que ce soit)
    • il est facile de voir des "preuves" de leur existence un peu partout
    • on ne peut pas démontrer leur non-existence
  • [^] # Re: C'est pas si simple l'email.

    Posté par  (Mastodon) . En réponse au journal Les emails par Neuf…. Évalué à 5.

    On est clairement ici dans un cas couvert par le troisième point (le serveur SMTP l'a accepté, mais il ne peut pas le déposer dans la boite du destinataire parce qu'un antispam l'en empêche), il faudrait donc envoyer une notification à l'expéditeur.

    Problème : on a quasiment 100% de chances que l'adresse de l'expéditeur soit fausse. Envoyer une notification n'est donc pas seulement inutile, ça contribuerait également à amplifier le problème du spam. Du coup, personne ne le fait. C'est clairement contraire à la RFC, mais on est dans un cas où respecter la RFC causerait une nuisance grave à plein de monde.

  • [^] # Re: FS

    Posté par  (Mastodon) . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 2.

    c'est une grosse violation du design des système de fichiers (un peut comme le fait FTP avec ses modes passif/actif).

    Euh… j'ai du mal à voir le rapport là.

  • [^] # Re: C'est pas si simple l'email.

    Posté par  (Mastodon) . En réponse au journal Les emails par Neuf…. Évalué à 7.

    chez moi si le serveur sendmail dit qu'il accepte, j'attends de lui qu'il livre le mail. S'il n'en veut pas il répond un code 4 ou 5.

    En général (en tout cas sur les grosses infrastructures), ce n'est pas le serveur SMTP lui-même qui délivre le courrier dans la boite de l'utilisateur. Donc on peut très bien se trouver dans une situation où le SMTP visible sur Internet va accepter le message (il voit passer de tels volumes qu'il ne peut pas se permettre de faire plus que quelques vérifications très sommaires), puis va essayer de le transmettre plus loin, à un serveur qui aura les ressources nécessaires pour faire une analyse plus poussée, où le message pourra être rejeté. Oups, trop tard pour envoyer un 4xx ou 5xx au client initial…

    La pratique correcte serait d'envoyer une notification à l'expéditeur pour lui signaler que son message n'a pas été délivré, mais vu que dans plus de 90% des cas, ça sera du spam avec une adresse expéditeur fausse, on ne le fait pas (ça se faisait il y a quelques années, mais vu le pourcentage de spam actuel, c'est complètement irresponsable aujourd'hui)

  • [^] # Re: Calcul correct ?

    Posté par  (Mastodon) . En réponse au journal Yo, ca gaze ?. Évalué à 4.

    Le beurre, c'est "seulement" environ 80-85% de matière grasse. Il y a aussi une petite quantité de protéines et de glucides (environ 1% chacun), le reste c'est principalement de l'eau (qui représente donc quand même autour de 15% du poids total)

  • [^] # Re: Beurre

    Posté par  (Mastodon) . En réponse au journal Pâtes à l'huile d'olive ou au beurre ?. Évalué à 2.

    Le rinçage, c'est uniquement si les pâtes ne sont pas mélangées immédiatement avec une sauce.

    Dans le cas contraire, il faut absolument éviter de les rincer, ça enlèverait l'amidon qu'elles ont en surface et qui va aider à bien lier la sauce (mais qui va les faire coller entre elles si on ne met pas de sauce)

  • [^] # Re: crême

    Posté par  (Mastodon) . En réponse au journal Pâtes à l'huile d'olive ou au beurre ?. Évalué à 2.

    Le meilleur : crème, ketchup et gruyère râpé.

  • [^] # Re: Tant que j'y pense…

    Posté par  (Mastodon) . En réponse à la dépêche Sortie de PulseAudio 2.0. Évalué à 2.

    La différence entre Mac et Linux pour Avahi/Bonjour, c'est surtout une question d'intégration.

    Sur Mac, c'est mis en avant par Apple et ça existe depuis longtemps, du coup les applications vont faire tout le boulot pour enregistrer les services qu'elles proposent. Du point de l'utilisateur, ça va marcher tout seul dans la plupart des cas.

    Sous Linux, il y aura très souvent une bonne dose de travail à faire manuellement.

  • [^] # Re: Ah ah

    Posté par  (Mastodon) . En réponse au journal Pâtes à l'huile d'olive ou au beurre ?. Évalué à 2.

    Avec assez d'eau (c'est le plus important) et en remuant régulièrement, ça passe très bien sans huile dans n'importe quelle casserole.