- Systemd 260 elimina el soporte a scripts System V y exige kernels modernos para aprovechar todas sus funciones.
- Refuerza seguridad y aislamiento con mejor soporte TPM2, PrivateUsers, xaccess y comprobaciones de integridad en volúmenes cifrados.
- Amplía capacidades de contenedores y redes con mstack, integración con ModemManager y nuevas opciones avanzadas en systemd-networkd.
- Introduce controles finos de CPU y memoria, servicios portables sin privilegios y documentación específica para contribuciones asistidas por IA.
La llegada de systemd 260 marca un punto de inflexión en cómo se inician, gestionan y aíslan los servicios en la mayoría de distribuciones GNU/Linux modernas. Esta versión estable introduce una oleada de cambios que afectan tanto a la administración clásica de sistemas como a entornos de contenedores, virtualización, nube y despliegues corporativos donde la seguridad y el rendimiento pesan cada vez más.
En esta edición se consolidan decisiones que llevaban tiempo cocinándose, como la retirada definitiva de los viejos scripts System V en favor de las unidades nativas de systemd, y se suman novedades orientadas a reforzar el aislamiento de servicios (sandboxing), mejorar la integración con hardware de seguridad como TPM2 y dar más control fino sobre CPU, memoria y red. Todo ello convierte a systemd 260 en una versión clave que conviene conocer a fondo antes de desplegar en producción.
Adiós definitivo a los scripts System V: solo unidades nativas
Uno de los cambios más sonados es la eliminación completa del soporte para scripts de servicios System V, también conocidos como SysV. Este soporte llevaba años marcado como obsoleto, pero en systemd 260 desaparece por completo, de modo que los sistemas deben apoyarse exclusivamente en unidades nativas de systemd para arrancar y gestionar servicios.
Para quienes todavía dependan de scripts en /etc/init.d o mecanismos de arranque heredados, el mensaje es claro: en las distribuciones que adopten systemd 260, esos servicios dejarán de arrancar si no se han migrado a unit files. Además, se eliminan componentes internos ligados a este legado, como systemd-rc-local-generator, rc-local.service, systemd-sysv-generator y systemd-sysv-install, que hasta ahora servían de puente con el mundo SysV.
Dentro del propio proceso de compilación también se notan los recortes: opciones de Meson como -Drc-local=, -Dsysvinit-path= y -Dsysvrcnd-path= pasan a estar obsoletas, mientras que otras, como -Dintegration-tests= y -Dcryptolib=, directamente se eliminan. Esto refuerza la apuesta del proyecto por simplificar el código, acabar con compatibilidades históricas y centrarse en el modelo de unidades nativas.
En entornos de producción con despliegues de larga duración o heredados, conviene revisar con lupa qué servicios siguen dependiendo de SysV y planificar la migración con tiempo. En infraestructuras europeas muy conservadoras todavía pueden quedar piezas críticas apoyadas en estos scripts, así que ignorar este cambio puede traducirse en servicios que no arrancan tras una actualización.
Requisitos de kernel más exigentes y recomendaciones de versión
Systemd 260 también sube el listón a nivel de kernel: la versión mínima de Linux soportada pasa a ser la 5.10, abandonando el soporte para la rama 5.4. Además, el proyecto recomienda utilizar, como mínimo, Linux 5.14 y se señala la serie 6.6 como referencia para aprovechar todas las capacidades introducidas en esta edición.
Este aumento de requisitos impacta especialmente en centros de datos y despliegues de ciclo muy largo donde todavía se ejecutan kernels LTS antiguos. Aunque las principales distribuciones empresariales y comunitarias actuales ya suelen estar en 5.10 o superior, en entornos con políticas muy restrictivas de actualización es fundamental comprobar qué versión de kernel se está usando antes de saltar a systemd 260.
En la práctica, esto significa que las nuevas prestaciones de seguridad, red y sandboxing se apoyan en funcionalidades del kernel que no estaban disponibles en ramas más antiguas. Quien quiera exprimir al máximo esta versión debería plantearse actualizar también el kernel a una rama moderna, especialmente si se trabaja con contenedores, virtualización intensiva o servicios de alto rendimiento.
Mstack y systemd-mstack: nuevas opciones para capas y contenedores
Entre las novedades más técnicas destaca la aparición de la función mstack y la herramienta de línea de comandos systemd-mstack. Mstack permite definir un sistema de capas basado en OverlayFS a partir de un directorio especial llamado .mstack/, siguiendo una estructura concreta que establece cómo se organizan las distintas capas.
El comando systemd-mstack facilita trabajar interactivamente con estas pilas, haciendo más cómodo crear, inspeccionar y gestionar los overlays que se apoyan en esta característica. Esta funcionalidad se relaciona de forma directa con mejoras en systemd-importd, que gana capacidad para descargar y manejar imágenes OCI, reforzando así el papel de systemd como pieza central en entornos de contenedores y sandboxing.
Todo este bloque de cambios está pensado para ampliar las opciones de aislamiento y despliegue ligero directamente desde systemd, sin depender tanto de herramientas externas. En proveedores de nube y plataformas de hosting, especialmente en Europa, donde los contenedores y servicios efímeros son el pan de cada día, este tipo de integración supone un plus de flexibilidad.
TPM2, udev y avances en sandboxing con PrivateUsers
Otra línea importante de trabajo en systemd 260 es el refuerzo del soporte para TPM2 (Trusted Platform Module 2.0), el chip o módulo de seguridad presente en muchas placas base con firmware UEFI y arranque seguro. Este hardware se utiliza, entre otras cosas, para facilitar el descifrado de discos o particiones cifradas durante el arranque, mejorando la seguridad del sistema sin penalizar la experiencia de usuario.
En esta versión, udev incorpora un nuevo comando integrado llamado tpm2_id, que sirve para extraer de forma automática el identificador de modelo y proveedor de dispositivos TPM2 a medida que son detectados. Esto simplifica la gestión de hardware de seguridad en entornos regulados, como administraciones públicas o empresas sometidas a normativas estrictas sobre protección de datos.
En paralelo, systemd sigue puliendo sus mecanismos de aislamiento. La implementación completa de PrivateUsers mediante PrivateUsers=full se ha actualizado para mapear el rango completo de identificadores de usuario (UID). Gracias a este cambio, se ha podido eliminar la solución de compromiso que existía para detectar correctamente instancias de systemd anidadas basadas en versiones anteriores a la 257.
Para quien no esté familiarizado con el concepto, PrivateUsers es una funcionalidad que crea un espacio de IDs de usuario aislado para una unidad concreta, lo que mejora el sandboxing al hacer que los procesos vean un mapa de usuarios distinto y, por tanto, queden mejor encapsulados frente al resto del sistema. Es un componente clave en la estrategia de endurecimiento de servicios de systemd.
FANCY_NAME en os-release y pequeños extras de usabilidad
En el archivo /etc/os-release, utilizado para identificar la distribución y versión del sistema, aparece un nuevo campo llamado FANCY_NAME=. Este campo es similar al ya conocido PRETTY_NAME, pero admite secuencias ANSI y caracteres Unicode más elaborados, permitiendo nombres más vistosos o diferenciados.
El valor de FANCY_NAME puede mostrarse a través del gestor de systemd, de systemd-hostnamed y del comando hostnamectl, lo que abre la puerta a que las distribuciones diseñen identificadores más atractivos o expresivos para entornos gráficos y herramientas de administración. Aunque parezca un detalle menor, en entornos corporativos con muchas máquinas puede ayudar a distinguir mejor ediciones, sabores o propósitos concretos.
systemd-networkd: integración con ModemManager y nuevas opciones de red
En el terreno de la red, systemd-networkd gana integración con ModemManager mediante el protocolo simple connect. Esta combinación facilita gestionar módems y conexiones móviles directamente desde los ficheros de configuración de networkd, lo que resulta muy útil en despliegues donde la conectividad depende de redes 4G/5G, como ubicaciones rurales o enlaces de respaldo.
Para ello se introduce una nueva sección en los archivos de configuración, que admite parámetros como APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=. Estos ajustes permiten definir de forma precisa cómo se establece y gestiona la conexión móvil en cada interfaz.
Además, los archivos .link empleados por systemd-networkd añaden nuevas opciones para afinar el comportamiento de dispositivos Ethernet. Entre ellas encontramos ScatterGather=, ScatterGatherFragmentList=, TCPECNSegmentationOffload=, TCPMangleIdSegmentationOffload=, GenericReceiveOffloadList= y GenericReceiveOffloadUDPForwarding=. Estas directivas permiten ajustar características avanzadas de offloading y recepción genérica, impactando directamente en el rendimiento de la pila de red.
También se han pulido las interfaces Varlink y JSON de systemd-networkd para que informen de las direcciones IP en formato de cadena legible para humanos, manteniendo al mismo tiempo la representación anterior como arreglo de enteros. Esto facilita la integración con herramientas de monitorización, paneles de control y scripts de administración utilizados en todo tipo de organizaciones.
Seguridad, integridad de volúmenes y delegación de acceso a dispositivos
Systemd 260 incorpora mejoras relevantes en materia de seguridad. Por un lado, systemd-repart añade comprobaciones básicas de integridad para volúmenes cifrados, lo que aporta una capa adicional de confianza cuando se trabaja con particiones protegidas mediante tecnologías de cifrado.
Por otro, systemd-logind y systemd-udevd introducen el concepto “xaccess”. Esta lógica permite delegar el uso de dispositivos concretos a usuarios con sesiones marcadas de forma especial, complementando el esquema existente de “uaccess”, que concede acceso a dispositivos a usuarios con sesiones en primer plano.
El caso de uso principal de xaccess es otorgar acceso controlado a dispositivos de renderizado de GPU a sesiones gráficas locales asociadas a usuarios remotos que no están físicamente en un puesto. La configuración se realiza mediante la variable de entorno PAM XDG_SESSION_EXTRA_DEVICE_ACCESS=, que se puede emplear en pilas de autenticación PAM para afinar qué hardware se expone a quién.
En contextos con requisitos estrictos de cumplimiento normativo y protección de datos, como los que se encuentran en la Unión Europea, poder delegar acceso a hardware sensible con tanta granularidad encaja muy bien con las necesidades de auditoría y control. Al mismo tiempo, se evita abrir de más los permisos de dispositivos a todo el sistema.
Servicios portables y máquinas efímeras para usuarios sin privilegios
En el ámbito de la portabilidad de servicios, systemd-portabled adquiere la capacidad de ejecutarse como servicio a nivel de usuario. Esto significa que cuentas sin privilegios pueden lanzar servicios portables dentro de su propio espacio, siempre que el kernel lo soporte, sin necesidad de recurrir a sudo ni elevar privilegios.
Además, systemd-portabled puede generar una política y fijar la imagen asociada a un servicio portable, de forma que esa imagen no pueda modificarse posteriormente sin volver a adjuntarla. Este detalle refuerza la seguridad y la reproducibilidad, evitando sorpresas por cambios silenciosos en las imágenes.
Por su parte, systemd-vmspawn se integra mejor con systemd-machined en la sesión de usuario, lo que facilita gestionar máquinas virtuales de manera más coherente dentro del ecosistema systemd. También se añade la opción --ephemeral para crear máquinas efímeras que se destruyen automáticamente al terminar su uso, algo especialmente atractivo para laboratorios, entornos de CI/CD o aulas donde se levantan y tiran entornos constantemente.
Estas mejoras encajan con la tendencia de descentralizar parte de la gestión de servicios hacia los propios usuarios, reduciendo la dependencia de la cuenta root y mejorando el aislamiento entre entornos. Para desarrolladores y equipos de pruebas, supone una forma cómoda de experimentar sin comprometer el sistema principal.
Control fino de CPU y memoria: SCHED_EXT y THP por servicio
Systemd 260 amplía el conjunto de directivas disponibles para gestionar el rendimiento. La opción CPUSchedulingPolicy= acepta ahora el valor ext, que permite activar el planificador SCHED_EXT. Este planificador, aún experimental, abre la puerta a políticas de planificación alternativas a las habituales en Linux, pensadas para escenarios avanzados.
Esta integración hace posible que servicios concretos se ejecuten bajo políticas de planificación especializadas, algo interesante para cargas críticas que requieran un comportamiento muy predecible o que estén siendo evaluadas en entornos de investigación y desarrollo.
En el lado de la memoria, se introduce la directiva MemoryTHP= para controlar el uso de Transparent Huge Pages (THP) por servicio. En lugar de activar o desactivar THP de manera global, ahora se puede decidir de forma precisa qué unidades se benefician de esta característica y cuáles no, según sus patrones de acceso a memoria.
Esta granularidad resulta especialmente valiosa en aplicaciones financieras, de seguros o de administración pública, donde se buscan equilibrios delicados entre rendimiento, latencia y consumo de recursos. Ajustar THP servicio por servicio ayuda a evitar efectos secundarios indeseados en procesos que no se llevan bien con las páginas enormes.
Varlink, nuevas utilidades y mejoras en systemctl
El proyecto sigue empujando el uso de Varlink como mecanismo de comunicación entre componentes. Systemd 260 continúa extendiendo este protocolo a distintas partes del ecosistema, lo que contribuye a una arquitectura más coherente y a una integración más sencilla con herramientas externas que quieran interactuar con systemd de forma estructurada.
En el área de administración, el conocido comando systemctl incorpora una nueva orden llamada enqueue-marked. Esta acción invoca internamente el método D-Bus EnqueueMarkedJobs(), lo que permite manejar colas de trabajos previamente marcados y habilita flujos de trabajo de orquestación más sofisticados en grandes granjas de servidores.
Aunque estas mejoras puedan pasar desapercibidas para el usuario final, para los equipos de operaciones que gestionan cientos o miles de máquinas suponen una ayuda importante a la hora de automatizar despliegues, reinicios controlados y tareas de mantenimiento.
Documentación específica para agentes de IA y contribuciones asistidas
Una de las sorpresas de esta línea de desarrollo es la inclusión en el repositorio de documentación pensada expresamente para agentes de inteligencia artificial. Se añade un archivo AGENTS.md que describe la arquitectura interna de systemd, el flujo de desarrollo, el estilo de código y las pautas de contribución, todo ello orientado a que herramientas de IA entiendan mejor el proyecto.
Este documento proporciona indicaciones sobre cómo ejecutar comandos, realizar pruebas de integración y revisar cambios, con la intención de que los asistentes de programación y revisión automática sean más precisos y útiles. Es una señal clara de que systemd asume que la IA formará parte del ciclo de vida del software de ahora en adelante.
Junto a ese archivo aparece CLAUDE.md, que referencia directamente a AGENTS.md como material de apoyo para la herramienta Claude Code, uno de los asistentes de desarrollo basados en IA más populares. Además, en el repositorio se incluye un fichero de configuración claude-review.yml, donde se describe cómo debe emplearse Claude Code para ayudar en la revisión de pull requests.
Todo este conjunto se complementa con requisitos de divulgación explícita para contribuciones que usen IA, como el uso de etiquetas Co-developed-by en los parches. De esta forma, el proyecto apuesta por una integración responsable de la inteligencia artificial en su flujo de trabajo, sin perder la trazabilidad de quién (o qué) ha intervenido en cada cambio.
Sumando todas estas piezas, systemd 260 se consolida como una versión que limpia compatibilidades antiguas, refuerza la seguridad mediante TPM2, sandboxing y comprobaciones de integridad, amplía las capacidades de red y contenedores y da pasos muy claros hacia un ecosistema en el que la automatización, la virtualización ligera y la colaboración con herramientas de IA son parte del día a día. Para administradores y desarrolladores, el reto está en revisar sus infraestructuras, verificar kernels, adaptar configuraciones y decidir qué novedades tiene sentido aprovechar en cada caso.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.