Fedora Linux Deep Dive 2026: What Actually Happens Under the Hood

Fedora Linux usually gets explained through its image: “the fast one”, “the developer one”, “the one with the new stuff”. None of that is wrong, but none of it is a statement either — it’s a vibe. What almost nobody writes down: how far ahead exactly, measured against what, and what it costs.

So we went and looked instead of describing. This article is not a distro comparison — we already wrote those in Fedora vs Ubuntu and Debian vs Ubuntu. This is about the mechanics: what Fedora technically does, why it does it, and where it hurts.

Every number in this text was gathered on 15 August 2026. Specifically, we downloaded the package metadata for Fedora 44 (release repo, updates repo and Rawhide) and analysed it locally — roughly 480 MB of SQLite — plus the package indexes of Debian 13 and Ubuntu 26.04 LTS as a cross-check. Where we had to correct our own measurements, it says so in the text. That’s part of the method.

Fedora Linux by the numbers: how big is this thing?

Before any philosophy discussion makes sense, the scale. The “Everything” repository of Fedora 44 for x86_64 contains:

Method: primary.sqlite from the repodata of releases/44/Everything/x86_64/os/, fetched and analysed on 15 Aug 2026. Sizes are sums across all packages, including architecture variants.

The distribution says more than the total. 17,233 packages start with rust- — every Rust crate needed as a build dependency is its own RPM. On top of that: 4,744 texlive-, 4,075 perl-, 4,073 python3-, 1,203 golang-. And 28,211 packages end in -devel.

That’s the first finding that explains Fedora’s character: the catalogue is built for building, not for using. More than a third of all packages are development files, another near-quarter are language-ecosystem libraries that hardly any end user ever installs directly. Describing Fedora as a “desktop distribution” describes the surface of a system that is internally, above all, a very large and very current build machine.

For comparison, pulled from each project’s own raw data on the same day:

Method: Fedora from primary.sqlite (base + updates, unique package names); Debian from dists/trixie/main/binary-amd64/Packages.xz; Ubuntu from dists/resolute/{main,universe}/binary-amd64/Packages.xz. All fetched 15 Aug 2026.

The three are effectively the same size. The familiar “Ubuntu has more software” is not measurable across the official repositories. The difference lies elsewhere — and that’s the actual story.

Upstream proximity: the core of the Fedora model, measured

“Fedora is closer to upstream” is the standard sentence. It can be measured precisely. We compared the actually shipped version of 17 core components across all three distributions:

Method: Fedora from release plus updates repo (i.e. the state a current system actually has today); Debian and Ubuntu from the official Packages indexes, upstream version without epoch and without distribution revision. All values fetched 15 Aug 2026. Ubuntu values from main and universe.

Fedora leads or ties in 13 of 14 comparisons. More interesting than the result is the size of the gap, which is very unevenly distributed: for glibc and Python, Fedora is a single patch level ahead of Ubuntu. For LLVM it’s three major versions ahead of Debian. For Rust, twelve releases separate Debian from Fedora.

That isn’t random, it’s the fault line: the faster an upstream project releases, the further a long-freeze distribution falls behind. For software on an annual rhythm the difference is cosmetic. For compilers and toolchains on a six-week rhythm it becomes an obstacle to work.

The kernel: the single most telling number in this article

Fedora 44 was released on 28 April 2026 with kernel 6.19.10. The kernel a Fedora 44 system installs today is 7.1.8, built on 10 August 2026.

Now the point. We checked kernel.org for what counts as current on the same day. The answer from releases.json:

latest_stable: 7.1.8 — released 9 August 2026.

Inside an already-released version, Fedora ships exactly the kernel that kernel.org designated current stable one day earlier. Not in the development branch. In the stable release that has been running on production machines for three and a half months.

This is the core of the Fedora model and simultaneously its biggest misunderstanding: Fedora does not freeze versions within a release. A Fedora version is not a state, it’s a time window. What was in it at the start is often no longer in it at the end.

We counted this across the entire catalogue: of the 67,424 packages in the release repo, 19,677 have received an update since release. For 1,063 of those it was a jump in the major version number — not a bugfix, but a new major version mid-release. On top of that, 1,547 packages only appeared after release.

