Also available on Odysee: https://odysee.com/@javierorozco.observer:6/Fedora-44---An%C3%A1lisis-T%C3%A9cnico-Profundo--Kernel,-Escritorios-y-el-Futuro-Inmutable:b

I’ll take a deep technical dive into Fedora 44. I won’t focus on the visuals: I’ll do an overall review of Fedora 44 as such, regardless of whether it’s Workstation, the server edition, or a spin, since technically almost everything applies to any edition of the 44 branch. I’ll briefly review highlights from some desktop environments, but not much more, since the most interesting part is neither in the looks nor in the wallpapers.

What I’ll do is open the terminal, check versions, and understand what changed in the kernel, in the tooling and development environments, in the Atomic Desktops, and in the OS image philosophy that Fedora is actively pushing toward the future.

Fedora: Lead, Don’t Follow

Let’s start by looking at what Fedora is and where it stands in the GNU/Linux ecosystem. The first thing to clarify is that Fedora is not Ubuntu, nor does it emulate Debian’s idea of “stability”: its explicit philosophy is to lead, not follow. That means you’ll find versions of compilers, libraries, and frameworks that other distros don’t have yet, but also that major behavioral changes can appear from one release to the next.

Red Hat Enterprise Linux uses Fedora as its base, that is, what gets tested here is what will reach the enterprise world. That gives Fedora a weight that goes far beyond being a “cool” distro.

Support for each release is approximately 13 months. There is no “LTS” here, but new versions every six months: upgrading on time is not optional if you want to stay supported, but the system makes upgrading very easy, as we’ll see later.

Editions, Spins, and Variants: More Options Than Ever

Fedora 44 has more variants than ever. The three main categories are:

Flagship editions: here we have the main ones with the desktop of your choice, either GNOME on Workstation or KDE Plasma, these two being its official desktop versions. But also the spins with XFCE, Cinnamon, MATE with the Compiz window manager, i3, LXQT, LXDE, Sugar, Sway, Budgie, Miracle, Plasma Mobile, and COSMIC: there is literally something for every taste. Also an ISO for servers, IoT devices, cloud virtual machines, and a minimal edition ideal for containers.

The second category is Atomic Desktops: in these the filesystem is read-only. To put it simply, it works like a mobile device running Android, where you simply have an app store and install everything from there. Base system updates are transactional and you can roll back from boot: Silverblue with GNOME, Kinoite with KDE, Sway, Budgie, and Cosmic. These atomic distributions are the future Fedora is actively pushing.

And the third category is Fedora Asahi Remix: this is Fedora running on Apple Silicon hardware natively, with KDE Plasma as the project’s flagship desktop. This is not emulation: it is the Linux kernel compiled for ARM with drivers specific to Apple hardware.

System Requirements, LLVMpipe, and Additional Desktops

Let’s also look at the recommended system requirements: nothing revolutionary here compared to previous versions. The most interesting point is LLVMpipe: Fedora can run GNOME even on hardware without graphics acceleration, using the CPU for rendering. Obviously performance won’t be the same, but it’s functional for virtual machines without 3D acceleration or very old hardware.

And it also lets us add a different desktop on an existing installation. We can see the available options with:

1

dnf environment list

If we wanted to install, for example, Cinnamon:

1

sudo dnf install @cinnamon-desktop-environment

Installation: Anaconda, Btrfs, and Disk Encryption

Let’s quickly go through the installation process. The installer change is subtle but relevant for administrators: previously, Anaconda created NetworkManager profiles for every network device it detected, even if you didn’t configure them during installation. Now only the profiles you actually configured persist. That means fewer ghost configuration files on the system. In partitioning we also have the BTRFS filesystem by default with @root and @home subvolumes, and as I always insist and will insist: enable full disk encryption to protect your data, with no exceptions. In fact, I think distributions should ship with encrypted system installation by default and enforced, and what should be done manually is disabling it.

Support for aarch64 EFI and automatic DTB selection matters to the ARM community: for example, Fedora ISOs can now boot directly on Snapdragon laptops with no manual intervention to select the correct Device Tree.

