Objective Review: Immutable variants are the majority of Fedora Linux in use

Project Discussion
, , , ,
1

We’re working on Fedora Strategy 2028 — our next five-year plan. We are now reviewing those Objectives and their associated Impact. Read this guide for details on the current planning phase.

This Objective is part of the Theme “Fedora leads in Linux distribution development” and the Focus Area Technology Innovation & Leadership. For general discussion of this focus area, please see the topic Fedora Strategy 2028: Focus area review (Technology Innovation & Leadership).

Objective and Impact

Objective: Immutable variants are the majority of Fedora Linux in use
Impact: New way of doing things brings excitement and new energy.

There is a strong trend towards “immutable” or “image based” Linux systems. In fact, Linux Weekly News went so far as to predict that 2023 will be “the year of the immutable distribution”:

The classic Linux distribution follows in the footsteps of the Unix systems that came before; a suitably privileged user can change any aspect of the system at any time. For a few years now, though, we have seen movement away from that model toward a system that is, at least in part, immutable. Android is arguably the most prominent example of an immutable system; the Android core can only be changed by way of an update and reboot — and the previous version is still present in case the need arises.

Distributions like Fedora’s Silverblue have been exploring the immutable space as well. The upcoming SUSE Adaptable Linux Platform (ALP)[1] is based on an immutable core, as is the just-released, Ubuntu-based Vanilla OS system. It seems likely that others will follow, perhaps using the blueprint that was laid out at the 2022 Image-Based Linux Summit. By the end of the year, there may be a number of immutable alternatives available to play with — and to use for real work.

— from Welcome to 2023 [LWN.net]

Fedora has long been a leader here (Fedora Atomic Host was an F22 feature!), and Fedora CoreOS is currently our fourth most-popular variant (after Workstation. Cloud, and Server). Silverblue (and Kinoite and friends) have smaller numbers, but a definite outsized impact in terms of press and enthusiast excitement.

Meanwhile, though: our traditional system works quite well. This puts us in a “local maximum” situation — it’s hard to get to something new. (See also: the Innovator’s Dilemma.) With this Objective, the Fedora Council would like to explicitly commit to investing in the immutable approach, with an eye towards making it the default for most use cases.

Our goal now

For this Objective and related Impact, validate that:

  1. If the Impact is achieved, it’s reasonable to expect an increase in active Fedora contributors.
  2. Success in the Objective logically results in the intended Impact.
  3. That link is reasonably sufficient — that is, it represents everything needed to have the Impact.
  4. While there might be other ways to have similar Impact, the chosen Objective is the right one for Fedora right now.
  5. The wording is precise and clear. The Objective is concrete, and the Impact is (at least a little bit) inspirational. Together, they fit into this Focus Area.

Bonus. If you can improve the longer explanatory paragraphs at the top of this post, that’s helpful too!

As outlined in the roadmap, this post will close in one month.

  1. link is broken in the LWN article — see The SUSE ALP Dolomite Guide | What is ALP Dolomite? and https://documentation.suse.com/alp/bedrock/html/alp-bedrock/concept-alp.html ↩︎

10 Likes
2

The Suse link is broken.

They split it into 2 separate links:

Micro for running containers like FCOS or FIoT

and

Bedrock for Flatpacks like Silverblue and Kinoite

@mattdm

3

It is broken in the LWN article. I’ve added a footnote with a current link.

4

This impact is right, but there’s more to it. I see this as an existential issue for Linux distributions. The immutable model represents a big step forward in safety and reliability for users. If we don’t lead the trend here, we may find ourselves left behind.

7 Likes
5

What about these observations?

6

I think Colin has lost that battle. In any case, it does not matter what we call it. That doesn’t change the strategy.

2 Likes
7

I agree. I think the popularity of the Steam Deck has turned a spotlight onto immutable Linux distributions. Also along the lines of what @mattdm said about Android, I (like to) think of Kinoite as a great choice for something like the PinePhone and wanted to get one just to give it a try.

2 Likes
8

I’m still skeptical about us being successful on mobile, because it’s such a hard market, but I’d love to be wrong. This also ties into Objective Review: Fedora Linux is available pre-installed on more systems from more vendors — it is possible an ostree-based Fedora Mobile Edition could help convince Pine or some other hardware company to ship with our OS.

3 Likes
9

I don’t think I can say “anti-hysteresis” with a straight face in a marketing context. I get what @walters is going for, but it needs to be something that explains itself. And… it’s not particularly catchy. (Another reason I’d like to bring back the Atomic brand!)

