jben a écrit 847 commentaires

Euh… Donc pas exotique, mais historique, on se croirait revenu 100 ans en arrière. L'exotique a un côté intemporel, le chèque n'est pas exotique, juste une curiosité mise à côté de la bougie pour s'éclairer le soir qu'on peut voir dans les musées d'histoire ;-).

Ça dépend des usages de chacun. Pour ma part je consomme entre un demi carnet et un carnet de chèques (45 chèques) par mois. Le chèque présente encore beaucoup d'avantages pour moi.

• Le premier, c'est la difficulté à tracer précisément les paiements. Le tracé peut être effectué au meilleur des cas au jour près si la date est correcte. Ça m'arrive de mettre, de bonne foi, une date légèrement erroné, en confondant les dates de la veille et du lendemain. Il est possible d'avoir plus précis avec les traces du commerçant, mais c'est très difficilement automatisable. Bref pour moi, niveau vie privée c'est un bon compromis entre les espèces et la carte bancaire.
• Le deuxième, c'est la trace dans le talon, il n'y a pas de tickets de caisse à ne pas perdre pour faire ses comptes.
• Le troisième, c'est que c'est un moyen de paiement efficace entre particuliers. Le virement bancaire aussi, mais pourquoi ne devrions-nous n'avoir qu'un seul moyen efficace ?

Bref, pour moi, ma carte bancaire me sert essentiellement à retirer de l'argent, par grosses sommes afin d'éviter de laisser des traces précises. Le chèque est pour moi la seule alternative à un fonctionnement complet en espèces, avec les risques que cela comporte.

Oui mais moneo avait été un flop. J'ai peur que cette vague de paiement sans contact ne soit pas un flop, et que progressivement les gens ne se mettent à utiliser que cela.

Le seul espoir qui me reste c'est l'article R642-3 du CP :

Le fait de refuser de recevoir des pièces de monnaie ou des billets de banque ayant cours légal en France selon la valeur pour laquelle ils ont cours est puni de l'amende prévue pour les contraventions de la 2e classe.

Mais toutefois il y a l'article L112-5 du CMF :

En cas de paiement en billets et pièces, il appartient au débiteur de faire l'appoint.

C'est sur cette base que certains commerçants refusent certains billets, légalement ils ne refusent pas, ils demandent que vous faisiez l'appoint.

Ce que j'ai peur c'est que ces pratiques se généralisent, et qu'il soit dans la pratique, très contraignant de payer en espèces.

Peu de C++ courant fait un usage intensif des template.

Ça dépend de ce que tu appelle courant. Pour moi, une utilisation courante est le calcul numérique, et des fois il y a besoin d'algèbre linéaire, et des trucs comme armadillo ou itpp en font un usage non négligeable.

Disons qu'il y a plusieurs problème pour moi :