Method: package names from release repo and updates repo matched (architectures x86_64 and noarch), major version taken as the leading digit sequence of the version string. Packages with date-based versions (e.g. 2026.06.16) were excluded from the major-jump count because a year rollover there is not a substantive jump — that affected another 127 packages.

That’s the honest price of “current”: a Fedora system left untouched for three months and then updated doesn’t just get security fixes, it partly gets new software. If you need stable target environments, you’re in the wrong place — by design, not by lack of quality.

Rawhide: far closer to stable than its reputation suggests

Rawhide is Fedora’s permanently rolling development branch. Its reputation: “everything breaks constantly.” We measured how far Rawhide actually sat from Fedora 44 at the time of measurement.

We compared every package that exists in both (65,874 shared names):

Method: primary.sqlite from development/rawhide/Everything/x86_64/os/ against Fedora 44 release+updates, unique package names, architectures x86_64 and noarch, fetched 15 Aug 2026. Snapshot in time — the gap is smallest shortly after a release and largest shortly before the next.

Almost nine out of ten packages are bit-identical between Rawhide and stable Fedora. The difference concentrates in a few but fundamental components:

This explains Rawhide’s risk profile better than any anecdote: the risk isn’t in the breadth, it’s in the depth. The 2.6 % of packages that run ahead aren’t randomly distributed — they are systemd, glibc, the desktop and the language runtimes. Exactly the parts whose failure doesn’t break a program, it breaks booting.

And a detail that surprises many: Rawhide contains release candidates and betas (3.15.0~rc1, 51~beta, 6.1.0~rc1). That’s not an oversight, it’s the purpose. Rawhide is the integration surface on which Fedora tests upstream pre-releases under real conditions — and it’s a good part of the bug reports upstream projects receive before going final.

RPM 6: the biggest packaging update in years — with one caveat

Fedora 44 ships RPM 6.0.1. That’s notable because RPM stayed on major version 4 for a full 25 years, from 4.0 (year 2000) through 4.20. RPM 6.0.0 appeared on 22 September 2025, 6.0.1 on 10 December 2025.

The substantively important changes, per the official release notes on rpm.org:

• Signature checking is enforced by default. Previously it was configurable optional behaviour.
• MD5 and SHA1 removed as package digests. New: SHA3-256 as header digest, SHA-512 and SHA3-256 as payload digests.
• Support for OpenPGP v6 and post-quantum keys. This is the most concrete PQC preparation you can see in a package manager today.
• Multiple signatures per package. A package can be attested separately by build, distribution and re-signing.
• Installing RPM v3 packages removed. Querying and unpacking still works.
• All file sizes and limits are now 64-bit.

The part we checked ourselves — and which qualifies the headline

“Fedora 44 uses RPM 6” is the obvious summary. It’s imprecise, and the difference matters: RPM 6 can build two package formats, v6 and v4. So the question isn’t just which tool is installed, but which format the packages are actually in.

You can check that directly on the file. Every RPM starts with a 96-byte “lead”; the fifth byte holds the format field. Per the format documentation on rpm.org, it carries 3 for v4 packages and 4 for v6 packages.

We fetched the first 96 bytes of one package from each of three different repositories:

Method: HTTP range request for the first 96 bytes of each .rpm file, magic ED AB EE DB confirmed, byte 4 read out. Format mapping per the official v6 format description on rpm-software-management.github.io. Fetched 15 Aug 2026.

Fedora ships RPM 6 as the tool but still builds its packages in v4 format — in Rawhide too, and for freshly built packages too. The new cryptography and the post-quantum signatures are therefore present and usable, but not yet in service in the shipped catalogue.

That’s the more honest sentence, and it’s also the more sensible state of affairs: changing the package format of a distribution with 76,000 packages isn’t flipping a switch, it’s a migration touching every tool in the ecosystem. Anyone concluding from “Fedora has RPM 6” that they’re installing post-quantum-signed packages today is wrong.

