benoar a écrit 4229 commentaires

  • # La fin justifie-t-elle les moyens ?

    Posté par  . En réponse au journal Traduction : Payer ne permet pas d'échapper aux monopoles. Évalué à 8 (+6/-0).

    La compagnie dépense plus de 26 milliards de dollars par an pour disposer de la place par défaut à tout endroit où vous pourrez jamais rencontrer un moteur de recherche.

    Milliards qui servent entre autre à… financer quasi-entièrement le développement de Firefox, en étant son moteur de recherche par défaut. Je vous laisse 2h pour savourer cette ironie et me sortir une justification à ces pratiques.

    Sinon bravo pour cette traduction, elle est vraiment très bien réalisée, avec un vocabulaire très travaillé comme dans l’original.

  • [^] # Re: Défis

    Posté par  . En réponse au journal Générer des images vectorielles procédurales avec des technologies des années 2000. Évalué à 3 (+1/-0).

    Retrouvé :
    https://fdik.org/yml/
    Il propose aussi YSLT comme alternative à XSLT :
    https://fdik.org/yml/yslt

  • [^] # Re: Coquille

    Posté par  . En réponse au journal Générer des images vectorielles procédurales avec des technologies des années 2000. Évalué à 2 (+0/-0).

    On termine effectivement toujours les années utilisées dans cette expression par 0 ; je ne comprends pas trop ta remarque. C’est effectivement pour rappeler la notation scientifique, je crois.

  • [^] # Re: Défis

    Posté par  . En réponse au journal Générer des images vectorielles procédurales avec des technologies des années 2000. Évalué à 3 (+1/-0).

    Je n’ai jamais utilisé ReactJS mais j’avais déjà vu cette syntaxe, d’abord avec E4X, puis effectivement celle-ci issue de React qui s’appelle JSX. Je la trouve vraiment pratique, et c’est vraiment bien pour facilement intégrer du *ML, mais ça reste un fichier de syntaxe principale Javascript, avec des bouts de XML dedans, et non du XML « pur ». Je suis d’accord que c’est l’avantage et l’inconvénient de XML : c’est puissant, mais du coup la syntaxe est naze pour du code, d’où le rejet de XSLT par plein de monde.

    Le côté « descriptif » du XML permet de rester sur de la donnée arborescente (à la Lisp en fait ; je pensais que quelqu’un allait me le sortir au moins…) qui est interprétée comme du code, et a donc cette facilité d’être abordée de multiples angles. Un langage de programmation peut bien sûr être vu comme un arbre (le T de AST) mais son côté plus proche du langage naturel, qui est son avantage, gêne les autres utilisations, je trouve. J’ai toujours voulu trouver des notations de XML plus proches d’une syntaxe sans balise, et il y a quelques essais (je me souviens de YML je crois — non, pas YAML — mais qui est introuvable aujourd’hui dans un moteur de recherche…) mais aucun qui ne m’a vraiment convaincu.

  • # Défis

    Posté par  . En réponse au journal Générer des images vectorielles procédurales avec des technologies des années 2000. Évalué à 2 (+1/-1).

    Et pour ceux qui aiment les défis, vous pouvez par exemple essayer de faire la même chose avec ce joli exemple en tikz :
    https://fr.wikipedia.org/w/index.php?title=Fichier:Neighbourhood_definition2.svg&lang=fr

    Et pour ceux qui se sentent encore plus en forme, je vous laisse réfléchir à une solution multi-dialecte en JSON… Non, pardon, je déconne, c’est pas possible ! (ceux qui me sortent du JSON-LD – fils batard de JSON et RDF – je leur lance des œufs pourris)

  • [^] # Re: Extension CleanURL

    Posté par  . En réponse au journal Décès des pages de résultats Google sans tracking à 25 ans. Évalué à 7.

    Merci, je ne connaissais pas.

    Je suppose que c’est la fonctionnalité de base de rewriting qui sera utilisée pour ma navigation sans JS ici, car quand je lis :

    Prevents Google from rewriting the search results (prevents the insertion of tracking code)

    Ça c’est pour la version avec Javascript, où les liens sont tout d’abord ré-écrits sans tracking, afin qu’un survol du lien donne un résultat innocent (comme évoqué dans le commentaire après le tiens), mais où Google rajoute un callback au onclick afin de re-rajouter le tracking à ce moment-là. C’est vicieux qand même, hein ?

  • [^] # Re: Contre-productif

    Posté par  . En réponse au journal L’écriture inclusive sur linuxfr.org est-elle un crime ?. Évalué à 2.

    Merci d’avoir sû bien exprimer l’impression que j’ai toujours eu également, même si je n’ai pas ton expérience de l’utilisation de l’écriture inclusive : pour moi qui suis fan de l’orthographe orthodoxe, avant, le genre neutre restait plutôt neutre, même s’il avait certes un certain penchant masculin. Aujourd’hui, avec « l’égalisation » masculin-féminin, dans ma tête le neutre sonne clairement beaucoup plus masculin dorénavant. D’où aussi certaines réactions négatives très vives, je pense, car la généralisation de ce genre d’orthographe alternative atteint très clairement les esprits dans leur ensemble, et « déforment » ainsi un acquis ancestral, ce qui peut être vécu assez violemment.

  • [^] # Re: À propos…

    Posté par  . En réponse au journal Mettre à jour le firmware d'une imprimante OKI. Évalué à 3.

    Marrant de voir comment on peut influencer les autre ;-)

    Concernant ton problème de scan réseau, c'est effectivement le point sur lequel j'ai buté aussi. J'ai fini par passer par l'envoi réseau, par SMTP : vu que j'ai un SMTP local, ça n'est pas trop dérangeant pour moi. Ça fonctionnait très bien, jusqu'à cette histoire d'initialisation du Wifi qui a cassé cette fonction, pour une raison débile, vu que je suis toujours passé par l'Ethernet et que ça marchait très bien comme ça.

  • # Parti aussi

    Posté par  . En réponse au journal Merci Linuxfr, aujourd'hui je fais mes valises. Évalué à 4.

    Merci pour ton journal, qui me permet d'essayer de dire que tu n'es pas seul : je suis plus ou moins parti il y a un an pour ma part, pour des raisons similaires liées au même sujet. Ça fait bizarre de se rendre compte d'un coup (même si je sentais des divergences depuis un bout de temps) que la « liberté » telle qu'on l'envisage est très différente en réalité de la « liberté » d'autres personnes qu'on pensait du même courant, le logiciel libre. Pour ma part je me contenterai dans le futur des sujets techniques, et n'aborderai plus de sujets politiques, qui étaient pourtant une particularité de linuxfr que j'affectionnais en particulier.

    D'un autre côté, cela m'a permis d'analyser les choses et de me rendre compte de tous les indices qui mèneraient à cette dystopie : les geeks informaticiens sont en général des « control freak » et des scientistes parmi les plus zélés. Et le fait que l'arbitraire qu'on trouve de le numérique (arbitraire des choix, changement de conditions réguliers, contrôle permanent*, etc) se soit abattu sur le réel n'est pas une coïncidence, pour moi c'est un constat d'échec : les informaticiens n'ont pas su faire advenir un modèle d'informatique respectant réellement la liberté, et du coup le modèle dominant, porté par la puissance de la machine, s'est appliqué sur le réel. Ce modèle n'est pas seulement purement technique, mais liées aux méthodes de réflexions, qui me semblent si inhumaines. Cela fait longtemps que j'avais essayé de dénoncer celles de Zorro par exemple, qui est une caricature type je pense, mais je n'avais pas imaginé sa prévalence dans le monde du libre.

    Pour essayer d'amener une note de réflexion sur des auteurs, autre que Sadin que j'ai vu cité plus haut (et qui aime bien citer Arendt qui tu invoques), je vous conseillerais par exemple Célia Izoard, qui fait de très bon articles sur Reporterre, en plus de ses livres et de ses traductions (1984 de Georges Orwell, pour la dernière) ; ici sur la violence de la numérisation :

    https://reporterre.net/La-numerisation-du-quotidien-une-violence-inouie-et-ordinaire

    Qu’on veuille les aider ou leur botter les fesses, on présente toujours ceux et celles qui répugnent à numériser leur vie comme des gens qui n’ont pas encore compris, alors que, bien au contraire, ils ont souvent très bien compris. La question n’est pas celle de l’aptitude personnelle mais celle de la liberté.

    Car je suis convaincu que le seule solution pour sortir de cet écueil est la dé-numérisation. J'avais parlé de néo-luddisme à Stallman en 2019, et il me répondait que pour lui le libre était une forme de néo-luddisme. Je ne suis pas complètement d'accord, car même si le libre est un élément essentiel d'une informatique respectant les libertés, la limitation des domaines de l'implantation de l'informatique (ça me fait penser à Houellebecq de dire ça…) est essentielle à la conservation de nos libertés.

    RDV dans le monde réel, pour ceux qui veulent bien continuer parmi les humains.

    * Pour l'anecdote, rappelez-vous qu'une des raisons pour RMS d'avoir créé un mouvement « libre » était que les premières stations Unix qu'il utilisait au MIT ne demandaient qu'un login, pas de mot de passe…

  • # Sur le vote et l'utilisation hors des grands événements

    Posté par  . En réponse au journal TousAntiCovid Carnets, sans TousAntiCovid. Évalué à 8.

    l'instauration du passe sanitaire a déjà été votée

    Faux, le vote au Sénat est passé, et c'est un projet de loi en lecture accélérée (comme souvent aujourd'hui) donc il n'y aura pas de deuxième lecture, mais il faut encore attendre le vote de la Commission Mixte Paritaire (Assemblée/Sénat) (cf. le dossier au Sénat) prévu le 27 mai, et les décrets d'application.

    Et tant qu’à être contrôlé, ne préférons-nous pas que ce soit par un logiciel libre qui respecte la vie privée et qui ne diffuse pas nos informations médicales aux organisateurs d’événements ?

    Sur ta proposition de l'utiliser pour des rassemblements privés comme indiqué dans ta dernière news, qui était à priori ta motivation originelle, je cite un extrait du même projet de loi :

    Est puni d’un an d’emprisonnement et de 45 000 € d’amende le fait d’exiger la présentation des documents mentionnés au premier alinéa du présent D pour l’accès à d’autres lieux, établissements ou événements que ceux mentionnés au 2° du A.

    Ceux-là étant les « lieux, établissements ou événements impliquant de grands rassemblements de personnes pour des activités de loisirs ou des foires ou salons professionnels ».

  • [^] # Re: Configuration serveur et écosystème de clients

    Posté par  . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 3.

    Bonjour, je me permets bien après la bataille quelques commentaires historiques sur la tendance actuelle à vouloir absolument stocker les mots de passe hashés, vu ton obstination à le faire je me disais qu'une petite perspective historique pourrait t'aider à comprendre.

    Très historiquement, les protocoles d'authentification étaient effectivement « en clair » et on envoyait les mot de passe directement au serveur, sans préoccupation de divulgation des secrets. Ce problème a été résolu au cours des années 90 avec différentes implémentations de protocoles défi-réponse (challenge-response) comme DIGEST-MD5 (cité plus haut) pour le web, CHAP pour PPP, etc. Ils ont été améliorés par l'ajout de nonce pour éviter les rejeux. Il faut se remémorer à l'époque qu'utiliser des canaux chiffrés n'était pas encore très répandu, et la cryptographie très réglementée et limitée (par les US) : ces protocoles protégeaient l'authentification lorsqu'on utilisait un canal non-chiffré, mais pas le canal de données associé. Le développement de la cryptographie a amené dans le même genre de thème l'authentification défi-réponse par clé dans SSH par exemple, ou l'authentification client par X.509 par certificat. Ces méthodes permettent, contrairement aux précédentes, de ne même pas stocker de secret côté serveur ! Car oui, bien que protégeant le canal d'authentification, les méthodes de défi-réponse citées nécessitent de stocker le mot de passe de manière récupérable sur le serveur (ce qui n'est pas forcément directement en clair, mais pas très loin il est vrai).

    Puis est venu le temps de la généralisation du chiffrement des canaux avec TLS, qui a bien sûr commencé tôt sur le web, et s'est généralisé ailleurs après (sachant qu'il existait d'autres techniques aux buts similaires avant, mais qui ont eu moins de succès, ou alors dans des niches, comme IPsec, et SSH — pour son canal chiffré par DH, pas pour l'auth, ici —). Pour différentes raisons, les techniques « anciennes » d'authentification avec communication du mot de passe ou d'autre secret partagé sans souci de la confidentialité de l'échange — puisqu'ici obtenu à travers TLS — sont redevenues populaires, car souvent plus simples à implémenter une fois que le boulot de confidentialité de la couche TLS a été effectué. Certains voient ça comme un progrès, personnellement je vois plutôt ça comme une régression : maintenant, le serveur doit être mis au courant à travers le réseau du secret du client lors de la négociation de l'authentification. Le client doit avoir un moyen de garder ce secret sur le long terme et le présenter au serveur à sa demande ; il ne peut ainsi plus déléguer par exemple le défi d'authentification à un token comme une clé USB de cryptographie, ou utiliser de la cryptographie asymétrique qui lui permettrait de garder les secrets dans un endroits sécurisé et pérenne, puisqu'il n'a pas besoin de le « ressortir » et l'envoyer sur le réseau à chaque authentification. Mais aujourd'hui la cryptographie asymétrique « à l'ancienne » a perdu, les navigateurs veulent même supprimer l'authentification client par certificat X.509.

    Bref, on a mis sur le dos du client le poids de devoir garder un secret qu'il doit communiquer « en clair » (mais sur un canal chiffré), pour simplifier la vie des serveurs qui se font facilement poutrer… pour quelle raison ? Est-ce la responsabilité du client si le serveur n'est pas capable de garder des secrets comme il faut ? On avait su inventer des mécanismes évitant tout stockage « chaud » de secret et de communication de secret en ligne grâce à la cryptographie asymétrique, mais aujourd'hui des considérations de practicité utilisateurs (c'est soit-disant trop dur à gérer) et de soit-disant préoccupation relatives au traçage d'identités (LOL c'est Google qui dirige les normes sur les nouveaux token qui empêchent la reconnaissance cross-site… sachant que Google le fait lui-même autrement) ont mis fin à ces mécanismes utilisés tels qu'à l'époque.

    Alors aujourd'hui, on a su trouver des solutions intermédiaires différentes, qui ont certains avantages et d'autres désavantage : SCRAM-* par exemple, qui permet de faire du challenge-response d'un secret partagé sans avoir à stocker ce secret tel-quel sur le serveur. Ou les différentes formes d'authentification « fortes » par clé asymétriques comme WebAuthn, qui sont très spécifique au Web contrairement à X.509, et imposent des modèles d'identité et de confidentialité bien différents de ce qu'on avait avant (grand débat de savoir s'ils sont meilleurs ou moins bons…). Pourquoi pas, mais pour ça on a « mis à la poubelle » tout un tas de technologies qui étaient éprouvées et fiables, bien qu'ayant des désavantages (comme le stockage de secret « en clair » côté serveur) cités comme complètement rédhibitoire par certains comme toi, alors que les méthodes modernes ont d'autres désavantages qu'on cite moins. Tout ça est une histoire de compromis, et crier sur les gens quand ils stockent des secrets côté serveur comme si c'était universellement mauvais, alors que ça met un fardeau de gestion de secret supérieur sur le client, ça n'est pas très honnête ni constructif.

  • [^] # Re: Pour ce que ça change...

    Posté par  . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 1.

    C'était pas une question de pénurie, mais une politique : les PI provoquent l'augmentation du nombre de routes de la DFZ et de la désaggrégation, et un des buts d'IPv6 est d'aggréger au maximum, donc ils ont (de mémoire) arrêté d'en faire, même si au début (il y a pas mal de temps quand même) c'était autorisé sans y avoir trop réfléchi histoire de faire « comme en IPv4 » (qui lui a vu l'arrêt des PI avec la pénurie). C'est resté pour les IX qui sont des cas spécifiques et limités, mais c'est tout. Encore une fois, je ne trouve pas de document pour appuyer mes dires.

  • [^] # Re: Pour ce que ça change...

    Posté par  . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 2.

    À ma connaissance il n'y avait plus de PI IPv6 au RIPE depuis un bout de temps, à part pour les IX. Le document de leur politique concernant les PI https://www.ripe.net/publications/docs/ripe-738#IPv6_PI_Assignments n'a pas l'air de le préciser, c'est étrange.

  • [^] # Re: Pour ce que ça change...

    Posté par  . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 3. Dernière modification le 13 février 2021 à 12:17.

    Pour quelle raison celui qui signe les chèques en ferait un pour ça ?

    Oui, tu pointes effectivement les bonnes raisons, et je sais bien que les coûts immédiats sont souvent énormes et dissuasifs. Les arguments que je présente sur « dé-complexifier » l'applicatif et la gestion réseau sont des arguments de long terme, et c'est très peu entendu dans ces structures intermédiaires.

    Un autre problème qui vient avec l'IPv6 pour ces structures : ça les lie fortement à leur opérateur. Et souvent, elles aiment pas ça (et je les comprend).

    Alors ça dépend de comment tu le fais : encore une fois, ça concerne l'applicatif, et c'est un chantier énorme. J'ai souvent recommandé de revenir à une gestion saine du DNS et augmenter son utilisation dans l'applicatif, car c'est le seul moyen de se défaire du couplage des applications avec les adresses : ce dont tu parles, c'est parce que tout le monde hardcode l'adressage et se lie à sa structure, ce qui amène des complications horribles en cas de renumérotation, effectivement. Et tous les devs et tous les frameworks aujourd'hui ont cette tare… alors qu'historiquement, l'utilisation des noms était beaucoup plus développée, et le NAT est venu casser cette dynamique car il rend compliqué l'utilisation des noms. C'est triste, mais c'est un combat nécessaire pour améliorer le réseau de manière générale.

    Ensuite, tu peux également choisir de te préparer à l'utilisation d'adresses multiples, avec des préfixes d'origine différentes, ou alors d'adresses changeantes, afin de te défaire de cette dépendance. Ça doit être galère sans DNS, mais c'est une possibilité.

    Le jour où tu veux changer d'opérateur, tu dois refaire tout ton plan d'adressage interne.

    Alors, si tu ne te débrouilles pas trop mal, tu referas les configurations d'adressage de tes équipements, mais tu ne changeras pas la structure, vue que normalement ton nouvel opérateur t'offriras un préfixe assez grand pour faire un adressage similaire au précédent. Tu traduis juste le préfixe, quoi, même si je comprends la galère du changement de conf. Si tu décides de te baser sur les noms comme proposé plus haut, ça peut même être grandement simplifié. Et tu pourras même avoir de l'adressage multiple avec deux opérateurs upstream si tu le veux.

    Et il ne faut pas croire que la transition d'opérateur est toujours rose même en IPv4 : tu as l'air de parler de professionnels maîtrisant bien leurs réseau, et j'ai déjà vu des transitions IPv4 où une partie de l'expertise est « avalée » par l'opérateur réseau pour différentes raisons (manque de compétences internes à l'entreprise, offre commerciales préférées par les dirigeants, etc) et les changements nécessaires aux équipements afin de gérer le ré-adressage sont substantielles !

    À moins de n'utiliser que les adresses fd00:/8 en interne, mais du coup, ça supprime une partie des avantages de l'IPv6.

    Ça dépend, tu peux aussi essayer de le faire « bien » : tu as en adressage pérenne en ULA (même pas forcément NATé upstream, uniquement pour la communication intra-entreprise), auquel tu peux ajouter des adresse de préfixes globaux de tes FAI pour les besoins d'accès (facile, laisse l'autoconf activée) ou de proposition de service (plus difficile mais réalisable). Comme d'habitude, il faut prendre le réflexe en IPv6 de penser que les technos peuvent s'ajouter, même si gérer la diversité augmenté bien sûr la complexité.

    Avoir des ULA par défaut (non routées/NATées upstream) avec un ou des préfixes supplémentaires routés, c'est la configuration adoptée par défaut depuis quelques années par OpenWrt : tu vas me dire que ça n'est pas pour un contexte professionnel, mais je trouve que c'est une très bonne solution même dans ce contexte, qui peut satisfaire les exigences de stabilités comme celles d'atteignabilité globale. Encore une fois, bien sûr que ça amène un peu plus de complexité dans le réseau et la configuration des applications, mais en enlève aussi au niveau des NATs.

    Bref, de mon point de vue, c'est surtout pour ces structures intermédiaires (mais nombreuses) que l'IPv6 représente un coût démesuré par rapport aux gains (à peu de choses près nuls)

    Je pense que tu vises juste pour leurs appréhensions, mais je pense personnellement qu'il y a moyen de montrer que la réalité peut être plus simple en choisissant des stratégies de migration adaptées. Je suis par contre d'accord que ces stratégies que je propose ne sont pour l'instant pas souvent déployées, et très peu d'offres professionnelles sont proposées.

  • [^] # Re: Pour ce que ça change...

    Posté par  . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 3.

    C'est effectivement une des raisons, et c'est un truc qui nous concerne nous développeurs car c'est parce que les applications sont tellement mal codées que le NAT64 « brut » a eu besoin d'être suppléé par du 464XLAT : dans les deux cas, ce qui circule sur le réseau de l'opérateur (avant d'arriver aux traducteurs) est de l'IPv6 « pur » (c'est le cas pour presque tout le réseau de Free aujourd'hui, je pense), et le « bénéfice » du 464XLAT c'est uniquement d'apporter un adressage local IPv4 (une re-traduction, en gros) afin de plaire aux hôtes qui ont des outils déficients en IPv6, et présenter une API ancienne aux applications qui ne sont pas capables d'utiliser des sockets correctement. En effet, l'API des sockets a été prévue pour que la transition puisse se faire en douceur, mais dans beaucoup de cas les logiciels sont implémentés à la truelle et font de la merde. Le NAT64, qui aurait pu fonctionner si des socket AF_INET6 étaient simplement directement utilisées (pour les softs IPv6-only qui comptent sur la présence de traducteurs sur le réseau) ou si les softs utilisaient correctement getaddrinfo(3), se plante au point qu'on est obligé de simuler un réseau et une API IPv4 pour faire fonctionner correctement les applis : c'est moche.

    C'est le deuxième chantier qui est à mon avis encore gigantesque, après les manques des réseaux de certains opérateurs : faire que les applis et les framework arrêtent de réinventer la roue en ajoutant des couches « d'abstraction » qui collent complètement au modèle d'Internet NATé (ce qui est la cas de toutes les technos citées plus haut) et sont inadaptables à IPv6 au point où on en est obligé d'émuler IPv4 pour que ça « marche » (pour les « clients » seulement, car le 464XLAT pour les serveurs, ça n'est pas trop ça, il faudra faire autre chose).

  • # Software BOM

    Posté par  . En réponse au journal Assurer la sécurité informatique sur le modèle de la sécurité alimentaire. Évalué à 3.

    J'arrive après la bataille, mais ce que tu me racontes s'apparente à une Software bill of materials : une liste de composants utilisés, avec diverses informations pour retrouver leur origine, leur licence, la durée de leur support, etc. Ça vient du monde de la gestion de chaîne logistique, et moi je l'ai surtout connu en électronique : chaque composant utilisé sur un schéma est listé, avec ses caractéristiques, ses fournisseurs, et le temps pendant lequel il est garantit d'être produit et disponible, donc également le stock et l'approvisionnement. Ça permet de gérer ton histoire de « péremption » un peu mieux : ça n'est pas parce que quelque-chose est « vieux » qu'il est mauvais, c'est juste qu'il faut qu'il y ait quelqu'un « derrière » pour assurer qu'il soit disponible et avec un support.

    Je ne connais pas l'écosystème logiciel autour de ça, mais j'en ai de plus en plus entendu parler récemment, surtout lié aux attaques visant des éléments logiciels qu'on ne pensait même pas avoir inclus, comme tu l'évoques.

  • [^] # Re: Pour ce que ça change...

    Posté par  . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 10.

    Les limitations que tu pointes sont pertinentes, même si dans l'absolu il existe des équivalents IPv6 à presque tout (et il existe de meilleures manières de faire que ce que tu cites, qui sont des conceptions « anciennes » et problématiques de voir le réseau). Mais c'est sûr que viser le dual-stack, c'est multiplier par plus que deux la complexité : la vraie bonne solution, qui est poussée par pas mal de monde aujourd'hui, est de faire de l'IPv6 uniquement et de compter sur les technologies de transition pour relier les deux mondes.

    Ensuite, la complexité que tu vois sur l'adressage et le routage du réseau, c'est en définitive pour simplifier l'aval du réseau, qui est aujourd'hui un sac de nœud sans nom : regarde la gueule des technos réseau autour d'OpenStack, Docker et k8s, c'est un bordel immonde ; ou alors toutes les technos client pour « traverser » les NAT. Le problème est effectivement que comme le bordel a été « factorisé » dans ces technos et t'es livré inclus de base, on ne le « voit » plus, du coup on ne comprends pas l'intérêt d'avoir un réseau avec un plan d'adressage correct. Mais peut-être qu'un jour certains apprécieront, quand ils auront compris qu'on peut simplifier l'infra et l'applicatif avec une technologie réseau — car c'est le vrai but d'Internet à la base, de faciliter l'interopérabilité d'applications.

    Bref, le dual-stack c'est compliqué, c'est sûr, et quand on réalisera qu'on pourra simplifier l'applicatif avec un réseau plus simple, l'IPv6 commencera peut-être à prendre.

  • [^] # Re: Hum ?

    Posté par  . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 4.

    numerama explique que ce qui freine IPv6 c'est pas les terminaux, mais les réseaux

    Tu aurais le lien de l'article Numérama ? Pour le frein, oui effectivement ce sont surtout les réseaux aujourd'hui, même si ça s'est amélioré comme le signale l'ARCEP dans son compte-rendu cité plus bas.

    c'était difficilement applicable (le lien de l'avocat)

    Pour des raisons un peu moisies dans l'absolu, même si ça se comprend légalement : la France transcrit une directive de manière plus contraignante (l'obligation d'IPv6 n'est pas mentionné au niveau européen), absence d'un calendrier précis de transition, et l'obligation serait « disproportionnée ». Ils parlent de la disproportion de s'adapter au marché français seul, sans parler du fait que l'obligation pour le Brésil est déjà en place depuis plusieurs années, par exemple (avec ses propres limitations, certes).

    l'arcep contraint tout opérateur souhaitant proposer de la 5G a passer en IPv6.

    Tu as des sources là-dessus ? Je ne suis pas du tout un spécialiste 5G, mais des trucs que j'ai glané, la 5G est basiquement très orientée IPv6, voire promouvant l'IPv6-seul. Ça n'est pas pour rien que Huawei est le leader dans les RFC proposant de passer à « l'IPv4-as-a-Service », c'est-à-dire faire des réseaux uniquement IPv6, avec IPv4 « en option » pour ceux qui ont vraiment besoin de l'ancien monde… (basiquement c'est juste des méthodes de découverte de ponts NAT64 ou autre techno de transition).

  • [^] # Re: Javascript

    Posté par  . En réponse au journal Je suis humain / cloudfare n'a plus de flair!. Évalué à 3.

    Je navigue également sans JS, et pourtant je ne vois quasiment jamais de tels blocages… Tu as d'autres exemples que leboncoin ? (qui a effectivement un blocage si on n'accepte pas les cookies, et c'est pas pareil en fonction des navigateurs)

  • [^] # Re: Fascinant

    Posté par  . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 7.

    Perso c'était même pas une veille, je suis tombé par hasard dessus, en partant de la fiche Wikipédia de Pannier-Runacher (oui, je creuse loin…).

  • [^] # Re: Où est l'intérêt de leur point de vue ?

    Posté par  . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 7.

    Je ne pense pas que le but soit de freiner la compatibilité IPv6, mais juste d'éviter de se prendre des procès pour non-conformité. Bon, c'est vrai que du coup, sans punition les opérateurs/fabricants peuvent plus facilement traîner des pieds…

    Beaucoup d'articles dans cette loi suppriment des obligations pour les entreprises qui existaient pour faire les choses « bien », ça n'est pas pour qu'elles le fassent forcément moins (mmhh) mais pour qu'on n'ait pas de recours pour les emmerder si elles ne le font pas.

    La dérégulation, quoi : le « marché » s'en charge, pas « besoin » de loi pour ça.

  • # Résultats cachés par CSS

    Posté par  . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 4.

    Merci à tous pour vos suggestions, bien que je n'ai rien découvert de nouveau et que trouver le juste milieu entre emmerdement et laisser-faire est toujours difficile. Je n'ai pas répondu à quiconque, désolé, mais je trouve les réactions intéressantes.

    Je suppose qu'un nouveau tour de Google en CSS cache les résultats

    Aujourd'hui j'ai pris quelques minutes pour regarder encore une fois précisément ce qui avait changé dans la page pour donner cette « page blanche », et en fait c'est tout simple : au sein de la balise noscript (qui contient le meta refresh évoqué dans ce journal), il y a une balise style contenant table,div,span,p{display:none}, c'est tout. Ça doit pouvoir se bloquer à coup de règle de filtrage CSS, mais j'étais justement en train d'abandonner Adblock Plus pour une autre extension qui ne permet pas le filtrage CSS…

    Bon, tentons quand même : google.com##noscript>style, ça matche bien, mais la page reste blanche. Je suppose qu'ABP peut bloquer ainsi des éléments HTML désignés par un sélecteur CSS, mais ne bloque pas l'interprétation d'un bloc CSS désigné par un sélecteur CSS… ou un truc du genre.

    Bref, les ingés de Google ont bien joué avec celle-ci, mais je trouvais quand-même cela assez hallucinant que les utilisateurs d'un trick si « bête » et sûrement marginaux soient visés, en 2021, par de tels changements.

  • # Fiabilité à long terme ?

    Posté par  . En réponse au journal Le trackpoint sur les thinkpad…. Évalué à 2.

    J'aime bien les trackpoints également, mais j'ai un problème en particulier qui m'a un peu refroidi, moi qui ai l'habitude d'utiliser des vieilles machines : j'ai l'impression qu'avec l'âge, l'étalonnage se perd un peu (même si est refait automatiquement au démarrage, je sais) et l'arrêt de l'appui dessus n'entraîne pas l'arrêt immédiat du signal, ce qui fait que le pointeur a une sorte d'inertie très désagréable qui le rend très imprécis.

    Pour l'expliquer autrement, on envoie le pointeur dans une direction, avec la dextérité acquise on vise bien sur l'objet visé du premier coup, mais au moment de lâcher le trackpoint, le pointeur se met à dériver légèrement dans la direction qu'on lui avait indiquée. Ça ne le fait pas sur des trackpoints neufs, mais sur des machines de plus de cinq ans d'âge, je l'ai vu plusieurs fois. C'est je pense plutôt une sorte de problème physique dû à l'usure.

    Ça plus les problèmes de tendinite évoqués plus haut, que je n'avais pas étant jeune mais qui arrivent avec l'âge, m'ont fait abandonner l'utilisation des trackpoints, qui sont pourtant pour moi la meilleure manière d'utiliser le pointeur pour un utilisateur avancé du clavier, pour toutes les raisons évoquées plus haut.

  • [^] # Re: "Nous autres traductions, nous savons maintenant que nous sommes mortelles"

    Posté par  . En réponse au journal Orwell dans le domaine public: nouvelle traduction chez Agone (et deux autres chez Gallimard). Évalué à 5. Dernière modification le 19 janvier 2021 à 01:25.

    Retraduire n'importe quel autre bouquin, peut-être. Mais retraduire celui qui dénonçait la manipulation de la langue… c'est fort de café !

    P.S. : au passage, un article du fondateur d'Agone était paru en papier pour une plus grande audience dans le Diplo, quelques mois après ce post de blog : https://www.monde-diplomatique.fr/2019/07/DISCEPOLO/60049

  • [^] # Re: Comme une prison

    Posté par  . En réponse à la dépêche Systèmes d’exploitation pour téléphones — partie 3 : Android 🤖💚 . Évalué à 3. Dernière modification le 08 janvier 2021 à 22:37.

    Pour la même raison que les SMS ne sont plus autorisés, il faut que la vérification dépende aussi de la transaction.

    Alors c'est marrant et intéressant, le boîtier que m'a fournit le Crédit Coop fait une sorte de challenge/response, où ça n'est pas simplement un OTP généré par la carte de crédit. On rentre un code donné par l'établissement de vérification de la transaction lors du paiement, et on renvoie un code retour (après avoir tapé son code de carte bancaire). C'était utilisé au début pour les transactions les plus sensibles (je ne me souviens plus desquelles, mais je me souviens l'avoir utilisé), cependant ça a été abandonné il y a quelques années pour une raison que je ne connais pas ; je suppose que la fusion avec le SI tout moisi de la Caisse d'Épargne a joué pour le nivellement par le bas… Et que c'était également peut-être « trop compliqué » pour certains utilisateurs… Il existe également sur le boîtier une troisième fonction « signature » que je n'ai jamais vue utilisée.

    Ça pourrait à mon avis tout à fait remplir le critère de « lien dynamique » entre la transaction et le code renvoyé pour le boîtier.