jben a écrit 841 commentaires

Juste une astuce, je ne sais pas si elle s'applique à ton problème.

Tu parles de déplacement de fichiers, et dans ce cas rsync refait un transfert du fichier, il n'a pas vu que c'est le même.

Par exemple, un répertoire nommé dossier/, synchronisé sur serveur:dossier/.

Initialement on fait

rsync -a dossier/ serveur:dossier/

Puis un jour on veut faire un déplacement de fichier, on fait :

mv dossier/fichierA dossier/fichierB
rsync -a dossier/ serveur:dossier/

Et là c'est le drame. Il retransfère le fichierB.

L'astuce c'est d'utiliser l'équivalence entre mv a b et ln a b; rm a, mais on va rajouter un rsync entre les deux.

cp -al dossier/fichierA dossier/fichierB
rsync -a dossier/ serveur:dossier/
rm dossier/fichierA
rsync -a --delete dossier/ serveur:dossier/

J'utilise cp -al et non ln, car ça permet de conserver les permissions et de faire le machin recursivement pour un répertoire si c'est un répertoire qui est bougé.

Et comme ça, ça passe très bien, il detecte que fichierA et fichierB sont des hard link, il crée fichierB comme un hard link sur fichierA dans la destination, et à l'étape suivante il supprime fichierA.

Alors je ne sais pas si c'est de ce type de déplacement dont tu parles, mais c'est une astuce à connaître quand on utilise rsync.

Utilise tu la compression du flux avec ssh ssh -XC ou non ssh -X ?

La compression rajoute une charge, très faible sur nos processeurs modernes, qui peut des fois être génante avec du matériel ancien. Par contre ça réduit considérablement la taille du flux.

Moi je ne l'active pas sur un réseau local, mais à travers une connexion ADSL je l'utilise.

Bref si tu ne l'utilise pas, fais l'essai en l'activant, si tu l'utilise, fais l'essai en la désactivant.

Ben prenons un exemple de logotype. Un T, on est purement dans le domaine d'application du png.

Voici l'original :

Et voici ce que ça donne en JPEG (tout le signal est dans la luminance on s'en fout des chrominance, et donc le sous-echantillonage des chrominances n'importe), je présente la version obtenue, ainsi que la difference relative à l'original.

• quantification au seuil de 50 %
• quantification au seuil de 75 %
• quantification au seuil de 94 %

Quant au constat au niveau des tailles, il se passe de commentaires :

jben@ginette /tmp/T $ find . -type f -printf '%s\t%f\n'
1889    c94.jpg
1610    c50.jpg
1673    c75.jpg
595     orig.png

Il y a quoi que tu ne comprends pas dans le fait qu'il y a des pertes ? Qu'on voit qu'elles sont selon la base du DCT dans les bords des lignes, et que le codage entropique de PNG est plus adapté ?

Je ne suis pas pro-PNG, je ne suis pas anti-JPEG. J'essai juste d'être cohérent. Pour enfoncer un clou, j'utilise un marteau. Pour visser un vis, j'utilise un tournevis. Et j'ai l'intime conviction que, dans chaque cas, utiliser l'autre outil serait moins efficace.

Je pense que tu ne comprends pas la probèmatique.

Le JPEG, en gros c'est, découpage en bloc, DCT, quantification, puis codage entropique. (Je passe le passage en luminance-chrominances et sous-échantillonage des chrominances). Les pertes se font dans l'étape de quantification, c'est à dire dans la base de la DCT. Autant ces pertes sont acceptables pour l'œuil quand il s'agit d'éléments continus (comme une photo, oh, justement c'est pour ça qu'il a été créé), qu'elles deviennent visibles dès qu'elle existent, même à un niveau très faible en cas de variation brutal du signal.

Rien qu'une ligne noire sur un fond blanc suffit à montrer les artefacts de la quantification des valeurs après transformation par la DCT.

Après, on peut supprimer la quantification, oh, ben dans ce cas JPEG se réduit à un codage entropique. PNG est prévu pour, c'est dommage de ne pas l'utiliser, en plus il y a un canal alpha.

Je le repète sur un logo avec des trucs genre des applats de couleurs, des lignes, quelque soit le niveau des pertes avec JPEG, elles seront beaucoup trop visibles par rapport au gain apporté.

La graisse est un ajout :

Je parle des gens qui ne font pas de bio, physique ou math, public traditionnel de LaTeX en France.

Ça serait tellement bien si c'était vrai !

Tu attaques sur plusieurs fronts de manière parfaitement ridicule.

Je n'utilise aucun des produits de Microsoft, personnellement et professionnellement, je n'ai rien à défendre.

Premier point, on te demande d'intervenir sur un systeme que tu ne maitrise pas. Je ne suis pas sûr que ça soit la faute du système en question. Moi si on me demande de faire de la chimie organique, et que ça ne fonctionne pas, il ne me viendrai pas à l'idée de remettre en cause la qualité des réactifs. Sur ce point, c'est plutôt l'organisation de ta structure qui est à mettre en cause.

Ensuite du dénigre Microsoft au niveau technique, en ayant assumé être incompétent sur ce système, je pense que c'est non pertinent.

Pour continuer tu égrènes des affirmations sur l'importance du rapport qualité prix des produits Microsoft dans la progression du libre. Il y a beaucoup d'autre facteurs à prendre en compte pour pouvoir expliquer la progression du libre, et celui là me parrait, au mieux négligeable. Je te conseille donc d'étayer ton affirmation ou ne rien affirmer.

Passé les insultes, tu parles des virages technologiques que Microsoft aurait raté, ce n'est pas la première boîte à avoir loupé un virage, et pour une boîte qui a loupé un virage, elle n'a pas l'air tant sortie de la route que ça.

Donc si tu veux souhaiter bon courage à pbpg pour répondre, je te conseille de l'attaquer avec une argumentation construite et cohérente.

Nota: Écrire M$ est parfaitement ridicule.

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.