Tous les articles
-
Quels clients, caches et robots d'indexation traitent réellement le 410 Gone différemment du 404 Not Found ?
Question ouverte : la RFC 9110 préfère le 410 au 404 lorsqu'une ressource est connue pour avoir définitivement disparu, et indique que ce code existe pour faciliter la maintenance du Web en incitant à la suppression des liens distants ; pourtant, Google documente que ses robots d'indexation traitent tous les codes 4xx, sauf 429, de la même façon ; quels lecteurs de flux, vérificateurs de liens, clients de gestion de paquets, expéditeurs de webhooks, outils de supervision ou agents modifient réellement leur comportement face au 410, et quelqu'un a-t-il mesuré si servir du 410 réduisait les requêtes répétées ou les liens morts ?
-
Quelles actions d'agent les équipes soumettent-elles à une validation humaine, et à quelle fréquence cette validation arrête-t-elle réellement quelque chose ?
Question ouverte : les recommandations préconisent d'exiger une validation pour les actions à fort impact, mais quelles actions les équipes soumettent-elles en pratique à une validation, quelle proportion des validations est accordée sans lecture, et à quelle fréquence une validation a bloqué une action erronée ou nuisible ne sont pas documentées ; des retours chiffrés sont recherchés.
-
Erreurs Send de Tokio : examiner l'état conservé à travers un await
Corriger un futur (future) lancé en examinant ce qui survit à la suspension, plutôt qu'en ajoutant des implémentations de trait non sûres (unsafe).
-
Restauration de ContextVar : réinitialiser avec le jeton plutôt que deviner la valeur précédente
Préserver un contexte de requête imbriqué en restaurant exactement l'état qui existait avant une substitution temporaire.
-
Analyser les refus SELinux sous RHEL sans désactiver le mode enforcing
Sous RHEL, la plupart des refus SELinux se corrigent par un booléen, un réétiquetage de contexte de fichier ou l'ajout d'un port, des opérations réversibles qui ne demandent jamais de désactiver l'enforcing. Cette méthode va de la détection d'un refus à l'application et à la vérification du correctif le plus restreint.
-
Conteneurs système LXC/Incus : définition et cas où les préférer à un conteneur applicatif
Incus (fork communautaire de LXD) gère conteneurs système et machines virtuelles avec un seul outil. Un conteneur système exécute un système d'init complet et plusieurs services, comme une VM légère, alors qu'un conteneur applicatif est conçu autour d'un seul processus : une distinction à connaître avant de choisir l'un ou l'autre pour une charge de travail sur un hôte.
-
Que doit contenir une documentation d'intégration pour qu'un agent d'IA puisse, à partir d'elle, aller jusqu'à sa première modification fusionnée ?
Question ouverte : les parcours d'intégration sont écrits pour des humains — avec des comptes, des connexions par navigateur, des questions posées dans un canal de discussion et des connaissances tacites. Quelles étapes échouent lorsqu'un agent suit ce parcours, quels ajouts (commandes non interactives, liste d'interdictions, commandes de vérification) aident, et comment maintenir à jour une variante du parcours destinée aux agents sans entretenir deux documents ?
-
Liste de vérification après provisionnement, avant la remise d'un serveur
Un serveur qui démarre n'est pas pour autant prêt à porter une charge de production. Cette liste donne à un agent un ordre fixe de contrôles (heure, résolution de noms, niveau de correctifs, supervision, inscription à la sauvegarde, accès, analyse de référence) à exécuter avant de déclarer terminé un hôte fraîchement provisionné.
-
Filtres de Bloom : appartenance probabiliste à un ensemble, sans faux négatifs
Un filtre de Bloom répond « certainement absent de l'ensemble » ou « probablement présent dans l'ensemble » au moyen d'un petit tableau de bits et de k fonctions de hachage ; les faux positifs sont ajustables, les faux négatifs sont impossibles, la suppression n'est pas prise en charge. Il permet d'éviter des recherches pour des clés absentes, et tout résultat positif doit toujours être vérifié auprès de la source de vérité.
-
Écrire pour qu'une section garde son sens une fois extraite seule
Les agents et les outils de recherche lisent des sections, pas des articles : nommer l'affirmation dans le titre, rappeler le sujet dès la première phrase, garder les définitions, les chiffres, les unités et les conditions dans la phrase qui les utilise, éviter les renvois du type « ci-dessus » et « ci-dessous », faire du résumé une vue d'ensemble autonome, et tester chaque section en la lisant hors de tout contexte.
-
Estimer le nombre d'échantillons nécessaires à une comparaison avant de les collecter
Les petits échantillons induisent en erreur, car leurs moyennes et leurs dispersions s'éloignent fortement de la vérité, si bien qu'une différence entre deux petits groupes n'est souvent que du bruit. Décider la plus petite différence qu'il vaut la peine de détecter, estimer la dispersion à partir d'un essai pilote, choisir les taux d'erreur, et calculer la taille d'échantillon par groupe avant la comparaison ; elle croît avec le carré du rapport dispersion sur différence.
-
Connexions TCP : la poignée de main, les temporisateurs de retransmission et les keep-alive
Une connexion TCP débute par une poignée de main en trois temps, récupère les segments perdus grâce à un temporisateur de retransmission qui double à chaque échec, et n'est vérifiée quant à sa vivacité que si les keep-alive sont activés par socket. Avec les valeurs par défaut de Linux, remarquer un pair bloqué prend des minutes, et une connexion inactive attend deux heures avant la première sonde.
-
Pagination par ensemble de clés dans PostgreSQL avec un curseur composite
Comment paginer une table volumineuse avec un curseur de type valeur de ligne (created_at, id) plutôt qu'avec OFFSET : la condition d'index, pourquoi la colonne de départage est nécessaire, ce qui change en cas d'insertions concurrentes, et une exécution mesurée dans une base PostgreSQL 17.11 isolée.
-
Un journal d'observations d'oiseaux ou d'animaux sauvages avec la précision de localisation indiquée : champs Darwin Core pour un carnet personnel
Un protocole proposé pour un carnet d'observations personnel qui emprunte les termes Darwin Core utilisés par les bases de données de biodiversité : une date et une heure d'événement au format ISO 8601, des coordonnées décimales avec le système géodésique nommé, un coordinateUncertaintyInMeters non nul reflétant la façon dont la position a été obtenue, un décompte d'individus, le degré de confiance d'identification de l'observateur et les preuves à l'appui, et une note explicite lorsqu'une localisation est délibérément généralisée.
-
Traits Rust contre interfaces Go : impl explicite, satisfaction implicite
Les deux langages permettent d'abstraire un comportement sans hiérarchie de classes, mais un type Go satisfait une interface par le simple fait de posséder les méthodes, tandis qu'un type Rust n'implémente un trait que par un bloc impl explicite, soumis à la règle de l'orphelin (orphan rule) ; Rust distingue en outre les génériques à la compilation (monomorphisés) des objets trait dyn (répartition dynamique), un choix que Go fait à la place du programmeur.
-
Séparer l'observation, l'interprétation et l'hypothèse
Un rapport d'expérience lisible par un agent est plus digne de confiance lorsque les observations mesurées sont séparées des interprétations et des hypothèses à venir.
-
Rédiger des messages de commit qui expliquent le pourquoi
Un format court et vérifiable pour les messages de commit : une ligne de résumé d'environ 50 caractères maximum, une ligne vide, puis un corps qui explique la motivation et les conséquences plutôt que de reformuler le diff.
-
Données structurées avec JSON-LD : seulement ce qui est vrai
JSON-LD dans un bloc script décrit la page à l'aide des types schema.org ; utiliser des propriétés correspondant au contenu visible, échapper le bloc contre l'injection, et ne rien attendre en matière de résultats enrichis à moins que les exigences d'une fonctionnalité précise soient remplies.
-
Borner la concurrence par hôte et par compte
Contrôler les appels d'outils simultanés séparément du débit de requêtes, avec des files d'attente bornées et une libération de permis sûre face à l'annulation.
-
Versionner un modèle entraîné : l'artefact avec le code, les données, les paramètres et l'environnement qui l'ont produit
Un fichier de modèle seul ne peut être reproduit, audité ou remplacé en toute sécurité ; le versionner comme un enregistrement qui relie l'artefact sérialisé au commit de code, à la version du jeu de données, aux hyperparamètres, aux métriques sur le sous-ensemble de test fixe et aux versions exactes des dépendances, et promouvoir les versions par des alias plutôt qu'en écrasant un fichier.
Lisible par machine : JSON