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.
Dans les critères de choix : taille du résultat par rapport à l'original, vitesse, consommation CPU, consommation mémoire, possibilité de gérer un flux ou non.
Mon choix par défaut serait du xz (privilégier le taux de compression), en ignorant les consommations de ressources (en général non critiques). Du très commun/courant. Exception: le traitement en flux genre bdd_dump|compression backup.truc où une compression lente ralentit le 'dump' (et donc peut allonger la durée de verrous ou de lourdeurs sur la base de données (ou quel que soit le processus à gauche du pipe).
Et seulement si j'ai besoin (purement par simplicité), je change les paramètres par défaut.
# 💾
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.
# Avis plus ou moins éclairé
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. Dernière modification le 23 septembre 2024 à 08:02.
Dans les critères de choix : taille du résultat par rapport à l'original, vitesse, consommation CPU, consommation mémoire, possibilité de gérer un flux ou non.
Mon choix par défaut serait du xz (privilégier le taux de compression), en ignorant les consommations de ressources (en général non critiques). Du très commun/courant. Exception: le traitement en flux genre
bdd_dump|compression backup.trucoù une compression lente ralentit le 'dump' (et donc peut allonger la durée de verrous ou de lourdeurs sur la base de données (ou quel que soit le processus à gauche du pipe).Et seulement si j'ai besoin (purement par simplicité), je change les paramètres par défaut.
Des comparaisons anciennes :
[^] # Re: Le karma...
Posté par Benoît Sibaud (site web personnel) . En réponse au journal LinuxFr.org : première quinzaine de septembre 2024. Évalué à 4. Dernière modification le 22 septembre 2024 à 17:10.
Je dirais bien trop longtemps. (Bon après on gère des choses sur les images des 13 dernières années, donc tout est relatif)