Naming on os-tree based variants

I’m +1 for this. Although I’m a KDE user, I would consider my distro as Silverblue (in contrast to Fedora Workstation)

I’d consider Silverblue (Vanilla) as the Gnome one, and we also have brands, including Silverblue KDE, Silverblue XFCE, etc. We could also have Silverblue Scientific, if the current Fedora Scientific has a rpm-ostree based distro.

+1 Keep current Kinoite name for KDE

1 Like

I fully support reviving the Fedora Atomic brand as well, though I propose omitting “with” and following the mutable naming convention: “Fedora Atomic Workstation”, “Fedora Atomic KDE Plasma Desktop Edition” (or “Fedora Atomic KDE” for short), etc.

As for keeping the Silverblue brand to avoid complication, changing the name in any way (or keeping the name) will make this matter more complicated, because the names are already really complicated to begin with.

Personally, “Silverblue” is a really confusing name here, as it does not convey anything, especially to a newcomer, so I propose to deprecate this name entirely. I personally believe we should base the naming convention on the already existing mutable variants’ and focus on long term benefits: clarity and consistency, and focus less on short term downsides.

We could also explain in a Fedora Magazine article about the history of names with immutable variants and our motivation in changing names, so the community can have a proper understanding on the context.

1 Like

There are a lot of great comments here. One thing that I think is clear is that we will not make everyone happy. :grinning: But we can try to account for all the feedback as best we can.

To help gauge where this discussion is going, I want to take a totally statistically-insignificant flash poll about what people think. Add a vote and let us know why you voted the way you did below:

How should we refer to ostree-based variants?

  • Fedora Atomic family (Atomic Xfce, Atomic Sway, etc.)
  • Fedora Silverblue family (Silverblue GNOME, Silverblue Sway, etc.)
  • Some mix of the above options (describe in a reply)
  • None of the above options (describe in a reply)

0 voters

I think we may be putting the cart ahead of the horse here. We’re talking about names without coming to a consensus on what the brand should be. I’m still contemplating this idea, but I’ll try to get a blog post out in the next few days that explains what I mean.

1 Like

According to me, those suggestions don’t reflect the reality or make the name so long that it is basically unusable.

Silverblue is related to Workstation but different enough to need another name to distinguish it. Similarly, Kinoite is related to the KDE Spin but different enough to need another name.

Naming everything Silverblue is also misleading: Kinoite shares the base technologies with Silverblue but is its own thing, not constrained by Silverblue decisions and the user experience is much closer to the KDE Spin than to Silverblue which uses GNOME.

See also "Flavors" over "Solutions"? - #27 by bcotton - Fedora Discussion

Link to my previous attempt at reviving the atomic brand: Issue #361: Re-purpose the Fedora Atomic brand for unbranded rpm-ostree builds of Fedora - tickets -


This sounds nice because it is explicit, descriptive, but it does not work day to day as the names are way too long and thus they quickly get abbreviated, and then you’re back to a code name that has no meaning.

“Fedora Atomic Workstation” and “Fedora Atomic Host” were abbreviated as “FAW” & “FAH” and it’s really hard to figure out what this means when you don’t know it already. Similarly, “Fedora CoreOS” (which is already not that long) is already often abbreviated as “FCOS”. People say “Silverblue” instead of “Fedora Silverblue” and similarly for “Kinoite”.

When you have a clear name / brand (Silverblue, Kinoite), abbreviating it does not hurt as you can easily figure it out. Longer names don’t have that benefit.

1 Like

I agree to omit the “with”. This word makes the name too long and provides no information.

1 Like

I completely agree. It really sucks that no name is perfect, but with Fedora Atomic, we get the benefit of having a grouped name. I find it better to be inconvenienced by long singleton names than having no official grouped name. In my experience, people (including myself) often referred to Silverblue as “every OSTree variant” than just GNOME. I only speak for myself, but I don’t want to say “Fedora Silverblue/CoreOS/Kinoite” when I mention OSTree variants; presumably others would feel the same. Fedora Atomic is much easier to say and is much shorter in contrast, but you get the inconvenience of having long singleton names.

1 Like

When I speak about all rpm-ostree based variants I usually use either:

  • rpm-ostree based Fedora variants
  • ostree based Fedora variants
  • image based Fedora (variants)

Remember that we have Fedora IoT, Fedora CoreOS, Fedora Silverblue and Fedora Kinoite and each one of those is its own thing even though they share the Fedora base and rpm-ostree technology, podman, etc.

Should we have “Fedora Atomic variants” as an umbrella name? Then we’ll have “Fedora Atomic Desktops”. But that does not get us much compared to “Fedora Ostree Desktops” or “Image Based Fedora”.

Knowing the names of all the variants is useless for most users. They most likely only use one. What they care about is to be able to find the right one on the Fedora website and to find relevant help via a web search with a well known name.

1 Like

I love the idea of a grouped name, however, I’m against using the word Atomic. As I replied to Joseph, the word Atomic is used too widely. It’s not only about SEO. IMHO it’s easier to connect a more specific name to Fedora as a user

I do want to stress the value of Silverblue being a name that the community is already comfortable with and for which articles and videos have been made since 2019. Whether we chose Silverblue or Atomic, they are both arbitrary names in the end. At least Silverblue is what’s currently being used and is known.

If we’re talking about reducing the number of names to simplify the scheme, changing it to Atomic comes at the cost of basically reteaching the whole Linux community a name for the same product at no benefit because it already had a name. If we simplify so that every desktop just integrates the name of the DE, that will be a minor and more easily understandable change. So the new Sway spin would be called ‘Fedora Silverblue Sway’. If we change to ‘Fedora Atomic Sway’, we’ve reached the same scheme but with the added hurdle of reeducation.

