jben a écrit 860 commentaires

C'est même un peu plus vicieux que ça. Tu prends deux branches qui fonctionnent, tu vires la moité des commits de chaque branche, et tu merges. Ce qui est vraiment impressionnant c'est que Oh my fucking God ça compile !

Moi je n'ai pas de carte d'identité et je ne suis pas malade, c'est bien que ça a un rapport !

C'est simple de savoir, il suffit de lire la phrase suivante :

Ils doivent se mettre en file simple dès la chute du jour et dans tous les cas où les conditions de la circulation l'exigent, notamment lorsqu'un véhicule voulant les dépasser annonce son approche.

À votre avis, si la phrase précédente voulait dire que rouler à deux de front est interdit, quelle est le sens de cette phrase ?

Je viens de vérifier. Alors en fait c'est le bordel, mais c'est bien ça en gros.

Dans l'ordre :

• Pensions alimentaires. Elles sont prioritaires. Articles L213-1 et L213-2 du Code des procédures civiles d'exécution :

  La demande vaut, sans autre procédure et par préférence à tous autres créanciers

• Puis après on a l'avis à tiers detenteur un nom bien barbare pour la saisie des impôts.

  Elle est définie à l'article L262 du livre des procédures fiscales,

  Les dépositaires, détenteurs ou débiteurs de sommes appartenant ou devant revenir aux redevables d'impôts, de pénalités et de frais accessoires dont le recouvrement est garanti par le privilège du Trésor sont tenus, sur la demande qui leur en est faite sous forme d'avis à tiers détenteur notifié par le comptable chargé du recouvrement, de verser, aux lieu et place des redevables, les fonds qu'ils détiennent ou qu'ils doivent, à concurrence des impositions dues par ces redevables

  Il convient de noter que cela ne fonctionne que pour les impots. Donc je pense que ce ne serait pas utilisable pour le recouvrement d'un chèque ayant servit à payer un timbre-amende.

  Elle est prioritaire sur la saisie de droit commun selon l'article R3252-37 du code du travail

  La notification à l'employeur d'un avis à tiers détenteur conforme aux articles L. 262 et L. 263 du livre des procédures fiscales suspend le cours de la saisie jusqu'à l'extinction de l'obligation du redevable, sous réserve des procédures de paiement direct engagées pour le recouvrement des pensions alimentaires.

• Et enfin la procédure de droit commun, l'article L3252-8 du code du travail dispose

  En cas de pluralité de saisies, les créanciers viennent en concours sous réserve des causes légitimes de préférence.

  Toutefois, les créances résiduelles les plus faibles, prises dans l'ordre croissant de leur montant, sans que celles-ci puissent excéder un montant fixé par décret, sont payées prioritairement dans les conditions fixées par ce décret.

  et cette somme selon l'article D3252-34-1 du code du travail cette somme c'est 500 €.

Vraiment, le droit fiscal, je n'aime pas ça.

Disons que le site officiel de l'administration française aboutit à la même conclusion que moi. Par contre je sais pas si ils se basent sur la même chose que moi, n'indiquant pas sur quoi ils se basent sur ce point.

Bien dans le cas de chèques sans provisions, après avoir obtenu le certificat de non-paiement (donc un mois après le rejet initial), l'avoir donné à un huissier, et après 15 jours sans payer, l'huissier entame les mesure d'execution forcés, la saisie sur salaire en fait partie.

Par contre en cas de plusieurs saisies sur salaires concurrentes il y a un ordre à respecter. De mémoire c'est pension alimentaire, puis trésor public, puis créanciers privés.

L'article L113-3 du code de la consommation dispose :

Tout vendeur de produit ou tout prestataire de services doit, par voie de marquage, d'étiquetage, d'affichage ou par tout autre procédé approprié, informer le consommateur sur […] les conditions particulières de la vente

