Peut-être que c'est une question piège ? Il faudrait idéalement répondre que c'est une très mauvaise idée du point de vue sécurité d'essayer de réimplémenter un générateur pseudo-aléatoire quand on n'est pas un spécialiste hyper-pointu du domaine.
les suggestions de recherche sont activées par défaut pour les utilisateurs qui ne les ont pas désactivées explicitement (passage de opt-in à opt-out)
Alors ça c'est la modification qui me troue le plus le cul : je trouvais pas mal le comportement de demander à l'utilisateur lors de la première recherche dans la barre de navigation (elles étaient déjà actives pour la barre de recherche ; je ne l'utilise personnellement jamais) s'il veut activer l'auto-complétion ou non. C'était une des protections essentielles de la vie privée que je voyais encore active dans Firefox (et ça a l'air d'être encore vaguement dans leurs priorités vu que plus loin dans la dépêche ils semblent vouloir « protéger un peu mieux la confidentialité des données utilisateurs »).
Je vois bien que les priorités de Mozilla sur la vie privée changent un petit peu à chaque version, depuis longtemps, et qu'ils le font façon « fable de la grenouille », mais ça devient de plus en plus insupportable.
Sur PowerPC les différentes variantes du shift (comme le rotate, si on peut vraiment le considérer comme tel) sont synthétisées par une seule instruction « rlwirm » — dans la grande tradition du RISC — qui est juste paramétrée différemment. Cf. le Programming Environments Manual, dont le tableau F.4.2 trouvable ici http://www.csit-sun.pub.ro/~cpop/Documentatie_SMP/Motorola_PowerPC/PowerPc/GenInfo/pemappF.pdf résume bien la génialité de la chose : on pourrait presque imaginer, en regardant par exemple les tableaux détaillant le codage consécutif des instructions ici http://www.nxp.com/assets/documents/data/en/reference-manuals/MPCFPE32B.pdf, le câblage du CPU devant ses yeux (juste un bit change pour un paramètre différent qu'on retrouve dans plein d'instructions similaires, de manière à minimiser le coût en transistors).
Malheureusement, ça n'est pas exploitable directement en C, et le compilateur doit en déduire des manipulations d'entier si l'instruction unique est émissible.
Bon, ça c'était l'instruction avec une valeur de shift immédiate, mais il existe aussi les version indexées par un registre.
Et pour revenir au journal, arithmétique modulo ou pas, rotate ou shift, tout est géré par cette instruction magique comme vous le souhaitez : il n'y a pas un choix plus « logique » que l'autre.
le mandat de prélèvement est dorénavant le moyen standard pour transférer de l'argent entre un organisme ou entreprise et un particulier, et c'est le seul moyen qui permette un traitement automatisé des payements (sans envois de bouts de papier qui, de toutes façons, n'assurent aucune sécurité supplémentaire).
C'est complètement faux par rapport au journal que j'avais posté : le virement SEPA est également un moyen très standard de régler des dettes en Europe. C'est utilisé dans tous les autres pays, sauf la France… Comme tu précises plus bas, c'est peut-être « source d'erreur » pour l'état, mais pour le citoyen c'est un pouvoir de négociation non-négligeable qui lui permet de choisir si la demande de règlement est légitime ou non. Et ça ça n'est pas négligeable du tout : on inverse complètement le rapport de force qui existait jusqu'à présent.
Il y aurait peut-être un effort de normalisation à faire de la part des banques sur la référence du paiement, mais ça c'est un peu dû à l'incompétence des banques qui n'ont même pas été foutues d'avoir un format commun de référence SEPA à foutre dans les credit transfer/direct debit.
Moi ça fait des années que j'ai un setup avec un modem ADSL sur le même réseau que le LAN, et ça marche très bien. OpenWrt sait gérer ce genre de setup depuis bien longtemps.
Je n'ai pas le routeur sous la main, mais en gros, tu as ton LAN appelé « lan », et tu indique que ta connexion WAN en PPPoE passe également par ce réseau « lan ». Comme ça, hop, un modem avec un seul Ethernet, un routeur pareil, un gros switch au milieu, et tout roule.
Je ne comprends pas que tant de monde ait des problèmes avec des routeurs à un seul port Ethernet, même si je peux comprendre qu'au premier abord, un routeur avec seulement une prise Ethernet ça peut paraître étrange.
Ta question m'a intriguée, chez moi ça marche. En fait, c'est le nouveau format de fingerprint de ssh. Pour avoir l'ancien, en md5, il faut faire (avec la nouvelle version de ssh-keygen, que je n'ai pas en Debian stable) :
ssh-keygen -E md5 -lf ~/.ssh/id_rsa.pub Cf. http://stackoverflow.com/questions/9607295/how-do-i-find-my-rsa-key-fingerprint
Récupérer ses programmes ouverts peut-être éventuellement ?
« Éventuellement » ? Pour moi c'est absolument indispensable ! J'utilise le suspend-to-ram et l'hibernation à fond, et ces fonctionnalités sont tout bonnement indispensables pour une utilisation correcte de mes machines.
Regardez comme Apple a même supprimé la modalité « d'alimentation » de sa machine : elles sont toujours allumées, vous ne pouvez même plus vraiment les « éteindre », et vous retrouvez toujours tous vos programmes disponibles sans avoir à les démarrer… C'est vraiment très bien fait !
J'ai l'impression de le répéter souvent : le swap est au contraire toujours très utile quand tu utilises beaucoup de programmes. Ton kernel va pouvoir mettre « de côté » certains programmes (sur le swap) pendant qu'il utilise plus de RAM pour un autre, que ça soit en mémoire allouée ou en cache disque. Sans swap, il devrait garder tous les programmes en RAM tout le temps, même ceux qui sont actuellement inutilisés. Vois ça comme une sorte « d'hibernation » pour programme peu utilisé.
Pour aller encore plus loin, idéalement, le swap permettrait de supprimer la modalité « programme chargé ou pas ». Dans l'idéal, on n'aurait pas à savoir si on doit « démarrer » un programme ou pas, il aurait un état « permanent » qu'on (enfin, le kernel) chargerait comme il veut. Allez voir le checkpoint/restore pour voir ce que ça donne quand on étend le principe du swap à un état partitionnable et transférable entre machines (le swap ça serait un état propre à une seule machine).
Notez aussi qu'il existe aussi déjà un « swap implicite » avec le mapping à la demande des programmes et bibliothèques présents sur le disque. Bref, le swap c'est utilisez à fond le principe de mémoire virtuelle, qui a été inventé il y a longtemps mais que j'ai l'impression les jeunes générations n'apprennent plus…
Je ne l'utilise plus mais mon téléphone SIP Siemens marchait très bien derrière un NAT ipv4. Je crois qu'il utilisait STUN pour cela mais quoiqu'il en soit c'est possible. Le fait que le NAT est utilisé par défaut depuis 2 décennies pour l'acès internet des réseau domestique fait qu'on a depuis mis en place toute sorte de méthodes et que ça n'en fait pas un accès [i]minitel[/i].
Je pense que ton téléphone ne marchera plus aussi bien aujourd'hui, et ne marchera plus dans le futur, à cause des « CGN » et autres conneries pour minitéliser Internet. C'est le problème d'IPv4 : ça va marcher de moins en moins bien ; enfin, pour les protocoles qui exploitent vraiment l'architecture d'Internet. Pour consulter FB, forcément, oui, ça marchera toujours… Mais la non mise en place d'IPv6 va finir de tuer ces usages décentralisés.
Pour tes arguments sur la non-migration, bien sûr qu'ils sont valides et comptent aussi, mais le miens sur « l'ouverture » que permet IPv6 n'est pas anodin non plus, et prend de plus en plus d'importance au fur et à mesure que les premiers deviennent de moins en moins valable.
En général, derrière un NAT, on a accès à tout Internet…
Tu as accès au Minitel, oui, mais tu ne fais pas partie d'Internet. Donc tu n'auras pas de téléphone SIP qui marche (ton FAI se garde de la concurrence ainsi), tu ne pourras pas t'autohéberger facilement, tu ne pourras pas avoir de service de télévision multicastée (ton FAI te « l'offre », pourquoi aller voir ailleurs ?), etc.
Et en l'occurrence, concernant Linuxfr ou les VPS OVH, je ne vois même pas où est censé être ce « NAT protecteur ». Ce n'est pas parce qu'un hébergeur ne fournit pas IPv6 que l'IPv4 du serveur est NATtée.
Je pensais qu'on parlait des FAI pour le grand public, quand tu disais qu'ils étaient à la bourre sur IPv6. Je parlais du NAT sur le grand public, donc.
Tu ne serais pas en train de chercher à inventer des coupables ? Je n'ai jamais vu d'applications qui serait écrites en imposant à l'utilisateur d'être derrière un NAT.
Je n'ai pas dit ça. Je dis au contraire que les applications actuelles sont souvent codées pour s'accommoder du NAT, du coup les opérateurs les utilisent comme excuse pour ne pas proposer IPv6. En oubliant de parler des problèmes pour les applications qui tirent profit complètement de l'architecture d'Internet : SIP, P2P, etc.
Oui, enfin franchement, j'ai l'impression que tu as rencontré un jour dans ta vie un cas de framework mal codé, et que tu extrapoles à la Terre entière parce que ça t'arrange de croire que tous les autres codent comme des gorets alors que toi, tu as tout compris.
Je ne dis pas que « j'ai » tout compris, ça vient de l'IETF. Les applis étaient relativement bien codées jusqu'à maintenant, c'est juste qu'on vient mettre une couche avec les containeurs qui casse souvent ces applications. C'est cette régression que je déplore.
Franchement, je n'ai pas l'impression que les services logiciels les plus répandus ne soient pas compatibles IPv6.
Les services « les plus répandus », oui, mais ceux qui créent des services au-dessus et qui cassent tout en les utilisant mal…
Par contre, des opérateurs ou des fournisseurs d'accès qui ne fournissent pas de connectivité IPv6 correcte, ça existe encore
Oui ça c'est vrai que c'est l'autre gros point noir ; je m'y était juste tellement habitué que je n'y fais plus gaffe. Mais ça n'est pas près d'arriver, vu que c'est pour des raisons commerciales : offrir de l'IPv6, c'est ouvrir le marché de se abonnés captifs derrière leur NAT « protecteur »…
Je me doute bien qu'il y a quelques bouts de code de-ci de-là qui ne connaissent que AF_INET, mais ce n'est pas le problème dominant.
C'est le problème dominant de la couche « service » uniquement, mais ça n'est pas rien. C'est également une des excuses des opérateurs : les applications « n'en ont pas besoin », vu que tout est codé pour s'abstraire d'IP à cause des NAT et de réinventer des couches d'abstraction usine à gaz en-dessous.
Corrigeons : très peu de gens se soucient de l'API socket parce qu'ils développent des services réseaux à un plus haut niveau, en se basant sur un canevas logiciel ou au minimum une couche d'abstraction existante. On est en 2017…
Oui, mais souvent ils l'utilisent mal… Par exemple, au-delà des sockets pur, savoir utiliser getaddrinfo() : tu vas me dire que c'est abstrait par les framework, mais non, souvent soit ils ne l'utilisent pas, soient ils l'utilisent mal ; on doit normalement itérer sur les résultats pour jauger la connectivité, pour des raisons de transition, de répartition, et de disponibilité. Encore une fois, ces frameworks veulent souvent abstraire ça et rajouter un couche, et foutent la grouille parce qu'ils n'ont pas compris que seule l'application elle-même peut prendre des décisions sur le choix des destinations en fonction de leur atteignabilité.
Malheureusement, j'ai rarement (voire jamais) vu une bonne séparation des rôles comme tu le prônes en pratique. C'est dans quel genre de boîte que tu vois ça ?
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.
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 ?
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.
# Question piège ?
Posté par benoar . En réponse au message Implémentation de /dev/random. Évalué à 7.
Peut-être que c'est une question piège ? Il faudrait idéalement répondre que c'est une très mauvaise idée du point de vue sécurité d'essayer de réimplémenter un générateur pseudo-aléatoire quand on n'est pas un spécialiste hyper-pointu du domaine.
# La suggestion de recherche activée par défaut ça améliore la confidentialité ?
Posté par benoar . En réponse à la dépêche Firefox 55 est prêt pour la rentrée 2017. Évalué à 6.
Alors ça c'est la modification qui me troue le plus le cul : je trouvais pas mal le comportement de demander à l'utilisateur lors de la première recherche dans la barre de navigation (elles étaient déjà actives pour la barre de recherche ; je ne l'utilise personnellement jamais) s'il veut activer l'auto-complétion ou non. C'était une des protections essentielles de la vie privée que je voyais encore active dans Firefox (et ça a l'air d'être encore vaguement dans leurs priorités vu que plus loin dans la dépêche ils semblent vouloir « protéger un peu mieux la confidentialité des données utilisateurs »).
Je vois bien que les priorités de Mozilla sur la vie privée changent un petit peu à chaque version, depuis longtemps, et qu'ils le font façon « fable de la grenouille », mais ça devient de plus en plus insupportable.
[^] # Re: Un utilisateur OCaml sous PowerPC
Posté par benoar . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 3.
[Hors Sujet, un peu]
Sur PowerPC les différentes variantes du shift (comme le rotate, si on peut vraiment le considérer comme tel) sont synthétisées par une seule instruction « rlwirm » — dans la grande tradition du RISC — qui est juste paramétrée différemment. Cf. le Programming Environments Manual, dont le tableau F.4.2 trouvable ici http://www.csit-sun.pub.ro/~cpop/Documentatie_SMP/Motorola_PowerPC/PowerPc/GenInfo/pemappF.pdf résume bien la génialité de la chose : on pourrait presque imaginer, en regardant par exemple les tableaux détaillant le codage consécutif des instructions ici http://www.nxp.com/assets/documents/data/en/reference-manuals/MPCFPE32B.pdf, le câblage du CPU devant ses yeux (juste un bit change pour un paramètre différent qu'on retrouve dans plein d'instructions similaires, de manière à minimiser le coût en transistors).
Malheureusement, ça n'est pas exploitable directement en C, et le compilateur doit en déduire des manipulations d'entier si l'instruction unique est émissible.
Bon, ça c'était l'instruction avec une valeur de shift immédiate, mais il existe aussi les version indexées par un registre.
Et pour revenir au journal, arithmétique modulo ou pas, rotate ou shift, tout est géré par cette instruction magique comme vous le souhaitez : il n'y a pas un choix plus « logique » que l'autre.
[^] # Re: Déja discuté
Posté par benoar . En réponse au journal Comment se faire forcer la main par les impôts. Évalué à 2.
C'est complètement faux par rapport au journal que j'avais posté : le virement SEPA est également un moyen très standard de régler des dettes en Europe. C'est utilisé dans tous les autres pays, sauf la France… Comme tu précises plus bas, c'est peut-être « source d'erreur » pour l'état, mais pour le citoyen c'est un pouvoir de négociation non-négligeable qui lui permet de choisir si la demande de règlement est légitime ou non. Et ça ça n'est pas négligeable du tout : on inverse complètement le rapport de force qui existait jusqu'à présent.
Il y aurait peut-être un effort de normalisation à faire de la part des banques sur la référence du paiement, mais ça c'est un peu dû à l'incompétence des banques qui n'ont même pas été foutues d'avoir un format commun de référence SEPA à foutre dans les credit transfer/direct debit.
[^] # Re: La Brique
Posté par benoar . En réponse au message Routeur pour VPN@Home. Évalué à 4.
Moi ça fait des années que j'ai un setup avec un modem ADSL sur le même réseau que le LAN, et ça marche très bien. OpenWrt sait gérer ce genre de setup depuis bien longtemps.
Je n'ai pas le routeur sous la main, mais en gros, tu as ton LAN appelé « lan », et tu indique que ta connexion WAN en PPPoE passe également par ce réseau « lan ». Comme ça, hop, un modem avec un seul Ethernet, un routeur pareil, un gros switch au milieu, et tout roule.
Je ne comprends pas que tant de monde ait des problèmes avec des routeurs à un seul port Ethernet, même si je peux comprendre qu'au premier abord, un routeur avec seulement une prise Ethernet ça peut paraître étrange.
# Nouveau format
Posté par benoar . En réponse au message Comment retrouver une clé SSH à partir de son empreinte ?. Évalué à 10.
Ta question m'a intriguée, chez moi ça marche. En fait, c'est le nouveau format de fingerprint de ssh. Pour avoir l'ancien, en md5, il faut faire (avec la nouvelle version de ssh-keygen, que je n'ai pas en Debian stable) :
ssh-keygen -E md5 -lf ~/.ssh/id_rsa.pub
[^] # Re: Le swap ?
Posté par benoar . En réponse au journal Du bon partitionnement entre un SSD et un HDD . Évalué à 5.
« Éventuellement » ? Pour moi c'est absolument indispensable ! J'utilise le suspend-to-ram et l'hibernation à fond, et ces fonctionnalités sont tout bonnement indispensables pour une utilisation correcte de mes machines.
Regardez comme Apple a même supprimé la modalité « d'alimentation » de sa machine : elles sont toujours allumées, vous ne pouvez même plus vraiment les « éteindre », et vous retrouvez toujours tous vos programmes disponibles sans avoir à les démarrer… C'est vraiment très bien fait !
[^] # Re: Le swap ?
Posté par benoar . En réponse au journal Du bon partitionnement entre un SSD et un HDD . Évalué à 7.
J'ai l'impression de le répéter souvent : le swap est au contraire toujours très utile quand tu utilises beaucoup de programmes. Ton kernel va pouvoir mettre « de côté » certains programmes (sur le swap) pendant qu'il utilise plus de RAM pour un autre, que ça soit en mémoire allouée ou en cache disque. Sans swap, il devrait garder tous les programmes en RAM tout le temps, même ceux qui sont actuellement inutilisés. Vois ça comme une sorte « d'hibernation » pour programme peu utilisé.
Pour aller encore plus loin, idéalement, le swap permettrait de supprimer la modalité « programme chargé ou pas ». Dans l'idéal, on n'aurait pas à savoir si on doit « démarrer » un programme ou pas, il aurait un état « permanent » qu'on (enfin, le kernel) chargerait comme il veut. Allez voir le checkpoint/restore pour voir ce que ça donne quand on étend le principe du swap à un état partitionnable et transférable entre machines (le swap ça serait un état propre à une seule machine).
Notez aussi qu'il existe aussi déjà un « swap implicite » avec le mapping à la demande des programmes et bibliothèques présents sur le disque. Bref, le swap c'est utilisez à fond le principe de mémoire virtuelle, qui a été inventé il y a longtemps mais que j'ai l'impression les jeunes générations n'apprennent plus…
[^] # Re: Pinaillage
Posté par benoar . En réponse à la dépêche La voiture en open source. Évalué à 2.
C'est une parodie de la vidéo « bien connue » (pas pour les français…) effectivement. Et une autre très bonne : https://www.youtube.com/watch?v=xuxO6CZptck.
[^] # Re: 2FA
Posté par benoar . En réponse au journal Sécurité et authentification des sites bancaires.. Évalué à 4.
C'est également le cas pour les particuliers, et depuis un bout de temps.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 2.
Je pense que ton téléphone ne marchera plus aussi bien aujourd'hui, et ne marchera plus dans le futur, à cause des « CGN » et autres conneries pour minitéliser Internet. C'est le problème d'IPv4 : ça va marcher de moins en moins bien ; enfin, pour les protocoles qui exploitent vraiment l'architecture d'Internet. Pour consulter FB, forcément, oui, ça marchera toujours… Mais la non mise en place d'IPv6 va finir de tuer ces usages décentralisés.
Pour tes arguments sur la non-migration, bien sûr qu'ils sont valides et comptent aussi, mais le miens sur « l'ouverture » que permet IPv6 n'est pas anodin non plus, et prend de plus en plus d'importance au fur et à mesure que les premiers deviennent de moins en moins valable.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 4.
Tu as accès au Minitel, oui, mais tu ne fais pas partie d'Internet. Donc tu n'auras pas de téléphone SIP qui marche (ton FAI se garde de la concurrence ainsi), tu ne pourras pas t'autohéberger facilement, tu ne pourras pas avoir de service de télévision multicastée (ton FAI te « l'offre », pourquoi aller voir ailleurs ?), etc.
Je pensais qu'on parlait des FAI pour le grand public, quand tu disais qu'ils étaient à la bourre sur IPv6. Je parlais du NAT sur le grand public, donc.
Je n'ai pas dit ça. Je dis au contraire que les applications actuelles sont souvent codées pour s'accommoder du NAT, du coup les opérateurs les utilisent comme excuse pour ne pas proposer IPv6. En oubliant de parler des problèmes pour les applications qui tirent profit complètement de l'architecture d'Internet : SIP, P2P, etc.
Je ne dis pas que « j'ai » tout compris, ça vient de l'IETF. Les applis étaient relativement bien codées jusqu'à maintenant, c'est juste qu'on vient mettre une couche avec les containeurs qui casse souvent ces applications. C'est cette régression que je déplore.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à -2.
Les services « les plus répandus », oui, mais ceux qui créent des services au-dessus et qui cassent tout en les utilisant mal…
Oui ça c'est vrai que c'est l'autre gros point noir ; je m'y était juste tellement habitué que je n'y fais plus gaffe. Mais ça n'est pas près d'arriver, vu que c'est pour des raisons commerciales : offrir de l'IPv6, c'est ouvrir le marché de se abonnés captifs derrière leur NAT « protecteur »…
C'est le problème dominant de la couche « service » uniquement, mais ça n'est pas rien. C'est également une des excuses des opérateurs : les applications « n'en ont pas besoin », vu que tout est codé pour s'abstraire d'IP à cause des NAT et de réinventer des couches d'abstraction usine à gaz en-dessous.
Oui, mais souvent ils l'utilisent mal… Par exemple, au-delà des sockets pur, savoir utiliser getaddrinfo() : tu vas me dire que c'est abstrait par les framework, mais non, souvent soit ils ne l'utilisent pas, soient ils l'utilisent mal ; on doit normalement itérer sur les résultats pour jauger la connectivité, pour des raisons de transition, de répartition, et de disponibilité. Encore une fois, ces frameworks veulent souvent abstraire ça et rajouter un couche, et foutent la grouille parce qu'ils n'ont pas compris que seule l'application elle-même peut prendre des décisions sur le choix des destinations en fonction de leur atteignabilité.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 3.
Malheureusement, j'ai rarement (voire jamais) vu une bonne séparation des rôles comme tu le prônes en pratique. C'est dans quel genre de boîte que tu vois ça ?
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 5.
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.
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.
Je ne connais pas, mais qu'est-ce que ça apporte face à syslog ?
En effet.
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.
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.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 6.
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…
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 ?
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.
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 !
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 3.
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.
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.
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.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 1.
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).
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 3.
Ah, en fait j'ai même pas lu les commentaires, je l'ai fait de mémoire /o\
Ouai donc ya quand même un peu de code à faire… :-)
Ç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 ?…
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 ?
Oui, c'est sûr.
# Microsoft Allemagne vient de déménager à Münich
Posté par benoar . En réponse au journal [Marque‐page] Réaction de la Document Foundation à la décision de Munich de repasser sous Windows. Évalué à 10.
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 /.)
# Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 5.
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é.
[^] # Re: Fake information
Posté par benoar . En réponse au journal Payer ses impôts en choisissant la date. Évalué à 1.
Merci pour ce bel exemple de novlangue.
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.
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.
Arrête de lire sélectivement, tu as omis tous les arguments qui ne t'arrangeaient pas.
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.
[^] # Re: Fake information
Posté par benoar . En réponse au journal Payer ses impôts en choisissant la date. Évalué à 1.
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é.
Ç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.
[^] # Re: Et?
Posté par benoar . En réponse au journal Payer ses impôts en choisissant la date. Évalué à 2.
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.
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.
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.
Ça ça me va mieux.
J'aime bien cette analogie, merci :-)
Effectivement.
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.
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 » !
[^] # Re: Et?
Posté par benoar . En réponse au journal Payer ses impôts en choisissant la date. Évalué à 1.
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.