benoar a écrit 4236 commentaires

Perdu, tu as mal lu les commentaires. C'est tout l'inverse.

Ah, en fait j'ai même pas lu les commentaires, je l'ai fait de mémoire /o\

Pour le code, on sait ce qui ne va pas marcher

Ouai donc ya quand même un peu de code à faire… :-)

Par contre, on est actuellement hébergé chez la fondation Free et elle ne nous donne pas d'IPv6 (en tout cas, pas par défaut, on ne leur pas fait de demande particulière pour ça non plus).

Ça c'était le problème dont j'avais également entendu parler. À une époque j'avais proposé (en commentaire) de voir pour que FDN puisse vous faire un tunnel par exemple. J'aurais dû en parler plus concrètement la dernière fois que j'ai croisé oumph, mais je suppose que la flemme a frappé. Ou sinon, j'espère que la fondation Free peut peut-être elle-même vous fournir de l'IPv6, depuis le temps ?…

Ensuite, il faudrait également gérer le routage vers les containers LXC et les différents services (webalizer, sympa, etc.).

Je voudrais commencer à troller, mais sérieusement, si possible : une des choses qu'amène IPv6, mais que personne n'a l'air de comprendre, c'est qu'avec Internet partout on était sensé se passer de ces problèmes. Je veux dire, une application se bind sur sa socket (addresse + port), ou se connectait à une autre (addresse + port), et point, elle n'avait rien d'autre à faire. Le problème du routage, ça revenait à l'admin sys/réseau, et chacun faisait bien son boulot sans mélanger les problématiques. Mais depuis sont arrivés les devops avec les VMs et les containers, et tout est parti en sucette : on a tout mélangé, on s'est « abstrait » d'IP en réiventant tout mais en moins bien (vive docker et son archi NATée IPv4… on est en quelle année déjà ?), et maintenant quand il faut déployer en IP « normal » (= v6) bah c'est la grosse galère. Je veux bien regarder s'il y a moyen de brancher ça sans trop tout foutre en l'air, mais ça aurait été beaucoup plus simple, je pense, de migrer vers IPv6 si la containerisation n'était pas passée par là. Après, tu me dis LXC et pas docker, donc j'ai un peu d'espoir que ça ait été bien fait, et je sais que normalement tu codes pas trop mal, alors je vais partir positif pour une fois et pas trop râler !

Par contre j'ai cherché dans le code et je vois pas de trace de sympa ou webalizer : c'est géré en interne ? Y a-t-il moyen de contribuer ?

Et surtout passer du temps à bien tester tout ça.

Oui, c'est sûr.

Bien sûr ça n'a aucun rapport, mais Microsoft vient de déménager ses quartiers généraux à Münich en fin d'année dernière :
https://mspoweruser.com/microsoft-germany-moves-into-a-new-headquarters/
(vu sur /.)

Le problème n'est pas l'accès, mais l'applicatif, cf. https://linuxfr.org/suivi/support-ipv6
Tant qu'un codeur en ruby n'y aura pas jeté un œil, malheureusement ça restera bloqué.

Non, ce n'est pas une perte de souveraineté, c'est juste de la délégation

Merci pour ce bel exemple de novlangue.

