benoar a écrit 4240 commentaires

Dire que les conteneurs ça ne scale pas j ai un peu du mal avec ça, suffit de voir les démos hyperscale de mesos pour être convaincu du contraire.

Mais à quoi ça sert de mesurer le nombre de containers que tu peux faire tourner ? Dire qu'on peut mettre 1000 apache sur une machine est une prouesse qui sert à quoi ? Sans containers, tes applis marcheraient aussi bien, voire plus vite, mais personne n'a jamais pensé à faire sa pub sur combien d'applis il pouvait faire tourner sur une machine… Ce que je dis, c'est que les containers c'est souvent coupler l'appli, l'admin, et le réseau, et ça c'est mauvais pour scaler.

Je sais pas comment on fait des conteneurs chez toi mais perso je trouve ça propre et les développeurs gèrent pas le réseau,

Alors ça m'intéresse de savoir comment « ils ne gèrent pas le réseau » : dans la plupart des cas d'utilisation que j'ai vu, les développeurs codent en dur des confs réseau et des paramètres de leurs socket, pour que ton framework de container fasse une traduction (ou une autre forme de configuration indirecte). C'est un état intermédiaire inutile, sujet à bugs, problèmes de fiabilité, etc.

ni la collecte des logs d ailleurs (12 factor apps),

Je ne connais pas, mais qu'est-ce que ça apporte face à syslog ?

après on est d accord qu il sa faut des gens compétents qui gèrent la platerforme.

En effet.

Docker et ipv6 c est des sujets complètement orthogonaux pour moi.

Théoriquement, oui. Je vois juste que les devs qui utilisent le réseau comptent sur son infra de NAT pour corriger leur méconnaissance de l'archi du net. Peut-être qu'en IPv6 ça va changer, mais j'ai quand-même vu des gens promouvoir le NAT IPv6 avec Docker, et ça me fait peur. Tant que les devs ne seront pas sensibilisés à l'architecture d'Internet, on aura des horreurs comme ça, même si en théorie ça doit être orthogonal.

La non migration d ipv4 à ipv6 n est en aucun cas lié au vm mais au fait que on a pas pensé la transition, par exemple combien de temps entre le début des normes ipv6 et les premiers tunelles 6 to 4?

