Fedora 44 | Análisis Técnico Profundo: Kernel, Escritorios y el Futuro Inmutable

Sun, 03 May 2026 12:00:00 +0000

También disponible en Odysee: https://odysee.com/@javierorozco.observer:6/Fedora-44---An%C3%A1lisis-T%C3%A9cnico-Profundo--Kernel,-Escritorios-y-el-Futuro-Inmutable:b

Realizaré un análisis técnico profundo de Fedora 44. No me centraré en lo visual: haré una revisión general de Fedora 44 como tal, sin importar si es la Workstation, la edición para servidores o un spin, pues técnicamente casi todo se aplica a cualquier edición de la rama 44. Revisaré brevemente aspectos destacados de algunos entornos de escritorio, pero no mucho más, ya que lo más interesante no viene ni en lo estético ni en los fondos de pantalla.

Lo que haré es abrir la terminal, revisar versiones, entender qué cambió en el kernel, en las herramientas y entornos de desarrollo, en los Escritorios Atómicos y en la filosofía de imagen del sistema operativo que Fedora está empujando activamente hacia el futuro.

Fedora: liderar, no seguir

Iniciemos por ver qué es Fedora y cuál es su lugar en el ecosistema GNU/Linux. Lo primero que toca aclarar es que Fedora no es Ubuntu, tampoco emula la idea de “estabilidad” de Debian: su filosofía explícita es liderar, no seguir. Eso significa que vas a encontrar versiones de compiladores, librerías y frameworks que otras distros todavía no tienen, pero también que entre versión y versión pueden aparecer cambios de comportamiento importantes.

Red Hat Enterprise Linux usa Fedora como base, es decir, lo que se prueba aquí es lo que llegará al mundo empresarial. Eso le da a Fedora un peso que va mucho más allá de ser una distro “cool”.

El soporte de cada lanzamiento es de aproximadamente 13 meses. Aquí no tienes “LTS”, sino versiones nuevas cada seis meses: actualizar a tiempo no es opcional si quieres mantenerte con soporte, pero el sistema facilita mucho la actualización, como veremos más adelante.

Ediciones, spins y variantes: más opciones que nunca

Fedora 44 tiene más variantes que nunca. Las tres categorías principales son:

Ediciones flagship: aquí tenemos las principales con el escritorio que elijas, ya sea GNOME en Workstation o KDE Plasma, siendo estas dos sus versiones oficiales en el escritorio. Pero también los spins con XFCE, Cinnamon, MATE con el gestor de ventanas Compiz, i3, LXQT, LXDE, Sugar, Sway, Budgie, Miracle, Plasma Mobile y COSMIC: hay literalmente para todos los gustos. También una ISO para servidores, dispositivos IoT, máquinas virtuales cloud y una edición mínima ideal para contenedores.

La segunda categoría es la de Escritorios Atómicos: en estas el sistema de archivos es de solo lectura. Para que se entienda fácil, es como funciona un dispositivo móvil con Android, en el cual simplemente tienes una tienda de aplicaciones e instalas todo desde ahí. Las actualizaciones del sistema base son transaccionales y puedes hacer rollback desde el arranque: Silverblue con GNOME, Kinoite con KDE, Sway, Budgie y Cosmic. Estas distribuciones atómicas son el futuro que Fedora está empujando activamente.

Y la tercera categoría es Fedora Asahi Remix: esto es Fedora corriendo en hardware Apple Silicon de forma nativa, con KDE Plasma como escritorio flagship del proyecto. No es emulación: es el kernel de Linux compilado para ARM con drivers específicos para el hardware de Apple.

Requisitos del sistema, LLVMpipe y escritorios adicionales

Veamos también los requisitos recomendados del sistema: nada revolucionario aquí comparado con versiones anteriores. El punto más interesante es LLVMpipe: Fedora puede correr GNOME incluso en hardware sin aceleración gráfica, usando la CPU para renderizar. Obviamente el rendimiento no será el mismo, pero es funcional para máquinas virtuales sin aceleración 3D o hardware muy viejo.

Y también nos permite agregar un escritorio diferente en una instalación existente. Podemos ver las opciones disponibles con:

1

dnf environment list

Si quisiéramos instalar, por ejemplo, Cinnamon:

1

sudo dnf install @cinnamon-desktop-environment

Instalación: Anaconda, Btrfs y cifrado de disco