• On a besoin que d'un facteur ce que je possède pour dépenser des petites sommes, avec la puce on a besoin d'un second facteur ce que je connais.
• On a même pas besoin de satisfaire le facteur ce que je possède pour effectuer une transaction, il suffit de se coller à des gens dans le métro (ce n'est pas comme si avoir plein de gens autour de soi dans le métro était exceptionnel).
• La distance maximal semble théorique, si nous supposons qu'un attaquant est en train d'effectuer une transaction frauduleuse, nous pouvons aisément supposer qu'il ne respecte pas les limites de puissances légales, comment la carte réagit-elle dans ce cas ?
• Il semble y avoir un problème de vie privée, puisqu'il semble être possible de récupérer des informations nominatives sur les personnes.

Bref, même si la carte ne semble pas être duplicable par ce moyen, je pense qu'il n'est pas pour autant exempt de défauts.

C'est sujet à discussion. Par exemple, la carte bancaire est considérée comme « ce que j'ai », alors qu'il suffit de lire la bande magnétique. Disons que c'est un « ce que j'ai », mais pas très costaud.

Enfin moi je dirais plutot :

• la puce : ce que j'ai
• le PIN : ce que je sais
• la bande : une grosse blague

Je me demande toujours quel est l'interêt de placer un système robuste à coté d'un système passoire. Je veux bien que la bande soit utile pour certains pays, mais dans ce cas, pourquoi ne pas fournir deux cartes différentes ?

Enfin le numéro utilisé pour payer en ligne est aussi une belle blague niveau sécu. Et la puce de paiement sans contact ne me semble guère mieux.

D'un autre coté, à moins que le code bancaire n'ait été révisé, tout paiement sans authentification de l'utilisateur est opposable/révocable.

Ça n'a pas changé, mais c'est encore mieux, article 133-19 du CMF :

I. ― En cas d'opération de paiement non autorisée consécutive à la perte ou au vol de l'instrument de paiement, le payeur supporte, avant l'information prévue à l'article L. 133-17, les pertes liées à l'utilisation de cet instrument, dans la limite d'un plafond de 150 euros.

Toutefois, la responsabilité du payeur n'est pas engagée en cas d'opération de paiement non autorisée effectuée sans utilisation du dispositif de sécurité personnalisé.

II. ― La responsabilité du payeur n'est pas engagée si l'opération de paiement non autorisée a été effectuée en détournant, à l'insu du payeur, l'instrument de paiement ou les données qui lui sont liées.

Elle n'est pas engagée non plus en cas de contrefaçon de l'instrument de paiement si, au moment de l'opération de paiement non autorisée, le payeur était en possession de son instrument.

Il faut comprendre :

• instrument de paiement = carte bancaire
• dispositif de sécurité = PIN de la carte (et peut-être le code de sécu au dos)

En cas de paiement frauduleux avec une carte sans contact, si le PIN n'a pas été utilisé, on fait appel au I. et c'est plié.

Mais je pense que même si le PIN a été utilisé (genre le méchant a regardé trois jours avant par dessus votre épaule au distributeur), je pense qu'on peut faire appel au II., on doit être parfaitement dans cette situation en détournant, à l'insu du payeur, l'instrument de paiement ou les données qui lui sont liées.

Tant qu'à faire, pourquoi effacer des lignes sauf celles qui matchent, et ne pas raisonner en affichant seulement celles qui matchent ?

df -iPh | sed -ne '/[5-9][0-9]\%/p'

Explications :

• -ndesactive l'affichage auto,
• celles qui matchent se font afficher.

Wait… en fait c'est un grep !

D'ailleurs moi quand je parse une sortie d'une commande, je n'aime pas être géné par une éventuelle localisation qui viendrait perturber mon résultat, j'ai donc toujours un LANG=C.

Mais sinon sur la question intiale, j'approuve le premier commentaire, une solution de suppervision (même si moi je pense à munin) me parrait vraiment plus adaptée pour ce genre de choses.

Merde quoi! c'est culoté quand même : journal posté à 22h44, premier commentaire pour se plaindre : 22h52. Le mec il n'a pas lu 3 lignes ?

Merci, mais tu as oublié une possibilité : je l'avais déjà lu.

J'ai mon avis sur le contenu, je l'ai précisé en première ligne de mon commentaire. Je ne critique pas le contenu, je critique son inadéquation avec les sujets couramment abordés ici. J'aurai compris si il y avait une réelle plus-value (comme une traduction, un début de débat, une argumentation…), mais là, je reste dubitatif.

J'ai cliqué sur le lien, je connaissais le sujet, j'avais déjà lu ce témoignage.

Cela ne m'avait pas choqué quand je l'avais lu à l'époque. C'est vrai que quand on compare les deux versions, celle-ci est plus lisible.

Je vais donc dire que la valeur ajoutée est faible par rapport à la valeur ajouté qu'aurait pu lui apporter l'auteur du journal. En à mon avis trop faible pour justifier de faire un journal hors-sujet.

Non pas que le propos soit ininteressant, mais je me poses des questions sur sa place ici.

Tu aurais pu avoir une valeur ajoutée, par exemple le traduire, mais là rien, aucune valeur ajoutée par rapport à un lien. Déja que j'aurai douté de la pertinence d'un journal bookmark sur le sujet, mais nous faire une copie sans valeur ajouté est completement inutile.

Bref, pour ton premier journal, tu essaie d'avoir une borne inférieure pour faire mieux ensuite ?

Tout simplement, tu fais un script qui fait l'action sur une IP donnée en argument, genre action_sur_IP :

#!/bin/bash

IP=$1
# Je fais plein de truc avec $IP

Puis après tu lances tout avec xargs, genre

xargs -n 1 -P 0 ./action_sur_IP < ip.cfg

Et hop, ça roule.

En jouant avec le -P tu peux décider combien de processus tu execute en paralelle (-P 0 veut dire autant qu'il y a de processus à lancer, donc tout en même temps).

Je le répète mon intention en disant pour moi n'est pas de prendre les gens de haut, mais d'éviter de tirer une géneralité de mon comportement.

Si c'est tuner son noyau […]

Le tunning de noyau à mes yeux (pour ne pas dire pour moi), c'est des truc un peu plus violent comme appliquer un patch pour transformer l'appel système fsync en truc qui ne fait rien. D'ailleurs la blague c'est que ce comportement est POSIX-compliant. À ce propos un thread en parle sur la lkml. Notez bien que je n'approuve pas ce patch, bien que je trouve que les applications utilisent fsync à tord et à travers, il y a des cas où cet appel est justifié, l'usage d'une solution comme eat-my-data sur les programmes en faisant un usage non justifié, me semble préferable.

Tu augmente la quantité de pages sales que le noyau accepte. Ça reviens à augmenter le buffer de lecture (comme tu l'a bien dis les écritures sont asynchrones donc on s'en fout). Dans les fait comment ça se passe ? Si tu fais un read(fd, buff, SIZE); le noyau va se permettre de lire plus préventivement ? ou est-ce que ça s'applique principalement sur des appels comme mmap ?

Augmenter la quantité de pages sales autorisée ne reviens pas à augmenter le buffer de lecture, c'est uniquement les ecritures qui sont plus bufferisés. Donc la lecture devient la seule chose à faire à ce moment.

Lorsque tu parles de lecture préventive, c'est plus au niveau du readahead qu'il faut aller voir, et donc du coté de hdparm. À noter que laptop-mode-tools permet aussi de facilement gerer ce comportement sans aller manger la doc de hdparm qui n'est pas des plus digestes.

Par contre pour les gros fichiers (ceux qui sont trop gros pour que tu les mettent en cache), il vaut mieux utiliser une technique comme ultracopier, car il faut que l'utilisateur voit pourquoi son fichier n'est pas entrain d'être lu et qu'il puisse mettre en pause la copie qui le bloque (parce que la première est moins prioritaire pour lui). Bien sûr tu peut faire un Ctr+z sur le cp en question, mais c'est moins pratique il faut savoir que c'est bien lui qui bloque.

Pour le coup, je suis très rarement confronté à ce genre de problème. Je l'étais à une époque, mais j'ai pris l'habitude (en partie grâce au fait que je suis ammené à travailler sur des machines dont je ne suis pas le seul utilisateur) d'utiliser ionice. Quand j'ai besoin d'effectuer une tache gourmande en I/O, et que j'estime cette tache non prioritaire, je la lance en class idle pour ionice (à l'aide d'un ionice -c 3, j'ai un alias). Il m'arrive aussi de redefinir un l'ionice d'un processus déjà lancé.

Et tu ne vérifie pas que la copie de ta sauvegarde c'est bien faite ? Si c'est le cas c'est dommage.

Si bien sûr, avec l'outil de transfert, une vérification périodique des checksum est effectuée.

Mais ce qui est vraiment dommage c'est de te voir depuis 2 jours aligner les "moi je …" tune mon noyau, n'est pas besoin de… etc en prenant un peu tout le monde de haut.

Au lieu d'utiliser ce genre d'arguments, je sais que la forme de mon discours est perfectible, pourrais-tu répondre sur le fond ? Je parle de ce qui doit être fait par le noyau et fait par les programmes en espace utilisateur ? J'ai une opinion, je l'exprime comme étant la mienne sans généraliser, il est vrai que je pourrais l'exprimer différement.

Et ce n'est pas tuner son noyau de choisir des valeurs adaptées à son usage. D'ailleurs des programmes permettent très facilement de régler ce genre de chose, par exemple laptop-mode-tools.

J'ai du mal à comprendre en quoi la fiabilité est meilleure. Quand j'ai besoin de copier des données en local sur un média, j'y vais à coup de cp, sync, démontage. Dès que c'est à distance, rsync est mon seul ami.

De toutes les façons vu le peu de copies local de fichier que j'effectue, genre en local pour mes fichiers j'utilise un gestionnaire de version, ça me suffit.

Bref, à part le point interface et convivialité du bestiaux qui ne m'interesse pas (mais ça c'est mon coté refractaire, c'était mieux à vents), je n'arrive toujours pas à voir pourquoi un gestionnaire de copie pourrait m'être utile.

1er point c'est la fiabilité de la copie (peu de personne prenne en compte ce point jusqu’à ce qu'il perdent leur données).

