Software management when image-based Fedora becomes default (Strategy 2028)

Ask Fedora
1

One of the goals in Fedora’s 2028 roadmap is to make image-based editions the default offering. This goal raises some questions about the intended user experience when dnf in its current form is presumably no longer the primary entry point for software management.

A wealth of Linux software is still distributed primarily in the form of DEBs and RPMs. One reason is that apt and dnf remain the most pervasive and convenient tools for managing software on Linux systems. Even if Fedora advertises image-based editions by default, the vast majority of Linux users will still be using systems where the package manager remains the main software management tool. Besides the usual Linux distributions running on bare-metal, package-based Linux distributions are also getting a lot of exposure on popular commercial platforms:

  • WSL (mainly Ubuntu)
  • ChromeOS Crostini (Debian)
  • Cloud VMs (e.g. Amazon Linux based on Fedora)
  • Android Terminal (Debian)

Another reason is that unlike Flatpak, these are fully general purpose software delivery mechanisms, capable of shipping arbitrary code from kernel modules to web servers to web browsers. While Flatpak is gaining some traction, it is simply not suitable for certain software. Here are some of the tools I use regularly:

  • Docker
  • Kubectl
  • VSCode/Intellij
  • MySQL shell
  • VPN software like Tailscale
  • Emacs/vim
  • Command line shells besides the system default shell (note – shells, not merely terminal emulators)

Most of these would not work properly using Flatpak. This is no fault of either Flatpak or the applications since Flatpak was designed primarily for unprivileged, graphical desktop applications, and some software are simply designed to run directly on the bare-metal host. For all of these programs, the official installation instructions for Fedora users consist of either 1) directly downloading a pre-compiled binary or 2) adding the project’s RPM repo and installing the official RPM package using dnf.

From the user’s point of view, the package manager also provides a convenient one-stop shop for all kinds of software. It’s no accident that both Windows and MacOS have grown their own package ecosystems; the ability to run apt-get install <X> or brew install <X> and be immediately ready to roll is compelling. In contrast, Silverblue users are faced with a choice of at least three different software management tools, each with its own gotchas – flatpak, dnf-in-toolbox, rpm-ostree layering. The average user would not appreciate having to navigate a decision tree for which technology to use. Think for example of someone who just switched from MacOS – they’re used to either 1) dropping a self-contained app bundle into /Applications for graphical apps, or 2) running brew install <X> for CLI tools. Why would they want to choose between three or four different software installation mechanisms on image-based Fedora when they could just apt-get install everything on Ubuntu?

How are Fedora users intended to manage their software come 2028 when Fedora starts nudging its install base toward image-based editions? Will users need to be reeducated in new ways of doing things? Would dnf still be present on image-based Fedora and magically do the right thing as if the user were on Fedora Workstation? Or would people who currently use dnf be counseled to live in a Fedora Workstation toolbox, which has its own limitations?

If dnf is relegated from a user-facing package manager to a tool for Fedora maintainers to build the system image, do installation instructions for third-party software need to be rewritten? For example, the Kubectl website publishes instructions using apt-get for Debian based distributions and using dnf for RPM based distributions. Will they need a separate section for Fedora users come 2028?

6 Likes
2

I did not know of the “strategy”.
What is “the average user”?
If it is me, I don’t need any “image-based-distribution” and I don’t like to be forced to do things, that was the reason I quit Microsoft so it seems it would be the reason I will quit Fedora.

To answer your question, I think the idea is “the average user” will “use” Gnome Software to install flatpaks and that’s all. Who ever needs other ways is not “average”.

3 Likes
3

I wonder if this is still a reachable goal for 2028.

There are quite a few milestones to be reached before atomic desktops would become the default Fedora offering (such as switching from OSTree to bootc etc). I’ve seen discussions about intentions to make dnf work with bootc images, as well as to provide the user with functionality to easily “convert” an atomic desktop to a traditional one and vice-versa, before having image-based variants become the default.

Besides, traditional desktop offerings will still be available. And RPM packaging won’t go away, it will still be the basis for Fedora images too.

Additionally, you are obviously not speaking from the POV of the average user but rather of a developer. I can even imagine the current Fedora Workstation edition be rebranded to Fedora Developer edition or something similar.

So I wouldn’t worry too much about loosing the ability to install RPM packages.