Il s'agit donc d'une obligation d'information. C'est pour ça qu'il y a marqué dans nombre de tabac nous n'acceptons pas les chèques, ce n'est pas juste pour ne pas répeter toujours la même chose. C'est aussi pour cela que les commerce vérifiant les chèques à l'aide du FNCI (verifiance par exemple) l'indiquent, sinon ils n'auraient pas droit de refuser les chèques refusés par le système.

Pour se retourner contre le vendeur qui se retracerai après le virement, même si le vendeur est identifié, il faut aller au tribunal de proximité ou tribunal d'instance selon la somme du coté du civil, ou alors porter plainte pour escroquerie auprès du procureur de la république et se porter partie civile. Le fait que le vendeur soit identifié simplifie la procédure je suis d'accord, mais ça reste quand même contraignant.

Concernant les chèques, j'exclus le chèque volé de mon raisonnement. Accepter un chèque sans vérification d'identité relève de l'inconscience. Dans ce cas, il est possible, et c'est une procédure classique, de se retourner contre l'émetteur. La procédure est balisée, même pas besoin d'aller devant un juge.

Il y a encore des gens qui acceptent un chèque de banque sans passer un coup de fil à la banque ayant émis le chèque ?

Généralement quand on a recours au chèque de banque, c'est que la somme en jeu justifie la précaution élémentaire de ce coup de fil.

Je l'évite quand même pas mal. À l'étranger je paie en espèces (retirées en France, au distributeur ou en commande pour autre chose que des euros, c'est le plus économique). En France je paie en espèces. Ce que je paie en chèque, au final c'est ma vie courante (bouffe, restau, vetements, chaussure, essence, vélo…).

Trop dur d'attendre 24 heures…

Ça dépend, si on parle d'un service, genre vente de voiture entre particulier, le paiement par virement necessite la confiance :

• de l'acheteur si le virement est fait à l'avance, si le vendeur se rétracte et refuse de rembourser ça risque être compliqué de se retourner contre le vendeur ;
• du vendeur si le virement est fait après la remise de la voiture, l'acheteur peut très bien faire le mort, et ça risque être compliqué de se retourner contre l'acheteur.

Le chèque pour ce type de transaction présente bien des avantages, il permet la simultanéité de l'échange pognon ←→ voiture. Même s'il y a un risque de manque de provision, il laisse une trace.

Ce n'est pas pour rien que pour ce type de transaction, nous utilisons régulièrement des variantes du chèque, pour garder ses avantages et gommer ses inconvénients : le chèque certifié et le chèque de banque.

Justement, la comparaison était entre chèque et virement bancaire dans le cadre d'un paiement entre particulier.

Dans le cas d'un virement bancaire, le particulier destinataire doit faire confiance au particulier émetteur pour effectuer le virement, s'il ne le fait pas, alors il ne reste aucune trace de la créance, et il est difficile de se retourner.

Dans le cas d'un chèque, un fois l'identité de la personne vérifiée pour s'assurer que le chèque n'a pas été volé, si le chèque est sans provisions, il y a une trace de la créance, et le particulier émetteur a une obligation à assumer (provisionner le chèque, payer sa dette). Alors oui, cela peut-être long, énervant, mais contrairement au virement bancaire le particulier destinataire a un moyen de se retourner contre le particulier émetteur, et en plus le parcours à suivre est plutôt balisé.

Pour le paiement entre particuliers, entre espèces, virement, et chèque, ils ont pour moi tous des avantages, tous des inconvénients, mais pas les mêmes.

Si tu veux faire tes achats sans être traçable, sans divulguer au marchand qui tu es, et sans divulguer à ton banquier où et quand tu fais tes courses, le chèque n'est pas la solution : il est tout aussi nominatif que la carte bancaire…

Avec les chèques, je suis tracable, juste beaucoup moins précisement. C'est une histoire de compromis. Quand je dépense 300 euros dans un magasin, quand je paie mon loyer, même si j'ai généralement de quoi payer en espèces (pas forcément sur moi), je préfère payer par chèque, et garder les espèces pour plus tard, sinon je serais obligé de retirer de vraiment trop grosses sommes, ce qui pose certains problèmes (agressions, cambriolages…).

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é.