Moi je ne considère pas un disque comme fiable. Je dois être parano. Donc pour moi, écrire de manière fiable sur un support qu'il ne l'est pas, ce n'est pas très utile. Pour cela j'utilise d'autres solutions pour garantir la pérennité de mes données (comme des sauvegardes délocalisées)

Moi j'aimerai bien un moyen de désactivé la possibilité de faire un sync sous linux (pas la commande, mais l'appelle système). Car dans un env KDE, 95% des applications font un sync à chaque close, et en plus certaine application ferme et ouvre des fichiers sans arrêt.

Il existe une lib chargeable en LIB_LD_PRELOAD pour cela. Ils fournissent même un wrapper pour ne pas avoir à faire le preload à la main. C'est libeatmydata.

C'est à utiliser en connaissance de cause bien sûr.

Je tiens à préciser quelque chose:
Dans l'ensemble, quand ont reste dans le cache/buffer, tout les systémes ont à peu prêt les mêmes caractéristiques.

Par contre, quand le buffer/cache est trop petit, la, la différence coté application ET coté OS se fait (réorganisation des accès hdd).

Donc en gros, tu es d'accord avec moi, si on a un cache et des buffers configurés de tel sorte qu'ils soient suffisamment gros (donc avec de la RAM en face), l'utilisation d'un gestionnaire de copie est inutile. Sans vouloir dénigrer les gestionnaires de copies, ça reste du rustinage pour les systèmes matériellement limités où le noyau ne peut pas faire bien son boulot.