Another point about the code names is the emotional component users may have. If you’re really into Silverblue, you’re using every day, and you like telling people about it, there’s a good chance you like the name too. It can be a bummer and almost frustrating to people who really like the spin to have the name swapped to something else. Even if we do decide to change the name, we want to be really careful with that because the name seems to be beloved by lots of people. I could be wrong, but I think Kinoite is in a similar boat.

I don’t think so personally, becuase IMO one of the biggest things about Tesla is that they are electric only - but we are not image-based/containerized only. At least not yet :smile:

Fedora is much closer to e.g. Ford which makes both gas and electric cars.

I love this car analogy because it applies in so many ways. For example: like cars, operating systems do not exist in a vacuum. They are part of, and require an ecosystem - not just fueling but maintenance/repair and other infrastructure like garages. Another very strong part of this analogy is around the need for similarity of user interfaces.

Just to reiterate my perspective in a different way: I like to think of my role as analogous to that of the people who are working on the Ford F-150 Lightning. The designers of that truck very deliberately did not make it look different from the gasoline powered ones. They intend it to be a Serious Truck used for Serious things.

Of course, another strong proponent of the “make it boring” model was Jon Masters when working on aarch64 (ARM) for Linux, and that’s arguably been successful today.

1 Like

Yeh, but I meant the Tesla comment more as… Tesla has no non ev variants. They’re all ev. There’s no version of Silverblue that isn’t ostree (“ev”), the fact is ostree is baked into its own brand.

Vs a Ford Mustang Mach-e… It’s a Ford Mustang but with a “mach e” label to indicate ev, but you can buy an ICE Mustang and that’s the norm. So a Ford Mustang is “Ford Mustang” and you assume ICE engine, whereas a “Ford Mustang Mach-E” is ev and you get that from the extra third label. You label the thing that isn’t the assumed norm. So you set up a hierarchy there, and also a family of cars under the same model name.

This is all both a technical/nomenclature problem as well as a branding one and I think it’s easy to mix them up. But the point was more, you can have a brand that has the technology choice baked into it, or have a brand thats more about what the thing does (a mustang / sports car) and the tech as to how it does it (ICE vs electric) is a moniker / label applied to the core model brand.

Having the tech baked into the brand means a proliferation of weird abstract names whereas having the tech as a label or moniker on top of some shared brand to have some coherece between deliverables that do the same thjng via diff tech means is a decision point… and we havent made a decision which we care about so we’re gotten here now. :grimacing:

Do we want to treat ostree as “not the norm” and call it out label it, and if a deliverable isnt labeled with an ostree moniker it’s assumed to be a non ostree OS? (Ford Mustang vs Ford Mustang Mach-E) Is that what we want? Or do we want the reverse… assume ostree unless we label it (Ford Mustang vs Ford Mustang ICE) ? Do we want to present them as equal options (please lets not) (Ford Mustang ICE vs Ford Mustang Mach-E.) Do you see how having an extra label for one sort of normalizes / expresses a hierarchy or preference in favor for the other one?


Too early and a separate discussion about where the future of Silverblue is going. But if it’s “the future of Fedora” as it is stated, consideration should be taken to think about if it’ll be desired for the name “Silverblue” to outlive “Workstation”.

To extend the analogy, Ford may be painting themselves in a corner by the Mach-E moniker. Because it’s clear that at some point ICE will no longer exist. At that point, do they only have Mach-E? Or will they have to reclaim the non-Mach-E name for EV?

1 Like

IMHO, if we decide for a “new” standard, it should apply to all deliverables, including the already “known ones” (such as Kinoite in your example), since it’s going to be way easier to explain the rename to the people that already know and understand the project rather than explaining the inconsistency to new people in the future.


1 Like

My understanding of Silverblue being the future is that it would eventually become Workstation, and at the point the Silverblue name would go away. But it would be a good thing because OSTree would be the default! And the same would go for all of the DE spins.

1 Like

Why is it too early?

When cars shift to mostly ev, they shift their branding. You simply shift from emphasizing ev / nextgen to emphasizing ice / legacy. So you drop mach-e, the transition will be “ford mustangs” == ev except for the ICE models which are called out as such “ford mustang ice”

it’s not difficult, it’s an easy pivot. They can restyle mach-e as a trim level if they find value in it as a sub-brand or drop it. They did it as a model under mustang - theyd not drop mustang easily but mach-e is three levels down without a long historical legacy. Auto makers do drop model names over lengths of time shorter than Fedora has been around at this point.

1 Like

There actually isn’t any reason why we have to apply rules in a consistent way. They can be applied in a limited fashion in a way that reinforces whatever hierachy or order we want to convey about the products.

We should not be asking “do you like X or Y naming scheme best?”

We should be asking things like “how do these different editions/deliverables relate / interact with each other? How would we like people to view them? What are our strengths? What confusion might arise between those that are in adjacent / overlapping spaces that we need to avoid? What are the problems with our existing naming scheme we would like to solve?”

Then once we’re all clear on that (i dont think we are) ’

what naming scheme will support those needs?

Does anybody have a good grip on the concerns above that could write up a summary / brief? Or is it really as of yet not fully understood / defined?


People would end up calling it Fedora Atomic overall, and that’s fine I believe.

Silverblue, Kinoite and Sericea don’t make sense in the long term IMO, and, while beautiful, they’re not descriptive and make the different ostree variants look more dissimilar than they actually are. Silverblue is already pretty opinionated, so I’d be against using it as a generic term. Atomic is much more descriptive, generic and neutral.

1 Like

Agreed. If we choose a name, it should apply retroactively to all the variants, new and existent