Ubuntu 26.04.1 LTS: pruebas reales en mi PC principal

Durante años, Ubuntu fue la respuesta casi automática cuando alguien preguntaba por dónde empezar en Linux. Hoy el panorama es distinto y las críticas hacia las decisiones de Canonical son constantes, por lo que decidí instalar Ubuntu 26.04.1 LTS en mi computadora principal para comprobar si esas quejas tienen fundamento en el uso real. Tras varios días probándolo con dos tarjetas gráficas, tres monitores, sesiones de programación, máquinas virtuales y juegos en Steam, descubrí que sus mayores aciertos están donde menos se comenta, pero sus puntos débiles aparecieron justo cuando necesitaba trabajar bajo presión.

A diferencia de una prueba rápida en máquina virtual, este experimento lo realicé sobre hierro real para evaluar si el sistema puede sostener mi flujo diario. Si prefieres ver las pruebas en acción, las capturas en vivo de los errores de Steam y el momento exacto en que la terminal dejó de responder, aquí tienes el video completo de mi experiencia.

Hardware de pruebas y objetivo del experimento con Ubuntu 26.04.1 LTS

Instalar cualquier distribución Linux y navegar por el escritorio durante diez minutos es sencillo. Lo que realmente separa a un sistema curioso de una herramienta de trabajo es cómo responde cuando conectas múltiples pantallas, compilas código, levantas hipervisores y ejecutas juegos exigentes.

Habitualmente utilizo Fedora como mi sistema operativo principal y mantengo una partición con Windows como entorno secundario. Mi intención no era mudarme definitivamente sin cuestionar nada, sino medir qué tan bien se comporta Ubuntu hoy en día con mi configuración actual:

• Procesador: AMD Ryzen 5 8600G con gráficos integrados Radeon.
• Tarjeta gráfica dedicada: NVIDIA GeForce GTX 1660 Super.
• Memoria RAM: 16 GB DDR5 (con una parte reservada para la gráfica integrada en BIOS).
• Almacenamiento para la prueba: SSD SATA dedicado de 240 GB.
• Monitores: Dos monitores de escritorio conectados a la GPU NVIDIA y un monitor portátil conectado a la salida de video de la placa madre.

¿Por qué Ubuntu divide tanto a la comunidad Linux?

Para entender el debate actual conviene mirar hacia atrás. Cuando Canonical lanzó la primera versión de Ubuntu en 2004, su meta era clara: lograr que cualquier persona pudiera usar una computadora con Linux sin tener que volverse administradora de sistemas.

Con el paso de los años, la distribución tomó rumbos técnicos que dividieron opiniones. Primero fue el salto al escritorio propio Unity, después el regreso a GNOME y, más recientemente, la adopción firme de los paquetes Snap para distribuir aplicaciones clave del sistema.

Quienes defienden este enfoque destacan la facilidad de mantenimiento y el soporte extendido. Quienes lo critican prefieren alternativas como Debian, Fedora o distribuciones amigables como Linux Mint y Zorin OS, argumentando que Ubuntu sacrifica flexibilidad. Para salir de dudas, descargué la imagen oficial desde la página de descargas de Ubuntu Desktop y puse a prueba la versión de mantenimiento 26.04.1 LTS, que integra correcciones acumuladas, un kernel actualizado y el entorno de escritorio GNOME 50.

Instalación en disco real y un primer tropiezo en el arranque

Preparé la memoria USB utilizando Rufus y ejecuté el instalador gráfico apuntando al SSD SATA de 240 GB. El asistente mantiene esa sencillez clásica que hizo famoso al sistema: elegir idioma, seleccionar el disco de destino y esperar unos pocos minutos sin necesidad de tocar la terminal.

El primer comportamiento extraño apareció justo al terminar la instalación. Al retirar la memoria USB y reiniciar el equipo, la computadora no cargó el gestor de arranque del sistema, sino que entró directamente a la BIOS.

En un segundo reinicio el sistema arrancó sin inconvenientes, aunque el síntoma volvió a presentarse más adelante tras aplicar una actualización del sistema. Siendo justo desde el punto de vista técnico, este mismo SSD SATA de 240 GB ya me había mostrado un comportamiento similar con otras distribuciones, por lo que podría tratarse de un detalle en la detección del disco o de la tabla UEFI de mi placa madre y no necesariamente de un fallo atribuible a Ubuntu.

GNOME 50 y la realidad sobre el consumo de memoria RAM

Al iniciar sesión nos recibe GNOME 50 con la personalización característica de Ubuntu: el dock lateral izquierdo, una tienda de aplicaciones renovada y un panel de configuración directo. Para monitorear el hardware instalé también Resources, una utilidad gráfica muy clara para inspeccionar el uso de CPU, discos y tarjetas de video.

