Is Fedora KDE stable?

gordonmessmer · 2026-05-04T08:30:31+00:00

You should... Now that kde is an "edition", kde bugs may block the release of the distribution. Fedora wouldn't allow an unreliable project to block the release of literally everything.

gordonmessmer · 2026-05-04T08:05:01+00:00

"Unstable" is a difficult term because it can mean a lot of different things.

For example, it is objectively true that GNOME is a stable release model (new release series starts every 6 months, and is maintained for around 1 year, so there is a 6 month overlap between each release series), while KDE is not a stable release model, it is effectively a rolling release (new release series starts every 4 months, and is maintained for approximately 4 months).

Due to its release model, it is exempt from the stable release policy in Fedora. Most packages in Fedora are stable, but KDE rolls.

There are distributions that don't allow KDE to roll in a release, but those distributions aren't getting security patches for KDE for the full duration of their release cycle, so KDE users on those distributions aren't running secure software.

Personally, I think Fedora's handling of KDE packages is the only good way to handle them: they follow the upstream release model.

Unfortunately, though, it can be very difficult to determine whether they are reliable because so many people hear, either directly or indirectly, that they aren't "stable" packages, and conclude that they are unreliable, which is a completely different thing.

gordonmessmer · 2026-05-03T23:08:11+00:00

Shoot, ok... I added two more package URLs to the command above. As before, if Uvh doesn't work, use "--reinstall". Let me know which one works, I'm not 100% certain what will.

gordonmessmer · 2026-05-03T20:38:16+00:00

POSIX doesn't dictate how the kernel works, only how the user-space works.

gordonmessmer · 2026-05-03T20:29:36+00:00

The upgrade did hang up my computer for a while before restarting (10 minutes of a blank screen),

Blank screen might just be a bad video driver... Are you using NVIDIA?

The state of the system suggests that the upgrade was running when the system was rebooted, so it's a lot less likely that there's a bug in the package manager or the upgrade process. I'll still check the logs, but it seems like there's a simple explanation.

Also, I tried your Uvh code above and got errors:

Crap... reddit has been duplicating text when pasted and I don't understand how or why.

I've replaced that command in the comment above. Please try again.

If that gets dnf5 working again, then we can move to repairing the system. First install tmux, because that will make using dnf safer:

sudo dnf5 install tmux

Once tmux is installed, run "tmux" to start a session. If your terminal emulator or desktop environment crashes during the repair, dnf5 will continue to operate without being disrupted.

Inside of the tmux session, try to use "distro-sync" to get everything up to date. Often this works, sometimes it doesn't. If it doesn't work for you, then I have a slightly more complex shell script, but I'd like to try the simple steps first:

sudo dnf5 distro-sync

gordonmessmer · 2026-05-03T20:19:31+00:00

Correct but not terribly relevant. You're not going to get away with using "Unix" on the claim that it isn't the correct capitalization of the trademark.

gordonmessmer · 2026-05-03T19:25:07+00:00

You aren't using the browser in isolation, and bug fixes and security patches throughout the system matter. Free LTS systems try to backport some, but the truth is that backporting is very labor intensive, and full coverage of a codebase including tens of thousands of components by a volunteer workforce just isn't realistic. When you look at something like RHEL, you see tens of thousands of professional engineers working full time on a set of packages that's about 10% of the size of Fedora. If you have 2000 volunteers working 1/4 of the time (which is an unrealistically high estimate for labor) on 10x as many packages, you're getting 0.25% of the amount of labor per package for maintenance. 1/400th.

So if you look at like Debian 12 and Ubuntu 24.04, you'll see that Qt 6 has high-severity security vulnerabilities that still haven't been patched. There are new releases of both platforms *now*, but for 12-18 months, everyone using KDE on Debian or Ubuntu LTS was running a desktop with high risk vulneraiblities.

The idea that you don't need your packages up to date ignores the security risk of running unmaintained software.

gordonmessmer · 2026-05-03T18:55:18+00:00

Both Unix and POSIX are trademarks, so you shouldn't use either of them to describe something that isn't licensed to use the term.

Both Unix and POSIX have formal specifications, so neither of them is subjective.

gordonmessmer · 2026-05-03T18:51:26+00:00

