YAST ahora es Agama, Cockpit y Myrlyn: así es el relevo en openSUSE

Última actualización: 25/02/2026
Autor: Isaac
  • YaST se retira progresivamente y su papel se reparte entre Agama, Cockpit y Myrlyn para modernizar la administración en openSUSE y SUSE.
  • openSUSE Leap 16 estrena Agama como instalador, Cockpit para la gestión del sistema y Myrlyn como nuevo gestor gráfico de paquetes basado en libzypp.
  • Myrlyn 1.0 iguala casi todas las funciones del módulo de software de YaST y las amplía, mientras Tumbleweed y Slowroll mantienen aún a YaST como herramienta central.
  • La transición será larga y prudente: YaST seguirá vivo en algunas ramas, mientras las nuevas herramientas se consolidan como estándar en el ecosistema SUSE.

Herramientas de administración en openSUSE

El ecosistema de SUSE y openSUSE está viviendo uno de los mayores cambios de su historia reciente: la retirada progresiva de YaST como pieza central de instalación y administración del sistema y la llegada de un trío llamado a tomar el relevo: Agama, Cockpit y Myrlyn. Para quienes llevan años usando openSUSE, puede sonar casi a sacrilegio, pero el movimiento tiene un trasfondo técnico y estratégico muy claro.

Este cambio no es un simple lavado de cara, sino una reestructuración profunda de cómo se instala, configura y mantiene un sistema basado en SUSE Linux, tanto en el ámbito comunitario (openSUSE Leap y Tumbleweed) como en el empresarial (SUSE Linux Enterprise). El resultado es un escenario de transición en el que YaST convive, a veces de forma tensa, con sus sucesores: Agama como instalador, Cockpit como centro de administración y Myrlyn como nuevo gestor gráfico de paquetes.

De YaST a un nuevo modelo de administración

Durante décadas, YaST ha sido la seña de identidad de SUSE: una herramienta monolítica, potentísima y muy integrada que centralizaba la instalación del sistema, la gestión de software y una larga lista de configuraciones avanzadas de red, hardware, seguridad y servicios. Podías montar un servidor FTP, unirte a un dominio Active Directory, ajustar el proxy global o gestionar impresoras, todo desde la misma interfaz.

Esa versatilidad tenía un precio importante: toneladas de código heredado, dependencias antiguas y una complejidad de mantenimiento cada vez mayor. Con el paso del tiempo, muchas de sus funciones se solaparon con herramientas más modernas del propio escritorio (KDE Plasma, GNOME, etc.) o con utilidades de consola mucho más ligeras, de manera que mantener todo el “monstruo” YaST dejó de ser sostenible a largo plazo.

La dirección de SUSE decidió, por tanto, trocear el papel histórico de YaST en varios componentes especializados y construidos con tecnologías actuales: Agama para la instalación del sistema, Cockpit para la administración postinstalación y Myrlyn como interfaz gráfica de gestión de paquetes basada directamente en libzypp. La idea es apoyarse más en estándares del sector y menos en herramientas “propietarias” de una sola distribución.

Esta separación también encaja mejor con las nuevas tendencias de sistemas inmutables, despliegues en la nube y administración remota vía navegador, ámbitos donde una herramienta monolítica como YaST encaja peor que un conjunto de servicios y frontends modulares accesibles por web.

El problema es que matar a un veterano tan integrado como YaST no es cosa de dos versiones, y eso explica por qué hoy todavía conviven mundos muy distintos según hablemos de Leap, Tumbleweed o SUSE Linux Enterprise.

openSUSE Leap 16: el punto de inflexión

openSUSE Leap 16 marca el antes y el después en esta transición. Es la primera versión de Leap en la que YaST se jubila de verdad como herramienta central, y en la que el nuevo trío Agama + Cockpit + Myrlyn se convierte en el núcleo de administración del sistema instalado.

Leap 16.0 está directamente basada en SUSE Linux Enterprise Server 16 e integra la nueva plataforma SUSE Linux Framework One (SLFO, heredera del proyecto ALP). Esto mantiene el modelo clásico de distribución basada en paquetes, pero sobre una base técnica modernizada, con ciclos de versión más largos y pensados claramente para producción.

Uno de los grandes cambios visibles para el usuario es el nuevo instalador Agama, que sustituye al instalador tradicional de YaST. Agama separa por completo la interfaz de usuario de la lógica interna de instalación, y permite orquestar instalaciones incluso mediante una interfaz web remota, lo que encaja muy bien con despliegues automatizados y entornos profesionales.

En el plano del escritorio, Leap 16 apuesta de lleno por Wayland: durante la instalación solo se ofrecen sesiones Wayland para los principales entornos (GNOME, KDE Plasma, etc.), quedando Xorg relegado a restos residuales. También se abandona por completo el soporte de scripts SysV init, adoptando únicamente systemd como sistema de inicio.