Uno de los mitos más repetidos en foros es que Ubuntu se ha vuelto excesivamente pesado en reposo. Para medirlo con precisión antes de abrir programas pesados, consulté el consumo de memoria directamente en la terminal con este comando, que muestra la memoria total, utilizada y disponible en unidades legibles:

free -h

El resultado me sorprendió para bien: recién iniciado, Ubuntu 26.04.1 LTS consumía alrededor de 1.5 GiB de RAM de los casi 14 GiB disponibles para el sistema (recordando que el resto de mis 16 GB físicos queda asignado a la GPU integrada del Ryzen 5 8600G). Tener cerca de 12 GiB libres desde el arranque demuestra que la gestión de memoria en reposo está bastante bien optimizada.

Paquetes Snap frente a DEB: ¿afectan el uso diario?

No se puede analizar Ubuntu sin tocar el tema de Snap. La polémica surge sobre todo cuando intentas instalar un programa utilizando el gestor tradicional APT y el sistema redirige la orden hacia un paquete Snap sin que lo hayas pedido explícitamente.

Un caso claro ocurre al instalar el navegador Chromium desde la terminal con la instrucción habitual de Debian y Ubuntu:

sudo apt install chromium-browser

Al ejecutar ese comando, APT descarga en realidad un paquete de transición que invoca a Snap para instalar el navegador. Mientras que un paquete DEB tradicional comparte las bibliotecas del sistema operativo, el ecosistema documentado en la guía técnica oficial de Snapcraft empaqueta la aplicación junto con sus dependencias, maneja sus propias actualizaciones y se ejecuta en un contenedor aislado.

Si deseas verificar qué paquetes de este tipo corren en tu equipo y cómo se montan como unidades virtuales de solo lectura (dispositivos loop), puedes revisar la lista de Snaps y el árbol de bloques con estos dos comandos:

snap list
lsblk

Es común que usuarios nuevos se alarmen al ver decenas de entradas loop al ejecutar lsblk, pero no son particiones reales ni discos físicos adicionales; simplemente son los puntos de montaje de cada aplicación empaquetada. En mi experiencia práctica usando Firefox preinstalado como Snap, pude navegar, consultar mi blog y reproducir video en alta definición sin notar lentitud. Entiendo a quienes prefieren tener control absoluto sobre el origen de sus paquetes, pero Snap está lejos de volver inutilizable al sistema.

Controladores NVIDIA, Wayland y configuración con tres monitores

La primera gran sorpresa positiva llegó al revisar el apartado gráfico. En otras distribuciones es habitual realizar pasos manuales tras la instalación para habilitar los controladores propietarios de NVIDIA. Aquí, desde el primer arranque, mi GTX 1660 Super ya estaba plenamente operativa.

Para comprobar qué controlador había cargado el sistema y confirmar que la aceleración por hardware estaba activa, ejecuté la herramienta de diagnóstico de NVIDIA en la terminal:

nvidia-smi

La salida confirmó que el controlador 595.99.02 estaba corriendo sin intervención mía. Además, como mi procesador Ryzen 5 8600G cuenta con gráficos integrados, puse a prueba una configuración multimonitor con doble tarjeta gráfica: dos monitores principales conectados a la tarjeta NVIDIA y un tercer monitor portátil conectado directamente a la placa madre.

Problemas de conexión en caliente y cierres en la pantalla secundaria

Ubuntu reconoció las dos tarjetas gráficas y me permitió trabajar con los tres monitores simultáneamente si encendía la computadora con todo conectado. El inconveniente surgió en un escenario muy común en mi rutina: encender la PC con el monitor portátil apagado y conectarlo a la corriente más tarde.

Cuando conectaba el monitor portátil en caliente, Ubuntu no lograba activarlo correctamente hasta que reiniciaba toda la computadora, algo que en Fedora, sobre este mismo hardware, funciona al instante sin necesidad de reiniciar. A esto se sumó un fallo peculiar: al arrastrar aplicaciones propias del sistema (como la Terminal o Configuración) hacia el monitor conectado a la GPU integrada de AMD y maximizarlas, las ventanas se cerraban de forma repentina.

Para confirmar qué protocolo gráfico estaba gestionando el escritorio en ese momento, consulté la variable de sesión activa desde la consola:

echo $XDG_SESSION_TYPE

El comando devolvió wayland. Aunque las aplicaciones heredadas de X11 siguen funcionando gracias a la capa de compatibilidad XWayland, todavía queda por determinar si esos cierres al maximizar en la segunda GPU provienen de la sesión Wayland, del compositor Mutter, del controlador gráfico o de la combinación híbrida entre AMD y NVIDIA.

Jugar en Ubuntu 26.04.1 LTS: Steam, bibliotecas de 32 bits y Proton