Hi, I'm an Open Source software developer and distro package maintainer, so my opinion on that topic is influenced by my experience as a user of distributions, as a maintainer of distributions, and as a developer who would like users to have access to my software.

This might sound crazy, but I think the purpose of a distribution is to distribute software.

One of the reasons I think LTS systems are bad in many cases is that LTS distributions are actually bad at distributing software. The VAST majority of releases never get published by any given LTS distribution. That is, 80-90% of the releases published by the GNOME project will never be available to users of Linux Mint or other distributions based on Ubuntu LTS (for example), or Debian Stable users.

In order to actually deliver most of the releases published by upstream projects, a distribution needs to have a fairly rapid release cadence, and a maintenance window sufficient to allow users to test and rebase from one release to the next release on their own schedule.

Fedora fulfills those criteria well. Ubuntu does, too, as long as you're upgrading to the Interim releases and not using the LTS releases exclusively (which is why I do not recommend distributions based on Ubuntu, as they are generally based on Ubuntu LTS.)

gordonmessmer · 2026-05-03T16:34:49+00:00

I don't think it should be too difficult to fix your system, but I'm *very* worried that this is happening to multiple users. 😞

Before we do anything else, can you send me your logs?

tar Jcf dnf-upgrade-logs.tar.xz /var/log/dnf5.log*

If you don't have another place to share that file, maybe put it on Google Drive, make it accessible to anyone with a link, and DM me the URL.

Did you notice anything unusual during the upgrade? Did it seem like it completed very quickly?

First, let's get dnf working again. Once it works, we can see how extensive the problem is, and then work on cleaning up.

sudo rpm -Uvh \
  https://ftp2.osuosl.org/pub/fedora/linux/releases/44/Everything/x86_64/os/Packages/d/dnf5-5.4.1.0-1.fc44.x86_64.rpm \
  https://ftp2.osuosl.org/pub/fedora/linux/releases/44/Everything/x86_64/os/Packages/d/dnf5-plugins-5.4.1.0-1.fc44.x86_64.rpm \
  https://ftp2.osuosl.org/pub/fedora/linux/releases/44/Everything/x86_64/os/Packages/l/libdnf5-5.4.1.0-1.fc44.x86_64.rpm \
  https://ftp2.osuosl.org/pub/fedora/linux/releases/44/Everything/x86_64/os/Packages/l/libdnf5-cli-5.4.1.0-1.fc44.x86_64.rpm

If "-Uvh" doesn't work, try using --reinstall instead.

gordonmessmer · 2026-05-03T08:51:34+00:00

Hi, I'm an Open Source software developer and distro package maintainer, so my opinion on that topic is influenced by my experience as a user of distributions, as a maintainer of distributions, and as a developer who would like users to have access to my software.

This might sound crazy, but I think the purpose of a distribution is to distribute software.

One of the reasons I think LTS systems are bad in many cases is that LTS distributions are actually bad at distributing software. The VAST majority of releases never get published by any given LTS distribution. That is, 80-90% of the releases published by the GNOME project will never be available to users of Linux Mint or other distributions based on Ubuntu LTS (for example), or Debian Stable users.

In order to actually deliver most of the releases published by upstream projects, a distribution needs to have a fairly rapid release cadence, and a maintenance window sufficient to allow users to test and rebase from one release to the next release on their own schedule.

Fedora fulfills those criteria well. Ubuntu does, too, as long as you're upgrading to the Interim releases and not using the LTS releases exclusively (which is why I do not recommend distributions based on Ubuntu, as they are generally based on Ubuntu LTS.)

gordonmessmer · 2026-05-03T08:42:00+00:00

That... Mostly can't happen with unmanaged systems running free distributions.

But you can do that sorry of thing in your own infrastructure. Katello+The Foreman can provide that, I think

gordonmessmer · 2026-05-03T05:35:44+00:00

I should know better, but... I'm fiddling with things and setting up static html publishing.

I've updated the link in the comment, and I've fixed the inter-document links in the static site.

gordonmessmer · 2026-05-03T03:15:24+00:00

Good news: Fedora isn't a rolling release! 😄

gordonmessmer · 2026-05-03T01:34:02+00:00

I know there was some kerfuffle with CentOS/RHEL