Otro cambio duro pero coherente es el salto de arquitectura: Leap 16.0 deja de ejecutar en máquinas x86_64-v1 y exige compatibilidad x86_64-v2, lo que en la práctica significa procesadores relativamente modernos (por ejemplo, Intel desde Nehalem). El objetivo es optimizar el rendimiento y aprovechar mejor las capacidades actuales del hardware.

  Cómo crear un disco RAM y usar la memoria volátil como almacenamiento ultrarrápido

Agama: el nuevo instalador de sistema

Agama es la pieza que toma el relevo del instalador clásico de YaST, y lo hace con una filosofía mucho más modular y “cloud-friendly”. Está escrito con tecnologías modernas (incluyendo Rust) y se apoya en una API que permite adaptar la experiencia de instalación a diferentes productos y escenarios.

En cuanto a la experiencia de usuario, Agama no descoloca a quien venga de YaST: mantiene un flujo de instalación familiar, con selección de idioma, particionado, elección de patrones de software (escritorios, pilas de servidor, etc.) y creación de usuarios. A nivel de estabilidad y rendimiento, la mayoría de reportes coinciden en que está ya a la altura de lo que ofrecía YaST en esta parte del proceso.

Donde Agama se queda algo corto frente al veterano installer de YaST es en las posibilidades “extra” que YaST permitía durante la propia instalación. Por ejemplo, Agama permite escoger patrones completos de software, pero no filtra paquete a paquete ni deja activar o desactivar servicios con el mismo nivel de detalle. Son opciones avanzadas que, por ahora, quedan fuera.

Esto no quiere decir que Agama sea limitado, sino que se centra en lo esencial: instalar un sistema sólido, con los componentes esperables, y delegar el resto en herramientas de administración posteriores como Cockpit o el propio gestor de paquetes. No está claro si en algún momento heredará parte de las opciones finas de YaST, pero de momento cumple sobradamente su papel.

En entornos de despliegue automatizado, Agama abre la puerta a escenarios imposibles con el antiguo instalador, ya que su interfaz web y su API encajan muy bien con orquestadores, herramientas de provisioning y modelos en los que el instalador se “controla” a distancia, no desde la pantalla del servidor.

Myrlyn: el heredero del módulo de software de YaST

Myrlyn 1.0 es la primera versión estable del nuevo gestor de paquetes gráfico de openSUSE, concebido como sustituto directo del módulo de software de YaST, pero sin arrastrar ninguna dependencia de la infraestructura de YaST en sí.

Desarrollado por Stefan Hundhammer, uno de los grandes nombres detrás de YaST, Myrlyn nació inicialmente durante una Hack Week de SUSE con un objetivo muy concreto: separar el selector de paquetes Qt de YaST y convertirlo en una aplicación Qt independiente basada en libzypp, el backend de gestión de paquetes de SUSE y openSUSE.

A nivel funcional, Myrlyn es un clon evolucionado del gestor de software de YaST: permite instalar, actualizar y eliminar paquetes individuales o múltiples, trabajar con patrones de software (grupos de paquetes) y gestionar repositorios de manera centralizada. Todo ello en una sola aplicación, sin necesidad de módulos separados para repos y para paquetes.

La interfaz está construida con Qt6 y mantiene el estilo clásico de los gestores “a la antigua”, con un listado de paquetes, filtros, panel de detalles y una zona donde se ve qué cambios se van a aplicar. Además, incorpora un simpático icono de mago que recuerda a épocas en las que estos frontends eran el centro de la experiencia en Linux.

La gran diferencia respecto a YaST Software es que Myrlyn no depende de todo el ecosistema YaST, sino que actúa como un frontend ligero contra libzypp. De hecho, puede funcionar en modo solo lectura como usuario normal, o bien elevar privilegios cuando es necesario realizar cambios reales en el sistema.

Funciones de Myrlyn: más que un simple gestor de paquetes

Desde la primera beta hasta Myrlyn 1.0 se ha ido ampliando notablemente la lista de funciones que ofrece, hasta el punto de que hoy es una alternativa muy seria y práctica para quienes prefieren gestionar el software con un control detallado.

En lo relativo a paquetes, Myrlyn ya permite prácticamente todo lo que ofrecía YaST Software: buscar por nombre, por descripción o por otros campos; ver información detallada (versión, origen, dependencias, datos técnicos); seleccionar qué instalar, actualizar o eliminar; escoger versiones concretas de un paquete si hay varias disponibles en distintos repositorios; y trabajar de forma cómoda con patrones de software para instalar o quitar grupos completos.