Veamos rápidamente el proceso de instalación. El cambio del instalador es sutil pero relevante para administradores: antes, Anaconda creaba perfiles de NetworkManager para todos los dispositivos de red que detectaba, aunque no los configuraras durante la instalación. Ahora solo persisten los perfiles que realmente configuraste. Esto significa menos archivos de configuración fantasma en el sistema. En el particionado también tenemos sistema de archivos BTRFS por defecto con subvolúmenes @root y @home, y como siempre insisto e insistiré: activen el cifrado completo de disco para proteger sus datos, sin excepciones. Es más, yo pienso que las distribuciones deberían venir por defecto y forzadas a instalar el sistema cifrado, y que lo que se debería hacer de forma manual es desactivarlo.

El soporte para aarch64 EFI y la selección automática de DTB es importante para la comunidad ARM: por ejemplo, las ISOs de Fedora ahora pueden arrancar directamente en laptops con Snapdragon sin intervención manual para seleccionar el Device Tree correcto.

GNOME: Controles Parentales, color, RDP e IBus

A GNOME le voy a dedicar un artículo aparte, así que aquí no voy a entrar en cada detalle del escritorio. Pero sí quiero nombrar lo que las propias notas de lanzamiento de Fedora señalaron como relevante.

Lo más llamativo desde el punto de vista del usuario cotidiano es el sistema de Controles Parentales nativos, parte de la iniciativa Digital Wellbeing (para quienes no lo conocen, es un término utilizado para describir el impacto de las tecnologías y los servicios digitales en la salud mental, física, social y emocional de las personas): por primera vez puedes configurar límites de tiempo de pantalla y horarios de uso directamente desde Ajustes, sin instalar nada extra. Útil en equipos compartidos o familiares.

Las mejoras en gestión de color y en el Escritorio Remoto RDP son importantes para flujos de trabajo profesionales: Fedora tiene soporte RDP nativo desde hace varias versiones y GNOME 50 lo refina aún más.

La accesibilidad recibió mejoras, y las aplicaciones por defecto también fueron actualizadas, como el visor de documentos, el gestor de archivos y el calendario.

En cuanto a IBus 1.5.34: el cambio de soporte para protocolos Wayland input-method aplica principalmente a entornos como KDE, Sway, Hyprland y COSMIC. GNOME maneja el método de entrada por su propio camino, así que en Fedora Workstation ese cambio de IBus no se siente directamente. Lo que sí es universal es el nuevo backend de voz WhisperCpp en ibus-speech-to-text, que ahora compite con Vosk ofreciendo mejor precisión, soporte multilingüe real y compatibilidad con modelos cuantizados.

También voy a dedicarle un artículo completo a Plasma, así que aquí vamos a lo esencial.

Los dos cambios más importantes a nivel de Fedora KDE específicamente son el Plasma Login Manager (el nuevo gestor de sesiones) y el Plasma Setup, que son complementarios entre sí: antes de que inicies sesión te recibe el nuevo Login Manager, y cuando es la primera vez que arrancas una instalación fresca, Plasma Setup toma el control para configurar usuario, zona horaria y preferencias básicas. Esto convierte a Fedora KDE en una opción viable para despliegues OEM: puedo instalar el sistema en la máquina de alguien sin crear su usuario de antemano; él lo configura en el primer arranque, como en Windows.

El reemplazo de SDDM es arquitecturalmente significativo: SDDM es un proyecto externo al ecosistema KDE, mientras que el nuevo Login Manager es nativo de Plasma e integrado con systemd. Ten en cuenta que las instalaciones que hacen upgrade desde Fedora 43 no se migran automáticamente: SDDM se mantiene. Hay que cambiarlo de forma manual si quieres tenerlo:

1
2


sudo dnf install plasma-login-manager kcm-plasmalogin
sudo systemctl enable --force plasmalogin

El cambio queda activado a partir del próximo reinicio.

En cuanto a Plasma 6.6 en sí: tenemos un nuevo teclado en pantalla con una implementación más moderna, una opción de guardar tu configuración actual como tema global personalizado, acento de color con intensidad de tinte ajustable por marco de ventana, el volumen por aplicación desde la barra de tareas (evita tener que abrir el mezclador de audio para ajustar una app específica) y la nueva característica del capturador de pantalla Spectacle con OCR, de las más útiles del día a día: haces una captura y puedes extraer texto directamente sin necesidad de herramientas externas. También puedes conectarte a WiFi usando un código QR.

