Multikernel Technologies publicó el código de KernelScript bajo licencia Apache 2.0 esta semana; la propuesta llega mientras el Storage Summit debate si los LLMs pueden revisar parches del kernel con fiabilidad comparable a la de los maintainers humanos.
Multikernel Technologies publicó el código bajo Apache 2.0 en la semana del 27 de mayo; el lenguaje propone hacer que escribir programas eBPF sea más seguro y accesible que en C puro, con un sistema de tipos que previene los errores más comunes del verificador del kernel.
Multikernel Technologies presentó esta semana KernelScript, un lenguaje de dominio específico diseñado para simplificar el desarrollo de programas eBPF en el kernel Linux. Según Phoronix, que publicó el análisis más detallado del proyecto, el objetivo es hacer que los programas eBPF sean más fáciles de escribir que en C puro y unificar el desarrollo de eBPF, código de espacio de usuario y extensiones de kernel en un lenguaje tipado de forma segura. El código se publicó bajo licencia Apache 2.0 con una implementación de referencia en Rust. eBPF —Berkeley Packet Filter extendido— es la tecnología que permite inyectar lógica en el kernel de Linux sin modificar su código fuente ni recompilar el sistema. La infraestructura de observabilidad, seguridad y redes de empresas como Meta, Google, Netflix y Cloudflare depende masivamente de eBPF. KernelScript propone abstraer las restricciones del verificador del kernel Linux que hoy hacen que escribir programas eBPF correctos requiera conocimiento muy específico de las reglas internas del verificador. El ángulo contrario: Alexei Starovoitov, uno de los creadores de eBPF y engineer en Meta, señaló en la lista de correo del kernel que introducir un nuevo lenguaje fragmenta el ecosistema y que la dirección correcta es mejorar el compilador de C a eBPF (clang-bpf) con mejores mensajes de error y verificación estática, no añadir otra capa de abstracción. La discusión en LKML continúa. Para los ingenieros de infraestructura en empresas tecnológicas de Costa Rica que usan eBPF en sus stacks de observabilidad —varios parques de zonas francas usan Cilium, que depende de eBPF— el proyecto vale la pena seguir aunque la adopción en producción tomaría al menos dos años.
Una sesión plenaria del Linux Storage, Filesystem, Memory Management y BPF Summit de 2026 debatió el uso de modelos de lenguaje para revisar parches del kernel, un tema que lleva varios meses circulando en la comunidad según LWN.net. Roman Gushchin, Chris Mason, Josef Bacik y Sasha Levin presentaron un análisis de 200 parches del subsistema de memoria que fueron revisados tanto por LLMs (Claude y GPT-5.5) como por maintainers humanos, comparando la tasa de detección de bugs reales versus la tasa de falsos positivos. Los resultados preliminares son mixtos: los LLMs detectaron el 74% de los bugs que los revisores humanos encontraron, pero también generaron un 31% de observaciones que los humanos clasificaron como falsos positivos o ruido. La velocidad es la ventaja obvia: un LLM procesa el parche en segundos frente a los días o semanas que puede tomar la revisión humana en la cola de un subsistema muy activo. El ángulo contrario: Levin advirtió que el 26% de bugs que los LLMs no detectaron tienden a ser exactamente los más sutiles —condiciones de carrera en arquitecturas específicas, interacciones con código de hardware— que son también los más peligrosos en producción. La conclusión provisional del grupo es que los LLMs son útiles como primer filtro pero no como sustitutos del revisor humano en parches de alto impacto. Para los desarrolladores costarricenses que contribuyen al kernel o a proyectos upstream, el resultado sugiere que las herramientas de revisión automática pueden mejorar la velocidad de iteración en PRs de cambios menores.
— Roman Gushchin presentó en el Linux Storage, Filesystem, Memory Management y BPF Summit de esta semana las primeras métricas comparativas entre revisión humana y revisión asistida por modelos de lenguaje en parches del subsistema de memoria.
cat /feed/kernelseguridad.md
El grupo de seguridad del kernel publicó esta semana una propuesta de diseño para un componente de desconexión de emergencia que permitiría mitigar temporalmente una vulnerabilidad explotada sin esperar el ciclo completo de parche.
> El grupo de seguridad del kernel Linux publicó el miércoles 27 de mayo una propuesta de diseño para agregar un componente de kill switch al kernel: un mecanismo que permitiría a administradores de sistema desactivar temporalmente una funcionalidad vulnerable —sin aplicar el parche completo— mientras el parche oficial completa el ciclo de revisión, compilación y despliegue. La propuesta surge del análisis del tiempo promedio de explotación activa después de la publicación de un CVE crítico: según datos del CERT/CC, ese ventana es de 4,8 días en promedio, mientras el ciclo de parche del kernel tarda entre 7 y 21 días desde la confirmación hasta que el parche llega a las distribuciones LTS.
> La propuesta tiene dos componentes: un nuevo syscall `secmod_disable()` que permite deshabilitar un módulo o subsistema específico en tiempo de ejecución sin reiniciar el sistema, y un mecanismo de notificación que alerta a los administradores cuando una funcionalidad fue deshabilitada y el parche oficial está disponible. El ángulo contrario: Greg Kroah-Hartman señaló en la lista de correo que la existencia de un kill switch crea un incentivo perverso: los administradores de seguridad presionarán para usarlo en vulnerabilidades donde el parche existe pero aún no se ha probado en producción, aumentando el riesgo de interrupciones del servicio. La propuesta requiere múltiples rondas adicionales de revisión antes de ser considerada para inclusión. Para las empresas costarricenses que administran infraestructura crítica con Linux, la propuesta es relevante porque el kill switch reduciría el tiempo de respuesta ante vulnerabilidades como io_uring que afectan servicios en producción.
La versión lanzada el 25 de mayo incluye el kernel Linux 7.0 por primera vez, un instalador renovado con mejor detección de hardware heredado y las ediciones habituales con Xfce, KDE Plasma y Fluxbox.
MX Linux 25.2 «Infinity», lanzado el 25 de mayo de 2026, es la segunda actualización de la serie MX 25 y la primera en incluir el kernel Linux 7.0 como opción predeterminada en las instalaciones nuevas. La distribución, derivada de Debian Stable con herramientas de administración propias del proyecto MX, mantiene su posición como la más descargada en Distrowatch gracias a su combinación de estabilidad, bajo consumo de recursos y las utilidades MX Tools que simplifican tareas como snapshots del sistema, gestión de paquetes planos y configuración de redes. El instalador renovado de la 25.2 mejora la detección de hardware heredado, especialmente en tarjetas gráficas NVIDIA de generaciones 700-900 y adaptadores WiFi Intel de las series AC 7260 y AC 8260 que tenían problemas de detección automática en la 25.1. Las ediciones con Xfce, KDE Plasma y Fluxbox están disponibles para arquitecturas x86_64, y la imagen para Raspberry Pi usa Fluxbox como entorno por defecto. El ángulo contrario: el proyecto MX Linux fue criticado esta semana en el foro de comunidad por su decisión de mantener el repositorio de paquetes planos (flatpak) como segunda clase —los paquetes DEB siguen siendo los preferidos por el equipo— en un momento en que el resto del ecosistema Debian-basado adopta flatpak como canal principal para aplicaciones de terceros. El mantenedor principal respondió que la política no cambiará hasta que flatpak resuelva sus problemas de sandboxing en distribuciones con systemd <250. Para los usuarios en Costa Rica, MX Linux 25.2 es la recomendación más sólida para hardware heredado con menos de 4 GB de RAM.
Siete semanas después del anuncio de Linus Torvalds el 12 de abril de 2026, el kernel Linux 7.0 está presente en el 34% de las distribuciones activas rastreadas por Distrowatch, según los datos del 28 de mayo. La adopción más rápida se produjo en las distribuciones rolling release: Arch Linux fue la primera con la ISO del 1 de mayo, seguida por Rhino Linux 2026.1 (23 de mayo) y MX Linux 25.2 (25 de mayo). Ubuntu 26.04 LTS incluye el 7.0 en su canal principal desde el lanzamiento del 23 de abril. Fedora 44, lanzada el 29 de abril, adoptó el 7.0 como kernel predeterminado en su primera semana. Las principales novedades del kernel 7.0 que están impulsando la adopción son el soporte ampliado para arquitecturas RISC-V y LoongArch, los nuevos controladores para SoCs Qualcomm de la serie X Elite, y las mejoras en el subsistema de gestión de memoria para sistemas con memoria en capas (tiered memory) que benefician a los servidores de IA. El ángulo contrario: el blog Soplos Linux publicó un análisis técnico del 26 de mayo señalando que el kernel 7.0.1 —la primera actualización de estabilización— corrigió 14 regresiones respecto al 7.0 que afectaban a tarjetas gráficas AMD de las series RX 5000 y RX 6000, y recomendó esperar al 7.0.2 antes de actualizar en producción.
Rhino Linux 2026.1, lanzado el 23 de mayo, incorporó por primera vez en la historia del proyecto imágenes ISO genéricas con Lomiri —el entorno de escritorio desarrollado por UBports que adapta la misma interfaz a escritorio, portátil y teléfono— para las arquitecturas x86_64 y ARM64. La integración de Lomiri en una distribución rolling release basada en Ubuntu es técnicamente significativa porque Lomiri ha sido históricamente difícil de compilar fuera del ecosistema de Ubuntu Touch por sus dependencias en versiones específicas de Qt y Wayland. El proyecto Rhino Linux, conocido por adoptar tecnología experimental antes que otras distribuciones, publicó el paquete `rhino-setup` 2.3 junto al lanzamiento, que automatiza la configuración inicial de Lomiri y la instalación de las aplicaciones más comunes en formato flatpak. El ángulo contrario: la convergencia de escritorio y móvil que Lomiri promete fue el objetivo original de Ubuntu Touch de Canonical en 2013, un proyecto que fracasó comercialmente y fue cancelado en 2017. El proyecto UBports lo mantiene vivo con recursos voluntarios, y su integración en Rhino Linux es un experimento técnico interesante pero con incierta viabilidad a largo plazo más allá de la comunidad entusiasta. Para usuarios de Linux en Costa Rica con dispositivos PinePhone o Librem 5, Rhino Linux 2026.1 con Lomiri es la opción más actualizada disponible.
El ecosistema Linux cierra mayo con propuestas que apuntan a la accesibilidad del desarrollo de kernel (KernelScript), la agilidad de respuesta ante vulnerabilidades (kill switch) y la velocidad de adopción de nuevas versiones.
La semana del 25 al 29 de mayo pone sobre la mesa tres tensiones que el proyecto Linux lleva años gestionando. La primera: cómo hacer que el desarrollo del kernel sea accesible a más contribuidores sin comprometer la fiabilidad del código —KernelScript es la propuesta más reciente, y como todas las propuestas de mayor abstracción en la historia del kernel, enfrenta resistencia de los maintainers que valoran el control fino de C. La segunda: cómo reducir el tiempo entre la divulgación de una vulnerabilidad y su mitigación —el kill switch aborda ese gap. La tercera: cómo acelerar la adopción de mejoras en producción —el 34% de adopción de Linux 7.0 en siete semanas es el número más optimista en años. Para el ecosistema Linux en Costa Rica, el panorama de la semana tiene impacto práctico en dos grupos: los administradores de sistemas que gestionan infraestructura crítica necesitan evaluar la actualización a kernel 7.0 con la precaución de esperar al 7.0.2 en entornos con tarjetas AMD; y los desarrolladores que trabajan con eBPF en stacks de observabilidad tienen en KernelScript una herramienta que vale la pena seguir aunque su adopción en producción sea aún lejana.