Actually, I find the experience of installing software on MacOS to be closer to Fedora atomic desktops that to Fedora traditional desktops (Workstation, KDE edition etc). Installing apps on MacOS from the App Store or as dmg image is IMO closer to installing Flatpaks than RPMs on Fedora. And installing packages with brew on MacOS could be compared to rpm-ostree install. It should be noted, though, that Homebrew is not the average user’s tool, it’s not delivered by default on MacOS and many MacOS users don’t know what Homebrew is. Finally, Toolbx is not a tool specific to atomic desktops, being available on Fedora Workstation too, and could be compared with the available container tooling on MacOS.

4

Fedora has long had a developer slant. To see Fedora’s intended core user base, look at the Fedora project’s mission statement:

“Fedora Workstation envisions an open world where developers and creators can easily make new and exciting things with accessible digital platforms.”

5

True, hence my remark above. On the other hand, I consider developers more advanced users, who (with some research if needed) understand the concepts of ostree, rpm-ostree, bootc, rpm, dnf, flatpak, etc, and many of which embrace the container-based workflows.

Maybe someone closer to the project will come around to address your concerns, but from what I’ve seen, the intention is to somehow integrate dnf with image-based offerings too.

6

You mean Fedora is a thing developers make for themselves?
Now that is something with some interesting consequences that aren’t about software.

Unfortunately the more I learn, the less Fedora looks like it is made for me.

1 Like
7

All Fedora image mode variants will eventually be transitioned to bootable containers. The various Fedora image mode variants are at different stages of this transition. AFIK, the maintainers of these variants and those of the bootc project (which are mostly the same developers) are still discussing the approaches and tools that would be used for local layering.

Since the topic is extensive and if there is interest, I can provide links to some of the discussions, approaches and tools I know about.

1 Like
8

Yes please.

9

why would any of these things you list not work properly when distributed as flatpaks?

flatpak can export executables and even systemd service files…its just not commonly done. In fact I had a conversation at GUADEC with people specifically about their desire to package a systemd service that is ebpf based deamon as a flatpak and exporting the systemd unit. That’s basically equivalent to loading up application specific kernel modules. All you have to do is get systemd to agree to look for service units in the location that flatpak can export symlinks to and that’s just configuration tweaking.

11

Very well written question. I don’t know the answer, but as someone who’s been using Silverblue for a few years (and now Silverblue++ ie. Bazzite/Bluefin so that my drivers and codecs are pre-installed), the answer is Homebrew for CLI apps + Flathub for GUI apps.

Anecdotal, and this won’t work for Tailscale and Docker (which Bazzite/Bluefin include for you on the image bc they’re tricky), but for your Kube link above on MacOS you can install Kube with brew.

Thanks for bringing this up!

12

Hi

Fedora’s user base will desert them when they don’t have the money to either buy a 256 CPU currently around 16K, or want to run their installation of Fedora in a data centre.

They forget they are not Microsoft with a significant market share they can have a take it or leave it attitude, I have left Redhat in the past and I can do it again, they must never forget the Linux community have a choice, something the users in the Microsoft world don’t have.

I think Redhat have missed a trick, with Microsoft telling everybody to throw their old equipment away and buy some new to run Windows 11, the ability to run Fedora on lower spec hardware could have given them a significant market share, but no one is going to jump when they will be unable to continue to run an operating system 3 years from now, and will have to buy new hardware anyway; may as well bit the bullet now and buy new hardware and continue with what we already know.

1 Like
13

Well, people around here would probably say two things, first Fedora aims to the latest technologies and that does not allow to support legacy hardware and software indefinitely, second Fedora basically works as beta testing for Redhat and Redhat doesn’t sell “consumer” or “home” products/services, it goes for the corporate market.

The “linux community” have a choice in theory.
In practical terms, “linux” is driven by Canonical, RedHat, Suse with their ecosystem and all of them aim for the corporate market.
So my guess is we will see more and more choices that make sense only there.

14

Fedora also tries to make a space for OEM manufacturers as community partners with its Fedora Ready program. So just because Red Hat doesn’t have a consumer product oriented business, doesn’t mean Fedora does have stakeholders in the the consumer device space.

1 Like
16

I don’t understand where this comment is coming from.