También gestiona parches y actualizaciones de forma integrada, de manera que puedes revisar qué parches hay pendientes, filtrarlos por repositorio, tipo o criticidad y decidir qué aplicar. Esto lo convierte en una pieza útil tanto en sistemas de escritorio como en máquinas que cumplen un rol más serio, pero siguen administrándose con interfaz gráfica.

  Tutorial completo de xargs en Linux para sacarle todo el partido

Donde Myrlyn da un salto respecto al viejo módulo de YaST es en la experiencia con repositorios. Nada más arrancar, puede actualizar automáticamente los metadatos de los repos, mostrando un feedback visual de lo que está haciendo (descargas, refrescos, etc.), y ofrece una vista muy clara de cada repo: nombre, prioridad, estado (habilitado o no), actualización automática, servicio asociado y URL.

Desde esa misma interfaz se pueden cambiar prioridades, activar o desactivar repos, modificar si se actualizan automáticamente, y editar nombre y URL al vuelo. Además, muestra también las URL con y sin variables de libzypp (como $releasever, $arch o $basearch), lo que ayuda a entender de dónde salen exactamente los paquetes.

Otra de las funciones interesantes es la gestión de repositorios comunitarios conocidos: desde Myrlyn se pueden añadir con unos clics repos tan típicos como Packman, drivers de NVIDIA, OpenH.264 o LibDvdCss, escogiendo automáticamente la URL correcta según la versión de la distro (Leap 15.x, Leap 16.x, Tumbleweed, Slowroll, SLE-15 SPx, etc.).

Por último, Myrlyn ofrece un modo de solo lectura muy práctico cuando no se tienen privilegios de root, lo que permite explorar repos y paquetes sin riesgo de romper nada. Esta opción ni siquiera estaba disponible en YaST Software y resulta muy útil para usuarios que simplemente quieren revisar qué hay instalado o disponible antes de pedir a un administrador que haga cambios.

Myrlyn frente a otras herramientas de gestión de software

En el escritorio actual, muchos usuarios apenas pisan gestores de paquetes clásicos, ya que con GNOME Software, KDE Discover y compañía tienen más que de sobra para instalar aplicaciones populares, actualizarlas y gestionar complementos. Además, los formatos universales como Flatpak han cogido mucho peso.

Sin embargo, herramientas como Myrlyn o el antiguo YaST Software siguen teniendo un hueco muy claro para quienes necesitan un control más fino de repositorios, versiones y dependencias, o para tareas en las que una app store “bonita” se queda corta. En ese sentido, Myrlyn juega en la misma liga que Synaptic en el mundo Debian/Ubuntu.

Una crítica recurrente a Myrlyn tiene que ver con su modelo de permisos: mantiene una separación entre modo solo lectura y modo completo, en lugar de pedir privilegios solo cuando hace falta ejecutar una operación crítica, como hacen muchos gestores actuales. No es un drama, pero se percibe como un detalle algo anticuado.

En lo visual, las diferencias con YaST Software no son tan dramáticas como algunos comentan. Ambos usan Qt, y la legibilidad o el “look” dependen mucho más del tema gráfico configurado para la cuenta de usuario o para root que de la aplicación en sí. Para muchos, la mejora está más en la limpieza arquitectónica que en un rediseño radical de la interfaz.

En cuanto al backend, conviene recordar que Myrlyn no es simplemente una GUI para zypper, sino una interfaz para libzypp, igual que zypper es su equivalente en línea de comandos. Esto le permite ofrecer una experiencia coherente con la resolución de dependencias y los comportamientos que los usuarios de openSUSE ya conocen de zypper.

Todo esto hace que Myrlyn sea especialmente atractivo para usuarios avanzados de escritorio y administradores que quieren una herramienta gráfica potente sin depender del entramado completo de YaST, y que necesitan algo más que un “centro de software” simplificado.

Cockpit: la nueva suite de administración del sistema

El otro gran protagonista del relevo de YaST es Cockpit, una interfaz web de administración que lleva años utilizándose en el mundo empresarial y que se ha ido consolidando como estándar de facto en muchas distribuciones orientadas a servidores.

En el ecosistema SUSE, Cockpit entra para cubrir el enorme espacio que deja la parte administrativa de YaST: gestión de usuarios, servicios, almacenamiento, red, actualizaciones, contenedores y más, accesible desde el navegador y de forma modular mediante plugins.

A diferencia de Myrlyn, Cockpit no viene instalado por defecto en todos los entornos, especialmente en sistemas de escritorio, porque muchas de sus funciones se solapan con las herramientas del propio entorno gráfico (gestión de usuarios, discos, etc.). Sin embargo, para servidores y despliegues remotos es una pieza clave.

Es importante recalcar que Cockpit no cubre el 100 % de lo que hacía YaST. Hay ajustes, módulos y tareas muy específicas que no tienen equivalente directo, y en algunos casos se delega en herramientas de terceros o en la terminal. Dado el enfoque actual hacia cloud y contenedores, SUSE ha preferido centrarse en lo más útil y estándar en lugar de clonar todo el catálogo histórico de YaST.