🔑 Rule of thumb for any version claim: the installed version of a tool tells you what is possible — not what is being done.

DNF5: what the switch actually changed

Fedora 44 ships DNF 5.4.1.0. The most important part of this switch isn’t the speed everyone talks about, it’s an architectural decision: DNF5 is written in C++, DNF4 was Python. That has three practical consequences.

First, the Python interpreter startup on every invocation is gone. That’s why dnf feels different today — not a faster solver, but a startup penalty that no longer exists.

Second — and this matters more — the package manager can now be embedded as a library into other programs without dragging a Python stack along. That’s why dnf5daemon exists as a PackageKit replacement: the graphical software manager on the desktop now talks directly to the same library as the command line. Previously those were two routes to the same destination that occasionally disagreed.

Third, python3-dnf is still installed — at version 4.24.0. Anyone with automation written against the DNF4 Python API will still find it there. That’s transition comfort, not a commitment.

We counted the command surface directly from package metadata rather than quoting documentation. DNF5 advertises each subcommand as its own dnf5-command(...) provide:

Method: provides table from Fedora 44’s primary.sqlite, filtered to entries of the form dnf5-command(...). Fetched 15 Aug 2026.

The mechanism behind this is more elegant than it looks: because every subcommand is its own RPM provide, DNF can look up for an unknown command which package would supply it. Same trick as command-not-found, but inside the package manager.

And dnf5 additionally provides plain dnf. So typing dnf install invokes DNF5. That explains the most common confusion in forums: older guides keep working about 90 % of the time, and the remaining 10 % — mostly certain options and output formats — then fail for no visible reason.

The practical stumbling blocks

• dnf5 no longer knows some DNF4 options. The classic is group management, whose syntax changed.
• DNF4 plugins don’t run under DNF5. They need their own port — hence the separate list above.
• Scripts that parsed dnf output are fundamentally suspect. They always were; DNF5 merely collected the overdue bill.

SELinux: the difference you only notice when it gets in the way

Fedora has had SELinux enabled by default since Fedora Core 2, in enforcing mode with the targeted policy. It’s the setting new users most often disable first, and the one least often understood.

The difference from AppArmor, used by Ubuntu and openSUSE, is not “stricter versus looser”. They are two different models:

AppArmor is path-based. A rule says: this program may access this file path. That’s readable and easy to write. The drawback sits in the model: a path is a name, not an object. Hardlinks, bind mounts and renames can sever the relationship between rule and actual file.

SELinux is label-based. Every file, process, port and socket carries a label in an extended file attribute. Rules describe which type may access which type. The label sticks to the object, not the name — which is why it doesn’t get lost when things move, and also why it’s so painful when a label is wrong.

That’s exactly where the most common Fedora frustration comes from: you mv a file from your home directory to /var/www, it keeps its home label, and the web server isn’t allowed to read it. The file is there, permissions are correct, ls -l looks perfect — and it still doesn’t work. That’s not a bug, that’s the model. restorecon resets the label to the value intended for the path.

The number that shows how seriously the ecosystem takes this

A security technique is only worth its coverage. We counted how many packages in Fedora 44 ship their own SELinux policy:

• 73 packages end in -selinux and thus bring their own rule set — including container-selinux, flatpak-selinux, cockpit-selinux, fail2ban-selinux, ceph-selinux, grafana-selinux, freeipa-selinux.
• The central selinux-policy is at version 43.3 and split into seven variants: targeted (default, approx. 18 MB installed), minimum, mls, plus devel, doc, sandbox and the base package.

Method: package names and installed sizes from Fedora 44’s primary.sqlite, fetched 15 Aug 2026.

That’s the actual point: in Fedora, SELinux isn’t a system setting, it’s a packaging convention. Whoever brings a server application to Fedora ships the policy with it. That’s why so many services work out of the box in enforcing mode there — and why turning SELinux off is more expensive than it feels: you throw away 73 shipped rule sets at once.

And the mls variant is the reason the technology looks the way it does: Multi-Level Security comes from the requirements of agencies with classification levels. SELinux was originally developed by the NSA and released under the GPL in 2000; RHEL — and therefore Fedora as its proving ground — made it standard equipment.

