- Systemd 260 elimina definitivamente el soporte a scripts SysV y exige adoptar unidades nativas.
- La versión sube el requisito mínimo de kernel a Linux 5.10 y refuerza TPM2, sandboxing y control de acceso.
- Se amplían capacidades en red, contenedores y servicios portables, con más control de CPU y memoria.
- El proyecto integra documentación y flujos de trabajo específicos para herramientas de inteligencia artificial.
La llegada de systemd 260 marca un antes y un después en el ecosistema de las distribuciones Linux modernas. No se trata solo de una actualización más del framework que se encarga del arranque y la gestión de servicios, sino de una versión que rompe definitivamente con parte del legado clásico y refuerza áreas clave como la seguridad con TPM2, el aislamiento de servicios y la integración con contenedores y redes avanzadas. Es una de esas ediciones que obligan a los administradores a revisar con calma qué tienen desplegado.
En esta nueva versión estable nos encontramos con cambios de calado tanto técnicos como organizativos: adiós definitivo a los scripts SysV, nuevos requisitos mínimos de kernel, herramientas pensadas para escenarios de virtualización y contenedores, ajustes de rendimiento a nivel de CPU y memoria, más control sobre el acceso a dispositivos, integración con módems y, de forma muy llamativa, documentación específica para agentes de inteligencia artificial que analizan el código del proyecto. Vamos a desgranar, con calma pero sin rodeos, todo lo que trae systemd 260 y qué implica para quienes administran sistemas, sobre todo en entornos europeos.
Adiós definitivo a SysV: solo unidades nativas de systemd
Uno de los puntos más contundentes de esta versión es la retirada completa del soporte para los scripts de inicio de System V, los clásicos scripts en /etc/init.d y derivados. Ese soporte llevaba años en fase de retirada, pero con systemd 260 desaparece por completo, lo que significa que cualquier distribución que adopte esta versión se apoyará exclusivamente en unidades nativas de systemd para gestionar servicios.
Como consecuencia directa, se han eliminado componentes internos que servían como puente con el viejo mundo SysV: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator y systemd-sysv-install dejan de formar parte del proyecto. Es decir, el mecanismo tradicional que permitía seguir arrancando servicios heredados basados en scripts ya no estará disponible, así que si aún tienes algo colgando de ese modelo, va siendo hora de migrarlo.
En la parte de compilación también hay limpieza: las opciones de Meson relacionadas con ese legado han cambiado de estatus. Las banderas -Drc-local=, -Dsysvinit-path= y -Dsysvrcnd-path= pasan a estar obsoletas, mientras que otras como -Dintegration-tests= y -Dcryptolib= directamente desaparecen de la configuración. Esto obliga a adaptar recetas de construcción y scripts de empaquetado de distribuciones que se apoyasen en estas opciones.
Para los administradores de sistemas en España y en el resto de Europa esto se traduce en una exigencia clara: todos los servicios deben estar definidos como unit files de systemd. Si en tus servidores todavía sobreviven scripts clásicos de arranque, en cuanto la distribución que uses salte a systemd 260 esos servicios simplemente no se iniciarán. La migración a unidades nativas ya no es una recomendación, es una obligación técnica.
Requisitos de kernel más estrictos y recomendaciones de versión
Systemd 260 también aprieta las tuercas en cuanto a la base sobre la que se ejecuta. La versión mínima del kernel Linux soportada pasa a ser la 5.10, dejando atrás ramas antiguas que durante mucho tiempo se usaron como LTS. Además, el propio proyecto recomienda trabajar idealmente sobre Linux 5.14 o, mejor, sobre la serie 6.6 si se quiere aprovechar todo el potencial de este lanzamiento.
Esta subida de listón tiene impacto directo en entornos muy conservadores que siguen anclados en kernels LTS veteranos. La mayoría de distribuciones empresariales y comunitarias modernas ya están como mínimo en la 5.10 o más arriba, pero hay despliegues de misión crítica —en data centers, administraciones públicas o grandes empresas europeas— que tienden a congelar versiones durante muchos años. Antes de planificar el salto a systemd 260 toca revisar qué kernel se está usando y si entra dentro del rango soportado.
La razón de este aumento de requisitos no es caprichosa: muchas de las nuevas funciones de systemd dependen de capacidades del kernel relativamente recientes. Hablamos de mejoras de cgroups, nuevas APIs para seguridad, ajustes de memoria o soporte de drivers modernos de red y almacenamiento. Mantener compatibilidad con ramas extremadamente viejas limitaría en exceso la evolución del proyecto.
PrivateUsers y refuerzo del aislamiento (sandboxing)
En el terreno de la seguridad y el aislamiento, systemd 260 introduce cambios importantes en la funcionalidad PrivateUsers, que se utiliza para mapear identificadores de usuario en entornos aislados. La implementación de PrivateUsers=full se ha actualizado para mapear el rango completo de IDs, evitando las limitaciones que existían en versiones anteriores.
Este cambio permite, entre otras cosas, eliminar el apaño que se usaba para detectar instancias de systemd anidadas basadas en versiones previas a la 257. Ahora el comportamiento es más coherente y robusto, lo cual es clave en escenarios donde se ejecuta systemd dentro de contenedores o máquinas virtuales que, a su vez, corren sobre sistemas que también usan systemd.
Para quienes no estén muy familiarizados, PrivateUsers forma parte del arsenal de técnicas de sandboxing que ofrece systemd para aislar servicios del resto del sistema. Al controlar cómo se mapean los IDs de usuario dentro de un contexto concreto, se reducen las posibilidades de que un proceso escape o interfiera con otros recursos de la máquina. En entornos donde la seguridad es prioritaria, este tipo de mejoras suma puntos.
Mejoras en TPM2 y nueva utilidad tpm2_id en udev
Otro frente en el que systemd 260 avanza con decisión es en el soporte a TPM2, el módulo de plataforma segura integrado en muchas placas con firmware UEFI. Este hardware se utiliza, entre otras cosas, para almacenar claves de cifrado y facilitar procesos de descifrado de discos o particiones protegidas durante el arranque del sistema.
En esta versión, udev incorpora una nueva herramienta llamada tpm2_id, pensada para identificar el modelo y el proveedor de los dispositivos TPM2 conectados. Cada vez que se detecta un TPM2, esta utilidad permite obtener de forma automática esos datos, lo que simplifica el inventario y la gestión de este tipo de hardware en flotas grandes de equipos.
Para organizaciones europeas sujetas a regulaciones estrictas sobre protección de datos y seguridad —como administraciones, bancos o empresas del sector sanitario—, contar con un manejo más fino y automatizado del TPM2 encaja muy bien con las necesidades de cifrado de disco y custodia de claves. Además, al integrarse a nivel de udev, se abre la puerta a reglas y automatizaciones que reaccionen ante la presencia de módulos concretos.
Nuevo concepto de xaccess para delegar acceso a dispositivos
Systemd 260 también refuerza el control de acceso a hardware gracias a un nuevo concepto gestionado por systemd-logind y systemd-udevd: xaccess. Este mecanismo se suma al ya conocido uaccess, que se encarga de conceder acceso a dispositivos a usuarios con sesiones en primer plano.
Con xaccess, se puede delegar el uso de dispositivos específicos a usuarios cuyas sesiones estén marcadas de forma especial. El caso de uso principal que plantea el proyecto es bastante claro: otorgar acceso a dispositivos de renderizado de GPU a sesiones gráficas locales asociadas a usuarios remotos, es decir, que no están físicamente sentados delante de la máquina.
La configuración de estas sesiones se lleva a cabo mediante la variable de entorno PAM XDG_SESSION_EXTRA_DEVICE_ACCESS=, que entra en juego dentro de esta lógica. De este modo, se pueden diseñar políticas de acceso muy finas en las que determinados dispositivos solo estén disponibles para sesiones que cumplan ciertos criterios, sin tener que abrir la mano a todo el sistema.
En el contexto europeo, con marcos regulatorios exigentes como el RGPD y otras normativas sectoriales, esta granularidad en la delegación de acceso a dispositivos sensibles resulta especialmente útil. Permite construir entornos multiusuario más seguros sin renunciar a la flexibilidad necesaria en escenarios de trabajo remoto, virtualización de escritorios o laboratorios compartidos.
Integración de systemd-networkd con ModemManager y mejoras de red
En el apartado de red, systemd 260 viene cargado de novedades. Una de las más notables es que systemd-networkd se integra ahora con ModemManager usando el protocolo simple connect, lo que facilita mucho la gestión de módems y conexiones móviles desde la propia infraestructura de networkd.
Para soportar esta integración aparece una nueva sección de configuración en los archivos de red, , que admite parámetros como APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=. Con ellos, es posible definir de manera detallada cómo deben establecerse y gestionarse las conexiones móviles, algo muy práctico en despliegues que dependen de 4G/5G, ya sea en zonas rurales o en soluciones IoT.
Además, los archivos .link de systemd-networkd ganan nuevas opciones para afinar el comportamiento de dispositivos Ethernet. Entre ellas se incluyen ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload y parámetros relacionados con GenericReceiveOffload y GenericReceiveOffloadUDPForwarding. Todo ello permite ajustar el rendimiento de la pila de red a nivel de hardware y driver, algo clave en centros de datos y redes corporativas de alto rendimiento.
No se queda ahí: las interfaces Varlink y JSON de systemd-networkd se mejoran para reportar direcciones IP en formato de cadena legible por humanos, manteniendo también la representación como arreglo de enteros. Esto simplifica la vida de quienes integran estas APIs con sistemas de monitorización, herramientas de orquestación o scripts de administración utilizados en muchas organizaciones europeas.
Mstack, systemd-mstack y refuerzo de la containerización
Mirando hacia los contenedores y entornos aislados, systemd 260 introduce la función mstack y el comando systemd-mstack. La idea detrás de mstack es permitir definir un OverlayFS a partir de la estructura de un directorio especial llamado .mstack/, siguiendo una especificación clara para organizar las distintas capas.
El comando de línea de órdenes systemd-mstack facilita el trabajo interactivo con estas pilas de archivos, permitiendo gestionar de forma más cómoda estos overlays. Esta funcionalidad se relaciona con las capacidades de systemd-importd para descargar y manipular imágenes OCI, reforzando así el papel de systemd como pieza central también en escenarios de containerización y entornos IoT.
Para proveedores de nube, plataformas de alojamiento o entornos de CI/CD extendidos por Europa, contar con un mecanismo más integrado para construir y gestionar pilas de sistemas de archivos encaja muy bien con estrategias modernas de despliegue. Se facilita la construcción de entornos efímeros, imágenes personalizadas y servicios aislados con un mayor control desde el propio systemd.
Portabilidad y servicios sin privilegios: systemd-portabled y vmspawn
Otra de las áreas donde se nota el empuje de esta versión es la portabilidad de servicios. systemd-portabled obtiene la capacidad de ejecutarse como servicio a nivel de usuario, lo que permite que cuentas sin privilegios puedan lanzar servicios portables dentro de su propio espacio, siempre que el kernel lo soporte.
Esto implica que el típico usuario de escritorio o de un servidor multiusuario puede ejecutar servicios portables sin recurrir a sudo ni a elevar privilegios, algo muy interesante para separar responsabilidades y reducir la superficie de ataque asociada a la cuenta root. En entornos donde se fomenta que cada equipo autogestione parte de sus servicios, esta novedad da bastante juego.
Además, este mismo módulo es capaz ahora de generar una política y fijar la imagen para los servicios portables, de manera que la imagen no pueda ser modificada posteriormente sin volver a ser adjuntada. Este detalle mejora la confianza en el contenido que se está ejecutando, evitando cambios silenciosos que puedan introducir vulnerabilidades o comportamientos inesperados.
En paralelo, systemd-vmspawn mejora su integración con systemd-machined dentro de la sesión de usuario, y añade la opción -ephemeral para crear máquinas virtuales efímeras que se destruyen automáticamente al terminar su uso. Estas funcionalidades son especialmente atractivas para laboratorios de pruebas, plataformas educativas y pipelines de CI/CD en los que se crean y destruyen máquinas con gran frecuencia.
Control más fino de CPU y memoria: SCHED_EXT y THP por servicio
En lo que respecta al rendimiento, systemd 260 amplía las herramientas disponibles para ajustar el comportamiento de los servicios, como las usadas para monitorizar tu sistema en Linux. La directiva CPUSchedulingPolicy= admite ahora el valor ext, que permite activar el planificador SCHED_EXT. Este tipo de planificación alternativa puede ser útil en entornos experimentales o en despliegues que requieren políticas de CPU no estándar.
Al mismo tiempo, hacen su aparición nuevas opciones como MemoryTHP=, pensada para gestionar el uso de Transparent Huge Pages (THP) por servicio. En lugar de depender de un ajuste global, cada unidad puede indicar cómo quiere que se trate esta funcionalidad, lo que ofrece un control mucho más granular sobre memoria y rendimiento.
En sectores como la banca, las aseguradoras o las instituciones públicas europeas, donde hay aplicaciones críticas con requisitos muy estrictos de latencia y consumo de recursos, poder decidir por servicio si conviene o no usar THP o qué política de planificación de CPU aplicar puede marcar la diferencia. Se evitan ajustes de “talla única” que a unos les sientan bien y a otros les penalizan.
Integridad de volúmenes cifrados y mejoras en repart
Dentro del ámbito del almacenamiento, systemd-repart también recibe atención en esta versión. Se añaden comprobaciones básicas de integridad en volúmenes cifrados, de forma que haya una capa adicional de verificación cuando se trabaja con particiones y discos protegidos mediante cifrado.
Esto no convierte a systemd-repart en una herramienta criptográfica completa, pero refuerza el flujo de trabajo en el que se crean, gestionan y despliegan volúmenes cifrados. Para infraestructuras donde el cifrado es obligatorio —por políticas internas o por normativa—, tener estas verificaciones integradas en el proceso ayuda a detectar problemas antes de que se conviertan en incidencias graves.
Novedades en systemctl y automatización avanzada
La herramienta de administración por excelencia de systemd, systemctl, también recibe nuevas capacidades. Una de las más interesantes para quienes automatizan despliegues y operaciones es la incorporación de la orden enqueue-marked.
Esta orden llama internamente al método D-Bus EnqueueMarkedJobs(), lo que abre la puerta a flujos de trabajo más sofisticados para gestionar colas de trabajos y servicios previamente marcados. En grandes granjas de servidores, donde se encadenan cambios y se manejan numerosos servicios, disponer de este tipo de mecanismos hace mucho más sencilla la orquestación fina desde scripts o herramientas externas.
Aunque este tipo de mejoras no se nota directamente para el usuario final, para los equipos de operaciones y SRE supone un pequeño salto cualitativo en cuanto a cómo pueden pilotar las infraestructuras desde la línea de comandos y a través de D-Bus.
Identidad del sistema: nuevo campo FANCY_NAME en os-release
En el archivo os-release aparece un nuevo campo llamado FANCY_NAME=, que complementa al ya clásico PRETTY_NAME. La diferencia es que este FANCY_NAME puede contener secuencias ANSI, incluidos caracteres Unicode más elaborados, lo que permite descripciones más vistosas de la distribución o edición instalada.
Este nuevo identificador se puede mostrar a través del gestor de systemd, desde systemd-hostnamed y con el comando hostnamectl, de modo que las distribuciones tienen un campo extra con el que presentarse de forma algo más “decorada” si así lo desean. Puede parecer un detalle menor, pero para herramientas gráficas de administración o para entornos de escritorio corporativos ayuda a identificar la plataforma de forma más clara.
Expansión del uso de Varlink y mejora de APIs
A lo largo de distintos componentes, el proyecto sigue ampliando la adopción de Varlink como interfaz de comunicación. Esto se aprecia, por ejemplo, en systemd-networkd, pero se extiende también a otras piezas de la arquitectura, consolidando un enfoque más coherente para que herramientas externas hablen con systemd.
Junto con las interfaces JSON mejoradas, este trabajo facilita la integración con paneles de monitorización, sistemas de gestión centralizada y asistentes automatizados que necesitan consultar o modificar el estado del sistema. En organizaciones con infraestructuras distribuidas por varios países europeos, donde la gestión remota y centralizada es el pan de cada día, este tipo de mejoras encaja perfectamente.
Documentación específica para IA: AGENTS.md, CLAUDE.md y revisión asistida
Una de las novedades más curiosas y reveladoras de hacia dónde se mueve el proyecto es la incorporación de documentación específica dirigida a agentes de inteligencia artificial que analizan el código de systemd. En el repositorio se ha añadido un archivo denominado AGENTS.md pensado precisamente para estos asistentes.
Este documento describe la arquitectura general de systemd, el flujo de desarrollo, el estilo de código y las pautas de contribución. También ofrece indicaciones sobre cómo ejecutar diversos comandos y pruebas de integración, con la idea de que las herramientas de IA que ayudan en programación y revisión de código entiendan mejor cómo está organizado el proyecto y puedan ofrecer resultados más fiables.
Junto a AGENTS.md se incluye CLAUDE.md, un archivo que hace referencia explícita a ese material como guía para la herramienta Claude Code, uno de los asistentes de desarrollo basados en IA más utilizados. Esto pone negro sobre blanco que los mantenedores de systemd son conscientes de que muchos colaboradores ya emplean IA en su flujo de trabajo y quieren orientar bien ese uso.
Además, el repositorio suma un fichero de configuración llamado claude-review.yml, donde se define cómo debe realizarse, con ayuda de Claude Code, el proceso de revisión de solicitudes de cambio. Todo ello se alinea con la exigencia de que las contribuciones que han utilizado IA incluyan etiquetas de divulgación como Co-developed-by en los parches, dejando claro qué parte del trabajo ha contado con asistencia automatizada.
Este conjunto de cambios apunta a una tendencia clara: grandes proyectos de software libre asumen que la IA forma parte del ciclo de desarrollo y se preparan para integrarla de forma transparente y controlada, tanto desde el punto de vista técnico como desde el punto de vista ético y de atribución.
Impacto práctico para administradores y elección de distribución
Como en cada lanzamiento de systemd, sobre todo en los últimos tiempos, el volumen de cambios es enorme y toca muchas áreas distintas. Lo que hemos repasado aquí son los aspectos más visibles o con más impacto práctico, pero el anuncio oficial de la versión 260 detalla todavía más ajustes, correcciones y pequeñas incorporaciones que completan el cuadro.
Para el usuario final típico de escritorio, la actualización de systemd no suele ser un proceso crítico que exija intervenir manualmente, especialmente si se utilizan distribuciones de lanzamiento puntual que congelan una versión concreta de systemd durante todo el ciclo de vida. En esos casos, la adopción de la 260 llegará cuando la distribución lo considere maduro y estable.
Sin embargo, en este mundillo siempre hay perfiles que quieren llevar lo último de lo último sin esperar al siguiente lanzamiento estable de su distribución. Para esos casos, lo más sensato sigue siendo apostar por distros de lanzamiento continuo como Arch Linux u openSUSE Tumbleweed, que suelen incorporar versiones recientes de systemd con rapidez. Fedora, por ejemplo, tiende a no actualizar la versión mayor de systemd a mitad de ciclo de vida de una versión concreta del sistema.
En entornos profesionales y de producción —especialmente en Europa—, la clave está en planificar bien la adopción: revisar requisitos de kernel, comprobar si quedan servicios basados en SysV, evaluar el uso de TPM2 y ajustar políticas de seguridad y rendimiento. Systemd 260 ofrece herramientas potentes para mejorar la seguridad, la automatización y la gestión de recursos, pero para sacarles partido hace falta dedicarles un tiempo de análisis y pruebas.
Al final, esta versión de systemd se puede ver como un punto de inflexión: cierra definitivamente una etapa basada en compatibilidad con scripts de arranque tradicionales, refuerza la integración con contenedores, redes avanzadas y hardware de seguridad, y abre la puerta a una colaboración más estrecha con herramientas de inteligencia artificial en el propio proceso de desarrollo. Para quienes administran sistemas Linux en España y el resto de Europa, supone un buen momento para revisar sus infraestructuras y decidir cómo quieren aprovechar todo este arsenal de novedades.