También tenemos nuevas opciones de accesibilidad, y el filtro por ventana en el screencast desde la barra de título resuelve un flujo que antes era incómodo: seleccionar exactamente qué ventana estás compartiendo sin salir de la aplicación. Algo curioso para añadir es que desde el día del lanzamiento de la distribución, el fabricante Star Labs, que fabrica equipos con el firmware abierto coreboot, vende sus máquinas directamente con Fedora 44 preinstalado como una de las opciones a elegir.

NTSYNC en el kernel y el adiós a cert.pem

Este es el núcleo técnico del análisis.

Hablemos de NTSYNC: es un módulo del kernel que reimplementa primitivas de sincronización de Windows (como los mutexes o exclusiones mutuas, los semáforos que son mecanismos de sincronización entre procesos e hilos, y los eventos que son registros generados por el núcleo del sistema operativo que listan actividades críticas como asignación de memoria, operaciones de entrada y salida, llamadas al sistema y errores de hardware). Todo esto ahora corre directamente en el espacio del kernel.

Sin NTSYNC, Wine tiene que emular estas operaciones al nivel del espacio del usuario, lo que genera latencia. Con NTSYNC, el kernel habla el mismo idioma que las aplicaciones Windows, reduciendo el gasto de recursos de hardware significativamente, especialmente en juegos multihilo.

También hay que hablar de un cambio silencioso que puede romper cosas, y es el cambio más peligroso para entornos de producción que actualizan desde Fedora 43: el archivo /etc/pki/tls/cert.pem ya no existe por defecto. Cualquier aplicación que hardcodee esa ruta fallará en validación de certificados. La forma correcta es usar las APIs de las librerías criptográficas para resolver los certificados, no una ruta fija. Revisen sus scripts y aplicaciones si actualizan.

DNF5 completa la transición: PackageKit sobre libdnf5

Analicemos también el gestor de paquetes. DNF5 no es nuevo en Fedora 44: es el gestor de paquetes predeterminado desde Fedora 41. Pero en esta versión se completa un capítulo importante de la transición: PackageKit migra al backend de DNF5. ¿Qué significa eso en la práctica? Que GNOME Software, Plasma Discover y Cockpit, que usan PackageKit por debajo, ahora todos hablan con la misma librería: libdnf5. Antes de F44, esas herramientas seguían usando el backend de DNF4, lo que generaba inconsistencias entre lo que veías en la terminal y lo que hacía la interfaz gráfica; por ejemplo, diferencias en cómo se resolvían dependencias o en el estado del historial de transacciones. Ahora hay una sola fuente de verdad.

La diferencia técnica entre DNF4 y DNF5 es importante: DNF4 estaba escrito en Python, DNF5 está escrito en C++ sobre libdnf5. Eso se traduce en resolución de dependencias más rápida, menor uso de memoria y mejor rendimiento en sistemas con muchos repositorios. Para usuarios con RPM Fusion, COPR y varios repositorios activos, la diferencia se nota.

Si vienes de Fedora antigua y tienes scripts que llaman a dnf4 directamente, el paquete de compatibilidad sigue disponible, pero conviene ir migrando los comandos porque dnf4 es transitorio y en algún momento desaparecerá.

Un punto importante: PackageKit con DNF5 como backend es lo que hace funcionar Cockpit correctamente en Fedora Server 44. Si administras servidores Fedora vía Cockpit y estabas en F43, este cambio consolida la experiencia de gestión desde el navegador.

Stack de desarrollo: Ruby 4.0 y MariaDB 11.8

En cuanto al stack de desarrollo, Fedora siempre viene cargada con lo último de lo último. Ruby 4.0 es el caso más delicado, pues hace un salto de major version desde 3.4, que se tenía en Fedora 43. Los paquetes que usan extensiones binarias necesitan ser recompilados. Si tienes gems con extensiones nativas (C/C++), hay que reconstruirlas. El upstream prestó atención a la compatibilidad a nivel de código fuente, así que en muchos casos no hay que cambiar el código Ruby en sí, pero sí reconstruir las extensiones. También tenemos MariaDB 11.8 con un nuevo charset por defecto y funciones de vector optimizadas para aprendizaje automático o machine learning, además de dump y restore paralelo.

Nix llega a los repositorios oficiales