Btrfs by default: what that means in practice

Since Fedora 33, Btrfs has been the default filesystem for the desktop variants. The reason is written out in the official change proposal in the Fedora wiki: they wanted to provide filesystem features “in a transparent fashion” — that is, deliver capabilities without users having to configure them.

What Fedora actually creates on a default install:

• One Btrfs partition with the subvolumes root and home — not separate partitions. Space is therefore shared, not pre-allocated. That ends the classic problem of /home being full while 200 GB sit idle in /.
• Transparent compression with zstd:1. On modern CPUs that’s practically free and saves considerable space on source code, logs and text data.
• Checksums for data and metadata. Btrfs detects silent data corruption instead of passing it along.

And now the part missing from most Fedora recommendations:

Fedora does not set up automatic snapshots by default. Copy-on-write and subvolumes are the technical prerequisite for snapshots, but the automation isn’t included. If you want openSUSE-style comfort — a snapshot before every package operation, rollback from the boot menu — you install and configure snapper, the matching DNF plugin and grub-btrfs yourself.

That’s a deliberate decision, not a gap: automatic snapshots need a cleanup concept, otherwise the disk eventually fills — and a rollback mechanism nobody has tested is more dangerous than none. But you should know it before relying on a safety net that isn’t actually strung.

Btrfs tooling in Fedora 44: btrfs-progs 6.19.1 in the release, meanwhile 7.0 via updates. Again a major version jump inside a running release.

Where Btrfs is not the right choice

Staying honest: Btrfs isn’t superior everywhere.

• Databases and VM images suffer under copy-on-write (fragmentation, write amplification). For those directories, chattr +C or a separate XFS volume is the better call. This is why Fedora Server still uses XFS as its default, not Btrfs.
• RAID 5/6 is still considered not production-ready in Btrfs. For block-level redundancy it remains mdraid, or RAID 1/10 within Btrfs.
• On very full filesystems, space behaviour is harder to predict than with ext4 — df can be misleading on Btrfs because metadata and data have separate reserves.

The Atomic Desktops: Fedora’s most interesting experiment

Fedora 44 ships four Atomic Desktop variants. We checked the ISO directories of the official mirror rather than relying on overview articles:

Method: directory listing of dl.fedoraproject.org/pub/fedora/linux/releases/44/, fetched 15 Aug 2026.

The ostree in the filename is the whole difference. A classic Fedora installs individual RPMs into a writable root filesystem — the state emerges from the sum of every transaction ever performed. An Atomic Desktop instead receives a finished, immutable system tree, like a container image. Nothing is installed individually; a new tree is deployed and booted into on next start.

The practical consequences:

• The root filesystem is read-only. /usr is not writable, /etc and /var are.
• Updates are atomic. Either the new tree is fully there, or you stay on the old one. A power cut mid-update leaves no half-updated system.
• Rollback is a boot menu entry. The previous tree is retained. rpm-ostree rollback plus a reboot is enough.
• Two identical machines are genuinely identical. On package-based systems the state is path-dependent — whatever was once installed and removed leaves traces.

Fedora 44 ships rpm-ostree 2026.1 and bootc 1.12.1. The latter is the more interesting number: with bootc the model shifts from “ostree trees” to “the operating system is an OCI container image you boot”. The toolbox you build containers with becomes the same one you build operating systems with. At the time of our measurement, bootc upstream was at v1.16.8 from 13 August 2026 — here too, upstream moves faster than the release.

The price no Atomic marketing text mentions

The trade is real: you give up the ability to just quickly install something.

Software on an Atomic Desktop arrives via three routes — and the most convenient is the one you’re supposed to use least:

1. Flatpak for graphical applications. The intended route. Fedora ships flatpak 1.17.6 and operates its own Flatpak registry.
2. Containers for everything development-related, via toolbox (0.3) or distrobox (1.8.2.4). You work inside a container that looks like a normal Fedora but doesn’t touch the base system.
3. rpm-ostree install as the escape hatch. This “layers” an RPM onto the system tree. It works — but every layered package has to be re-applied over the tree on every update. Accumulate twenty of them and you’ve acquired the downsides of both worlds.

