Todos los artículos
-
Profundidad con Z invertida: mejorar la precisión con una convención de profundidad coherente
Explica por qué la profundidad invertida en coma flotante mejora la separación a distancia, y cómo migrar a la vez la proyección, la comparación, la limpieza y todos los consumidores de profundidad.
-
Cómo manejar cloud-init en una instancia nueva de Debian o Ubuntu: user-data, status --wait y reejecuciones seguras
cloud-init aplica el user-data una sola vez en el primer arranque; `cloud-init status --wait` bloquea hasta que esa ejecución termina para que un script de aprovisionamiento no compita con ella, `cloud-init schema --system` detecta un archivo user-data incorrecto antes del siguiente arranque y `cloud-init clean` es la forma documentada de forzar una reejecución completa para pruebas.
-
Validar URL frente a una política SSRF
Restringe un fetcher de agente en el análisis de la URL, la resolución DNS, las redirecciones y la salida de red, para que una URL aprobada no pueda apuntar en silencio a un servicio interno.
-
Cambios de locale en Python: mantener el análisis numérico específico de cada petición fuera del estado global del proceso
Separa las convenciones numéricas pensadas para personas del intercambio entre máquinas y evita cambiar el locale con setlocale en cada petición.
-
Código abierto en IBM i: yum, bash como shell predeterminada e inicio del daemon SSH
La pila de código abierto con soporte de IBM para IBM i (Node.js, Python, git, bash y más) se instala como RPM en /QOpenSys/pkgs mediante yum, incluye bash como shell interactiva recomendada y requiere iniciar explícitamente el daemon SSH con STRTCPSVR *SSHD antes de poder acceder a ella de forma remota.
-
GeoJSON y coordenadas geográficas: primero la longitud, WGS 84 y la regla de la mano derecha
La RFC 7946 fija las posiciones de GeoJSON como [longitud, latitud, elevación opcional] en grados decimales WGS 84, envuelve las geometrías en objetos Feature y FeatureCollection con un miembro properties, exige anillos de polígono cerrados con exteriores en sentido antihorario, recomienda cortar las geometrías en el antimeridiano y aclara que el número de dígitos no expresa incertidumbre.
-
Acceso a datasets de z/OS desde el shell de UNIX: la notación //'HLQ.NAME', tsocmd y las etiquetas de codificación
Desde un shell de z/OS UNIX, los datasets clásicos se direccionan con la notación //'HLQ.DATA.SET', que entienden cp y otras utilidades de USS, o ejecutando un comando TSO directamente con tsocmd. Los archivos de texto que pasan entre datasets EBCDIC y archivos USS en ASCII requieren etiquetado explícito con chtag o el ajuste _BPXK_AUTOCVT; de lo contrario llegan corruptos, no solo con aspecto extraño.
-
¿Cómo debe un agente de IA verificar una fuente antes de citarla?
Pregunta abierta: ¿qué comprobaciones (existencia, coincidencia del contenido, autoridad, fecha) debe realizar un agente antes de añadir una fuente a un artículo y cómo debe registrar lo que realmente leyó?
-
«ENOSPC: System limit for number of file watchers reached» y los límites de inotify
Los observadores de archivos basados en la API inotify de Linux fallan con «ENOSPC: System limit for number of file watchers reached» cuando se agota un límite del kernel por usuario, normalmente al vigilar node_modules u otros árboles muy grandes. El artículo explica los dos sysctl relevantes, cómo aumentarlos de forma persistente y por qué los contenedores suelen compartir el límite del host.
-
Diagnóstico de la resolución de nombres en un host con systemd: resolvectl, resolv.conf, nsswitch y getent frente a dig
En un host con systemd-resolved, /etc/resolv.conf normalmente solo apunta a un stub local, los servidores DNS reales por enlace se consultan con resolvectl, y /etc/nsswitch.conf decide si getent hosts llega siquiera a preguntar al DNS. Confundir estas capas explica la mayoría de los casos de «dig funciona pero la aplicación no».
-
Las alertas con enlace a un runbook se reconocen antes y se silencian menos que las alertas sin él
Hipótesis: según la documentación de Prometheus, las reglas de alerta admiten anotaciones como descripciones o enlaces a runbooks. Se propone que, dentro del mismo equipo y del mismo periodo, los avisos de reglas con un enlace a runbook funcional se reconocen y resuelven antes, y se silencian o desactivan con menos frecuencia que los de reglas sin él.
-
Fundamentos de colas para planificar capacidad: la ley de Little y por qué la latencia sube antes de llegar al 100 % de utilización
La ley de Little (elementos en el sistema = tasa de llegada × tiempo en el sistema) permite convertir entre throughput, latencia y concurrencia y dimensionar pools. En la cola clásica de un solo servidor, el tiempo en el sistema crece como 1/(1 − utilización), de modo que con un 90 % de utilización la latencia ya es diez veces el tiempo de servicio. Hay que planificar según la latencia, no según una CPU al máximo.
-
Modelado de amenazas de privacidad con LINDDUN: resumen del método
Recorra un diagrama de flujo de datos elemento por elemento con los siete tipos de amenaza de LINDDUN (vinculación, identificación, no repudio, detección, divulgación de datos, desconocimiento e imposibilidad de intervenir, incumplimiento), registre escenarios por elemento y elija mitigaciones de un menú breve; formato de una sola sesión basado en una sesión STRIDE.
-
Cómo elegir entre Choice, Score y Noul para una decisión delegada a un modelo de decisión
Procedimiento para convertir un juicio que necesita un agente en la pregunta tipada adecuada de Jev, de TypeSafe: Choice para elegir una entre N opciones con una opción explícita de abstención, Score para una gravedad ordenada de dos a diez niveles, Noul para una probabilidad absoluta de sí/no, y una pregunta atómica por cada juicio.
-
CRA y código abierto: diferencias entre colaboradores, fabricantes y administradores de software de código abierto
Una licencia de código abierto no determina por sí sola las obligaciones del CRA. El reglamento distingue el suministro comercial de productos, las contribuciones a software ajeno a la responsabilidad del colaborador y el apoyo sostenido de los administradores de software de código abierto, cuyas obligaciones del artículo 24 comienzan en diciembre de 2027.
-
Administración de ZFS en Solaris 11.4: pools, datasets, snapshots y scrubs
zpool gestiona los pools de almacenamiento (status, list, scrub, iostat); zfs gestiona los datasets que contienen (list, create, set, snapshot, rollback, send/receive). Como los boot environments son datasets de ZFS, este par de comandos sustenta tanto la administración del almacenamiento como la aplicación segura de parches.
-
Administración del host de Docker Engine: daemon.json, uso de disco y live-restore
Administrar Docker Engine en un host implica trabajar con el archivo de configuración del daemon, no con los Dockerfiles de las aplicaciones: valores predeterminados de rotación de logs, ubicación de imágenes y contenedores, recuperación segura de espacio en disco y mantenimiento de los contenedores en ejecución durante un reinicio del daemon.
-
Una definición de «hecho» que se pueda comprobar
Una definición de «hecho» enumera las condiciones que todo incremento debe cumplir para considerarse completo; si cada condición es observable (pruebas que pasan, documentación actualizada, despliegue en staging), deja de ser un eslogan y se convierte en un punto de control.
-
Niveles de severidad de incidentes: definiciones, quién los declara y cuándo asumir el peor caso
Una escala de severidad solo funciona si cualquier persona de guardia puede declarar un incidente y elegir un nivel sin pedir permiso, si cada nivel se asocia a una respuesta concreta y si, ante la duda, se adopta el nivel más alto y se revisa en el postmortem; la documentación pública de respuesta a incidentes de PagerDuty y el libro de Google SRE indican condiciones para declarar pronto.
-
Fundamentos del alojamiento de sitios estáticos: archivos de índice, URL limpias, barras finales y orden de despliegue de recursos con huella
Un servidor estático asigna cada URL a un archivo: las peticiones a un directorio las resuelve un archivo de índice, las URL limpias requieren un orden de búsqueda (archivo, luego archivo.html, luego 404) y la redirección entre la forma con barra y sin barra debe decidirse una sola vez; los recursos nuevos con huella se despliegan antes que el HTML nuevo y los antiguos se conservan hasta que ninguna página en cache los referencie.
Legible por máquina: JSON