Tous les articles
-
Le biais du survivant dans les conseils d'ingénierie
Les conseils du type « les équipes qui réussissent font X » sont tirés des cas qui sont restés visibles ; sans connaître le taux de X parmi les équipes qui ont échoué ou sont parties, cela ne dit rien. Chercher le dénominateur, accorder un poids important aux rapports d'échec, et préciser la population dont tout conseil a été tiré.
-
System Integrity Protection et Signed System Volume : ce qu'ils protègent et pourquoi il ne faut pas les désactiver
SIP interdit même à root de modifier les chemins système protégés ou d'intervenir sur les processus protégés ; le Signed System Volume scelle cryptographiquement tout le volume système et le vérifie à chaque démarrage. Ensemble, ils expliquent pourquoi /usr/local est accessible en écriture mais pas /usr, et pourquoi désactiver SIP n'est pas une solution légitime à une erreur de permissions.
-
Pratiques de travail pour un agent d'IA qui modifie une base de code
Lire avant d'écrire, reproduire avant de corriger, changer par petites étapes vérifiées, exécuter les vérifications propres au projet, ne jamais retenter une écriture à l'aveugle, et rendre compte précisément de ce qui a été testé ; une méthodologie pour les agents qui modifient du code.
-
Compression des réponses : où la faire et quoi en exclure
Compresser les réponses textuelles (HTML, JSON, Markdown) au niveau du proxy ou de l'application, ignorer le contenu déjà compressé et le contenu en streaming, garder des ETags honnêtes à travers les encodages, et définir Vary: Accept-Encoding.
-
Budgétiser les textures BC, ASTC et ETC2 sur des cibles réelles
Comparez les formats de blocs GPU à partir de la prise en charge réelle, des canaux requis, du stockage arrondi au bloc et des artefacts visibles après l'import.
-
Concevoir des limites de débit qui protègent le service et informent le client
Limiter selon l'identité que l'on peut vérifier (compte, préfixe réseau), utiliser des compteurs atomiques dans des fenêtres fixes ou glissantes, répondre 429 avec Retry-After, garder des budgets séparés pour les lectures, les écritures et les inscriptions, et publier les limites effectives.
-
Quelle part du contexte d'un agent est constituée de sortie d'outils dans des exécutions réelles, et son élagage change-t-il la réussite de la tâche ?
Question ouverte : la spécification MCP indique que les clients devraient valider les résultats d'outils avant de les transmettre au modèle, mais laisse la quantité à la discrétion du client ; dans des exécutions d'agents enregistrées, quelle proportion des jetons est constituée de sortie d'outils plutôt que d'instructions ou de raisonnement, et le fait de tronquer, résumer ou filtrer la sortie des outils change-t-il la réussite de la tâche, le coût et la latence ?
-
Choisir un outil ou une compétence avec un modèle de décision : Choice pour classer, Noul pour s'abstenir
Pourquoi un Choice portant sur des outils candidats répond à une question relative (quel candidat convient le mieux) alors qu'un Noul par candidat répond à une question absolue (ce tour a-t-il seulement besoin d'un outil), et comment le cookbook de suggestion de compétences de TypeSafe combine les deux sur un catalogue de 182 compétences : une première requête classe tous les candidats, une seconde lit les trois premiers et peut tous les rejeter.
-
Vérifier, installer et confirmer les mises à jour Windows sans interface graphique
La page de mises à jour de sconfig, les vraies limites de Get-HotFix, WSUS comme voie standard de gestion des correctifs, et une méthode documentée pour détecter un redémarrage en attente avant de planifier la prochaine fenêtre de maintenance.
-
Rédiger un rapport de bug exploitable
Un rapport de bug est exploitable quand une personne extérieure peut reproduire le défaut sans poser de question : un titre précis, l'environnement avec ses versions, des étapes numérotées pour reproduire le problème, le résultat attendu et le résultat réel séparés, le message d'erreur littéral et un exemple aussi réduit que possible. Les hypothèses sur la cause figurent dans une section à part.
-
Cohérence entre nom d'hôte, FQDN et DNS inverse : pourquoi les vérifications de nom Kerberos et TLS échouent en cas de désaccord
Les tickets de service Kerberos et la vérification du nom d'hôte TLS supposent que le nom résolu par le client pour un serveur corresponde à celui que le service pense porter. Un désaccord entre le nom d'hôte configuré, /etc/hosts, le DNS direct et l'enregistrement PTR produit des erreurs d'authentification et de certificat qui semblent sans rapport avec le nommage.
-
Routage conditionné par la confiance avec un modèle de décision : des seuils qui s'ajustent aux enjeux
Comment utiliser la valeur de confiance que portent les réponses Choice et Score comme un second axe à côté de la réponse elle-même : un plancher en dessous duquel l'agent n'agit pas, et des seuils par action qui augmentent avec le coût d'une erreur, calibrés sur les données propres de la partie appelante et figés sur une version de modèle.
-
Politique sudo en fichiers drop-in dans /etc/sudoers.d, vérifiée avec visudo -c
Ajouter une règle ciblée sous forme de fichier distinct dans /etc/sudoers.d, validé par visudo avant prise d'effet, rend la politique sudo auditable et évite qu'une erreur de syntaxe ne prive tout le monde d'accès. Cette méthodologie traite aussi du risque des règles NOPASSWD trop larges et de l'endroit où sudo journalise ses décisions.
-
Lier l’identité de publication npm et PyPI aux artefacts de version approuvés
La publication de confiance par OIDC supprime les jetons de publication stockés, mais sa sécurité dépend toujours du workflow autorisé. Séparer la construction de la publication, protéger les approbations et vérifier l’identité de l’artefact sans considérer sa provenance comme un verdict sur l’absence de code malveillant.
-
Étude de cas d'un service de téléversement de fichiers : tickets directs vers le stockage, analyse asynchrone et quotas
Une étude de conception pour des téléversements qui contournent les serveurs d'application : un ticket qui réserve un quota et renvoie une URL de téléversement signée, une étape de finalisation qui vérifie l'objet stocké, un worker d'analyse qui le promeut ou le supprime, des règles de cycle de vie pour les téléversements abandonnés, et un modèle de statut qui explique chaque objet stocké.
-
epoll en mode déclenché par front : vider le travail non bloquant avant d'attendre un nouveau front
Éviter une connexion bloquée en séparant les notifications de disponibilité des messages applicatifs complets.
-
Unreal Motion Matching : construire un mouvement exploitable par la recherche avant d'ajuster les poids
Relier les schémas Pose Search, la couverture d'animation et les requêtes de trajectoire, puis s'appuyer sur les sélections enregistrées pour distinguer un mouvement manquant d'une recherche mal configurée.
-
Images adaptatives avec srcset, sizes et picture
srcset avec des descripteurs de largeur, associé à un attribut sizes, permet au navigateur de choisir le fichier image le plus petit qui remplit l'emplacement pour le viewport et la densité de pixels actuels ; les descripteurs x servent des images de taille fixe à plusieurs densités ; picture avec des éléments source gère la direction artistique et le repli de format. Toujours conserver width et height pour que la mise en page ne bouge pas pendant le chargement de l'image.
-
rc.conf, sysrc et service sous FreeBSD : activer, démarrer et vérifier ce qui s'exécute au démarrage
Sous FreeBSD, les services sont activés de manière déclarative par une variable rc.conf (dans /etc/rc.conf ou dans un fichier propre au service sous /etc/rc.conf.d) ; sysrc et service <nom> enable ne font qu'écrire cette variable, et rc.conf n'est pas censé exécuter quoi que ce soit directement : il se contente de définir des variables que lisent les scripts rc de /etc/rc.d. sysrc modifie ces variables de façon sûre depuis un script, et service démarre et arrête le script rc.d correspondant et en indique l'état.
-
Les pipelines qui rejettent à l'ingestion un changement de schéma source inattendu le détectent plus tôt en amont, mais échouent plus souvent que les pipelines qui forcent la conversion
Hypothèse : un pipeline qui fait échouer une tâche d'ingestion lorsque le schéma source diffère du schéma déclaré (à la manière dont la résolution de schéma d'Avro signale une erreur quand un champ du lecteur n'a pas de valeur par défaut et que l'écrivain ne le fournit pas) détecte les changements en amont dès la première exécution, mais échoue aussi sur des changements inoffensifs, tandis qu'un pipeline qui force la conversion continue de fonctionner et laisse certains changements atteindre les consommateurs sans être remarqués ; une comparaison proposée sur les mêmes sources, sans résultat revendiqué.
Lisible par machine : JSON