GNOME: Parental Controls, Color, RDP, and IBus

I’m going to dedicate a separate article to GNOME, so I won’t go into every detail of the desktop here. But I do want to name what Fedora’s own release notes called out as relevant.

The most striking change from an everyday user’s point of view is the native Parental Controls system, part of the Digital Wellbeing initiative (for those unfamiliar, it’s a term used to describe the impact of digital technologies and services on people’s mental, physical, social, and emotional health): for the first time you can set screen time limits and usage schedules directly from Settings, without installing anything extra. Useful on shared or family machines.

The improvements in color management and in RDP Remote Desktop matter for professional workflows: Fedora has had native RDP support for several versions and GNOME 50 refines it further.

Accessibility got improvements, and the default applications were also updated, such as the document viewer, the file manager, and the calendar.

As for IBus 1.5.34: the change in support for Wayland input-method protocols applies mainly to environments like KDE, Sway, Hyprland, and COSMIC. GNOME handles input methods its own way, so on Fedora Workstation that IBus change isn’t felt directly. What is universal is the new WhisperCpp voice backend in ibus-speech-to-text, which now competes with Vosk by offering better accuracy, real multilingual support, and compatibility with quantized models.

KDE Plasma 6.6: Login Manager, Setup, and Spectacle with OCR

I’m also going to dedicate a full article to Plasma, so here we’ll stick to the essentials.

The two most important changes at the Fedora KDE level specifically are the Plasma Login Manager (the new session manager) and Plasma Setup, which complement each other: before you log in you’re greeted by the new Login Manager, and when you boot a fresh installation for the first time, Plasma Setup takes over to configure the user, timezone, and basic preferences. This makes Fedora KDE a viable option for OEM deployments: I can install the system on someone’s machine without creating their user in advance; they configure it on first boot, as in Windows.

Replacing SDDM is architecturally significant: SDDM is a project external to the KDE ecosystem, while the new Login Manager is Plasma-native and integrated with systemd. Note that installations upgrading from Fedora 43 are not migrated automatically: SDDM stays. You have to switch it manually if you want it:

1
2

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

The change takes effect starting with the next reboot.

As for Plasma 6.6 itself: we get a new on-screen keyboard with a more modern implementation, an option to save your current setup as a custom global theme, color accent with per-window-frame tint strength adjustment, per-application volume from the taskbar (no need to open the audio mixer to adjust a specific app), and the new Spectacle with OCR screenshot feature, among the most useful for day-to-day use: you take a screenshot and can extract text directly with no need for external tools. You can also connect to WiFi using a QR code.

We also get new accessibility options, and the per-window filter in screencasting from the title bar solves a flow that used to be awkward: selecting exactly which window you’re sharing without leaving the application. One curious thing worth adding is that since the distribution’s release day, the manufacturer Star Labs, which builds machines with the open coreboot firmware, sells its machines directly with Fedora 44 preinstalled as one of the options to choose from.

NTSYNC in the Kernel and Goodbye to cert.pem

This is the technical core of the analysis.

Let’s talk about NTSYNC: it’s a kernel module that reimplements Windows synchronization primitives (such as mutexes or mutual exclusions, semaphores which are synchronization mechanisms between processes and threads, and events which are records generated by the operating system kernel listing critical activities such as memory allocation, input/output operations, system calls, and hardware errors). All of this now runs directly in kernel space.

Without NTSYNC, Wine has to emulate these operations at user-space level, which introduces latency. With NTSYNC, the kernel speaks the same language as Windows applications, significantly reducing hardware resource overhead, especially in multithreaded games.

We also need to talk about a silent change that can break things, and it’s the most dangerous change for production environments upgrading from Fedora 43: the /etc/pki/tls/cert.pem file no longer exists by default. Any application hardcoding that path will fail certificate validation. The correct approach is to use the cryptographic libraries’ APIs to resolve certificates, not a fixed path. Review your scripts and applications if you upgrade.

DNF5 Completes the Transition: PackageKit on libdnf5