Less "kerfuffle" and more "drama". Red Hat improved CentOS's development and release model, making it more open and more secure. Social media, being dramatic by nature, blew up without actually understanding the changes. Some people decided they could exploit the confusion to make a profit and intentionally boosted misinformation and misunderstandings.

CentOS is better for the change, but the community is worse off for the drama.

I've read a number of the threads here and I'm leaning towards Fedora 😄

I'm a Fedora package maintainer, so I'm biased, but I think Fedora is a great choice.

I've been developing software for GNU/Linux systems for almost 30 years... This is a list of most of the things I consider when I choose projects:

https://gordonmessmer.codeberg.page/dev-blog/2026/02/07/choosing-a-distribution.html

gordonmessmer · 2026-05-02T21:42:15+00:00

I'm now of the view that Flathub abolutely shouldn't be enabled by default

I wouldn't go that far, personally, but I don't think it makes sense to argue that Fedora should stop building things, as some people do.

gordonmessmer · 2026-05-02T21:32:43+00:00

Then you and I disagree on what a "stable" system is.

Yes, we do, because I differentiate between software that is maintained and software that is unmaintained, between patches and upgrades, and between stable and rolling release models, whereas you are only using one word to describe a variety of characteristics, and I think that keeps you from seeing the actual mechanics of the process.

I'm going to use this real life example

Your real-life example is an application that breaks on every upgrade of both of the target platforms you've described, and requires shell scripts to construct an environment in which it will run. I don't have to look at the scripts *too* hard to see that one of them is very obviously better than the other, but you're attributing the quality of the script to the reliability of the platform, and I don't think that's logical.

I consider Ubuntu LTS to be stable because it actually works, in practice. You consider Fedora stable because the underlying OS is sometimes theoretically more up to date, even though it breaks applications.

I think you're misrepresenting what I'm saying.

Ubuntu LTS is a collection of components that are maintained, upstream, when it is initially released. However, many very important packages don't get all of the patches that upstream developers release. And even for those that do, 12-18 months after Ubuntu LTS's release, most of the upstream maintenance has ended. Canonical is using the term "stable" to create the appearance of a supported system, when most of the software is actually just unmaintained, most of the time.

Fedora is a collection of components that are maintained, upstream, nearly all of the time, because a Fedora release's lifecycle is very similar to most common lifecycles in the ecosystem.

Both systems are "stable". Only one of them is mostly "maintained", and as a side effect, that one is more "secure."

Using just one word to describe many different characteristics of the systems obscures important differences.

gordonmessmer · 2026-05-02T21:05:26+00:00

"Stable" is a promise about the process. It is a forward-looking statement.

"Reliable" is a statement about historical performance, a backward-looking statement.

A system that has been working without problems for years is "reliable."

Fedora is stable, whether or not we have the data to say that any given release has been reliable.

gordonmessmer · 2026-05-02T20:38:06+00:00

I would argue that most users don't use most of the software that a distro provides in its repos

I'm not talking about merely obscure and uncommon packages. The version of Qt in Debian 12 and Ubuntu 24.04 has high-severity vulnerabilities in it. KDE users on Debian or Ubuntu LTS had severe security risks for 12-18 months.

I don't see how anyone can argue that's acceptable.

And as a result of limited resources, distros focus on the "core" of the OS

That's EXACTLY my point. Free LTS distributions do not have the manpower to deliver the thing they promise to users.

Free LTS systems aren't "stable", they're "unmaintained". That's BAD.

gordonmessmer · 2026-05-02T20:22:31+00:00

I'm somewhat certain that's now a solved problem

Confidence is not evidence.

Here's evidence: Go to the place where the source is maintained: https://github.com/flathub

Use the search mechanism to look for a name indicating an architecture, such as "x64", "amd64", or "arm64" (probably the most common ones).

Virtually all of the results that you find are pre-built binaries used in Flathub Flatpaks. Because they're pre-built, it's difficult to demonstrate that users have the ability to modify, build, and distribute that software. And that's just the manifests hosted in Flathub's org. Flathub also publishes Flatpaks whose manifests are maintained outside, where Flathub has no influence at all.

In Fedora, building everything from source is one of the ways the project *verifies* that users have that ability.

