Tous les articles
-
Le chiffrement au repos : contre quoi il protège et contre quoi il ne protège pas
Le chiffrement de volume protège les données sur des disques volés ou mis au rebut, ainsi que sur des supports qui quittent les locaux ; tant que le système fonctionne et que le volume est monté, tout processus disposant d'un accès en lecture voit les données en clair, si bien que ce chiffrement ne fait rien contre une injection SQL, un identifiant applicatif volé ou un hôte compromis. Le chiffrement au niveau des colonnes et le chiffrement côté client déplacent la frontière, au prix de la gestion des clés dans l'application.
-
Combien de temps les clients ont-ils continué à utiliser l'ancienne adresse après un changement DNS, et quels résolveurs ou clients ont ignoré le TTL ?
Question ouverte : la RFC 1035 définit le TTL comme l'intervalle pendant lequel un enregistrement peut être mis en cache avant de consulter de nouveau la source, et la RFC 8767 permet aux résolveurs de servir des données périmées lorsque les serveurs faisant autorité sont injoignables ; après un changement réel d'enregistrement avec un TTL abaissé, combien de temps le trafic vers l'ancienne adresse a-t-il persisté, et quels résolveurs, bibliothèques ou processus de longue durée étaient responsables de cette traîne ?
-
Classer les erreurs avant de choisir une nouvelle tentative
Utiliser une table de reprise explicite qui distingue les entrées invalides, les échecs d'accès, la surcharge transitoire et les résultats d'écriture inconnus.
-
BitLocker sur Windows Server : activation, vérification de l'état des volumes et sauvegarde des informations de récupération avant le redémarrage
La fonctionnalité BitLocker doit être installée avant que manage-bde ou Get-BitLockerVolume soient disponibles ; un protecteur de mot de passe de récupération permet à un administrateur verrouillé de retrouver l'accès, mais il n'est fiable qu'une fois sauvegardé dans Active Directory ou Microsoft Entra ID et vérifié à cet endroit avant le prochain redémarrage.
-
Callbacks de boucle en Python : lier la valeur voulue avant l'exécution différée
Distinguer une fermeture (closure) portant sur un nom qui change d'un callback qui doit conserver la valeur au moment de l'enregistrement.
-
Texturation virtuelle : gérer la résidence en mémoire, le feedback et les pages manquantes
Séparez une grande texture virtuelle de son cache physique, puis définissez les règles de feedback, de repli et d'éviction qui garantissent un streaming stable.
-
Les changements qui touchent à la fois les tests et le code sont annulés moins souvent que les changements de code seul de taille comparable
Hypothèse : un changement qui modifie ou ajoute des tests en même temps que son code a été exercé au moins une fois par la personne qui l'a écrit, de la façon que les tests décrivent, si bien qu'il est suivi d'un git revert ou d'un commit correctif moins souvent qu'un changement de code seul de même taille et de même zone ; un test proposé sur l'historique du dépôt avec appariement sur la taille.
-
Concevoir les exceptions d'une bibliothèque Python
Définir une exception de base par bibliothèque, en dériver des erreurs spécifiques, lever ces erreurs avec du contexte, chaîner les causes avec « raise ... from », et ne capturer étroitement qu'à la frontière où l'échec peut être traité.
-
Des cloisons (bulkheads) par dépendance maintiennent la disponibilité des points de terminaison non liés lorsqu'une dépendance ralentit
Hypothèse : lorsqu'un service appelle plusieurs dépendances à partir d'un même bassin partagé de threads ou d'emplacements de concurrence, une dépendance qui devient lente (sans être hors service) entraîne avec elle des points de terminaison sans rapport dès que ce bassin est épuisé ; donner à chaque dépendance son propre bassin borné maintient les autres points de terminaison proches de leur latence et de leur taux d'erreur de référence pendant le même ralentissement.
-
Rapporter le résultat d'une tâche d'agent : terminée, partielle ou bloquée, avec preuves
Une structure fixe pour le message final d'une tâche d'agent, afin que la personne qui lit puisse s'y fier sans tout revérifier : un des trois statuts (terminée, partielle, bloquée), ce qui a été vérifié et comment, ce qui a changé, ce qui a été supposé, ce qu'il reste à faire et ce qui permettrait de débloquer la situation, sans aucune affirmation d'achèvement qui ne soit étayée par une vérification que la personne qui lit pourrait reproduire.
-
Unity SRP Batcher : optimiser la préparation côté CPU sans le confondre avec l'instancing
Comprendre le rôle du SRP Batcher côté CPU, vérifier la compatibilité des matériaux et des shaders, et le mesurer séparément du GPU instancing.
-
Rendre le JSON sérialisé déterministe pour le hachage
Définir un contrat de sérialisation étroit avant de hacher du JSON, et distinguer une sortie Python reproductible d'un JSON canonique interlangage.
-
Relever un compteur électrique domestique selon un calendrier fixe : un protocole d'observation
Un protocole proposé pour consigner, à des heures fixes, la valeur cumulée en kWh affichée par un compteur domestique, ainsi que le registre suivi, la résolution de l'affichage et les conditions du foyer, afin que les écarts journaliers soient comparables d'un relevé à l'autre ; seul l'affichage est observé, et aucun chiffre de consommation n'est avancé.
-
Résumer un long document par blocs, avec des repères qu'une personne qui lit peut vérifier
Découper un long document selon sa propre structure, extraire des affirmations par bloc avec un repère (page, section ou plage de lignes) et une courte citation, fusionner ces affirmations en un résumé où chaque phrase conserve son repère, puis vérifier chaque citation par correspondance de chaîne avec le bloc dont elle provient.
-
Que s'attendent à voir supprimé les personnes qui activent la réduction des animations : toute animation, les grands mouvements, ou seulement la lecture automatique ?
Question ouverte : le réglage de réduction des animations dit « réduire », pas « supprimer entièrement », et les recommandations suggèrent de conserver de petites transitions porteuses de sens tout en supprimant les effets de parallaxe, les zooms et la lecture automatique ; existe-t-il des données sur ce que veulent réellement les personnes qui activent ce réglage, et leurs attentes diffèrent-elles selon la raison (trouble vestibulaire, distraction, batterie, préférence) ?
-
sort, uniq et comm : des opérations d'ensembles sur du texte qui dépendent d'une entrée triée
uniq ne fusionne que les doublons adjacents, comm exige que les deux entrées soient triées selon le même ordre de collation, et l'ordre de sort suit LC_COLLATE ; exécuter ce type de pipeline sous LC_ALL=C, choisir les bonnes options de clé (-n, -h, -V, -k, -t), et utiliser comm -12 et comm -23 pour les intersections et les différences.
-
Exécuter des commandes d'administration Linux en mode non interactif pour des agents sans supervision
Pager, invite de confirmation, locale qui reformate les nombres, demande de mot de passe sudo sans terminal pour y répondre : ces comportements interactifs par défaut sont les causes les plus fréquentes de blocage d'une session d'agent sans supervision sous Linux, ou d'une mauvaise lecture de la sortie. Cet article recense les options et variables d'environnement qui désactivent chacun d'eux.
-
Les entrées de journal de décision comportant une prédiction écrite améliorent les estimations ultérieures
Hypothèse : une équipe qui consigne, pour chaque décision non triviale, une prédiction concrète de son résultat et une date de révision, puis évalue cette prédiction par la suite, devient mieux calibrée au fil des mois qu'une équipe qui se contente de consigner ses décisions avec leur justification ; une comparaison proposée.
-
Combien d'emplacements de sondes externes, et quel seuil d'échec, rendent fiables les alertes de disponibilité pour un petit site ?
Question ouverte : un seul emplacement de sonde produit des alertes correspondant aux propres problèmes réseau de la sonde, tandis qu'exiger un accord entre de nombreux emplacements retarde les vraies alertes ; pour un petit site avec une seule origine, quelle combinaison d'emplacements, d'intervalles et de règles de confirmation a permis de garder un faible taux de fausses alertes sans manquer d'interruptions, et comment les deux catégories ont-elles été comptabilisées ?
-
Les politiques de sécurité au niveau des lignes réduisent les fuites de données entre locataires par rapport au filtrage côté application
Hypothèse : les services multi-locataires qui appliquent l'isolation des locataires au moyen de politiques de sécurité au niveau des lignes de PostgreSQL (un réglage du locataire par connexion, vérifié par la base de données) présentent moins de bogues d'exposition entre locataires que les services qui ajoutent un prédicat tenant_id à chaque requête, car une requête qui omet le prédicat de locataire ne voit malgré tout que les lignes du locataire courant, et une requête qui ne définit jamais le locataire ne renvoie rien ou une erreur, au lieu des lignes de tous les locataires.
Lisible par machine : JSON