Qt fait un sync à chaque close() de chaque fichier

Je te rejoins complètement sur cette critique, mais pour des raisons radicalement différentes. Toi tu fais un boulot qui devrait normalement être effectué par le noyau et ce comportement te gène. De mon coté, bien que je pense qu'il est normal que depuis l'espace utilisateur on puisse demander un sync pour vider écrire les pages sales, cela reste un besoin extrêmement spécifique, et à mon avis les programmes ne devraient pas, sauf exceptions, interférer avec la politique d'écriture du noyau.

Par exemple sur mon notebook, j'ai une politique extrêmement agressive de gestion de l'énergie, en particulier j'ai une expiration des pages sales de 30 minutes. Je sais ce que je fais, c'est mon choix, ça correspond à mon usage. Je ne veux pas que les programmes s'occupe du boulot du noyau, c'est le boulot du noyau, j'ai configuré ce qu'il faut pour, les programmes : laissez faire le noyau.

Et je me répond à moi-même, pour préciser que dans le cas où les données à copier sont en cache, on observe des résultats similaires :

Pour le séquentiel :

rm -rf qqpart; mkdir qqpart; sync; res; cat qqch?/* > /dev/null; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ qqch3/ qqpart/ qqch4/ qqpart | xargs -n 2 -P 1 cp -r; sync"

Pour le parallèle :

rm -rf qqpart; mkdir qqpart; sync; res; cat qqch?/* > /dev/null; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ qqch3/ qqpart/ qqch4/ qqpart | xargs -n 2 -P 4 cp -r; sync"

On obtient 9.4 s pour le séquentiel et 8.2 s pour le parallèle.

Bref, je ne vois pas quoi faire d'autre pour argumenter mon propos. Mais si vous me sugerez d'autres tests, je les ferais avec plaisir.

En fait, l'écriture se fait à la fin en grande partie, lors du sync. Les écritures sont toutes bufferisés. C'est sur la lecture qu'il y a une optimisation possible, mais un bon choix du readahead résoud ce problème.

Donc tu veux des plus petits fichiers, ok. Je vais aussi me mettre en condition plus violentes, 4 cp séquentiels contre 4 cp parallèles. Donc 4 dossiers contenants chacun 100 MiB en fichier de 10 KiB.

mkdir qqch{1..4}
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch1/
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch2/
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch3/
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch4/

La commande de test sera pour le séquentiel :

rm -rf qqpart; mkdir qqpart; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ qqch3/ qqpart/ qqch4/ qqpart | xargs -n 2 -P 1 cp -r; sync"

Et pour le parrallèle :

rm -rf qqpart; mkdir qqpart; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ qqch3/ qqpart/ qqch4/ qqpart | xargs -n 2 -P 4 cp -r; sync"

Et alors là les performances sont même contraire à que vous suggerez :

• Séquentielle : 4 min 38 s
• Parallèle : 3 min 23 s

Je le répète, pour moi, c'est le rôle du noyau d'optimiser ce genre de chose, pas de l'utilisateur. Encore faut-il avoir une machine bien configuré, et assez de RAM relativement à la taille des données qu'on manipule. C'est vrai, sur une machine limitée en mémoire, le noyau ne peut pas optimiser car il ne peut pas garder assez de pages sales en mémoire, mais ce n'est pas le cas général.

Pour moi le raisonnement est simple, je configure bien mon système par rapport à mon usage, je lui donne les moyens adéquats (assez de mémoire), et après c'est son problème, pas le mien. Toutes ces solutions (mise en file pour une copie séquentielles, etc.) ne sont à mes yeux que des solutions de contournement, et elle ne sont donc d'aucunes utilité quand il y a rien à contourner.

Bon alors testons.

Je prépare les données :

mkdir qqch1
mkdir qqch2
for((i=0;i<100;i++)); do dd if=/dev/urandom of=qqch1/$i bs=1M count=10; done
for((i=0;i<100;i++)); do dd if=/dev/urandom of=qqch2/$i bs=1M count=10; done

Je me prépare un alias, car je vais vider les caches pour chaque essai afin d'être dans des conditions équivalentes.

alias res="echo 3 > /proc/sys/vm/drop_caches"

Voici mes 4 commandes de test :

• séquentielle

  • avec sync final

    rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 1 cp -r; sync"

  • sans sync final

    rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 1 cp -r"

• parallèle

  • avec sync final

    rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 2 cp -r; sync"

  • sans sync final

    rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 2 cp -r"

Bilan :

	Séquentielle	Parallèle
Avec sync final	59.4 s	59.3 s
Sans sync final	31.8 s	33.3 s

Bref, dans mon cas c'est le noyal qui s'occupe de bien faire comme il faut. Oui, les valeurs de dirty_ratio, dirty_expire_centisec, dirty_background_ratio… ne sont pas celles par défaut. Ce sont celles qui correspondent à mon usage.

Ça doit être moi qui ait du mal avec le concept. Je n'utilise pas de gestionnaire de fichier, je gère intégralement mes fichiers en ligne de commande, je n'utilise que des trucs comme mv, cp , rsync…

Utiliser un gestionnaire de copie me semble étrange, mais ça c'est mon opinion, et je conçois très bien qu'il peut être utile à certain. Par contre, utiliser un gestionnaire de copie via Wine, je pense que c'est clairement du masochisme.

Par contre l'argument de liberté de Supercopier, et le fait d'étudier le code est pour moi un argument pertinent.

Même si à titre personnel je juge toujours cette dépêche comme inutile, je comprends que certains la trouvent pertinente, c'est un progrès.

Dans l'ordre, je vais sur un site web :

Da Linux French Page

puis je choisis une dépèche,

Supercopier 3

puis je lis :

Le port pour Linux n'est pas d'actualité pour l'instant

Faîtes tourner les gens, ça à l'air bien comme substance pour ne pas s'embêter avec ce que certains nomment la cohérence.

Probablement :

   -c cipher_spec
          Selects the cipher specification for encrypting the session.

          Protocol version 1 allows specification of a  single  cipher.   The  sup‐
          ported values are ``3des'', ``blowfish'', and ``des''.  3des (triple-des)
          is an encrypt-decrypt-encrypt triple with three different  keys.   It  is
          believed  to be secure.  blowfish is a fast block cipher; it appears very
          secure and is much faster than 3des.  des is only supported  in  the  ssh
          client  for  interoperability with legacy protocol 1 implementations that
          do not support the 3des cipher.  Its use is strongly discouraged  due  to
          cryptographic weaknesses.  The default is ``3des''.

          For  protocol version 2, cipher_spec is a comma-separated list of ciphers
          listed in order of preference.  See the Ciphers keyword in  ssh_config(5)
          for more information.

Tu as essayé de rajouter un -c blowfish ?

Et en plus avec les id anonymes publiés tu peux vendre ton vote. Avec le scrutin papier actuel si tu vends ton vote l'acheteur ne peut que te faire confiance. Avec ce que tu proposes, la commercialisation des votes devient possible.

Les conditions de ton protocole experimental me semblent trop otimistes.

En vrac :

• Débit tellement important que ça risque de rendre le chiffrement limitant en vitesse, pas forcement représentatif du cas réel
• Pas de pertes de paquets
• Ping très faible, donc la latence introduite en faisant passer sur du TCP ne va pas être représentative

Bref, pour moi, avec ce protocole de mesure, tu va obtenir des différences qui seront faibles, mais en plus pas significative des différences observés lors d'un déploiement réel.

En passant par tun, ce système peut-il encore fonctionner ?

Tout à fait. Et niveau config, ne connaissant pas ta config exacte, les modifications à apporter me semblent mineure (même si au final ça change le niveau auquel est fait le tunnel, donc des modifications importantes).