Con el controlador de NVIDIA funcionando, el siguiente paso fue instalar Steam y descargar cuatro títulos para evaluar tanto entregas compatibles de forma directa como juegos de Windows ejecutados mediante la capa de compatibilidad Proton desarrollada por Valve: GTA IV, Bully, Stardew Valley y No Man’s Sky.

Apenas abrí Steam apareció una ventana de error crítica: NVIDIA 32-bit libraries not found. Aunque el escritorio de 64 bits funcionaba de maravilla, el cliente de Steam y muchos componentes que utiliza Proton siguen dependiendo de bibliotecas gráficas de 32 bits.

Siguiendo la recomendación del propio aviso, habilité la arquitectura de 32 bits en el gestor de paquetes para poder instalar las bibliotecas correspondientes a la rama de mi controlador:

sudo dpkg --add-architecture i386
sudo apt update

Resultados dispares en las pruebas de juegos

Lo desconcertante fue que, inmediatamente después de instalar las bibliotecas de 32 bits y paquetes adicionales de Vulkan, ni GTA IV ni Bully querían arrancar. Tras varios intentos fallidos, decidí apagar el equipo y dejar la prueba para el día siguiente.

Al encender la computadora a la mañana siguiente y abrir Steam sin tocar un solo paquete más, ambos juegos arrancaron a la primera. Mi sospecha principal es que el reinicio completo del sistema terminó de cargar los módulos o bibliotecas que había instalado la noche anterior, aunque al haber aplicado varios ajustes previos no puedo asegurar qué cambio específico destrabó la ejecución.

En el caso de Bully, vale la pena matizar que la lentitud severa quedó registrada en el archivo grabado con OBS Studio, por lo que sin mediciones separadas no sería riguroso afirmar si el cuello de botella estuvo en el juego o en el codificador de captura de video. Por su parte, tanto Stardew Valley como No Man’s Sky funcionaron de forma impecable desde el primer intento.

Programación, máquinas virtuales con QEMU y los bloqueos que me preocuparon

Superada la fase de juegos, pasé a lo que realmente define si puedo usar un sistema todos los días: el trabajo pesado. Instalé mis herramientas de desarrollo, incluyendo Antigravity, y en tareas de edición de código el desempeño fue cómodo y equiparable al de cualquier otra distribución moderna.

El verdadero examen de estrés comenzó cuando configuré una máquina virtual utilizando la plataforma de virtualización QEMU/KVM en Linux para instalar Windows 11. Esta es una tarea habitual cuando preparo laboratorios o pruebo entornos de virtualización y servicios locales.

Conforme avanzaba la instalación de Windows 11 sobre el SSD SATA y la máquina virtual compartía los 14 GiB de memoria del sistema con el escritorio, la respuesta general cayó en picada. En medio del proceso, el navegador Brave se congeló por completo hasta que GNOME mostró el diálogo para forzar el cierre o esperar.

Lo más delicado es que no fue un incidente aislado durante la virtualización. En otras sesiones cotidianas, ejecutando comandos simples, la propia aplicación de Terminal dejó de responder por completo, y varias ventanas se cerraron solas cuando tenía múltiples programas abiertos simultáneamente.

Además, me topé con dos detalles molestos en el uso diario: el sistema Bluetooth nunca logró detectar mis audífonos Sony WH-CH720N y el selector de energía en Configuración no me permitió activar el perfil de alto rendimiento. Aunque no puedo atribuir todos estos fallos exclusivamente a Ubuntu sin antes auditar a fondo los registros del sistema y la interacción entre las dos GPU, la realidad es que bajo mi configuración actual encontré una fricción que afecta directamente mi trabajo.

Veredicto: ¿para quién recomiendo hoy Ubuntu 26.04.1 LTS?

Después de convivir varios días con el sistema en un escenario real, entiendo mucho mejor por qué genera opiniones tan polarizadas. No creo que el problema real de Ubuntu sean los paquetes Snap ni tener que ejecutar un par de comandos para añadir bibliotecas de 32 bits en Steam; esos son detalles que puedes resolver en diez minutos.

Lo que me impide adoptarlo como mi sistema principal frente a Fedora son los pequeños bloqueos y cierres inesperados bajo carga de trabajo. Cuando estás programando o administrando máquinas virtuales, necesitas la certeza absoluta de que tu entorno de escritorio no se va a congelar a mitad de una tarea.

• Cuándo sí vale la pena: Si tienes una computadora con una configuración estándar (una sola tarjeta gráfica y uno o dos monitores) y buscas iniciarte en Linux con el respaldo de una comunidad enorme, años de soporte LTS y un consumo de RAM muy contenido de 1.5 GiB en reposo.
• Cuándo conviene evaluar alternativas: Si trabajas con configuraciones de hardware híbridas (doble GPU activa, conexión de pantallas en caliente) o dependes de cargas intensivas de virtualización y multitarea donde en tu hardware específico aparezcan cierres en la sesión de Wayland.