(d'un truc qui d'ailleurs était anormal, on t'imprime un billet gratos alors que ça un coût pas petit,

Le sans-contact, c'est payé par ton commerçant, qui le répercute sur toi. Tu as donc un truc qui a l'air gratos (enfin, tu payes ta CB quand même, ça n'est pas si gratos) alors que ça a un coup pas petit que tout le monde paye.

c'est normal qu'on veuille le faire disparaitre, comme les chèques ou TIP d'ailleurs qui au passage étaient déjà en pseudo perte de souveraineté sans que ça te dérange plus que ça)

Le TIP ça se remplace avantageusement par un virement : si elles n'étaient pas si débiles, les banques auraient même pu s'accorder sur une nomenclature commune jusqu'à l'utilisateur, pour avoir un format qui permette le rapprochement, plutôt que de requérir du SDD. Le chèque je suis partagé : je trouve que c'est un moyen qui n'a pas d'équivalent en numérique, et on nous enlève une possibilité de paiement direct entre particuliers avec du papier. Je trouve que le virement pourrait éventuellement le remplacer, c'est donc pour ça que je prône l'utilisation de ce moyen de paiement, mais les gens n'ont pas l'air de trop accrocher. Je les comprends un peu, et je suis prêt à accepter le coût du chèque pour l'instant.

OK : on perd quels avantages déjà?
Pour discuter, il faudrait commencer par être objectif, comme par exemple ne pas balancer "perte de souveraineté" à tout va

Arrête de lire sélectivement, tu as omis tous les arguments qui ne t'arrangeaient pas.

(rappel : les banques doivent respecter la loi, loi faite par le peuple, qui d'ailleurs ne se prive pas de faire des lois dessus comme la limitation des frais).

La loi c'est l'écriture d'un rapport de force entre les gens : se dire qu'il n'y a que des gentils en face qui la respecteront, c'est faire son bisounours. Oui, je me base sur le fait que dans la société tout le monde va globalement respecter la loi, mais ça n'empêche pas de se protéger quand même au cas où. Penser qu'il ne faut aucun moyen de pression alternatif après la crise des subprimes, c'est naïf.

Je trouve que c'est l'exemple parfait de l'archaïsme des micro-paiments en liquide, tous les jours tu vas chercher ton pain, tous les jours tu manipules des petites pièces, il faut te rendre la monnaie, ça coûte de l'argent à la boulangerie de gérer tous ces fonds de caisse et de passer un temps fou à rendre la monnaie, à gérer les gens qui se pointent avec 50€ ou pas assez d'argent…

Archaïque peut-être, mais c'est un système géré par l'état. Avoir un fond de roulement ça coût au commerce, mais le micro-paiement aussi ! Et dans un cas, tu as un système géré par l'état, qu'on finance tous, et dans un autre c'est un système géré par des banques privées. Alors oui c'est un compromis, mais il faut pour moi ne pas cacher que c'est une perte de souveraineté.

Ce n'est pas parce que tu es habitué à un système foireux que c'est le meilleur!

Ça n'est pas parce qu'il est « moins pratique » qu'il faut cacher les désavantage en contrôle et en souveraineté de ces nouveaux moyens de paiement. Peut-être que ça vaut le coup de perdre ces avantages, mais ça se discute.

Le principe n'est pas du tout de faire un chèque en blanc, c'est de laisser au créditeur l'action de déclencher un virement (un appel de fonds, en quelque sorte). Tu as le contrôle en amont (gestion des listes blanches/listes noires et autorisations de prélèvement) et en aval (8 semaines pour contester un prélèvement). Tous les professionnels sérieux envoient les factures avant de déclencher les prélèvements, ce qui te laisse le temps de gérer les litiges, voire d'anticiper en annulant une autorisation de prélèvement.

OK, merci de le présenter ainsi, ça me permet de me rendre compte qu'on a plus de contrôle que je ne le pensais. Cf. les explications de Renault plus haut également.

Que tu le veuilles ou non, les banques ont décidé qu'il était plus facile et plus rentable de rembourser après coup en cas de (rares) litiges que de sécuriser le système. Exactement pareil que pour la carte bancaire ; la sécurité est douteuse et il y a plein d'arnaques ou de détournements, mais le coût de ces trucs là reste inférieur au coût associé à une réelle sécurisation des moyens de paiement.

Je suis conscient qu'il faut faire des compromis, et qu'ici on troque de la practicité contre une (petite, maintenant que je réalise mieux) perte de contrôle. Il reste l'histoire de choisir la date, qui est pour moi un problème pour les gros montants comme les impôts.

En tout état de cause, de toutes manières, ça n'est pas ton affaire.

Alors là justement, je ne suis pas d'accord : maîtriser ses moyens de paiements, c'est une question qui concerne tous les citoyens. Oui, les banques sont des organismes privés, mais à déléguer de plus en plus la gestion de la monnaie et de nos moyens de paiement, on perd un certain pouvoir tout de même. Alors oui à certains compromis, mais n'empêche que balayer la négociation de ces compromis avec un « ça n'est pas ton affaire », ça n'est pas bien.

Si on t'a pris des sous sans que tu le veuilles, tu annules, et c'est tout. La banque se démerde pour le reste, y compris pour prouver que tu es de mauvaise foi.

Ça ça me va mieux.

Personnellement, même si je suis un peu décontenancé par le principe (c'est un peu le principe de Wikipédia, mais avec ton pognon : tout le monde peut faire ce qu'il veut sur ton compte, mais tu peux réverter dans la foulée),

J'aime bien cette analogie, merci :-)

ça reste une solution élégante et fonctionnelle. En fait, tu n'as jamais eu autant de contrôle sur ton pognon, parce qu'avant, tu pouvais attendre longtemps avant de revoir ton fric en cas d'erreur de prélèvement ou de virement.

Effectivement.

Pour des raisons philosophiques/théoriques, le système te gêne, soit.

Mmhh, je ne suis pas sûr que ça soit si théorique que ça d'avoir le contrôle de quand tu payes. Cependant, expliqué comme tu l'as fait avec des arguments, tu me convaincs un peu que la solution de remplacement n'est pas si désavantageuse.

Mais bon, les arguments pourris, ça ne sert pas ta cause, et à part passer pour un vieux ronchon, je ne vois pas où tu veux en venir. Tu as peur que tout le monde te pique ton fric? Planque-le sous ton matelas, c'est ce que font les petits vieux.

Je n'ai pas tout à fait compris où sont les arguments « pourris », mais si on débat calmement (i.e. pas comme Zenitram), je peux tout à fait discuter des pour et des contres, et accepter quand je suis trop « ronchon » !

Tu m'expliques l'argument? Tu voudrais avoir le droit d'annuler un prélèvement du trésor public alors que tu avais les fonds disponibles (puisque le prélèvement est passé) alors que tu n'avais pas contesté le montant (que tu connais depuis des mois)?

Cf. mon expérience ci-dessus, sur le fait que les impôts me disaient que tu payes ce que tu penses être la bonne somme lors de ta contestation. Je ne sais pas ce qui se passe en cas de prélèvement quand tu contestes, mais c'est toujours dans les situations difficiles que c'est mieux d'avoir le contrôle.

cela te laisse quelques jours voire semaine pour contacter le débiteur avant l'opération pour régler les soucis éventuels.

OK, j'admets.

J'avais un soucis pour payer, j'ai contacté dès le départ les impôts pour signaler le soucis, ils ont accepté un nouvel échéancier et voilà.

OK, intéressant. Mon cas c'était pour payer une somme différente de celle qu'ils me demandaient (j'étais en désaccord avec eux). Ils m'avaient dit que je n'avais qu'à payer la somme que je pensais être la bonne, en même temps que je leur envoyait mon argumentation, et qu'ils feraient avec. Ça c'est bien passé. Je ne sais pas si on peut discuter une somme à prélever, si ça n'est pas pour un problème de solvabilité temporaire. Ton expérience est plutôt positive, ça me donne un peu d'espoir.

Du coup pas besoin de faire intervenir la banque dans la boucle, on a réglé cela avant.

Oui c'est clair que c'est mieux, mais pour moi c'est plus rassurant quand tu contrôle ce qui se passe sur ton compte, en cas de désaccord.

Merci pour les arguments étayés.

Mais… Vraiment, c'est peu. Et… ON S'EN FOUT : c'est prélevé tous les mois, tranquille.

Comme précisé plus haut, je suis au tiers, et c'est à date fixe au tiers également bientôt. Ça représente une somme.

Tu as dit "Putain mais arrête de prendre les gens pour des débiles", faudrait savoir. fait-toi plaisir à cracher sur tout, mais une chose est sûre : le problème n'est pas les autres.

Forcément, ta manière de vivre est la référence, et tout autre être vivant qui aurait choisi des compromis différents du tient mérite d'être insulté. Alors allons-y : pour moi, les personnes qui se basent sur des prélèvements forfaitaires comme toi sont des idiots incapables de gérer leur argent par eux-même et qui préfèrent abandonner leur droit à garder le contrôle de leur solvabilité à d'autres organismes. Ça te fait une belle jambe, hein ?

Hint : frais de gestion.

C'est bien ce que je dis : c'est déjà pris en compte pour ceux qui le font actuellement, et chaque méthode a ses frais. Je ne sais pas si le prélèvement a moins de frais (déjà, il est payant pour les impôts ; peut-être qu'il entraîne moins de frais de gestion du aux erreurs des contribuables après, je ne sais pas), mais il donne clairement plus de contrôle au contribuable.

Quel contrôle (sous entendu utile)?

Heu… le contrôle de à qui tu payes quoi ? Ça te semble assez utile ?… Ça fait partie des droits assez fondamentaux selon moi. J'ai appris par Renault plus haut que c'était plus facile que je le pensais de s'opposer, mais avec les impôts ça marche moins bien. Et il reste que ça n'est plus une décision que te reviens, mais à l'organisme. Pour moi c'est une perte de contrôle sur la gestion de ta solvabilité, qui est faite pour rendre la vie certes « plus facile », mais bien sûr comme toute solution elle a ses avantages et désavantages.

Bon, OK, compris, tu es bloqué dessus sans chercher à comprendre quoi que ce soit, rdv dans quelques années, ça te sera passé et tu auras honte d'avoir râlé.

C'est sûr que c'est toujours aussi agréable de débattre avec toi. Arrête de prendre les gens pour des cons et prends en compte leur réponse au lieu de tout résumer en deux lignes.

J'ai déjà rejeté et révoqué des mandats ou paiements SEPA en ligne, la banque ne demande rien, tu le fais et ça se met en place directement et voilà. Par contre faudra sans doute que tu discutes avec ce créancier à côté. Et tu as 8 semaines pour le faire après le dit paiement pour réagir.

OK, très bien si c'est aussi facile que ça. Ça n'empêche que c'est quand même un peu moins de contrôle que le virement, mais plus que je ne le pensais, c'est vrai. Cependant, ta remarque n'est pas valable pour le paiement des impôts, car je pense que c'est un cas « particulier » où ta banque refusera sûrement d'annuler le prélèvement.

C'est hyper simple et tu as un contrôle immense sur le processus. Et cela t'évite de devoir agir manuellement (tu contrôles et tu agis seulement si cela ne colle pas).

C'est « pratique », mais niveau contrôle je trouve cela quand même moyen. Après, il faut trouver un juste milieu sur contrôle et practicité, et dans certains cas ça peut valoir le coup, mais le généraliser est une erreur, je pense.

Forte volatilité ou pas, ton compte dois avoir les sous avant la date dans les deux cas. Mauvaise excuse.

Putain mais arrête de prendre les gens pour des débiles : dans le premier cas, je sais qu'il faut que je paye avant X jours, et comme je ne connais pas quel sera exactement l'état de mon compte dans ces X jours, je préfère payer tout de suite quelque-chose que je sais que j'ai maintenant sur mon compte, et peut-être pas dans X jours. Je choisis donc la date, et en plus c'est celle où je suis sûr d'être solvable puisque c'est tout de suite quand j'y pense.

La, tout ce que tu dis c'est que si tu vois les sous à J-1, tu vas le dépenser plutôt que d'attendre le prélèvement, mais la le problème n'est pas les impôts, juste la personne incapable de laisser un peu de sous sur son compte.

« Un peu de sous » ? Je ne sais pas si tu as déjà gagné plus qu'un SMIC, mais non, les impôts ça ne représente pas « un peu de sous » : c'est justement pour ça que je peux difficilement laisser cette somme pendant longtemps sur mon compte courant en étant sûr que je l'aurai encore d'ici X jours.

Bref : tu n'as aucun argument sur l'utilité de ce que tu préfères

Nan mais arrête avec le aucun argument : d'après toi le fait que depuis toujours les gens peuvent choisir la date de leur paiement ça n'est pas une indication qu'au moins une partie non-négligeable trouve cela utile ?

Donc quand l'État baisse les charges sur les cotisations patronales, ce n'est pas ton salaire qui est abaissé. Le brut reste inchangé. Le super-brut quant à lui est plus faible.

Donc tu coûtes moins cher à ton employeur, pour la même somme de travail que tu lui a donné, donc une partie de l'argent que gagne l'entreprise aurait pu aller vers payer des services publics, mais elle ira plutôt augmenter le capital. Si tu estimes que les services publics sont aussi le fruit de ton travail, tu as donc perdu une partie du fruit de ton travail.

Le choix, c'est bien… Si c'est utile et pas plus cher. Es-tu prêt à payer plus cher pour ça?

Pourquoi « plus cher » ? C'est déjà inclus dans les coûts actuels. Comme indiqué, je me plains de vouloir faire des économies sur ce moyen, que je trouve plutôt bon. Par contre personne ne parle du coût des solutions de paiements dans des stores proprios, qui ne sont pas des standards, nourrissent des grosses boîtes américaines avec notre argent et nos données personnelles, etc.

Tu vois la chose pas comme prévu, tu rejettes et basta.

Alors je n'ai pas expérimenté depuis SEPA, mais avant les prélèvements c'était toujours un peu sioux de les rejeter. Et même, comme ta banque évalue-t-elle la légitimité de la demande de prélèvement ? C'est cette perte de contrôle que je dénonce avec le « tout prélèvement ». Dans les pays que je cite, tu choisis de payer ou non, c'est un pouvoir autrement plus fort que l'opposition au prélèvement en France. Tu dois bien le savoir, avec ton expérience dans ce pays, non ?

ça rappelle juste les chieurs sur la peur de CB par Internet

Commence pas avec les amalgames à la con… je n'ai jamais parlé de ça.

Tu gères ton argent comme tu veux, que tu fasses le virement à date J-10 ou que tu sois prélevé à la date J ne change rien sur ta gestion

Et bien si. Peut-être pas pour toi, mais tu n'es pas tout le monde et tu n'as pas la science infuse.

(à part si tu n'es pas assez intelligent pour prévoir un retrait, mais bon la on irait loin).

Eh bien OK, disons que je ne suis pas assez intelligent. Est-ce que ça m'empêche de pouvoir payer mes impôts sans perdre le contrôle de mes paiements ? J'ai l'impression que c'est ce vers quoi tu veux arriver, avec ton ton.

A noter que quand l'UI de la banque est bien faite, elle affiche les prélèvements prévus (généralement 5 jours à l'avance) dans les comptes, au cas où on aurait une petite tête.

Ça dépend desquels, et surtout je te trouve optimiste avec les 5 jours, mais ça n'est pas le problème : oui j'ai une très petite tête, et je préfère donc pouvoir payer en avance à ma convenance pour palier à cette histoire de prévision.

Et c'est pas un bon argument pour le faire? Je dirai que si.

Si on estime que c'est une méthode inadaptée ou archaïque, oui. Comme j'ai dit plus haut à un autre interlocuteur, je comprends qu'on veuille supprimer le traitement papier, par exemple. Mais le virement SEPA est une méthode standard, commune à toutes les banques européennes, et a même été inventée pour ces cas de figure ! Quand je vois à côté qu'on peut payer par smartphone, comme j'indique plus haut, je trouve que ça au contraire ce sont des économies qu'on pourrait faire autrement plus facilement. J'aimerais bien avoir des chiffres pour comparer, mais vu comme le virement est caché au fin fond des possibilités de paiement de l'impôt (il faut aller récupérer physiquement l'IBAN de son centre des impôts…) j'ai peur que le virement soit considéré comme trop peu utilisé. Il devrait être mis beaucoup plus en avant, plutôt que des méthodes à la con non-standards sur des machines privatrices de liberté.

Prêt à t'engager à payer le coût du travail supplémentaire que tu demandes?

Mais putain ce coût est déjà pris en compte, je ne demande pas de nouvelles méthodes ! Et est-ce que le virement SEPA favorise plus la fraude ? Fais plus de papier ? Oblige à développer des trucs non-standards ? Non !

Parce que je ne vois pas pourquoi je devrais payer pour toi (on n'est pas dans le social, je n'ai aucun problème pour payer des impôts pour du social mais par contre payer pour faire plaisir à quelques personnes qui ne veulent pas X comme ça, non).

Encore une fois, on parle d'une solution où on donne le contrôle à l'utilisateur, il ne devrait même pas être questions de coût dans ce cas-là, vu que c'est une des dernières méthodes pour l'avoir (en liquide, tu es déjà limité à 300 €). Et je ne vais pas te rabacher les coûts pour les smartphone que je ne souhaite pas payer pour « faire plaisir à quelques personnes »).

Ou alors c'est tout qui fait juste chier les autres.

Je me disais bien que j'avais loupé quelque-chose, ça doit être ça ! Donne moi de vrais arguments contre le virement, on en discutera après, parce là si c'est comme ça je stoppe tout de suite.

Perso je hurle quand c'est l'inverse, quand le SDD n'est pas dispo car souvent ça veut dire "chèque" (donc coût pour tout le monde en gestion), et oui je fais encore des chèques à des organismes étatiques car ils ne sont pas foutus d'accepter un truc plus automatisé.

Et bien milite pour qu'ils acceptent le SCT ! Ça peut aussi bien être manuel qu'automatisé (contrairement au SDD qui est « automatisé » de ton point de vue, vu que tu ne choisis pas la date) et supprime le papier.

Effectivement, le TIP permet un peu de choisir la date. Cependant, contrairement à ce qu'on m'accuse, je souhaite éviter les coûts supplémentaires pour l'état et donc je me disais que continuer à utiliser du papier n'était pas l'idéal. Je pensais que le virement était une solution viable à terme, vu que c'est un standard bancaire européen moderne.

Si je ne me trompes pas en France le paiment des impôts se fait tous les ans au même moment non (septembre) ? Partant de là c'est pas vraiment compliqué de prendre ses dispositions pour éviter ce genre de joyeusetées.

Si je publie ce journal aujourd'hui, c'est qu'après-demain c'est la limite de paiement du premier tiers, pour ceux qui sont au tiers. Donc c'est trois échéances.

Enfin j'sais pas, si vous avez une utilisation très volatile de votre compte principal, faut savoir prendre ses dispositions […]

Bah mon problème, c'est qu'avant, et depuis qu'on prélève des impôts en France, j'avais une possibilité de faire avec la volatilité de mon compte, ce qui n'est plus possible aujourd'hui. Ça n'est pas un petit changement !

Et si vous n'avez pas envie d'être à découvert, demandez à votre banque un compte sans autorisation de découvert pardi.

Heu… ça n'est pas que j'ai « envie » ou pas d'être à découvert, c'est que je n'ai pas envie d'avoir des frais pour pouvoir gérer mon compte comme il me plaît, et donc payer des agios ou avoir un compte sans découvert ça coûte de l'argent… je veux gérer ma solvabilité en contrôlant les dates de mes paiements. C'est comme ça qu'on fait depuis la nuit des temps, avant l'invention des paiements forfaitaires ajustés plus tard, qui sont des instruments bancaires que je trouve personnellement faits pour les personnes qui justement contrôles elles-même mal leur solvabilité.

Enfin, il est toujours possible choisir la date du prélèvement. Si on reprend ce principe d'avoir un compte "salaire" très volatile et un autre compte dédié aux charges fixes à prélèvement automatiques sans autorisation de découvert, le paiement ne pourra se faire qu'au moment où tu alimentes ce compte.

Joli « hack », je trouve. Mais il existait encore la possibilité de simplement avoir le contrôle du virement, et c'est de sa disparition future dont je me plains.

Encore une fois, l'article pense que cette différence n'a pas d'importance, l'auteur de la proposition de nouveau RNG (et aussi l'auteur des pages de manuel Linux) pense que si.

De ce que j'ai compris, Stephan Müller dit que cette propriété de garantir d'avoir assez d'entropie est importante, mais son patch permet que /dev/urandom puisse être seedé avec assez d'entropie au boot, contrairement à l'ancien, et recommande toujours l'utilisation de /dev/urandom comme source d'entropie pour la plupart des usages, même cryptographiques ! Il n'est écrit nulle part dans sa proposition de préférer /dev/random, bien au contraire : il n'a fait que pérenniser ce que préconisent les promoteurs de urandom, comme Arcaik, et de permettre de continuer à se baser dessus, même au boot.

Et si tu veux faire l'ajout pour chaque ligne indistinctement de ce qu'elle contient (de ce que je comprends de la question), il suffit de laisser uniquement le "a…", c-à-d :

sed -i "aligne_supplémentaire_1\nligne_supplémentaire_2\nligne_supplémentaire_3" fichier

Tout le monde n'est pas formable

Ça c'est dommage, même si je peux comprendre certaines raisons. Mais déjà, leur apprendre à ne pas faire plus de mal au réseau que ce qu'il est actuellement, ça serait bien.

(sans parler des cas où il n'y a plus personne à former, et juste un truc dans un coin qui "juste marche" depuis des lustres).

Je ne suis pas pour tout remplacer du jour au lendemain, surtout ce qui marche, bien sûr ! IPv4 et certains NAT resterons encore longtemps. Mais aujourd'hui, beaucoup de choses ne marchent simplement pas. Alors autant les remplacer. Et surtout ne pas reproduire les erreurs du passé : malheureusement, c'est ce qui est en train d'arriver avec les firewalls stateful IPv6 qui sont configurés comme des merdes. D'où le besoin de formation.

Nan mais c'est pas possible que des mecs aient pu inventer ça… Détourner les réponses d'expiration de TTL pour passer en retour à un ping sur une fausse adresse, pour ensuite essayer en random des ports en UDP pour espérer passer à travers le bousin… (j'ai arrêté avant la fin) Sans déconner, comment peut-on vouloir faire marcher un réseau correctement avec ça ?!

Bordel, on s'emmerderait tellement moins si les gens passaient plus de temps à promouvoir des solutions pérennes comme IPv6, et sans les firewall de nazi au milieu.

Ça m'a aussi fait découvrir que c'est cette technique de connexion simultanée qui est utilisée pour passer les NAT avec le « hole punching ».

Heu… en TCP ?! Autant le hole-punching en UDP, ça se comprend un peu, même si c'est crade, mais alors en TCP… je suis allé voir la page wikipédia sur le TCP hole punching, et ça a effectivement l'air d'exister, mais alors niveau crade de chez crade et pas fiable, je ne pense pas qu'on puisse faire mieux. Je ne connais personne qui fait ça en pratique, ni entendu que ça puisse marcher.

Franchement, au lieu d'inventer des nouveaux trucs pas fiables, il vaudrait mieux passer son temps à former les admin réseaux sur comment le pas pourrir Internet, ça serait plus productif.

Coïncidence, j'étais justement en train de lire le RFC793 quand je suis tombé sur ce journal.

Merci pour la référence, c'est effectivement la « suite » des documents que je cite.

C'est rigolo, j'ai justement demandé par mail hier à Stéphane Bortzmeyer si ce cas de connexion simultanée existait en réalité. Je colle sa réponse (je pense qu'il ne m'en voudra pas, même si un mail est censé être privé), qui indique justement que ça peut se produire avec un port source fixe:

Oui, et en fait il faut se remettre en tête le contexte de l'époque : le réseau était beaucoup moins grand, moins dynamique, les processus aussi, et on mettait alors en place des « associations » entre processus sur des machines distantes en fixant statiquement certains paramètres. Ainsi, on pouvait éventuellement fixer complètement une association en y mettant les adresses locales et distantes, ainsi que les ports. Une association est alors ouverte (la commande OPEN de l'API de l'époque, décrit dans le 2.7 de ta RFC 793). Ce qui déclenche la synchronisation de numéro de séquence est l'activation de la socket, soit en l'indiquant explicitement, soit à l'époque également à l'envoi de données (c.f. 2.4.1 de l'IEN 21).

C'est une chose qui n'est pas tout à fait reflétée dans l'API des socket d'aujourd'hui : on ne peut pas (à ma connaissance) fixer d'adresse et le port d'une socket distante avec cette API en TCP sans l'activer immédiatement. En UDP, on peut tout à fait faire un ''connect'' (oui, ça peut sembler étrange pour un protocole « non-connecté ») pour les fixer à l'avance, si on n'accepte que les connexions d'un processus sur un nœud précis du réseau, et cela ne générera absolument aucun trafic.

Je ne connaissais par contre pas l'utilisation historique de ce genre de chose dans le DNS ou BGP : merci à Stéphane, donc.

Et tu donnes dans ce billet un exemple concret. Merci, ça tombe très bien :)

Exemple concret mais d'une utitilée très limitée quand même… Il sert quand même à réfléchir aux principes qui sous-tendent TCP. De rien :-)

Mmmhh, je ne suis pas tout à fait d'accord avec cette analogie : un descripteur de fichier est valable dans un contexte particulier, qui est celui d'un processus.

Je ferais plutôt l'analogie avec le nom d'un fichier, qui n'est valable que dans le contexte d'une machine mais est au moins le même pour tous les processus. Ici, on l'étendrait à l'ensemble du réseau : l'ensemble d'un hôte (adressé par nom ou par adresse) et d'un port (dont il existe un forme textuelle dans la base correspondante de l'IANA) forme le « nom » d'un processus sur le réseau. On retrouve cette terminologie dans l'API des sockets avec getsockname et getpeername, qui retournent respectivement l'ensemble adresse + port de l'hôte local ou distant. Ces ensembles ont une signification globale et non particulière à un contexte : en tout point du réseau, ce « nom » de processus l'identifie clairement.

J'insiste sur la signification globale de l'identifiant, car c'est le point central d'Internet : il n'y a pas d'état dans le réseau, et donc pas besoin de synchronisation au cœur du réseau, ce qui simplifie énormément le coût d'opération de celui-ci. L'intelligence est aux extrémités, qui gèrent leur synchronisation eux-même, en utilisant des identifiants globaux.

Bien sûr, ces principes sont cassés quand on n'utilise pas d'adresse globale, et la complexité de fonctionnement du réseau augmente exponentiellement, mais ça n'est pas nouveau. C'est juste que personne n'ose mesurer le coût de fonctionnement d'une telle architecture.

Voilà quand on lit trop vite le document : ici, c'est plutôt à la forme infinitive qu'il faut voir la synchronisation, car il est écrit que SYN permet de « SYNchroniser ».

reStructuredText ? De mémoire, j'ai déjà utilisé des liens dans ces trois formats, et ça marche.