Migrated to Fedora: Notes from the Switch
Fedora occupies an interesting position in the Linux ecosystem — it is a community distribution sponsored by Red Hat, ships near-bleeding-edge package versions, and operates on a roughly six-month release cycle that keeps it closer to upstream than Debian stable or Ubuntu LTS. This post, part of the blog, documents practical observations from switching a primary desktop installation from Debian to Fedora: what hardware worked immediately, where the package ecosystem required adjustment, how firewalld compares to the UFW model covered in the UFW vs firewalld technical note, and where the Intel graphics driver situation — approached differently than described in the Debian Intel graphics guide — proved to be a non-issue. The Linux on Windows topic hub provides context on the broader Linux desktop landscape for those approaching from a dual-boot or WSL background.
The short version
Fedora's hardware support out of the box exceeded Debian stable in most areas tested — newer kernel versions mean newer driver support is present from the first boot. The main adjustment areas were: the DNF package manager's different behaviour compared to APT, the split between main repository and RPM Fusion for non-free packages, and the transition from UFW to firewalld as the default firewall management tool. None of these adjustments took more than a few hours to work through. The release cadence means Fedora requires more active maintenance attention than a long-cycle distribution, which is an acceptable tradeoff on hardware where staying current with drivers matters.
Why switch
The decision to migrate came down to a specific hardware situation: a machine with newer Intel Arc integrated graphics where Debian stable's kernel was too old to provide reliable support. Chasing backported kernels and firmware packages on Debian is achievable — the Debian newer Intel graphics guide documents the process — but it creates a maintenance burden of checking kernel version compatibility on each upgrade. Fedora's rolling-ish model means the kernel version at release is recent enough that new Intel graphics silicon is generally supported without manual intervention.
A secondary factor was GNOME version. Fedora ships the current GNOME release, typically within a cycle of upstream. Debian stable ships a GNOME version that may be eighteen months to two years behind upstream. For daily desktop use, the practical difference is mostly cosmetic, but some extension compatibility and accessibility feature improvements are only present in more recent releases.
Hardware support at first boot
On a ThinkPad with Intel Arc integrated graphics, Wi-Fi (Intel AX211), and a fingerprint reader: Wi-Fi worked from the first boot using the iwlwifi driver, which ships with the Fedora kernel without requiring additional firmware packages. Intel Arc graphics initialised correctly with the DRM driver present in Fedora 39's kernel — the same hardware on Debian 12's stock kernel produced flickering and incorrect colour output that required a backported kernel to resolve. The fingerprint reader was not supported by any available driver, which was expected and consistent across distributions.
The hardware support experience is largely a function of kernel version. Fedora ships kernels that are three to six months newer than Debian stable's kernel at any given time, and for hardware released in the last year or two, that difference is meaningful. For hardware that is two or more years old, the practical difference is minimal.
Package ecosystem: APT to DNF
The transition from APT to DNF involves a different mental model for a few operations:
Debian/APT: Packages are installed from the main, contrib, and non-free repository tiers. Non-free firmware and codecs are in non-free and non-free-firmware. The package naming convention tends toward libfoo-dev for development headers and python3-foo for Python bindings. The APT cache is persistent and requires manual cleanup with apt autoremove and apt clean. Dependency resolution is generally conservative — APT will refuse to proceed if a clean solution cannot be found.
Fedora/DNF: The main repository is "everything" — but genuinely non-free packages (Nvidia drivers, certain codecs, Steam) require enabling RPM Fusion free and non-free. Package names follow a broadly similar convention but with differences: Python packages are often python3-foo matching Debian, but development headers are foo-devel rather than libfoo-dev. DNF's automatic cleanup behaviour is more aggressive by default. dnf autoremove removes orphaned dependencies, and dnf clean all clears the package cache. The key operational difference is Flatpak integration — Fedora Workstation ships with Flathub available, and the expectation is that desktop applications may come from Flatpak rather than RPM packages.
sudo dnf install \
https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
RPM Fusion free includes open-source packages excluded from the main Fedora repository for legal rather than technical reasons — primarily multimedia codecs (GStreamer plugins, FFmpeg). RPM Fusion non-free adds proprietary packages including Nvidia drivers and Steam. The distinction mirrors Debian's main/non-free split but is distributed through a separate repository rather than a component of the main repository.
Firewall: UFW to firewalld
The most significant tooling adjustment was the firewall management layer. Fedora uses firewalld as its default firewall tool, which has a substantially different operational model from UFW. The full comparison is in the UFW vs firewalld technical note, but the practical summary for a desktop workstation context is:
firewalld's zone model means that the default zone assignment for a network interface determines which rules apply. On Fedora Workstation, the default zone for wired and wireless interfaces is "FedoraWorkstation," which opens a small number of ports for desktop features. The UFW equivalents of ufw allow and ufw deny translate to firewall-cmd --add-service and firewall-cmd --remove-service.
# List active zone and its services
firewall-cmd --get-active-zones
firewall-cmd --list-all
# Allow SSH permanently
firewall-cmd --permanent --add-service=ssh
# Remove a service
firewall-cmd --permanent --remove-service=mdns
# Apply permanent changes to running config
firewall-cmd --reload
The --permanent flag writes to the persistent configuration; without it, changes apply only until the next reload or reboot. This explicit separation between runtime and permanent state is the main conceptual adjustment from UFW, where every ufw rule change is automatically persistent.
What required adjustment
SELinux is enabled and enforcing by default on Fedora. On Debian and Ubuntu, AppArmor is the default MAC framework and is configured far less aggressively. Several self-hosted services that ran without issues on Debian required SELinux policy adjustments on Fedora — specifically services writing to non-default paths, binding to non-standard ports, or using network namespaces. The symptom is a silent permission denial that does not appear as a filesystem permission error. ausearch -m avc -ts recent and sealert from the setroubleshoot-server package are the diagnostic tools.
Fedora 38 and later default to using a unified kernel image (UKI) format for the boot process, replacing the separate kernel and initramfs files with a single signed EFI binary. This has implications for custom kernel module signing and for tools that manipulate the initramfs directly. If you rely on DKMS modules or custom boot parameters set through GRUB, verify compatibility with the UKI boot path rather than assuming the Debian-familiar approach applies.
Fedora's six-month release cycle means end-of-life arrives relatively quickly — typically thirteen months after release. Unlike Debian stable, which receives security updates for five or more years, Fedora releases receive support for approximately one year. Staying on Fedora means performing a distribution upgrade roughly every twelve months. The dnf system-upgrade path handles this well in practice, but it is a planned maintenance event that requires testing — in contrast to the rolling update model of Arch or the extended stable model of Debian.