El valor de Cockpit dentro de la estrategia de SUSE está en ofrecer una administración unificada y moderna, más alineada con lo que se espera hoy en día en centros de datos, despliegues híbridos y entornos empresariales, sin atar todo a un único programa gráfico local como ocurría con YaST.

  Ejemplos prácticos de uso de nice, renice e ionice en Linux

SUSE Linux Enterprise y la transición pendiente

SUSE Linux Enterprise Server 16 apareció poco después de openSUSE Leap 16, pero inicialmente solo como edición para servidores. De un SUSE Linux Enterprise Desktop 16 “independiente” todavía no se sabe mucho; es posible montar una interfaz gráfica encima del servidor, pero como producto propio sigue en el aire.

En el ámbito empresarial, la presencia de Myrlyn es aún más tímida: por ahora no se ha integrado plenamente en SUSE Linux Enterprise, lo que indica claramente que openSUSE está ejerciendo de banco de pruebas antes de mover ficha de forma definitiva en SLE.

Mientras tanto, en SUSE 15 el ciclo de vida sigue su curso con YaST plenamente operativo, y es probable que muchas de las alternativas que hoy se están puliendo en Leap 16 no lleguen a esa rama en producción. Es una coexistencia curiosa: el veterano YaST seguirá en sistemas que vivirán más que algunas de las soluciones que vienen a sustituirlo.

La estrategia parece clara: estabilizar Agama, Cockpit y Myrlyn en openSUSE, con especial foco en Leap como variante “seria” pero comunitaria, para después llevar ese modelo a SUSE Linux Enterprise 16 y sucesivas versiones con el menor riesgo posible.

El debate en la comunidad, eso sí, no está cerrado. Hay usuarios y administradores que echan de menos la etapa en la que todo, absolutamente todo, se hacía desde YaST con un clic, y ven el nuevo modelo más disperso. Otros valoran precisamente lo contrario: menos dependencia de un único “centro de control” y más piezas intercambiables basadas en estándares.

Tumbleweed y Slowroll: donde YaST se resiste a irse

Si hay un escenario donde esta transición resulta llamativa, es en openSUSE Tumbleweed, la edición rolling-release que más ha crecido en los últimos años y que actúa como punta de lanza para tecnologías que luego aterrizan en Leap y SLE.

Pese a su filosofía de actualización continua y vanguardista, Tumbleweed sigue instalándose y gestionándose con YaST, y no hay señales claras de que eso vaya a cambiar a corto plazo. Incluso Slowroll, la rama intermedia entre Leap y Tumbleweed, mantiene también a YaST como pieza fundamental.

Dentro de la comunidad hay posturas enfrentadas respecto a este inmovilismo relativo: algunas voces prefieren seguir con YaST “hasta que reviente”, mientras otras consideran que sería un error dejar que se convierta en un obstáculo cuando ya existen reemplazos técnicamente viables.

Lo curioso es que Tumbleweed ya ha recibido Myrlyn 1.0 en sus repositorios, junto con varias actualizaciones de YaST2 (la capa gráfica ligada a la línea de comandos), lo que deja claro que la continuidad de este último está asegurada durante bastante tiempo.

Al mismo tiempo, el YaST “viejo” apenas recibe cambios relevantes, pero eso no parece preocupar a nadie: sigue funcionando bien como instalador y como conjunto de módulos de administración, y mientras eso ocurra no hay prisa especial por retirarlo de la edición rolling.

En la práctica, esto significa que Myrlyn está listo para sustituir a YaST Software donde se decida hacerlo, y de hecho ya asume ese rol en Leap 16, pero el salto definitivo en Tumbleweed y Slowroll se está tomando con mucha prudencia.

Con todo este panorama, el futuro de la administración en openSUSE y SUSE apunta claramente hacia Agama, Cockpit y Myrlyn, aunque la retirada completa de YaST vaya a ser un proceso largo, por fases y con muchas convivencias entre generaciones. Para el usuario final, el mensaje es claro: el viejo YaST se apaga poco a poco, pero su legado sigue vivo repartido en herramientas más modernas y específicas.

Para quien llegue ahora al ecosistema SUSE, el nuevo trío puede parecer lo normal, pero quienes han visto crecer a YaST notarán el cambio de filosofía: menos “navaja suiza” única y más piezas especializadas que, trabajando juntas, mantienen el mismo objetivo de siempre, que administrar openSUSE y SUSE sea potente, flexible y, dentro de lo posible, cómodo.

neofetch vs fastfetch
Artículo relacionado:
Neofetch vs Fastfetch: diferencias reales y cuál usar en tu sistema