Our honest assessment: Atomic Desktops are excellent for machines with a clear purpose — work devices, kiosks, developer laptops with containerised environments, fleets. They’re tedious for machines with unpredictable requirements, for specialist drivers, and for anything needing kernel modules. If you regularly attach hardware that has proprietary drivers, you’ll be happier with the classic Workstation model.

Fedora as a developer machine: why exactly, not just that

“Fedora is good for developers” is true and says nothing. From the numbers gathered, three concrete reasons can be named.

First: the toolchain is the current one, not last year’s. GCC 16.1.1, LLVM 22.1.8, Rust 1.97.1, Go 1.26.5, Python 3.14.6. That matters as soon as you build against language standards that move: Fedora 44 supports C++26 and C23 per project statements. Building on Debian 13 against LLVM 19 means developing against a compiler three major versions old.

Second: the repository is built for building. The 28,211 -devel packages aren’t ballast, they’re the point. Nearly every library in the catalogue has its headers available. In practice that means dnf builddep on a source package and the build environment stands — without hunting for the package that happens to contain that one header file.

Third: containers are first-class citizens, not retrofitted. Podman 5.8.4 is part of the base system, as are toolbox and distrobox. That’s no coincidence: Podman comes from the same house as Fedora, and rootless operation — containers without root privileges — has the longest practical track record here. Add container-selinux, which ships the hardening rather than leaving it to the user.

The price is stated above: 19,677 updated packages in three and a half months, 1,063 of them with a major version jump. A development machine that is current is by definition one that moves. If you need a target environment that stays exactly as it was on day one, you build that into a container — not into the host system.

Wayland: the transition is practically complete

Fedora was the first major distribution with Wayland by default (Fedora 25, 2016). Ten years on, the interesting question is no longer whether Wayland works, but what remains of X11.

Fedora 44 ships GNOME Shell 50.0 in the release and 50.4 via updates, with Mutter at the same version. The GNOME X11 session path was removed upstream by GNOME; starting GNOME on Fedora today starts Wayland — with no choice at the login screen.

What remains in practice:

• XWayland still translates for X11 applications. That covers old proprietary software and some games. Invisible to most users.
• Screen capture and remote access run via PipeWire and the portal system rather than direct X11 access. This is where Fedora users historically hit the most friction — and why GNOME 50 explicitly brings remote desktop improvements per the release announcement.
• Applications needing global hotkeys or other programs’ windows fundamentally work differently under Wayland. That’s not a bug, it’s the security model: under X11 any program could eavesdrop on any other.

If you prefer KDE: Fedora 44 ships Plasma 6.6, with the Plasma Login Manager instead of SDDM.

The Nvidia reality: the most honest section of this article

This is where Fedora loses newcomers most often — and we have first-hand experience, because an HP Omen with an RTX 4070 Laptop GPU (Ada Lovelace) was migrated to Fedora Workstation here.

The starting point: Fedora ships no proprietary Nvidia drivers. That’s not a technical decision but a licensing one — Fedora’s guidelines don’t permit non-free software in the official repositories. You need RPM Fusion, a community-operated additional repository.

We counted what’s actually in there for Fedora 44:

And the driver versions in the nonfree branch:

Method: primary.sqlite of the RPM Fusion updates repositories for Fedora 44, fetched 15 Aug 2026.

A detail we nearly wrote down wrong

Our first cross-check was the file latest.txt on Nvidia’s own download server. It said 580.126.09. The obvious headline from that would have been: “RPM Fusion at 610.57.04 is even ahead of Nvidia’s official driver.”

That would have been wrong. A look at the directory listing of the same server shows folders for 610.43.02, 610.43.03 and 610.57.04. So latest.txt doesn’t point to the newest driver overall, it points to the current state of one particular branch.

🔑 Rule of thumb: a file named latest is a statement about what someone chose to maintain as “latest” — not about what is newest. The correct summary is: RPM Fusion ships 610.57.04, and that’s also the highest version present on Nvidia’s server.

