Welcome to the Silverblue SIG thread! This thread wraps the SIG meeting on Monday 19th June at 1400UTC: before the meeting it captures discussion on specific topics, and after the meeting it hosts further discussion. This is designed to ensure that the sync meeting can be used effectively for sync discussion, but ensures that anyone that can’t attend can still participate in the SIG.
The meeting will follow a simple agenda, with topics proposed in this thread and given priority based on the amount of they get. Please propose a topic in this thread directly, and use the Reply button to discuss a specific topic. Only non-reply messages with s will be counted, and no other react emoji will be counted. Time will be managed in an attempt to get through all topics, but where necessary the lowest 'd topics may be cut.
Please note the issue tracker! The best place to raise bugs and enhancement requests are in the tracker, and attaching an issue to your topic is a great thing to do however, it is not mandatory.
When the meeting is over minutes will be placed in this thread for further discussion, and a new topic will be created a week after the meeting has taken place.
I reflected on the discussion in this thread (and other places) around the logo redesign. Personally, while I think it would be worthwhile to have a more holistic reconsideration of how we present and “sell” Silverblue, in the short term I think it makes sense to “update” the Silverblue logo to fit in with the rest of the Fedora Project aesthetic.
@jimmac designed an updated logo, presented below. We could ask the design team to sign this off and then raise some PRs to update the site as well as any other places the old logo is present (installation screen?).
Please react with if you think this should be discussed more.
Please react with if you think we should just go ahead with the updated design.
We should also consider how much support this should have, given that it’s a pretty minor change.
I will be honest, I’m completely stumped on how to move forward with this. Ticket here. @siosm suggested having the Respins SIG create an ISO but the response in the channel was:
if you can get it built i am willing to put it up with my updated isos
so how do you know its building now
i have no idea how to build silverblue images
I don’t know how to move forward with this, which is frustrating because I don’t want people on ARM devices to feel like they’re being ignored. Silverblue works on ARM, it was just a weird bug that stopped us building it in time for release.
Can anyone help? Maybe an older hand on the project?
Based on discussion last time I wanted to put forward a set of “principles” for Silverblue - a “Prime Directive”[1], if you will. This would serve to guide decision-making around the project going forward. Here’s my starter for ten:
Silverblue is an exact copy of Fedora Workstation, with the following differences:
We use rpm-ostree instead of dnf to install and manage packages
We use Fedora Flatpaks wherever stable versions are available
Silverblue acts as a constant alternative timeline for Fedora Workstation, representing a working example of how Fedora Workstation would perform as an immutable OS, and enabling early adopters to provide feedback and develop their workflows on top of.
Note that I used the word “available” instead of “ready”, for Flatpaks - this implies that we should move over to Flatpaks before they reach feature parity with Workstation, and has implications e.g. for Firefox (which is currently included in the base image). Currently we have a more complete approach to moving to a Firefox flatpak - discussed in this ticket - but I think the strength of feeling in the community is that we should move earlier (even though this breaks some things that are expected in Workstation), and this prime directive gives a sound basis for making this decision (if we were to adopt it).
I wouldn’t consider this something we’re ready to decide on, and I don’t have strong feelings personally on how this plays out, but I do think that a “Prime Directive” would give everyone clarity on decision-making around the variant.
I know, I used a Star Trek reference. I know nothing about Star Trek. Please don’t ask me anything about Star Trek ↩︎
I think there always has to be a balance between the vision we have for Silverblue , and keeping things usable for our users. Switching Firefox over to a Flaptak when there are still issues won’t get known issues resolved any faster.
We can review:
What are the issues that the Firefox Flatpak has
What work is being done to address those issues and on what timescale
and discuss when the result is “close enough”. I definitely don’t agree with the “prime directive” if it forbids us from being pragmatic for something as key as the brower.
Let’s make sure that if we decide to go for a new logo, both the legal and design teams are involved in the discussion before we do the update on the website.
Sure. I think this really comes down to a definition of “pragmatic”, though - right? To many people the whole idea of an immutable base is not pragmatic similarly, overriding the base image to remove Firefox, probably one of the most common overrides, isn’t very pragmatic.
The reason I’ve added this is because it’s a pretty common “complaint” about Silverblue (and the most common piece of advice I see is to install the Firefox Flathub Flatpak because it “just works”). Personally I don’t really like that it’s there, but it doesn’t bug me (I use Chrome) - but for many users having “two Firefoxes” is pretty frustrating.
To move away from the specifics of Firefox: it’s been frustrating for me, as a user of Silverblue, to try and understand the decision-making behind why things are how they are. E.g. some packages are in Workstation but not Silverblue, some packages are Flatpaks and others are in the base image. I think that if we want more people to move from “users” to “contributers” of Silverblue, we need to set out some table stakes - whatever they are - and then apply them consistently. Otherwise we’re sort-of stuck trying to perform digital archaeology.
The “prime directive” is an attempt to open that up, more than it is a question about any single package. It’s just about creating a consistent system of rules that people can build on in the absence of the original maintainers.
I just had a friend that I encouraged to try Silverblue (loves it, by the way, and isn’t a Linux user otherwise) realise that they were stuck on Fedora 37, and asked me why rpm-ostree upgrade wasn’t… well, upgrading. I explained how it worked and pointed out how to rebase (which was unintuitive but can make sense), which fixed the issue.
This got me thinking again about CoreOS running a constant stable tree instead of a branch per release (CoreOS still respects Fedora releases, they just automatically upgrade users two weeks after release), and how much this would improve the Silverblue experience.
I know there’s a ticket tracking possibly doing this (I don’t have it to hand) - but I just wanted to raise that this seems like a bit of a usability slam dunk
That should work, but it’s not efficient layer-wise and would bring things in Silverblue that we don’t have right now (Ignition, Afterburn, coreos-installer, etc.).
What we need is a common “base image” that is the common subset of all the rpm-ostree variants.
Is CoreOS currently using OCI images? If so, it seems like this would be a fairly easy change?
I’ll be honest, I think making a slightly “fatter” Silverblue image in the short term is a good trade-off for bringing the CoreOS and Silverblue images together.
There is a more philosophical question of whether Silverblue should become “closer” to Fedora Workstation/Server, or “closer” to CoreOS - which have very different infrastructure, processes, and release cycles (although of course CoreOS is derived from Fedora). Making Silverblue “CoreOS Workstation” would be easier if Silverblue adopted the CoreOS ways and means.
they get. Please propose a topic in this thread directly, and use the Reply button to discuss a specific topic. Only non-reply messages with 
however, it is not mandatory.
if you think we should just go ahead with the updated design.
similarly, overriding the base image to remove Firefox, probably one of the most common overrides, isn’t very pragmatic.