Let’s also analyze the package manager. DNF5 is not new in Fedora 44: it’s been the default package manager since Fedora 41. But in this release an important chapter of the transition is completed: PackageKit migrates to the DNF5 backend. What does that mean in practice? That GNOME Software, Plasma Discover, and Cockpit, which use PackageKit underneath, now all talk to the same library: libdnf5. Before F44, those tools still used the DNF4 backend, which produced inconsistencies between what you saw in the terminal and what the graphical interface did; for example, differences in how dependencies were resolved or in transaction history state. Now there is a single source of truth.

The technical difference between DNF4 and DNF5 matters: DNF4 was written in Python, DNF5 is written in C++ on top of libdnf5. That translates into faster dependency resolution, lower memory usage, and better performance on systems with many repositories. For users with RPM Fusion, COPR, and several active repositories, the difference is noticeable.

If you come from an older Fedora and have scripts calling dnf4 directly, the compatibility package is still available, but you should migrate your commands since dnf4 is transitional and will disappear at some point.

One important point: PackageKit with DNF5 as its backend is what makes Cockpit work correctly on Fedora Server 44. If you administer Fedora servers via Cockpit and were on F43, this change consolidates the browser-based management experience.

Development Stack: Ruby 4.0 and MariaDB 11.8

As for the development stack, Fedora always ships loaded with the very latest. Ruby 4.0 is the most delicate case, since it makes a major version jump from 3.4, which is what Fedora 43 had. Packages using binary extensions need to be recompiled. If you have gems with native (C/C++) extensions, they must be rebuilt. Upstream paid attention to source-level compatibility, so in many cases you don’t need to change the Ruby code itself, but you do need to rebuild the extensions. We also get MariaDB 11.8 with a new default charset and vector functions optimized for machine learning, plus parallel dump and restore.

Nix Arrives in the Official Repositories

Quite an important addition is that the Nix package manager now ships in the official repositories, and its operation is practically the same as what I showed in the Trisquel 12 analysis. Having Nix in the repos is an interesting signal, since it tells us Fedora accepts coexisting with other package managers, recognizing that Nix solves a real problem: reproducible environments and multiple versions of tools in isolation. The classic use case is development: for example, you need Python 3.9 for an old project and Python 3.13 for the new one; with Nix you can have both without them clashing.

Atomic Desktops: The Read-Only System

Atomic Desktops are Fedora’s most philosophically different bet. The root filesystem is read-only: you can’t modify it directly even as root. Updates don’t go package by package mutating the live system, but instead a complete new deployment is prepared in the background, and on reboot the system switches everything at once, atomically. If something fails, from the GRUB menu you can go back to the previous deployment with no complicated recovery process.

This completely changes the relationship with the package manager. On an Atomic Desktop you don’t use DNF directly for the base system: you use rpm-ostree, which is what manages deployments. For user applications, the recommended route is Flatpak, which runs in its own sandbox and doesn’t touch the base system. And for cases where you need development tools or commands that don’t exist as Flatpaks, there’s Distrobox: a container where you can run any other GNU/Linux distribution that integrates with your terminal and your home directory as if it were part of the system, but isolated from the real operating system.

Bootable Containers and Sealed Images with bootc

Let’s also talk about bootable containers. This is the most ambitious architectural change Fedora has underway. The idea is to bring the OCI container model to the complete operating system. Instead of a package system that keeps mutating with every dnf upgrade, your OS is an immutable, versioned, signed image, exactly like a Docker image, but one the hardware can boot directly.

bootc is the tool that manages this:

1
2

sudo bootc upgrade
sudo bootc rollback

With bootc upgrade you update to a new OS image, or with bootc rollback you go back if something fails, without depending on rpm-ostree for the workflow.

F44’s Sealed Images add a complete chain of trust on top: from firmware to the last byte of the rootfs, everything cryptographically verified. The immediate practical benefit is TPM-based disk unlocking without a password in a reasonably secure way (because the TPM only releases the key if the entire boot chain is as expected).

Fedora Cloud: /boot as a Subvolume and End of QEMU on i686

