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

Project Discussion
, , , ,
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.

1 Like
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!)

1 Like
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?

21

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.

22

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:

2 Likes
23

I would applaud this as an objective for the next five years - Silverblue is a great workstation OS today, with rpm-ostree enabling people to “get their work done” (by installing RPMs where necessary) while the Flatpak ecosystem and Developer toolchains catch up with the potential of an immutable OS. It has been transformational for me personally, and I recommend it to anyone looking for a low-tinker, high-reliability Linux desktop.

If this is to be pursued then the structure and position of Silverblue needs a re-think. The KDE and Sway spins of Silverblue have better websites than Silverblue itself, for example, and it’s a pity that Silverblue has been downgraded from having an equally-sized place with other editions on the website to a text mention in the footer. Externally Silverblue has an image of being somewhat “abandoned”, with the momentum existing externally (Ublue, I note, got some great ZDNet coverage which raved about underlying Silverblue features but doesn’t mention the OS once*). A re-design of the website has been discussed, fwiw, but it seems that this has languished (while other project sites have moved forward).

There are other examples, e.g. Fedora Flatpaks not being kept up to date (I don’t know if this specific issue is still recurring on new releases). In this issue I offered to help with the Flatpaks and was referred to the package maintainers documentation - but this is entirely about RPMs (not Flatpaks), and honestly I just started questioning the value of the Fedora Flatpaks in the first place (I’m now just using Flathub directly).

In my view, this is because Silverblue (and, possibly separately, Flatpaks) doesn’t really have a working group - or, at least, not one I could track down - and so it’s very hard to contribute. As an example, someone suggested on the Matrix channel yesterday that anyone could contribute a new website, which I could do (many people could do) but I don’t want to “waste” my time crafting a contribution without reasonably knowing that it would be accepted (who would even accept it?). I have also started discussions around what packages to ship with Silverblue, and when/whether to use the Firefox Flatpak - both have had some discussion and feedback (and might be bad ideas) but have otherwise sort-of languished, and this feels like where Silverblue is on any decision-making or direction (which is my perception, as someone that really likes Silverblue and wants to help, rather than necessarily a fair representation of what is going on internally).

I think there also needs to be a re-think on the messaging around rpm-ostree. This is the “killer app” that turns immutable desktops from “a bit of an experiment” to “working, today, for most use-cases” - put simply, you can basically treat Silverblue like a Workstation installation, install most** RPMs you’re already using, and immediately benefit from the increased reliability and stability of an immutable desktop. Of course, we should encourage users to try the Flatpaks (and Toolbx) first - but rpm-ostree along with the vast Fedora RPM ecosystem is a lovely, pillowy backup that you can fall back to if you just need to get something done. But this practice isn’t actually championed (indeed, I most often see it being discouraged) which leads to new users deploying dirty hacks (e.g. installing in Toolbx, then deploying many brittle wires back into the host - .desktop files, etc) to avoid using one of the key USPs of the OS! rpm-ostree is the path to Silverblue, it’s the key USP for Silverblue, and once you tell people they can bring most** of their Workstation setup to Silverblue they are usually much more up for the switch.

Anyway, I’ve tried to give some insight into what I see to be the obstacles to achieving this objective, without coming across too negative. @tpopela and @siosm (which, so far as I can tell, are Team Silverblue) have been really helpful on Matrix and on the issue tracker, and I’m grateful that they have kept the project going (seriously, I use this OS every day, and it’s been so transformational to my workflow I would really hate to go back to a mutable OS). I do think that if this objective is to be successful Silverblue needs distinct decision-making that builds on this, giving decisive direction to the edition, and giving contributors the confidence to invest their time (and if this exists, it needs externalising).

*note: this is not a criticism of the Ublue team. What they’re building on top of Silverblue is awesome, and the momentum they’ve built up is why they’re being awarded the mindshare.

**yes, not all RPMs work on Silverblue.

6 Likes
24

There is now a SIG for Flatpaks in Fedora with regular meetings.

Silverblue discussions most likely happen in the Workstation working group (not sure as I don’t attend those).

Kinoite discussions happen in the KDE SIG meetings.

2 Likes
25

This topic was automatically closed after 31 days. New replies are no longer allowed.