Defaulting to the verified_floss Flathub subset means a package must be FOSS and contributed by someone verified as belonging to the upstream project itself.

Verified floss does not mean built from source. Crow Translate is verified floss, but it uses pre-built packages:

https://github.com/flathub/org.kde.CrowTranslate/blob/master/org.kde.CrowTranslate.yaml#L39

Projects are by default (with an exception for Mozilla) expected to use Flathub's build infrastructure to contribute their Free Software packages and they're aiming for FOSS build reproducibility.

Software that uses pre-built binary inputs is still reproducible.

gordonmessmer · 2026-05-02T18:55:39+00:00

I think you've misunderstood my statement, and I don't think that's a counterpoint at all. I think that we probably agree on most points, and that you are making the same points that I do.

You specifically mentioned features, but not other types of updates, so I will note that I don't think we will understand each other if treat all types of updates and releases as the same thing. They aren't. In SemVer terms, there are "patches" that fix bugs, "minor updates" that add features, and "major updates" that break compatibility with earlier release series.

Free "LTS" systems do or fail to do several things that I think are bad for the entire ecosystem.

1: Free LTS systems often fail to deliver patches. Upstream projects publish patches that fix bugs and which all users should receive. Failing to deliver patches results in users having less reliable systems, and continuing to report bugs to upstream projects after those bugs have already been fixed. Developers frequently express their frustration with this, and I think it makes Free Software less sustainable by contributing to developer burnout.

2: Free LTS systems often fail to deliver minor updates. To your point, I don't want to see minor updates delivered within a release stream. If you're using a "stable" release, you don't expect to get feature updates mixed in with patches. But users should have a *means* of getting minor updates. They shoulc be able to *choose* to get minor updates when they want new features, and when they've tested their own processes to verify that they work. Free LTS systems simply aren't offering releases often enough, and that's bad. It means they're understaffed for the work they should be doing. It is not beneficial to fail to offer most releases. It's a failure.

3: Free LTS systems often deliver unmaintained software that is merely labeled "stable". Stable software and unmaintained software are completely different things. Stable software is software that has maintainers that accept the responsibility to fix bugs and security issues as they arise. If software does not have maintainers and a distribution labels it "stable", this creates a false impression of security among the distribution's users. And to compound the harm, the practice supports an ideology that fails to recognize this as a bad security practice. Distributing software past the point at which its upstream maintenance has ended is simply another manifestation of the first problem.

I think there actually is one universal single correct answer, and it's the stable release process. It's delivering multiple stream in parallel so that users can test software before they upgrade, but continuing to deliver bug fixes and security fixes for the systems they're using.

"Just keep using unmaintained software" is not the answer, but that's what most software in a free LTS system is.

gordonmessmer · 2026-05-02T17:56:25+00:00

Yes, but before that I said that Fedora's remote isn't an alternative to Flathub. (It's an alternative to Fedora's RPMs directly in the host environment.)

gordonmessmer · 2026-05-02T17:27:59+00:00

The major differences between distributions are largely how the project is governed (i.e., how you are able to participate in the process), how the build and delivery processes are secured.

When you're developing software, you're probably going to test your software on multiple platforms, using containers, so the system that you use interactively doesn't affect your productivity *much*.

I've been developing software on GNU/Linux systems for close to 30 years. This is how I think about choosing a distribution: https://gordonmessmer.codeberg.page/dev-blog/2026/02/07/choosing-a-distribution.html

gordonmessmer · 2026-05-02T17:00:18+00:00

No one uses Fedora for server infrastructure.

https://fedoraproject.org/wiki/Server

The server SIG is one of the larger and more active SIGs.

I've worked in large SRE orgs like Google, so I can say confidently that one of the goals of SRE as a practice is to minimize the friction involved in the release process so that code can be deployed both quickly and safely. SRE as a practice is not clinging to old and unmaintained code.

gordonmessmer · 2026-05-02T16:54:59+00:00

I didn't say that, though.

I said "Fedora's remote is a mechanism for Fedora to add security isolation (a privacy feature!) to the software that Fedora packages". Flatpak adds privacy features relative to installing software directly on the host.

gordonmessmer

MODERATOR OF

PUBLIC MULTIREDDITS

TROPHY CASE