Un añadido bastante importante es que el gestor de paquetes Nix ahora viene en los repositorios oficiales, y su funcionamiento es prácticamente el mismo al que había mostrado en el análisis de Trisquel 12. Tener Nix en los repos es una señal interesante, pues nos da a entender que Fedora acepta coexistir con otros gestores de paquetes, reconociendo que Nix resuelve un problema real: entornos reproducibles y múltiples versiones de herramientas de forma aislada. El caso de uso clásico es desarrollo: por ejemplo, necesitas Python 3.9 para un proyecto viejo y Python 3.13 para el nuevo; con Nix puedes tenerlos ambos sin que choquen.

Escritorios Atómicos: el sistema de solo lectura

Los Escritorios Atómicos son la apuesta más filosóficamente diferente de Fedora. El sistema de archivos raíz es de solo lectura: no puedes modificarlo directamente aunque seas root. Las actualizaciones no van paquete por paquete mutando el sistema en vivo, sino que se prepara un nuevo despliegue completo en segundo plano, y al reiniciar el sistema cambia todo de golpe de forma atómica. Si algo falla, desde el menú de GRUB puedes volver al despliegue anterior sin ningún proceso de recuperación complicado.

Esto cambia completamente la relación con el gestor de paquetes. En un Escritorio Atómico no usas DNF directamente para el sistema base: usas rpm-ostree, que es quien gestiona los despliegues. Para aplicaciones de usuario, la vía recomendada es Flatpak, que corre en su propio sandbox y no toca el sistema base. Y para casos donde necesitas herramientas de desarrollo o comandos que no existen como Flatpak, existe Distrobox: un contenedor donde puedes correr cualquier otra distribución GNU/Linux que se integra con tu terminal y tu directorio home como si fuera parte del sistema, pero aislado del sistema operativo real.

Contenedores booteables y Sealed Images con bootc

Hablemos también de los contenedores booteables. Este es el cambio arquitectural más ambicioso que Fedora tiene en curso. La idea es llevar el modelo de contenedores OCI al sistema operativo completo. En lugar de un sistema de paquetes que va mutando con cada dnf upgrade, tu OS es una imagen inmutable, versionada y firmada, exactamente como una imagen de Docker, pero que el hardware puede bootear directamente.

bootc es la herramienta que gestiona esto:

1
2


sudo bootc upgrade
sudo bootc rollback

Con bootc upgrade actualizas a una nueva imagen del OS, o con bootc rollback vuelves atrás si algo falla, sin depender de rpm-ostree para el flujo de trabajo.

Las Sealed Images de F44 añaden encima una cadena de confianza completa: desde el firmware hasta el último byte del rootfs, todo verificado criptográficamente. El beneficio práctico inmediato es el desbloqueo de disco por TPM sin contraseña de forma razonablemente segura (porque el TPM solo libera la clave si toda la cadena de arranque es la esperada).

Fedora Cloud: /boot como subvolumen y fin de QEMU en i686

Este apartado lo enfoco en Fedora Cloud, que es la edición pensada para despliegues en infraestructura: máquinas virtuales en proveedores cloud, instancias en QEMU/KVM, imágenes para OpenStack y similares. No es la edición que instala la mayoría en escritorio, pero los cambios que introduce tienen implicaciones para toda la dirección de Fedora.

Uno de los cambios es eliminar la partición /boot separada. Históricamente, /boot vivía en su propia partición porque los bootloaders antiguos tenían limitaciones para leer sistemas de archivos complejos como Btrfs o LVM: necesitaban una partición simple con ext4 o similar donde estar. Esa restricción ya no aplica en sistemas UEFI modernos con GRUB2 o systemd-boot, que entienden Btrfs perfectamente. Entonces Fedora Cloud 44 da el paso: /boot pasa a ser un subvolumen Btrfs dentro del volumen principal, en lugar de una partición propia.

¿Por qué importa esto? Tres razones concretas. La primera es la eficiencia de espacio: antes tenías que reservar un tamaño fijo para /boot al particionar. El dilema era que si lo hacías demasiado pequeño se podía llenar con kernels viejos, y si lo hacías demasiado grande desperdiciabas espacio. Con un subvolumen dentro de Btrfs, el espacio es compartido y se asigna según necesidad real. La segunda razón es que las imágenes Cloud resultantes son más pequeñas porque no necesitan incluir esa partición separada. Y la tercera: esto es coherente con la dirección de los Contenedores Booteables del apartado anterior. Si el sistema operativo entero va a vivir en una imagen Btrfs verificable criptográficamente, tener /boot como subvolumen del mismo volumen simplifica toda la cadena.

