jben a écrit 860 commentaires

Je ne suis pas vraiment d'accord avec toi, (après je ne connais pas le domaine, moi je ne lit pas des publis d'info).

les colonnes sont réduites, les marges énormes, le titre prend un tiers de page, il y a très peu de mots par ligne, la majorité des pages est remplie de sous-titres […] la police est énorme,

Attend, tu es en train de dire que ce qu'il a fait n'est pas assez dense, au sens typographique j'entends ? Faut arreter de faire des documents les plus illisibles possibles, en disant c'est de la science. Je ne sais pas dans quel domaine tu travaille, mais pour moi si tu veux être lisible il faut que ça ne soit pas trop dense. (Mon avis est peut-être biaisé par la proportion de formule par rapport au texte qui est plus importante dans les publis que je lis).

Ne suit pas les conseils […]

Tu as lu ce que j'ai écrit avant ? Pour moi il faut satisfaire les points précedents avant d'envisager celui là. Et vu le tas de documents présent sur Arxiv, ce n'est pas ça qui fera descendre la qualité globale du machin. Je pense qu'il est dommage de travailler pour ne rien en faire, et justement il me semble une bonne alternative d'avoir comme objectif de le déposer sur Arxiv, qui est un intermédiaire entre ne rien en faire et le soumettre à un journal. Après je suis d'accord avec toi, il y a du boulot, mais c'est aussi ce que j'ai noté. Après il faut admettre que pour un premier essai il y a, à mon avis des félicitations à donner.

Je ne sais pas si toi tu a réussi à écrire un bon papier du premier coup, mais moi j'en étais loin. Si il s'oriente vers une carrière scientifique, alors ça serait bien de ne pas déjà commencer à le dégouter avec les combats vicieux et de dénigrements entre chercheurs.

Alors mon expérience de l'écriture de papiers (qui n'est pas très grande) et de lecture de papiers (qui est plus grande), m'amène à te suggerer quelques petites choses. Attention, mon domaine c'est des maths appliquées (la statistique pour être précis) à la biologie, donc ce que je dis peut être faux dans ton domaine.

• Il faut étoffer ton introduction, tu dois te situer dans le contexte. Moi qui ne connait pas grand chose à la problèmatique, je dois pouvoir vaguement situer ton travail par rapport à l'existant. C'est ce qui souvent nommé state of the art. Il faut décrire l'existant, avec des citations pour les détails, sans toutefoix tomber dans l'extrème inverse de certains biologistes qui remontent jusqu'à Darwin avec deux cent vingt mille citations.
• Il faut décrire ce que tu apporte après avoir situé ton travail dans le contexte.
• Abandonne le deux colonnes, c'est ignoble. Profite en pour réguire le nombre de signe par page (taille++ et interlignage++). La majorité des journaux ont des style tassés en deux colonnes, ils ont des style spécifiques avec plus ou moins de lisiblilité, mais quand tu écris sans soumettre autant faire un article lisible. D'ailleurs si tu va fouiller sur arxiv, tu verras plein de truc du genre, puisque le style des revues n'est pas utilisé.
• Dépose le sur une plateforme genre arxiv. Il pourra être lu et cité.

Il y a encore plein de choses à améliorer, mais pour un premier essai, c'est une très bonne réussite. J'aurai aimé faire un premier essai de cette qualité, je suis jaloux.

Ce que j'aime chez toi, c'est ta cohérence. Je viens de découvrir la RFC 3849. Merci.

Oh, ça ce n'est pas uniquement la concurrence. EDF faisait bien de la publicité du temps où ils bénéficiaient d'un monopole.

Avant propos : Je n'ai pas d'opinion sur la question.

Je veux bien que le régime de sécurité sociale soit une pyramide de ponzi, je veux bien que le régime des retraites soit une pyramide de ponzi, mais justifier la première affirmation à l'aide d'un argument rattaché à la seconde affirmation me paraît spécieux.

Dans ce cadre d'auto-édition, à propos du dépôt légal, qui s'en charge t'il ? Toi en tant qu'auto-éditeur, l'imprimeur en tant qu'imprimeur ? Ou l'imprimeur se charge des parties éditeur et imprimeur ? Ou alors comme tu es le seul en France tu te charge des deux aspects ?

