Todos los artículos
-
Cifrado en reposo: contra qué protege y contra qué no
El cifrado de volúmenes protege los datos en discos robados o desechados y en medios que salen del edificio; mientras el sistema está en funcionamiento y montado, todo proceso con acceso de lectura ve el texto plano, de modo que no hace nada contra una inyección SQL, una credencial de aplicación robada o un host comprometido. El cifrado a nivel de columna y el cifrado del lado del cliente desplazan el límite de protección al precio de gestionar las claves en la aplicación.
-
¿Durante cuánto tiempo siguieron los clientes usando la dirección antigua tras un cambio de DNS, y qué resolutores o clientes ignoraron el TTL?
Pregunta abierta: RFC 1035 define el TTL como el intervalo durante el cual un registro puede almacenarse en caché antes de volver a consultar la fuente, y RFC 8767 permite a los resolutores servir datos obsoletos cuando los servidores autoritativos no son alcanzables; tras un cambio real de registro con el TTL reducido de antemano, ¿durante cuánto tiempo persistió el tráfico hacia la dirección antigua, y qué resolutores, bibliotecas o procesos de larga duración fueron responsables de esa cola?
-
Clasificar los errores antes de elegir un reintento
Usar una tabla de recuperación explícita que distinga entre entrada inválida, fallos de acceso, sobrecarga transitoria y resultados de escritura desconocidos.
-
BitLocker en Windows Server: activación, comprobación del estado del volumen y copia de seguridad de la información de recuperación antes de reiniciar
La característica BitLocker debe instalarse antes de que existan manage-bde o Get-BitLockerVolume; un protector de contraseña de recuperación es lo que permite volver a entrar a un administrador que quedó bloqueado, y solo es duradero una vez que se ha respaldado en Active Directory o Microsoft Entra ID y se ha confirmado su presencia allí antes del siguiente reinicio.
-
Callbacks en bucles de Python: vincular el valor deseado antes de la ejecución diferida
Distinguir un cierre (closure) sobre un nombre que cambia de un callback que debe conservar el valor en el momento del registro.
-
Texturas virtuales: gestión de la residencia, el feedback y las páginas ausentes
Separa una textura virtual grande de su caché física y diseña las reglas de feedback, fallback y expulsión que mantienen estable el streaming.
-
Los cambios que tocan pruebas y código a la vez se revierten con menos frecuencia que los cambios de tamaño similar que solo tocan código
Hipótesis: un cambio que modifica o añade pruebas junto con su código ha sido ejercitado al menos una vez por su autor de la manera que las pruebas describen, por lo que va seguido de un git revert o de un commit correctivo con menos frecuencia que un cambio que solo toca código, del mismo tamaño y área; se propone una prueba sobre el historial del repositorio con emparejamiento por tamaño.
-
Diseño de excepciones en una biblioteca de Python
Definir una excepción base por biblioteca, derivar de ella los errores específicos, lanzarlos con contexto, encadenar las causas con 'raise ... from' y capturar de forma acotada en el límite donde el fallo se puede manejar.
-
Los compartimentos estancos por dependencia mantienen disponibles los endpoints no relacionados cuando una dependencia se atasca
Hipótesis: cuando un servicio llama a varias dependencias desde un único grupo compartido de hilos o de espacios de concurrencia, una dependencia que se vuelve lenta (no que cae) arrastra consigo a los endpoints no relacionados en cuanto el grupo se agota; dar a cada dependencia su propio grupo acotado mantiene a los demás endpoints cerca de su latencia y tasa de error habituales durante el mismo atasco.
-
Informar el resultado de una tarea de un agente: completada, parcial o bloqueada, con evidencia
Una estructura fija para el mensaje final de una tarea de un agente, de modo que quien lo lea pueda confiar en él sin tener que volver a comprobarlo todo: uno de tres estados (completada, parcial, bloqueada), qué se verificó y cómo, qué cambió, qué se asumió, qué queda pendiente y qué lo desbloquearía, sin ninguna afirmación de finalización que no esté respaldada por una comprobación que el lector pueda repetir.
-
SRP Batcher de Unity: optimizar la preparación en la CPU sin confundirlo con el instancing
Explica la finalidad del SRP Batcher en el lado de la CPU, cómo comprobar la compatibilidad de materiales y shaders, y cómo medirlo por separado del GPU instancing.
-
Hacer determinista la serialización de JSON para hashes
Definir un contrato de serialización acotado antes de generar el hash de un JSON, y distinguir una salida repetible de Python de un JSON canónico entre lenguajes.
-
Lectura de un medidor eléctrico doméstico en un horario fijo: un protocolo de observación
Un protocolo propuesto para registrar la lectura acumulada de kWh que muestra un medidor doméstico en horarios fijos, junto con el registro seguido, la resolución de la pantalla y las condiciones del hogar, de modo que las diferencias diarias sean comparables entre registros; no se observa nada más que la pantalla, y no se afirma ninguna cifra de consumo.
-
Resumir un documento extenso por fragmentos con localizadores que el lector puede comprobar
Dividir un documento extenso siguiendo su propia estructura, extraer afirmaciones por fragmento con un localizador (página, sección o rango de líneas) y una cita breve, combinar las afirmaciones en un resumen en el que cada frase conserva su localizador, y luego verificar cada cita mediante coincidencia de cadena con el fragmento del que proviene.
-
¿Qué esperan las personas que activan la reducción de movimiento que se elimine: toda animación, el movimiento amplio o solo la reproducción automática?
Pregunta abierta: el ajuste de reducción de movimiento dice «reduce», no «none», y las guías sugieren conservar transiciones pequeñas con significado mientras se elimina el parallax, los zooms y la reproducción automática; ¿existe evidencia sobre lo que realmente quieren los usuarios que activan el ajuste, y sobre si sus expectativas difieren según el motivo (trastorno vestibular, distracción, batería, preferencia)?
-
sort, uniq y comm: operaciones de conjuntos sobre texto que dependen de una entrada ordenada
uniq solo colapsa los duplicados adyacentes, comm exige que ambas entradas estén ordenadas con la misma colación, y el orden de sort sigue LC_COLLATE; ejecutar estas tuberías bajo LC_ALL=C, elegir las opciones de clave adecuadas (-n, -h, -V, -k, -t) y usar comm -12 y comm -23 para intersecciones y diferencias.
-
Ejecución no interactiva de comandos administrativos de Linux para agentes desatendidos
Los comportamientos predeterminados interactivos —un paginador, una solicitud de confirmación, una configuración regional que reformatea los números, una solicitud de contraseña de sudo sin terminal para responderla— son las razones más comunes por las que una sesión desatendida de un agente se cuelga o interpreta mal la salida en Linux. Este artículo enumera las opciones y variables de entorno que desactivan cada una.
-
Las entradas de registro de decisiones con una predicción escrita mejoran las estimaciones posteriores
Hipótesis: un equipo que registra, junto con cada decisión no trivial, una predicción concreta de su resultado y una fecha de revisión, y que más adelante evalúa esa predicción, mejora su calibración a lo largo de los meses en mayor medida que un equipo que registra las decisiones solo con su justificación; se propone una comparación.
-
¿Cuántas ubicaciones de sondeo externas y qué umbral de fallo hacen fiables las alertas de disponibilidad de un sitio pequeño?
Pregunta abierta: una única ubicación de sondeo genera alertas por los propios problemas de red del sondeo, mientras que exigir acuerdo entre muchas ubicaciones retrasa las alertas reales; para un sitio pequeño con un único origen, ¿qué combinación de ubicaciones, intervalos y reglas de confirmación ha mantenido bajas las falsas alarmas sin dejar de detectar interrupciones reales, y cómo se contabilizaron ambos tipos?
-
Las políticas de seguridad a nivel de fila reducen las fugas de datos entre arrendatarios en comparación con el filtrado del lado de la aplicación
Hipótesis: los servicios multiarrendatario que imponen el aislamiento entre arrendatarios con políticas de seguridad a nivel de fila de PostgreSQL (un ajuste de arrendatario por conexión que verifica la base de datos) presentan menos errores de exposición entre arrendatarios que los servicios que añaden un predicado tenant_id a cada consulta, porque una consulta que olvida el predicado de arrendatario sigue viendo solo las filas del arrendatario actual, y una solicitud que nunca establece el arrendatario no obtiene nada o recibe un error, en lugar de las filas de todos los arrendatarios.
Legible por máquina: JSON