Why it still blows up regularly

The mechanism is called akmod. An akmod package contains no finished driver but source code plus the automation to rebuild it for the next kernel. That’s the answer to Fedora’s fast kernels — with 6.19 to 7.1 inside one release, a prebuilt module would be worthless within weeks.

The price: after a kernel update the module must be built before the new kernel boots. If that doesn’t happen in time — because you rebooted too quickly, because the build failed, because the new kernel changed an API Nvidia hasn’t adopted yet — you boot into a machine without a working graphics driver.

Practical rules that remove nearly all of the pain:

• After a kernel update, don’t reboot immediately. Check whether the module exists for the new kernel.
• Secure Boot requires its own signing key for the self-built module. Without that step the kernel won’t load it — and the error message rarely names the real cause.
• Keep the previous kernel. Fedora keeps three by default — the boot menu is the safety net.
• On hybrid-graphics laptops, the default is that the discrete GPU only spins up on demand. Forcing it on permanently costs battery life for no benefit.

None of this applies to AMD graphics. The driver is in the kernel, Mesa does the rest — Fedora 44 is at Mesa 26.1.6 by now. That’s why the Fedora experience with AMD hardware is so much smoother than with Nvidia, and one of the few cases where hardware choice matters more than distribution choice.

A side finding: Fedora still packages browsers itself

While cross-reading the Ubuntu package list, we noticed something that has nothing to do with Fedora and yet says a lot about it.

In Ubuntu 26.04 LTS, firefox, thunderbird and chromium-browser are no longer programs. They are transitional packages that install a snap:

Method: Installed-Size and Description fields from the Ubuntu Packages indexes for resolute, fetched 15 Aug 2026.

In Fedora 44 the same programs are ordinary RPMs: Firefox 153.0.3, Chromium 151.0.7922.137 (both via updates; the release had 150.0 and 146.0).

This isn’t a moral question but one about control: a snap is updated from the vendor store, independently of the system update, and can’t easily be pinned. An RPM comes from the same repository, the same signature chain and the same update transaction as the rest of the system. For workplaces with change processes that’s a tangible difference — and one of the most practical reasons Fedora is easier to justify in enterprise environments with strict policies than Ubuntu.

Who Fedora is right for — and who it isn’t

After all this measuring, the line can be drawn fairly sharply.

Fedora fits if:

• You develop and need a current toolchain — especially with C++, Rust, Go, Python or anything building against moving standards.
• You treat containers as a natural part of the work. Podman, rootless and container-selinux are finished here, not retrofitted.
• You have AMD graphics. Then you get current Mesa versions with no third-party repositories, and that’s the entire effort.
• You update regularly. Fedora rewards continuous maintenance and punishes neglect — after six months of silence the update is large.
• You mean the security model seriously and don’t want to disable SELinux but understand it.

Fedora doesn’t fit if:

• You need a stable target environment that doesn’t move for two years. For that there’s Debian stable, Ubuntu LTS, RHEL/AlmaLinux/Rocky — and Fedora is their proving ground, not their replacement.
• You run servers and want quiet. Fedora Server gets roughly 13 months of support per version. You could rebuild your servers every 13 months — most people don’t want to. We run our own production servers on Debian, not Fedora, for this reason.
• You update rarely, or maintain machines that stay off for months.
• You have Nvidia graphics and no appetite for the akmod cycle. It’s manageable, but it’s work.
• You need software that only exists as a .deb. That’s getting rarer, but it happens.

For the server case, our comparison Debian vs Ubuntu is worth a look; for everyday desktop trade-offs, Fedora vs Ubuntu sits alongside it. If you’re thinking about hardening, IT security vulnerabilities covers the attack classes techniques like SELinux were built against — and our report on the server hijacked for five days is the case where exactly that happened to us.

FAQ: Fedora Linux deep dive

Is Fedora just a testing ground for Red Hat Enterprise Linux?

Partly — and that’s an advantage, not a flaw. Fedora is the upstream source RHEL versions emerge from, and it is substantially funded by Red Hat. But that doesn’t make Fedora unstable: the numbers above show a system with complete security infrastructure, shipped SELinux policies for 73 packages, and an orderly release process. What Fedora doesn’t offer is long support windows — and those are exactly the product RHEL sells.