El cambio aplica a todas las arquitecturas soportadas por Fedora Cloud excepto IBM Z, que tiene sus propias convenciones de esquema, y las imágenes UEFI-UKI, que ya tienen su propio esquema de particionado por el Unified Kernel Image.

El otro cambio de este apartado es la eliminación de QEMU como host de 32 bits. Para evitar confusiones aclaro esto: QEMU sigue existiendo como target de emulación, es decir, puedes seguir creando y corriendo máquinas virtuales de 32 bits dentro de QEMU. Lo que se eliminó es correr QEMU mismo en un host i686, que es un caso de uso prácticamente inexistente hoy. Ningún servidor cloud actual corre un hipervisor de 32 bits.

Asahi Remix: Mesa oficial para Apple Silicon

Asahi Remix es un proyecto separado pero que sigue el ritmo de Fedora. El retiro del Mesa parchado manualmente es significativo: significa que el trabajo de los drivers para Apple Silicon ha madurado lo suficiente como para integrarse al Mesa oficial, que es el que llega directamente de los repos de Fedora. Menos parches propios, más mantenibilidad a largo plazo.

Post-instalación: RPM Fusion, codecs, drivers y firmware

Fedora sale del instalador en un estado deliberadamente mínimo. No viene con ffmpeg completo, no viene con los codecs privativos, y dependiendo del hardware puede que los drivers estén en un estado básico. Eso no es un defecto: es una decisión consciente de respetar la política de software libre en la imagen oficial. Pero en la práctica, hay un conjunto de pasos que cualquier instalación de Fedora necesita para estar lista para uso real, y eso es lo que vamos a hacer ahora.

Lo primero siempre es sincronizar los metadatos de los repositorios y traer todas las actualizaciones que hayan salido desde que se generó la ISO. El flag --refresh fuerza la sincronización aunque DNF crea que la caché está vigente, importante el día de la instalación:

1

sudo dnf upgrade --refresh

Con el sistema al día, lo siguiente es habilitar RPM Fusion. Fedora por política no incluye software con patentes ni código privativo en sus repos oficiales, como codecs de H.264, H.265, y los drivers privativos de NVIDIA tampoco están ahí. RPM Fusion existe precisamente para eso: Free para software libre que Fedora no incluye por razones de licencia, y Non-Free para lo que directamente no es libre. Son los repos complementarios de facto de Fedora, mantenidos por la comunidad desde hace más de una década:

1

sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-44.noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-44.noarch.rpm

Con RPM Fusion activo ya podemos instalar ffmpeg completo. El --allowerasing es necesario porque Fedora viene con un ffmpeg-free recortado que entra en conflicto con el ffmpeg completo de RPM Fusion: le estamos diciendo a DNF que puede remover ese paquete para resolver el conflicto. Para decodificación hardware por VA-API, en Intel hace falta intel-media-driver; en AMD los drivers de Mesa que ya vienen incluidos normalmente son suficientes:

1
2


sudo dnf install ffmpeg --allowerasing
sudo dnf install intel-media-driver

Si tienes GPU NVIDIA, este es el momento de instalar los drivers privativos. Lo dejo comentado porque no tengo NVIDIA en esta máquina, pero el flujo es desde RPM Fusion Non-Free con akmod-nvidia, que compila el módulo del kernel automáticamente para cada update de kernel:

1
2


# Solo si tienes GPU NVIDIA (RPM Fusion Non-Free):
# sudo dnf install akmod-nvidia

Flatpak viene preinstalado en Fedora Workstation, pero Flathub no está habilitado por defecto: hay que agregarlo manualmente. Flathub es el repositorio central de Flatpaks y tiene la gran mayoría de aplicaciones que vas a querer instalar:

1

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

fwupdmgr gestiona las actualizaciones de firmware directamente desde Linux: BIOS, controladores de SSD NVMe, periféricos compatibles. Muchos fabricantes ya publican sus actualizaciones de firmware a través de LVFS, el servicio que fwupd consulta. Vale ejecutarlo en cada instalación nueva:

1
2


fwupdmgr refresh
fwupdmgr update

El grupo “Development Tools” de Fedora instala el toolchain base: GCC, make, autoconf y compañía, lo mínimo para compilar desde fuente o trabajar con extensiones nativas:

1

sudo dnf group install "Development Tools"