En python je ne sais pas (enfin si, mais pas de tête) mais en perl je sais (et je l'ai même sous la main.

Tu remplace ton | sort -R | head -n1 par | perl -e 'my ($k,$l)=(1,"");while(<>){my $p=rand();if($p<$k){($k,$l)=($p,$_);}}print $l;'

Ça se comporte comme un tri selon une variable aléatoire, mais ça ne trie qu'au niveau de la première ligne. C'est donc en O(n). Tu ne peux pas faire mieux. Le choix est en O(1) mais la lecture des lignes est par construction en O(n).

Sur un exemple de 6⋅10⁵ lignes ça prend 60 fois moins de temps que ta solution.

Ça dépend. Il peut avoir des contact qui ont des comptes chez les entreprises concernés, et refuser d'envoyer des données personnelles dans des messages à ces personnes.

Moi ce qui me fait plaisir, c'est quand je refuse d'envoyer des données personnelles vers un mail hébergé par les entreprises concernés, on ne me considère plus comme quelqu'un de paranoïaque, mais juste comme quelqu'un de prudent. C'est plutôt agréable.

La graisse est de moi :

concernant la cryptographie à utilisation personnelle et la taille des clés

En fait il n'y a aucune restriction de ce genre, et heureusement.

En fait, le législateur a été parfaitement clair, (en étant taquin on peut dire, pour une fois). Article 30 de la LCEN :

I. - L'utilisation des moyens de cryptologie est libre.
[…]

Il n'y a pas de contrainte d'utilisation personnelle, et si on est tristement réaliste, c'est même moralement l'inverse. Ce n'est pas pour nous permettre de protéger notre vie privée que l'usage de la cryptologie a été libéralisé, mais pour des intérêts économiques qui dépassent complètement les considérations de vie privée dans l'attention du législateur.

Après c'est bien qu'on puisse en bénéficier pour une utilisation personnelle, même très bien, mais par conception, ce n'est pas le but premier.

il ne vaut mieux pas que le courant soit supérieur à la vitesse du nageur ;) sinon il va faire un temps négatif

J'avais présupposé que v<V hypothèse réaliste.

Je suis d'accord avec ton développement, mais l'avantage de faire un développement limité, c'est de voir que ça se compense à l'ordre un, et que ce n'est qu'à l'ordre deux (donc en (v/V)² ) qu'on a une difference positive… Je me place dans le cas réaliste où la vitesse du courant est faible par rapport à la vitesse du nageur, ce qui semble être le cas en l'espèce.

Alternative 1
[…]

C'est la même blague en vélo. 10 km à 10 km/h puis 10 km à 30 km/h, ça ne fait pas 20 km/h de moyenne mais une moyenne de 15 km/h. Ce n'est pas la moyenne des vitesse, mais l'inverse de la moyenne des inverses des vitesses.

Si le délai d'édition était plus long, j'aurai pu édité mon commentaire précédent…

Alternative 1

On peut aussi comprendre avec des valeurs théoriques. Soit V la vitesse du nageur, v la vitesse du courant, d la longueur du bassin.

• Aller, tps : T₁ = d/(V+v)
• Retour, tps : T₂ = d/(V-v) (on voit le comportement limite pour v→V)

Donc au total T = T₁+T₂ = d/V × ( 1/(1+v/V) + 1/(1-v/V) )

Un développement limité en v/V (qui est faible) nous donne : T = d/V × (2 + (v/V)² + O(v/V)⁴ )

En remarquant que 2d/V est le tps sans courant, en effet, au premier ordre, ça se compense, mais l'ordre deux est nuisible au nageur.

Alternative 2

Une autre manière de le voir et de voir qu'on va plus vite porté par le courant qu'à contre courant, on passe donc moins de temps porté par le courant qu'à contre courant. On passe donc plus de temps à lutter contre le courant qu'à en bénéficier. Il faut faire attention avec ce genre de raisonnement, ils ont un bon potentiel pour induire des conclusions fausses.

un ensemble de 2048 mots (ce qui est supposé dans le xkcd)

Le xkcd suppose 16 bits d'entropie, donc pour un tirage uniforme on suppose une taille de dictionnaire de 65536. Et 2¹⁶⁴ = 2⁶⁴ = 1.8 10^19. Ça correspond à un mot de passe pris aléatoirement de manière uniforme dans [A-Za-z0-9]+ de 10.7 caractères.

==Tupebar!5214
Okitypiop**--*

Ça fait 14 caractères plutôt aléatoires, mais facile à se souvenir.

Oh que non, une chaîne de Markov d'ordre 1 basée sur des transitions sur le clavier peut générer cela très facilement…

Dans le cas où elle est sur un support statique (et chiffrée avec une passphrase) le problème de compromission est bien moindre. Après pour le problème de perte, rien ne t'empêche de la distribuer selon un secret partagé de Shamir.

OpenPGP fournit déjà un mechanisme de sous-clef complètement satisfaisant sans à avoir à réinventer la roue.

Un usage raisonné d'OpenPGP consiste à génerer une clef secondaire de signature (et une clef secondaire de chiffrement), d'exporter la partie privée clefs en détruisant la partie privée de la clef principale, et d'utiliser cette version pour un usage quotidien. La clef privée complète est quant à elle écrite sur un support passif ou sur une machine déconnectée du réseau.