I have a T520 Lenovo laptop with a BIOS that reports a 2011 timestamp that I have successfully intalled Fedora 42 SilverBlue on in the last week. I hauled it out of storage just so I could have another system to test with. Its the oldest system I have with a working ATA hardrive.

So I’m not understanding what you mean by requiring a 256 CPU. It feels like you are speaking in emotional hyperbole, and not something grounded in actual personal experience. But I would like to give you the benefit of the doubt.

I’m just a little confused. Whatever your concern seems to be, the fact that I can install Fedora 42 on a laptop from 2011 tha I havent used in years… feels like there is some measure of legacy hardware support. I don’t have anything older on hand right now.. but 14+ years is a pretty good run

17

I would add something to that.

A few years ago, I don’t remember exactly how, I gave a friendly family a desktop computer because they didn’t have another one that worked. The machine has ASUS P7P55-M MB, Intel Core i5-750 CPU, 16GB DDR3 RAM, Sapphire R9 270X 4GB GPU and Fedora Silverblue, which I installed when I gave it to them. In my opinion, this is a relatively good machine even by today’s standards. These people, including their then 6-8 year old child, had not heard of Fedora and Linux in general. So far, the machine has been working flawlessly, it is used daily for various school, office and multimedia tasks, people are grateful and happy and upgrade the system with each new release.

I have the same machine, but with 8GB RAM and a smaller VGA, which I use to test Fedora image based systems. I also have less powerful machines, albeit newer ones, that run Fedora Atomic Desktop systems without any concerns.

18

One word not on that statement is performance, which is my main interest any OS. I haven’t seen that mission statement until now since F22 :stuck_out_tongue:

My concern is with newer tech not necessarily performing faster, but it does seem to match the statement goals.

19

I guess the train of “performance” left the station decades ago, when it became clear hardware was cheaper than people. And of course rapid obsolescence keep the sales going. Here we are discussing of another topic IMO that is “the user case” or “what is Fedora for”.

20

To bring the discussion back on topic, besides the obvious use of Flatpak, here are some other software management approaches that can be used with bootable containers.

One of their most powerful features is that you can use any existing base bootc image and customize it to your needs (e.g., install additional packages, copy files from the host, run configuration scripts, etc.) in a container build.

You can build and switch to a bootc image locally without having to push it to a remote container registry.

In addition to installing software during the container build, there are also (still considered experimental) systemd system extensions.

https://extensions.fcos.fr/

Here’s an interesting concept regarding package layering that has emerged recently.

6 Likes
21

I am convinced that image based distros are the future. Every popular modern OS does it this way (e.g. Android, iOS) and it makes it easier to provide much stronger security guarantees.

The current state of desktop Linux security against offline and online attacks is terrible. I don’t want to blame anyone working on distros for this state. Many use their free time to contribute and I welcome anyone contributing.

Nevertheless there is a need for change to not further fall behind in this area. We need much better, cryptographically enforced integrity guarantees, a full chain of trust, and only letting integrity checked executables run. Non-integrity checked executables should only be allowed to run in a strict sandbox. That’s the base for actual security guarantees to build upon and it is much easier to do this image based. In 2025 we have the tooling needed for it and systemd provides them. UKIs and minimal, verity-protected, hermetic /usr partitions should be the norm, not the exception.

System extensions can be made with systemd-sysext. These can be merged via an overlayfs and still be Verity protected. There could be sysext stores for common use cases, like Flatcar provides. Another option are Portable Services, which can be sandboxed and Verity protected. Additionally users always have the option to build and sign images themselves. This will provide users the actual flexibility they need to modify and extend the OS without sacrificing integrity guarantees.

On top of that the actual user applications in the form of sandboxed Snaps, Flatpaks or similar. Hopefully these will get signed and integrity enforcement (for example via IMA or fs-verity) in the future, too. And be in a position to force all applications to only use portals in the future, so it can properly enforce sandboxing without known escapes, like applications using full /home access.

All of this can be separated into different partitions. IPE could be used to disallow execution from non-integrity protected partitions, for example disallow execution from the home partition.

I would recommend to read Poettering’s Fitting Everything Together which lays this out much better than I could in a few words.

5 Likes
22

See “Signed, Sealed, and Delivered”, with UKIs and composefs and:

See the link to systemd system extensions for Fedora image based systems that I provided above. See also:

2 Likes