Por último (aunque realmente esto debí hacerlo al inicio), dos líneas que mejoran notablemente la velocidad de DNF en /etc/dnf/dnf.conf: max_parallel_downloads=10 descarga hasta diez paquetes simultáneamente en lugar del valor por defecto de tres, y fastestmirror=True selecciona automáticamente el mirror más rápido disponible para tu conexión:

1
2


max_parallel_downloads=10
fastestmirror=True

Actualizar a Fedora 44: upgrade, rebase y reglas de oro

La pregunta más frecuente cada vez que sale una versión nueva de Fedora es si vale la pena hacer el upgrade en caliente o si es mejor formatear e instalar limpio. La respuesta corta es que el upgrade en Fedora está notablemente bien implementado y en la mayoría de casos funciona sin problemas. Pero hay matices que vale tener claros antes de ejecutarlo.

El upgrade de Fedora no es como el de una distro rolling: no es DNF resolviendo dependencias en caliente mientras el sistema corre. Se puede hacer desde interfaz gráfica o por consola. Lo que hace es descargar todos los paquetes necesarios para la nueva versión en segundo plano, y cuando se ejecuta el reinicio, el sistema arranca en un entorno de actualización especial, aislado, sin servicios corriendo, sin que nada esté usando los archivos que se van a reemplazar. Eso reduce drásticamente los problemas de actualización en caliente que plagan a otras distros. Cuando vuelves al escritorio, ya estás en Fedora 44:

1
2


sudo dnf system-upgrade download --releasever=44
sudo dnf system-upgrade reboot

Una regla absoluta: no saltar versiones. Si estás en Fedora 41 o 42, primero actualizas a 43, y de ahí a 44. El sistema de upgrade de Fedora no está diseñado ni probado para saltos de más de una versión, y las posibilidades de que algo quede en un estado inconsistente aumentan mucho.

Para los Atomic Desktops, el flujo es diferente y en muchos aspectos más limpio: en lugar de un proceso de upgrade, haces un rebase a la nueva referencia con rpm-ostree rebase. El sistema descarga la nueva imagen completa de Fedora 44, y al reiniciar simplemente activas el nuevo deployment. El anterior queda disponible para rollback inmediato si algo falla. Si tienes paquetes de RPM Fusion layereados en Silverblue o Kinoite, hay que actualizar primero la referencia de RPM Fusion al nuevo release antes del rebase, o los layers quedarán en estado inconsistente.

Y las advertencias específicas de esta edición, que ya cubrimos en apartados anteriores pero que hay que tener presentes antes de ejecutar el upgrade: el cert.pem eliminado si tienes scripts o aplicaciones que hardcodean esa ruta, FUSE 2 eliminado en Atomic Desktops con el impacto en AppImages y Plasma Vaults, y el ABI break de Ruby 4.0 si tienes gems con extensiones nativas que necesitan recompilarse.

Conclusión: Fedora 44 no es un release de relleno

Fedora 44 no es un release de relleno. Tiene movimientos técnicos reales: el GNU Toolchain da un salto importante con GCC 16, Ruby 4.0 es un cambio de major version con implicaciones reales para quienes lo usan en producción, MariaDB 11.8 trae soporte de vectores para machine learning directamente en la base de datos, y NTSYNC en el kernel mejora concretamente el rendimiento de Wine y Steam.

Pero el cambio más importante no está en ninguna versión de paquete: está en la dirección arquitectural. Las Imágenes Selladas, los Contenedores Booteables, la unificación del bootloader, la migración del Cloud a subvolúmenes Btrfs. Fedora está construyendo activamente el modelo de sistema operativo del futuro: inmutable, verificable criptográficamente, gestionado como infraestructura de código.

Si vienes de otras distros y Fedora siempre te ha parecido “demasiado de vanguardia”, confundiendo esto con “inestabilidad” o “mal funcionamiento”, este es el momento de revisarlo. La base es sólida, el toolchain es el más moderno del ecosistema RPM, y el rumbo está clarísimo.

Fuentes y recursos

Anuncio oficial de Fedora Linux 44 — Fedora Magazine: https://fedoramagazine.org/announcing-fedora-linux-44/
Novedades de Fedora Workstation 44 — Fedora Magazine: https://fedoramagazine.org/whats-new-fedora-workstation-44/
Conjunto de cambios de Fedora 44 (ChangeSet) — Wiki de Fedora: https://fedoraproject.org/wiki/Releases/44/ChangeSet
Descargas y ediciones de Fedora: https://getfedora.org/

Fedora on Javier Orozco | Observer