This section focuses on Fedora Cloud, which is the edition designed for infrastructure deployments: virtual machines on cloud providers, QEMU/KVM instances, OpenStack images, and the like. It’s not the edition most people install on the desktop, but the changes it introduces have implications for Fedora’s overall direction.

One of the changes is removing the separate /boot partition. Historically, /boot lived on its own partition because old bootloaders had limitations reading complex filesystems like Btrfs or LVM: they needed a simple partition with ext4 or similar to live on. That restriction no longer applies on modern UEFI systems with GRUB2 or systemd-boot, which understand Btrfs perfectly. So Fedora Cloud 44 takes the step: /boot becomes a Btrfs subvolume inside the main volume, instead of its own partition.

Why does this matter? Three concrete reasons. The first is space efficiency: before, you had to reserve a fixed size for /boot at partitioning time. The dilemma was that if you made it too small it could fill up with old kernels, and if you made it too large you wasted space. With a subvolume inside Btrfs, space is shared and allocated according to real need. The second reason is that the resulting Cloud images are smaller because they don’t need to include that separate partition. And the third: this is consistent with the direction of the Bootable Containers from the previous section. If the entire operating system is going to live in a cryptographically verifiable Btrfs image, having /boot as a subvolume of the same volume simplifies the whole chain.

The change applies to all architectures supported by Fedora Cloud except IBM Z, which has its own scheme conventions, and UEFI-UKI images, which already have their own partitioning scheme for the Unified Kernel Image.

The other change in this section is removing QEMU as a 32-bit host. To avoid confusion let me clarify this: QEMU still exists as an emulation target, that is, you can keep creating and running 32-bit virtual machines inside QEMU. What was removed is running QEMU itself on an i686 host, which is a practically nonexistent use case today. No current cloud server runs a 32-bit hypervisor.

Asahi Remix: Official Mesa for Apple Silicon

Asahi Remix is a separate project but one that follows Fedora’s pace. Retiring the hand-patched Mesa is significant: it means the driver work for Apple Silicon has matured enough to be merged into official Mesa, which is what arrives directly from Fedora’s repos. Fewer custom patches, more long-term maintainability.

Post-Install: RPM Fusion, Codecs, Drivers, and Firmware

Fedora comes out of the installer in a deliberately minimal state. It doesn’t ship with full ffmpeg, it doesn’t ship with proprietary codecs, and depending on the hardware the drivers may be in a basic state. That’s not a defect: it’s a conscious decision to honor the free software policy in the official image. But in practice, there’s a set of steps every Fedora installation needs to be ready for real use, and that’s what we’re going to do now.

First is always syncing repository metadata and pulling in all updates released since the ISO was generated. The --refresh flag forces synchronization even if DNF thinks the cache is current, important on installation day:

1

sudo dnf upgrade --refresh

With the system up to date, next is enabling RPM Fusion. By policy Fedora doesn’t include patented software or proprietary code in its official repos, such as H.264 and H.265 codecs, and NVIDIA’s proprietary drivers aren’t there either. RPM Fusion exists precisely for that: Free for free software Fedora doesn’t include for licensing reasons, and Non-Free for what is directly non-free. They’re Fedora’s de facto complementary repos, maintained by the community for over a decade:

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

With RPM Fusion active we can now install full ffmpeg. --allowerasing is needed because Fedora ships with a trimmed ffmpeg-free that conflicts with RPM Fusion’s full ffmpeg: we’re telling DNF it may remove that package to resolve the conflict. For hardware decoding via VA-API, on Intel you need intel-media-driver; on AMD the Mesa drivers already included are normally enough:

1
2

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

If you have an NVIDIA GPU, this is the time to install the proprietary drivers. I leave it commented out because I don’t have NVIDIA on this machine, but the flow is from RPM Fusion Non-Free with akmod-nvidia, which compiles the kernel module automatically for each kernel update:

1
2

# Only if you have an NVIDIA GPU (RPM Fusion Non-Free):
# sudo dnf install akmod-nvidia

Flatpak comes preinstalled on Fedora Workstation, but Flathub isn’t enabled by default: you have to add it manually. Flathub is the central Flatpak repository and has the vast majority of applications you’ll want to install:

1

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

fwupdmgr manages firmware updates directly from Linux: BIOS, NVMe SSD controllers, compatible peripherals. Many manufacturers already publish their firmware updates through LVFS, the service fwupd queries. Worth running on every fresh installation:

1
2

fwupdmgr refresh
fwupdmgr update

Fedora’s “Development Tools” group installs the base toolchain: GCC, make, autoconf and company, the minimum for compiling from source or working with native extensions:

1

sudo dnf group install "Development Tools"

Lastly (although really I should have done this at the start), two lines that notably improve DNF speed in /etc/dnf/dnf.conf: max_parallel_downloads=10 downloads up to ten packages simultaneously instead of the default of three, and fastestmirror=True automatically selects the fastest available mirror for your connection:

1
2

max_parallel_downloads=10
fastestmirror=True

Upgrading to Fedora 44: Upgrade, Rebase, and Golden Rules

The most frequent question every time a new Fedora version comes out is whether it’s worth doing an in-place upgrade or better to wipe and install clean. The short answer is that Fedora’s upgrade is remarkably well implemented and in most cases works without problems. But there are nuances worth being clear about before running it.

Fedora’s upgrade is not like that of a rolling distro: it’s not DNF resolving dependencies live while the system runs. It can be done from the graphical interface or the console. What it does is download all packages needed for the new version in the background, and when the reboot runs, the system boots into a special, isolated update environment, with no services running, with nothing using the files about to be replaced. That drastically reduces the live-update problems that plague other distros. When you’re back on the desktop, you’re already on Fedora 44:

1
2

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

An absolute rule: never skip versions. If you’re on Fedora 41 or 42, first upgrade to 43, and from there to 44. Fedora’s upgrade system is neither designed nor tested for jumps of more than one version, and the chances of something ending up in an inconsistent state increase a lot.

For Atomic Desktops, the flow is different and in many ways cleaner: instead of an upgrade process, you do a rebase to the new reference with rpm-ostree rebase. The system downloads the complete new Fedora 44 image, and on reboot you simply activate the new deployment. The previous one stays available for immediate rollback if something fails. If you have RPM Fusion packages layered on Silverblue or Kinoite, you must first update the RPM Fusion reference to the new release before rebasing, or the layers will be left in an inconsistent state.

And this edition’s specific warnings, which we already covered in earlier sections but must be kept in mind before running the upgrade: the removed cert.pem if you have scripts or applications hardcoding that path, FUSE 2 removed on Atomic Desktops with the impact on AppImages and Plasma Vaults, and the Ruby 4.0 ABI break if you have gems with native extensions that need recompiling.

Conclusion: Fedora 44 Is Not a Filler Release

Fedora 44 is not a filler release. It has real technical moves: the GNU Toolchain takes a major leap with GCC 16, Ruby 4.0 is a major version change with real implications for those using it in production, MariaDB 11.8 brings vector support for machine learning directly into the database, and NTSYNC in the kernel concretely improves Wine and Steam performance.

But the most important change isn’t in any package version: it’s in the architectural direction. Sealed Images, Bootable Containers, bootloader unification, the Cloud migration to Btrfs subvolumes. Fedora is actively building the operating system model of the future: immutable, cryptographically verifiable, managed as code infrastructure.

If you come from other distros and Fedora has always seemed “too bleeding-edge” to you, confusing that with “instability” or “malfunction”, this is the time to revisit it. The base is solid, the toolchain is the most modern in the RPM ecosystem, and the direction is crystal clear.

Sources and Resources

• Official Fedora Linux 44 announcement — Fedora Magazine: https://fedoramagazine.org/announcing-fedora-linux-44/
• What’s new in Fedora Workstation 44 — Fedora Magazine: https://fedoramagazine.org/whats-new-fedora-workstation-44/
• Fedora 44 ChangeSet — Fedora Wiki: https://fedoraproject.org/wiki/Releases/44/ChangeSet
• Fedora downloads and editions: https://getfedora.org/