4 Likes
10

I wasn’t suggesting Fedora go laser focus on mobile; KDE and Gnome already have been working on being mobile friendly. What I was saying is that an immutable OS like Kinoite and Silverblue (would) make a great base for them.

2 Likes
11

I definitely agree — that’s why I went to “innovator’s dilemma” when describing this. Suggestions for an addition to the Impact text?

1 Like
12

I love that is the way we are going to follow, but I have a question that I’m sure I’m not the only one that have it. The idea is, as I understand it, that the core system is immutable and surrounding apps should be flatpaks, does this mean that Desktop Environments should be treated as core? I haven’t tried yet but what happen when a new DE is installed over a rpm-ostree core? How this will work on spins?

Maybe I’m wrong with the following statement but more spins are still based on X11 than on Wayland, so is the display server be part of the core?

Sorry if this question is out of scope or a crazy thought but I’m part of the i3 spin SIG and I would like to know how this will work for us, maybe our fate is to die and follow Sway that already have experience with Wayland

13

Yes. That’s how the existing rpm-ostree variants (Silverblue, Kinoite, etc) work. This changes the mechanism for delivery, but not how we deliver it. In other words, variants that use a different DE or display protocol will keep doing that if they want to.

1 Like
14

I’m a strong advocate for the use of Silverblue. Still, because Fedora is a community project, I think the end users should ultimately decide which Fedora Linux version is popular and which is not, rather than a small team of core devs*. From my understanding Silverblue is still unofficial and described as a preview of the future of Fedora on the download page–is that correct? I’m not into marketing and things like that but I think to myself, make it “official”, make it the present and not the future, and you’ll notice a sudden increase in popularity. As for now people think it’s an experimental distribution which shouldn’t be used in production or at least the web page is not very clear about the status of Silverblue.

*Of course, I’m not a Fedora developer. I’m just a user. I think my sentence was a little bit ambiguous.

15

Theoretically, one should be able to swap between them on an installed system. However, this does make it harder to have multiple desktop environments on the same machine. That might end up being a niche case for which a “traditional” rpm-based system is just better. Or, it may be in the future that we can actually deliver the desktop environment itself as a separate layer.

16

Well… we actually can’t do otherwise. But, we can decide where we want to direct work and resources. (And if that isn’t leading to the intended impact … we need to be able to see that in our metrics and adjust.)

That’s basically right, I think.

17

It’s fairly simple to rebase from Silverblue to Kinoite and pin each of them so that you can swap between them with a restart.

I don’t think that the rebase allows you to conserve on the file space if both of the commits have overlapping packages, but that’s an ostree detail that is answerable by anyone on one of the immutable host teams.

1 Like
18

Disclaimer: not an ostree developer per se, but I’ve worked on many of the ostree-based projects in Fedora/Red Hat

That’s one of the core features of ostree: a content-addressed-object store.

If you were to inspect the HEAD ostree commit on both fedora:fedora/37/x86_64/silverblue and fedora:fedora/37/x86_64/kinoite, you’ll find that both of them include the kernel-6.2.7-200.fc37.x86_64 package.

However, if you are already running the HEAD commit of either branch and you decide to rebase to the other branch, the rpm-ostree client is going to recognize that you already have the content for the kernel package on disk and won’t bother to fetch it from the remote. This applies for any of the RPMs that are shared between both branches.

(You can experiment for yourself with this script that I spent far too much time on for this example…)

On the topic of the Objective/Impact, I think the wording is sufficient for a something as broad and future-looking as a five-year plan. :smile:

2 Likes
19

Note that with (rpm-)ostree, /etc/ is stored per deployment (i.e. per version installed on a system).

So if you make a change to a config in /etc/ for your Silverblue deployment and then go back to your pined Kinoite deployment, then that change is “lost”.

Overall, I think that each spin should focus on a single desktop. If folks want multiple desktops installed at the same time, they should either use package layering or we could build an “all in” image that has all desktops and you can choose the one you like (but it will be big).

1 Like
20

[note: this comment is somewhat similar to the two other ones I just posted, but the topic matters to all:

Immutable variants present a major shift and some of them already work somewhat different wrt to how they are released (e.g. FCOS and its next, testing, and stable channels). Is our release model with it’s roots in the 90s a still a good fit here? Should maybe more of our immutable variants switch to the FCOS model and Fedora itself adjust its release model somewhat to better align everything?

1 Like