Ce n'est pas en ne changeant rien pour ne pas casser la compatibilité que l'on va évoluer… par définition pour changer de façon pérenne, il faut modifier quelque chose et ne pas conserver ce qui était avant. Ça nécessite un effort de changer.
Au XXe siècle il a fallu modifier la variable électeur parce que les femmes ont obtenu (en France) le droit de vote. Puis on a eu le vrai pays vs les colonies, le vrai pays vs les territoires outremer, le vrai centre/la capitale vs l'outrepériph, etc., etc. Bref qui on inclut/exclut suivant l'origine, la nationalité, la religion, l'argent, la santé, le sexe, le statut, etc. C'est la vie en société, l'évolution de la nation, la vraie politique, blabla.
Il faut aussi noter une certaine dissonance cognitive mise en valeur ici : soit renommer des choses est mineur sans effet (ironie sur le racisme a totalement disparu du jour au lendemain.), alors on s'en fiche un peu, le coût est finalement assez faible. Soit renommer des choses est suffisamment important pour venir s'en outrer (le premier commentaire) et la vraie raison semble plus le refus du changement du vocabulaire que le minime changement de configuration impliqué. Pas de souci sur les opinions de chacun/chacune, mais faut pas essayer d'emballer ça dans une attaque sur les autres / les développeurs qui font des gigantesques changements apocalyptiques avec l'outrecuidance de le mentionner en petit dans une annonce…
Et maintenant mon avis perso dont on se fout sur le vocabulaire :
allowlist/blocklist est plus clair/explicite que whitelist/blacklist. Les couleurs c'est "mignon" mais pas explicite, surtout qu'on en ajoute, genre greylist (ou blue/red/purple/… teams en sécu où il faut juste tout connaître par coeur parce que la couleur n'est pas vraiment informative)
master/main pour git: master est très polysémique et plus long que main. Je conçois plus ma branche par défaut comme la principale que comme la référence. Donc je préfère main. (divulgachage : et on fait le changement pour LinuxFr.org…)
maître/esclave : difficile de ne pas voir un lien de domination. Mais je préfère primaire/secondaire(s) par exemple, ça me semble plus logique de changer de place/ordre que de changer celui qui tient le fouet. Probablement lié au fait que ça peut qualifier des personnes (comme si on avait contrôleur/contremaître vs ouvrier, ou patron / salarié, ou roi / sujet).
Dernier point sur l'empathie : ce n'est pas parce moi je m'en foutrais de ce changement de vocabulaire que je peux nier/mépriser le ressenti des autres. Au minimum je suis capable d'en discuter s'en mettre des noms d'oiseaux sur l'autre.
Le commentaire est ironique, il utilise une forme stylistique basée sur l'exagération et une troisième personne de prise de recul. Le smiley final et le changement de personne indiquent selon moi une volonté de conseiller / suggérer. Visiblement le commentaire n'a pas atteint cet objectif présumé, et son auteur s'est exprimé pour préciser sa position. J'entends que l'on peut lire le commentaire avec une voix intérieure de reproche, ou bien avec une voix intérieur d'ironie/humour, ou probablement d'autres façons, et j'entends que, personnellement, tu l'as mal reçu. Ton interlocuteur est en désormais conscient, et il s'est exprimé dessus.
En tant que modérateur, après avoir lu le message initial et vu les ajouts des concernés, je ne pense pas nécessaire d'agir plus avant.
Une équipe de dev choisit de renommer une variable dans une version. Puis de retirer l'ancien nom dans une version ultérieure. Quelle audace, quelle nouveauté, quelle surprise, quelle absence d'intérêt pour une actu.. ça arrive extrêmement fréquemment dans plein de logiciels.
Bon donc là le but est juste d'avoir une indignation sur les termes concernés mais sans le dire pour ne pas créer un débat boomer passéiste contre ultra-wokiste ? Ben je dirais que ça reste peu intéressant, voire inutile. Et qualifier les gens de lourdingues pour ça (rien), c'est cela qui me semble lourdingue.
Si, en termes de visibilité par le lectorat (dépêche > journal > lien). Mais j'ai beau le répéter ça ne change pas la perception et les habitudes. Après le critère retenu semble plus souvent être la facilité/vitesse à publier que la richesse du contenu ou la taille du lectorat. Et c'est la personne qui publie qui choisit suivant ses critères.
Surtout que, hors tournoi, le but des échecs est de gagner la partie, sans forcément une contrainte de temps. Tu peux jouer en ligne à distance un coup par semaine… il y a aussi la légende (?) des maitres de go avec une partie étalée sur des années. Bref l'humain pourrait battre la machine à l'obsolescence matérielle… Il suffirait de changer les critères pour choisir le gagnant.
J'imagine qu'on s'accordera pour dire qu'un ordinateur calcule mieux et plus vite qu'un humain, qu'il bat les humains en calcul : pourtant les premiers étaient bien plus gros que les humains, plus énergivores, moins génériques, limités en taille des nombres, etc. Depuis ils ont bien progressé et aucun humain ne manipule des entiers ou des flottants chaque nanoseconde. Mais on n'a pas attendu les microprocesseurs en GHz pour dire que l'informatique calcule plus vite qu'un humain. Et ce n'est pas une domination absolue des maths non plus : l'ordi n'écrit pas le Frido seul et ne produit pas des théorèmes et des unifications de théorie (pour l'instant).
Bref on sait faire des machines qui battent les humains aux échecs, au go, en calcul, en plongée, en vol, en vitesse dans tous les milieux, dans plein de jeux vidéo, en génération de conneries, etc. Ce qui n'empêche pas l'être humain d'être (pour l'instant) incomparablement plus générique et énergétiquement efficace.
Hors tribune : on ne peut pas tester le lien à chaque conversion Markdown vers HTML. La conversion peut arriver de nouveau bien après l'écriture initiale du lien, le lien peut ne plus marcher, le domaine peut avoir été perdu, etc. L'idée est plutôt qu'un contenu Markdown donné donne toujours la même conversion en HTML, de façon stable.
Pour la tribune : la situation est différente on ne réédite / régénère jamais. Mais on ne vérifie pas non plus qu'un lien quelconque soit valide. Il n'y a pas de raison de traiter un lien avec un point final différemment d'un autre lien (qui pourrait contenir une virgule finale ou un point virgule final ou un point d'interrogation final). Analyser la phrase serait encore plus exagéré me semble-t-il. Et surtout c'est indécidable de toute façon : https//fr.wikipedia.org https//fr.wikipedia.org. https//fr.wikipedia.org? https//fr.wikipedia.org; https://fr.wikipedia.org/wiki/... sont tous "valides". Il faudrait du code côté client pour poser la question « vous voulez dire "https//fr.wikipedia.org." ou "https//fr.wikipedia.org" ? » et forcer la personne utilisatrice à choisir (et casser tous les bots qui postent sur la tribune).
Hypothèse : ça a été fait par que souvent les gens écrivent « voici un lien https://example.invalid. » en mettant un point en fin de phrase, et que le cas est plus fréquent qu'une adresse qui finit réellement avec un point ?
D'après les dizaines de messages reçus par semaine, ce qui rapporterait serait de se faire payer pour du placement produit déguisé (pardon du contenu produit en partenariat)…
Se faire récolter/traire gratuitement ou spammer ne rapporte évidemment rien.
MAIS OVI SVPPRIMONS TOVS LES ACCENTS ET LES SIGNES DE PONCTVATION CA NE SERT A RIEN TOVT CA ET PVIS LES MINVSCVLES QVEL GASPILLAGE TOVT VN DEVXIEME ALPHABET POVR FAIRE EXACTEMENT LA MEME CHOSE
Le .deb (ou le .rpm) peut être signé numériquement. Si c'est le cas ET que la clé est déjà connue ou obtenue depuis un moyen sûr, alors c'est mieux qu'un script shell non signé plus facile à modifier.
Ça ne change pas grand chose si personne ne vérifie la signature ou que la clé de signature est définie/contrôlée par l'attaquant.
4.2.1. The "atom:author" Element
The "atom:author" element is a Person construct that indicates the
author of the entry or feed.
atomAuthor = element atom:author { atomPersonConstruct }
If an atom:entry element does not contain atom:author elements, then
the atom:author elements of the contained atom:source element are
considered to apply. In an Atom Feed Document, the atom:author
elements of the containing atom:feed element are considered to apply
to the entry if there are no atom:author elements in the locations
described above.
(...)
3.2. Person Constructs
A Person construct is an element that describes a person,
corporation, or similar entity (hereafter, 'person').
atomPersonConstruct =
atomCommonAttributes,
(element atom:name { text }
& element atom:uri { atomUri }?
& element atom:email { atomEmailAddress }?
& extensionElement*)
3.2.1. The "atom:name" Element
The "atom:name" element's content conveys a human-readable name for
the person. The content of atom:name is Language-Sensitive. Person
constructs MUST contain exactly one "atom:name" element.
Pigz compresses using threads to make use of multiple processors and cores.
man xz
-T threads, --threads=threads
Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit.
Le changement doit d'abord être fait côté RoR pour définir les avatars avec des clés redis différentes (genre avatars/ au lieu de img/). Ensuite on peut modifier le daemon img pour séparer le traitement des requêtes HTTP "/img/encoded_uri vers les clés redis "img/uri" et le cache disque des img" par rapport aux requêtes "/avatars/encoded_uri vers les clés avatars/uri et le cache des avatars".
Il faudra aussi déplacer les avatars stockés dans l'actuel cache des img dans leur propre cache.
Et là on devrait pouvoir avoir la même adresse dans les deux caches mais avec un rendu éventuellement différent.
[^] # Re: purée, les développeurs
Posté par Benoît Sibaud (site web personnel) . En réponse au lien NetworkManager 1.50. Évalué à 6.
Ce n'est pas en ne changeant rien pour ne pas casser la compatibilité que l'on va évoluer… par définition pour changer de façon pérenne, il faut modifier quelque chose et ne pas conserver ce qui était avant. Ça nécessite un effort de changer.
Au XXe siècle il a fallu modifier la variable électeur parce que les femmes ont obtenu (en France) le droit de vote. Puis on a eu le vrai pays vs les colonies, le vrai pays vs les territoires outremer, le vrai centre/la capitale vs l'outrepériph, etc., etc. Bref qui on inclut/exclut suivant l'origine, la nationalité, la religion, l'argent, la santé, le sexe, le statut, etc. C'est la vie en société, l'évolution de la nation, la vraie politique, blabla.
Il faut aussi noter une certaine dissonance cognitive mise en valeur ici : soit renommer des choses est mineur sans effet (ironie sur le racisme a totalement disparu du jour au lendemain.), alors on s'en fiche un peu, le coût est finalement assez faible. Soit renommer des choses est suffisamment important pour venir s'en outrer (le premier commentaire) et la vraie raison semble plus le refus du changement du vocabulaire que le minime changement de configuration impliqué. Pas de souci sur les opinions de chacun/chacune, mais faut pas essayer d'emballer ça dans une attaque sur les autres / les développeurs qui font des gigantesques changements apocalyptiques avec l'outrecuidance de le mentionner en petit dans une annonce…
Et maintenant mon avis perso dont on se fout sur le vocabulaire :
Dernier point sur l'empathie : ce n'est pas parce moi je m'en foutrais de ce changement de vocabulaire que je peux nier/mépriser le ressenti des autres. Au minimum je suis capable d'en discuter s'en mettre des noms d'oiseaux sur l'autre.
[^] # Re: Répliques cultes
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Michel Blanc bronsonisé. Évalué à 6.
Ainsi que la confirmation que selon une étude, sur un malentendu ça peut passer.
# 💾
Posté par Benoît Sibaud (site web personnel) . En réponse au lien [HS] Chouette d’or : le trésor chassé depuis 31 ans a été déterré, annonce l’organisateur. Évalué à 3.
https://fr.wikipedia.org/wiki/Sur_la_trace_de_la_chouette_d%27or
[^] # Re: Cookies Having Independent Partitioned State (CHIPS)
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Avec Firefox 131, on va manger des CHIPS !. Évalué à 5.
Le commentaire est ironique, il utilise une forme stylistique basée sur l'exagération et une troisième personne de prise de recul. Le smiley final et le changement de personne indiquent selon moi une volonté de conseiller / suggérer. Visiblement le commentaire n'a pas atteint cet objectif présumé, et son auteur s'est exprimé pour préciser sa position. J'entends que l'on peut lire le commentaire avec une voix intérieure de reproche, ou bien avec une voix intérieur d'ironie/humour, ou probablement d'autres façons, et j'entends que, personnellement, tu l'as mal reçu. Ton interlocuteur est en désormais conscient, et il s'est exprimé dessus.
En tant que modérateur, après avoir lu le message initial et vu les ajouts des concernés, je ne pense pas nécessaire d'agir plus avant.
[^] # Re: purée, les développeurs
Posté par Benoît Sibaud (site web personnel) . En réponse au lien NetworkManager 1.50. Évalué à 6.
Une équipe de dev choisit de renommer une variable dans une version. Puis de retirer l'ancien nom dans une version ultérieure. Quelle audace, quelle nouveauté, quelle surprise, quelle absence d'intérêt pour une actu.. ça arrive extrêmement fréquemment dans plein de logiciels.
Bon donc là le but est juste d'avoir une indignation sur les termes concernés mais sans le dire pour ne pas créer un débat boomer passéiste contre ultra-wokiste ? Ben je dirais que ça reste peu intéressant, voire inutile. Et qualifier les gens de lourdingues pour ça (rien), c'est cela qui me semble lourdingue.
[^] # Re: Cookies Having Independent Partitioned State (CHIPS)
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Avec Firefox 131, on va manger des CHIPS !. Évalué à 5. Dernière modification le 04 octobre 2024 à 08:13.
Si, en termes de visibilité par le lectorat (dépêche > journal > lien). Mais j'ai beau le répéter ça ne change pas la perception et les habitudes. Après le critère retenu semble plus souvent être la facilité/vitesse à publier que la richesse du contenu ou la taille du lectorat. Et c'est la personne qui publie qui choisit suivant ses critères.
[^] # Re: un ordinateur ne pourra jamais battre un champion d'échec!
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Team claims human-level AI is impossible — ever. Évalué à 4.
Surtout que, hors tournoi, le but des échecs est de gagner la partie, sans forcément une contrainte de temps. Tu peux jouer en ligne à distance un coup par semaine… il y a aussi la légende (?) des maitres de go avec une partie étalée sur des années. Bref l'humain pourrait battre la machine à l'obsolescence matérielle… Il suffirait de changer les critères pour choisir le gagnant.
J'imagine qu'on s'accordera pour dire qu'un ordinateur calcule mieux et plus vite qu'un humain, qu'il bat les humains en calcul : pourtant les premiers étaient bien plus gros que les humains, plus énergivores, moins génériques, limités en taille des nombres, etc. Depuis ils ont bien progressé et aucun humain ne manipule des entiers ou des flottants chaque nanoseconde. Mais on n'a pas attendu les microprocesseurs en GHz pour dire que l'informatique calcule plus vite qu'un humain. Et ce n'est pas une domination absolue des maths non plus : l'ordi n'écrit pas le Frido seul et ne produit pas des théorèmes et des unifications de théorie (pour l'instant).
Bref on sait faire des machines qui battent les humains aux échecs, au go, en calcul, en plongée, en vol, en vitesse dans tous les milieux, dans plein de jeux vidéo, en génération de conneries, etc. Ce qui n'empêche pas l'être humain d'être (pour l'instant) incomparablement plus générique et énergétiquement efficace.
[^] # Re: Visiblement ce n'est pas propre à la tribune
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi les liens qui se terminent par un point ne sont pas « linkifié » correctement. Évalué à 4 (+0/-0). Dernière modification le 02 octobre 2024 à 16:01.
Hors tribune : on ne peut pas tester le lien à chaque conversion Markdown vers HTML. La conversion peut arriver de nouveau bien après l'écriture initiale du lien, le lien peut ne plus marcher, le domaine peut avoir été perdu, etc. L'idée est plutôt qu'un contenu Markdown donné donne toujours la même conversion en HTML, de façon stable.
Pour la tribune : la situation est différente on ne réédite / régénère jamais. Mais on ne vérifie pas non plus qu'un lien quelconque soit valide. Il n'y a pas de raison de traiter un lien avec un point final différemment d'un autre lien (qui pourrait contenir une virgule finale ou un point virgule final ou un point d'interrogation final). Analyser la phrase serait encore plus exagéré me semble-t-il. Et surtout c'est indécidable de toute façon :
https//fr.wikipedia.org https//fr.wikipedia.org. https//fr.wikipedia.org? https//fr.wikipedia.org; https://fr.wikipedia.org/wiki/...sont tous "valides". Il faudrait du code côté client pour poser la question « vous voulez dire "https//fr.wikipedia.org." ou "https//fr.wikipedia.org" ? » et forcer la personne utilisatrice à choisir (et casser tous les bots qui postent sur la tribune).# Visiblement ce n'est pas propre à la tribune
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi les liens qui se terminent par un point ne sont pas « linkifié » correctement. Évalué à 5 (+0/-0).
Exemple avec un %2e
https://fr.wikipedia.org/wiki/X_Corp%2e
Exemple avec un .
https://fr.wikipedia.org/wiki/X_Corp.
Hypothèse : ça a été fait par que souvent les gens écrivent « voici un lien https://example.invalid. » en mettant un point en fin de phrase, et que le cas est plus fréquent qu'une adresse qui finit réellement avec un point ?
[^] # Re: Toujours pareil
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Doctolib déploie une IA pour capter et analyser les conversations patients-médecins ! . Évalué à 5.
D'après les dizaines de messages reçus par semaine, ce qui rapporterait serait de se faire payer pour du placement produit déguisé (pardon du contenu produit en partenariat)…
Se faire récolter/traire gratuitement ou spammer ne rapporte évidemment rien.
[^] # Re: Infos à vérifier
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Faille d'exécution de code à distance dans cups. Évalué à 5.
Corrigé, merci.
[^] # Re: Enfin!
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Unicode en version 16.0.0, le plein de hiéroglyphes égyptiens et de symboles informatiques. Évalué à 10.
I. REVENIR A L ALPHABET LATIN LE VRAI
II. IE GRAVE SVR MARBRE POVR MOINS BAVASSER
III. TOVT VNIFIER PAR L IMPERIALISME
IV. SESTERCES!
# Liens supplémentaires
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Faille d'exécution de code à distance dans cups. Évalué à 6.
Références CVE-2024-47076, CVE-2024-47175, CVE-2024-47176, CVE-2024-47177
# Vidéos du GUADEC 2024
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Vidéos des dernières conférences : BreizhCamp, JDLL et transcriptions April. Évalué à 3.
https://linuxfr.org/users/vmagnin/liens/les-videos-du-guadec-2024-sont-en-ligne
[^] # Re: Le paradoxe de la sécurité
Posté par Benoît Sibaud (site web personnel) . En réponse au lien RootAsRole v3.0!. Évalué à 4.
Le .deb (ou le .rpm) peut être signé numériquement. Si c'est le cas ET que la clé est déjà connue ou obtenue depuis un moyen sûr, alors c'est mieux qu'un script shell non signé plus facile à modifier.
Ça ne change pas grand chose si personne ne vérifie la signature ou que la clé de signature est définie/contrôlée par l'attaquant.
# Voir journal
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Vérifier si CUPS tourne sur votre serveur Ubuntu et le désactiver. Évalué à 3. Dernière modification le 28 septembre 2024 à 11:26.
https://linuxfr.org/users/samuel/journaux/faille-d-execution-de-code-a-distance-elevation-de-privilege-dans-cups
et
https://linuxfr.org/users/cg/liens/une-faille-de-securite-a-distance-jugee-tres-serieuse-sera-rendue-publique-le-6-octobre-2024
# LinuxFr.org
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Down de juillet et avenir du Journal du hacker . Évalué à 7.
Nous (équipe LinuxFr.org) évaluons ce qui serait possible et comment on pourrait aider. La proximité avec les liens LinuxFr.org est assez évidente.
[^] # Re: Enfin!
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Unicode en version 16.0.0, le plein de hiéroglyphes égyptiens et de symboles informatiques. Évalué à 4.
Ce n'est pas le but des zones à usage privé ? so that third parties may assign their own characters without conflicting with Unicode Consortium assignments
https://en.wikipedia.org/wiki/Private_Use_Areas#Private_Use_Areas
[^] # Re: Je suis inclu
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Haiku a 23 ans - Haiku R1 bêta 5 (partie 3 : documentation, finances et GSOC). Évalué à 5.
Corrigé, merci.
[^] # Re: je réfléchis
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Pour une poignée de gigabits..... Évalué à 8.
Et si tu pouvais apprendre à mettre des étiquettes correctement aussi stp.
[^] # Re: Correction de hack ?
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche SPIP 4.3 : une sortie estivale. Évalué à 4.
Oui je suis bien d'accord c'est pénible ces acteurs du SEO qui jouent les pénibles chez les autres.
# précédent
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Linux boots in 4.76 days on the Intel 4004. Évalué à 6.
https://linuxfr.org/users/cg/liens/demarrage-de-linux-sur-un-processeur-4-bits-intel-4004-de-1971
# Spécifications pour les flux Atom
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Le flux RSS mésuse la balise <author>. Évalué à 3 (+0/-0).
https://www.rfc-editor.org/rfc/rfc4287#section-4.2.1
[^] # Re: pigz
Posté par Benoît Sibaud (site web personnel) . En réponse au message Question sur la gestion des fichiers compressés avec gzip sous Linux. Évalué à 6.
man pigz
man xz
# Analyse
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Séparer le cache des avatars du cache des autres images. Évalué à 3 (+0/-0). Dernière modification le 23 septembre 2024 à 11:25.
Le changement doit d'abord être fait côté RoR pour définir les avatars avec des clés redis différentes (genre avatars/ au lieu de img/). Ensuite on peut modifier le daemon img pour séparer le traitement des requêtes HTTP "/img/encoded_uri vers les clés redis "img/uri" et le cache disque des img" par rapport aux requêtes "/avatars/encoded_uri vers les clés avatars/uri et le cache des avatars".
Il faudra aussi déplacer les avatars stockés dans l'actuel cache des img dans leur propre cache.
Et là on devrait pouvoir avoir la même adresse dans les deux caches mais avec un rendu éventuellement différent.