How long is a Fedora version supported?

Roughly 13 months. New versions appear about every six months, and each is maintained until four weeks after the release after next. Fedora 44 appeared on 28 April 2026; Fedora 45 is in progress with a beta in August 2026. Practically that means at least one version upgrade per year, otherwise you run without security updates.

Can I use Fedora as a server?

Technically yes — there’s a dedicated Server edition and the package selection is excellent. Operationally, the 13 months of support argue against it. For servers meant to run without anyone watching, Debian stable, Ubuntu LTS or a RHEL rebuild are the better tools. Incidentally, Fedora Server still uses XFS as its default filesystem, not Btrfs.

Is Fedora faster than Ubuntu?

In perceived responsiveness often yes, but not for the reason people assume. The most noticeable difference is that Fedora ships system applications as native packages where Ubuntu uses snaps — the first launch of a snap is markedly slower. Add DNF5’s eliminated Python interpreter startup. In raw computational performance, the two distributions are indistinguishable.

Do I have to disable SELinux to make things work?

No, and you shouldn’t. The 73 packages with their own policy show the ecosystem is designed for it. On access errors the correct response is almost always restorecon on the affected files or setting an appropriate context — not setenforce 0. Disabling SELinux throws away all shipped rule sets at once.

Does Btrfs give me automatic snapshots and rollback?

No. Fedora creates Btrfs with subvolumes and zstd compression but sets up no automatic snapshots. For openSUSE-style comfort you need snapper, the DNF plugin and grub-btrfs — all installable afterwards, but afterwards is the operative word.

Silverblue or Workstation — which should I take?

Workstation if you need unpredictable software, build kernel modules or use proprietary drivers. Silverblue if your machine has a clear purpose, you work with containers anyway, and you want a system that doesn’t change through use. The honest rule of thumb: if you regularly need rpm-ostree install, Workstation is the right choice.

Does Fedora 44 really use the new RPM 6 package format?

No — and that’s an important distinction. Fedora 44 ships RPM 6.0.1 as the tool, which can build and read v6 packages. But the packages actually shipped are still in v4 format; we verified this directly on the file for packages from the release repo, the updates repo and Rawhide. Post-quantum signatures are therefore possible but not yet in service in the catalogue.

Is Rawhide worth using daily?

For most people no, but for a more precise reason than “too unstable”. Our measurement shows 88.4 % identical packages between Rawhide and Fedora 44. The difference concentrates in systemd, glibc, the desktop and language runtimes — exactly the components whose failure prevents booting rather than breaking one program. If you want to contribute, run Rawhide in a VM or on a secondary machine.

How do I switch from Ubuntu to Fedora?

The technical hurdle is low; the mental one lies in three points: apt is called dnf, SELinux is live instead of AppArmor, and proprietary drivers plus codecs come from RPM Fusion rather than the main repository. Set those three up on day one and the typical migration problems are behind you. Details in the comparison Fedora vs Ubuntu.

Conclusion: a distribution you have to understand rather than use

After this measurement we would no longer describe Fedora as “the current Linux” but more precisely: Fedora is a distribution that made currency a design decision — with all the consequences attached.

The three numbers that prove it are all above:

1. Kernel 7.1.8 in a release published three and a half months ago — the same state kernel.org designated current stable one day earlier.
2. 19,677 updated packages since release, 1,063 of them with a major version jump. A Fedora version is not a state, it’s a time window.
3. 88.4 % identical packages between Rawhide and stable Fedora. The development branch is far closer than its reputation suggests — the risk is in the depth, not the breadth.

Read that as an advantage and you get one of the best developer machines available. Look for stability in the sense of immutability and the same numbers read as a warning — entirely correctly.

And the finding that surprised us most while writing is the smallest one: Fedora ships RPM 6 and still builds v4 packages. We would have written that differently without checking, and it would have sounded right. It’s also the most general lesson of this article — the installed version of a tool tells you what is possible, not what is happening.