It is broken in the LWN article. I’ve added a footnote with a current link.
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.
What about these observations?
I think Colin has lost that battle. In any case, it does not matter what we call it. That doesn’t change the strategy.
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.
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.
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!)
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.
I definitely agree — that’s why I went to “innovator’s dilemma” when describing this. Suggestions for an addition to the Impact text?
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
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.
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.
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.
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.
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.
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/kinoite, you’ll find that both of them include the
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.
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).
[note: this comment is somewhat similar to the two other ones I just posted, but the topic matters to all:
- Objective Review: We integrate programming language stack ecosystems - #3 by thl
- Objective Review: Fedora is a popular source for containers and Flatpaks - #22 by thl ]
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
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?
I think Guix is slightly ahead (timeline wise) as a transactional system, which is entirely declarative, supports rollbacks (environment too) and user level package management.
Silverblue is very stable in everyday use, I began using it in the beginning when it got started. Aside from the subtle paradigm shift, it was extremely usable. With caveat’s of course. The container based workflow it fosters has now become more second nature for me. While there is still the ability to tinker under the hood through the tools rpm-ostree and ostree provide. it is comforting and somewhat liberating from a user POV to be able to be able to merely “rollback” an untintended consequence of a recent change. I think it is pretty easy to install multiple DE’s and switch as you normally would, again with some caveat’s, otherwise why make Kionite, right?
Immutability is an appealing feature that is gaining a lot of attention this past couple of years. I think Nix OS broke ground here for all.
If you havent looked a Guix lately, or are unfamiliar with it, you should take a look. After all it is GNU Linux. The one thing it does not do is stick to the FSH, which can be problematic for some.
I think there are some ideas in use with Guix that may work well in Fedora. Suchs as supporting transactional user home environments.
I’ve started the discussion about that in Change build and release cadence · Issue #384 · fedora-silverblue/issue-tracker · GitHub. To be able to change the release model, we need work on CI and openQA testing that is not done yet. See:
- Consider moving pagure.io/workstation-ostree-config to GitHub or to Fedora's GitLab · Issue #334 · fedora-silverblue/issue-tracker · GitHub
- Tracker for ostree native container conversion · Issue #359 · fedora-silverblue/issue-tracker · GitHub
- In progress CI work in fedora / Fedora Atomic Desktops / ci-test · GitLab