Pardon ? 6to4 (RFC 3056 https://tools.ietf.org/html/rfc3056 ; déprécié, attention !) est apparu en 2001, moins de trois ans après IPv6 (RFC 2460 https://tools.ietf.org/html/rfc2460 en 1998). Il existe pléthore de mécanismes de transition, mais ça n'est pas le problème : chez les devs, très peu de gens se préoccupent de l'abstraction de la famille sur les sockets, et c'est LE problème qui casse tout à chaque fois. Encore une fois, il y a deux catégories de problèmes, et il ne faut pas les mélanger : les histoires d'infra (admin système et réseau), et les histoires d'architecture logicielle (pour les devs). Pour les premiers, comme je disais, il existe plein de solutions différentes. Mais c'est chez les seconds qu'il y a de grosses lacunes. Le problème est qu'on est venu palier ces problèmes chez les devs avec des archis complexes de VMs et containers, qui en plus mélangent les problèmes de déploiements et administration (i.e. les premiers, qu'on devait séparer) ! C'est une erreur qui nous coûte très cher, car on n'est pas près de passer ces archis à IPv6, selon moi.

T'a perdu ton boulot à cause d'un devops pour être aussi négatif ?

Ah non, au contraire, ça me fait plein de boulot en plus, qu'on aurait pu éviter si les devops savaient bosser un peu mieux…

Oui les VM (afin les première version des outils de chez VMware) ne géré que du L2 et on a crée des énormes réseau L2 avec tout les problèmes que ça a amenés mais ce temps la est révolu.

Heu… et ça c'est quoi ? https://tools.ietf.org/html/rfc7348 (peut-être que tu considère ça vieux, je ne connais pas ton échelle de temps) On a ensuite réinventé la mobilité niveau L2 alors que c'était ce qu'apportait IPv6 en mieux, on a maintenant le problème des tables trop grosses donc on va partitionner, comme… du routage ! J'avais vu il y a quelques années un ingé de chez Gandi proposer de l'interconnexion de L2 (avec TRILL et compagnie) pour créer un grand réseau mondial !! Allo, NIH ?

Un DevOps "compétant" il te fait du L3 avec du iBGP pour le routage maintenant (et depuis quelque temps déjà).

J'aimerais bien en voir… ou pas, parce qu'un dev en général il connaît mal le réseau, ou pire, il croit le connaître bien… Mais le problème ça n'est pas que le dev, c'est toute l'infrastructure autour qui est en train de se complexifier à mort, et qui va lui donner raison d'avoir choisi du container complexe.

Après toute migration IPv4 -> IPv6 est compliquée, beaucoup de gens croit que c'est juste la taille des IP qui a grossie mais c'est quasiment tout qui change, y a beaucoup de chose a réapprendre (ARP -> NDP, les multiples configuration possible entre RA et DHCPv6 etc…).

Oui bien sûr, c'est plus compliqué que juste la taille. Les problèmes que tu cites sont par contre liés à l'administration du réseau et des machines, et ne devraient pas concerner les devs. Ils auraient théoriquement dû uniquement adapter leur code aux sockets indépendantes de la famille d'adresse (je ne dis pas que c'est facile, hein, mais peu de monde s'en préoccupe).

Ce qui me chagrine, c'est que depuis plusieurs années on a fait une migration d'IPv4 vers une « autre couche » non-standardisée au niveau des développeurs, au lieu de migrer vers une architecture IPv6 (avec des sockets simples), et comme plein d'argent a été mis dedans, on ne va pas vouloir la changer de si tôt ! Et rien n'a été appliqué de l'architecture d'Internet telle qu'elle a été définit (mais sûrement mal expliquée, vu que tout le monde martèle l'histoire de taille d'adresse uniquement). Ce qu'il faudrait enseigner, c'est la version technique du « Minitel 2.0 », et faire comprendre que gérer des VMs/containers ça scale pas, et que c'est juste une nouvelle couche pour devenir l'abstraction proprio (ou presque) de référence au détriment des technologies standard de l'Internet.

Mais en fait je me rends compte qu'à chaque fois que j'en parle, personne ne comprend… s'ils y en a qui voient un peu ce que je veux dire, qu'ils lèvent la main !

En fait, le commentaire est un peu approximatif. Les VMs/conteneurs sont arrivés pour répondre à un besoin

Besoin que je ne comprends toujours pas vraiment ; enfin, je vois bien les avantages, mais les désavantages qu'on aime bien cacher sous le tapis sont toujours trop grands pour moi.

mais ne changent pas spécialement la façon dont ça se connecte. Ça reste des équipements virtuels nécessitant des IPs.

Oui, mais la question est dans la gestion de la complexité de ton routage, et le découplage du réseau de l'application. Faire « de l'IP », c'est simple : c'est un des protocoles réseau les plus bêtes. Comprendre et bien utiliser l'architecture d'Internet, c'est une tout autre histoire. Quand les personnes qui font du Docker voudront automatiser la configuration réseau de leurs containers, ils vont réinventer DHCPv6, ça nous fera une belle jambe.

Là où benoar a raison, c'est la gestion du réseau y'a 2-3 ans dans Docker où c'était effectivement codé assez bizarrement de façon hard-codée dans tous les sens. Mais c'était de l'alpha.

Effectivement, c'est ce que j'avais vu à l'époque. Je n'ai pas trop regardé depuis, mais de ce que je lis ça n'est pas la folie non plus.

ça fait 2 ans que Docker fait de l'IPv6.

Ma critique va dans le sens où ça n'avance pas à grand chose de « faire de l'IPv6 », quand on n'utilise pas l'architecture logicielle de l'Internet : ton « unité » de base reste le container, avec ses API spécifiques. L'API de l'Internet, c'est les socket, et normalement une application a « juste » à gérer son socket pour pouvoir communiquer avec le reste du monde. De son côté, l'admin sys/réseau configure son OS et ses routeurs.

Ici, avec Docker, on a réinventé une nouvelle abstraction, avec son API, etc. Ceux qui savaient comment administrer un OS doivent tout réadapter avec cette nouvelle couche. Alors, pourquoi pas passer vers une nouvelle techno si elle t'apporte des bénéfices, mais perso je vois juste Docker comme un système de packaging qui s'abstrait de la distribution, avec plus de rigidité en échange d'une meilleure reproductibilité. Mais ça amène tout son lot de trucs chiants avec. En particulier pour les admin sys/réseau, je pense que c'est une grosse usine à gaz qui ne leur apporte pas vraiment grand chose.

En fait, Internet est une architecture logicielle qui est tellement plus que ce qu'on l'imagine : c'est comment découpler l'architecture du réseau des applications qui tournent dessus. L'intelligence est aux extrémités (dans les applications), découplée du fonctionnement du réseau (le routage), qui est très bête. Les VMs ou les containers, c'est ramener du couplage sous les applications, et ramener de l'état dans le réseau, à gérer, synchroniser, etc, et ça c'est très compliqué et peu fiable. Je suis quasiment sûr que ces couches ramènes des problématiques de circuit par connexion (avec du conntrack, voire pire, du NAT), et ça personne n'a l'air de comprendre pourquoi c'est mal même si on a la démonstration depuis des dizaines d'années par les telcos que ça scale pas (c'est pas pour rien que les propositions d'amélioration de MPLS vont vers moins d'état dans le cœur du réseau… ils réinventent Internet 40 ans plus tard, mais bon, on n'est pas à une réinvention de la roue près).

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.