En cas de compromission, les sous-clefs sont révoqués, de nouvelles sont générés et signées par la clef principale.

La clef principale n'est utilisé (sauf compromission des sous-clefs) que pour renouveller les sous-clefs ou pour étendre son réseau de confiance.

En parlant de TikZ et de graphviz dans le même thread, il y a dot2tex qui permet de génerer du code LaTeX utilisant PGF/TikZ à partir du résultat de graphviz. C'est tout simplement génial.

Il y a une chose dont je reverai à propos du choix des licences : un arbre de décision.

Genre

                           [ Redistribution ]
                         /                   \
                   faible contraintes      Avec la même licence
                   de licence
                   /
         [ Utilisation des auteurs
           pour en faire de la pub ]
            /           \
          oui           non
         /                \
        …             [ publicité ]
       /                /    \
     BSD-2            oui    non
                      /        \
                     …          …
                    /            \
                  BSD-4          BSD-3

(Aucune garantie de véracité sur l'arbre d'exemple proposé).

Exacte, j'utilise pentadactyl sur une machine et vimperator sur les autres, et les deux ont ce comportement.

On pourrait voir qu'il y a un copier coller qui correspond pas à ce qui s'affiche, et mettre un warning.

Mon navigateur m'affiche en bas, Yanked: "something", quand je copie un truc. Après, si je decide de le coller quelque part, c'est mon choix.

il ne va pas tester les nombres séquentiellement, sinon il va faire les même tests que les autres mineurs.

Je ne vous pas pourquoi, du moment qu'il commence à un endroit aléatoire, ça semble même être mieux.

• Notations, N le nombre de sels possibles, supposons qu'il sont de taille fixés (en vrai j'en sais rien), n le nombre de sels testés.
• Hypothèse 1 : les deux protagonistes tirent les sels aléatoirements, le nombre de sel en commun entre les deux suit une loi hypergéometrique de paramêtre (n,n/N,N). Avec n/N→0, on a une loi binomiale. Le nombre de sels en commun a donc pour espérance n²/N et pour variance n²/N.
• Hypothèse 2 : les deux protagonistes tirent séquentiellement les nombres à partir d'une position aléatoire (en supposant un bouclage si on arrive à la fin de l'espace des sels possibles), on obtient que la proba qu'il en aient exactement i en commun, avec i=1…n, qui vaut 1/N, bien entendu elle vaut 0 pour i>n, et elle vaut ce qu'il faut pour sommer à 1 pour i=0. On a donc (avec utilisation de n/N→0) une espérance de n²/(2N) et une variance de n²/(3N).

Bref, il semble même plus judicieux de tirer séquentiellement que à partir d'une position aléatoire. (Et en plus comme sha256 est un algo par bloc, on peut même avoir un avantage à ne pas recalculer depuis le début du sel pour aller plus vite, encore faut-il que le sel soit à la fin du machin à calculer, j'espère que non sinon c'est trop facile).

Après il ne faut pas oublier qu'on est en train de parler de proba qui sont très très petite, et même très très inférieure à la proba de trouver un sel valide, je m'excuse par avance auprès de la confrérie des mouches.

Justement, de loin, (je ne connais que rapidement le fonctionnement de bitcoin), ça a l'air d'un sel et non d'un nonce. La caractéristique d'un nonce c'est qu'il ne doit pas être réutilisé, on l'introduit pour éviter tout ce qui est du genre replay.

Y-a-t'il se genre de restriction, ou c'est juste un sel ?

Ça c'est déjà 512 ou 1536 Mio de plus que nécessaire.

Ça dépend comment tu défini necessaire.

Si c'est necessaire pour les programmes, alors oui, 512 MiB suffisent largement. Si c'est necessaire à un bon fonctionnement fluide, 2 GiB sont souvent appréciable, même sur un netbook, ainsi beaucoup de lectures se font sur le cache, les écritures peuvent se faire bufferiser largement…

J'en profite pour parler de torsocks, qui fonctionne pareil que tsocks, mais qui à quelques patches sympas en plus, dans l'optique de tor. C'est à dire, un peu plus d'appels interceptés, et il ne grogne pas quand il voit un .onion.

Et même dans le second cas, on va s'apercevoir que les requêtes DNS passent à côté par exemple.

Avec SOCKS 5 (et 4a) elles ne devraient pas passer à coté. Après il y a le risque d'un programme mal codé qui fait la résolution DNS dans tout les cas, c'est pour cela que je préfère en règle générale de passer via tsocks, car lui je sais qu'il fait le boulot.