Changes/AtomicDesktops

Fedora Atomic Desktops

Summary

We will regroup all desktop, rpm-ostree based variants of Fedora under the Fedora Atomic Desktops name. Each individual variant (Silverblue, Kinoite, Sericea, Onyx) may keep their name as is. While this is a Change Request, it is not addressed at FESCo but at the Fedora Council as this is not a technical change but a marketing / policy one.

Owner

• Name/Email: Timothée Ravier (siosm@fedoraproject.org), Micah Abbott (miabbott@redhat.com), Fabio Alessandro Locati (fale@fedoraproject.org), Joshua Strobl (joshua@buddiesofbudgie.org)

Current status

• Targeted release: Fedora Linux 40
• Last updated: 2024-01-24
• Announced
• Discussion thread
• Fedora Council issue: #361
• Tracker bug: #2260161
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

The Fedora website currently uses the term "Immutable Desktops" to regroup all desktop, rpm-ostree based Fedora variants. The term "immutable" is confusing to users, has been the source of many confusion and does not accurately reflect the advantages of those variants.

Thus we want to regroup those variants under a "new" name. The advantage of the Atomic name is that it already was a brand in the past, and it’s both technically accurate, short, but non-descriptive and non-restrictive so that people would have pre-conceived ideas like with “immutable”. It is important to state that this change does not intend to revive Project Atomic which acted as an umbrella for Atomic Host, Silverblue, and container technologies. This change is merely borrowing the "Atomic" name as a way to better describe the rpm-ostree based desktop operating systems.

We've created the Fedora Atomic Desktops SIG to co-ordinate across-variants work. One of the long term goals of this SIG is to work on making those variants the default option in Fedora, thus removing the need for a distinct name.

We will not require existing variants (Silverblue, Kinoite, Sericea, Onyx) to be renamed, as those brands already have some traction and history. It will be up to the decision of the SIGs if they want to rename the existing variants as a result of this change. We will not rename the ostree refs or do any technical changes related to this change to avoid costly and mostly useless or invisible work.

New variants will use the Fedora <Desktop> Atomic name. For example, in the case of XFCE it would be: Fedora XFCE Atomic.

Note that both Fedora CoreOS and Fedora IoT will remain as is and will not be regrouped under this brand, which only focuses on desktops. Both CoreOS & IoT variants have a strong brand on their own and do not suffer from the immutable naming.

Feedback

A lot of other names have been suggested ("package mode", "image mode", "reprovisionable", "anti-hysteresis") but so far those are either "too technical", "too long" or "too ambiguous/imprecise".

Another suggested option was to rename all variants under the Silverblue name (Silverblue GNOME, Kinoite -> Silverblue KDE, etc.). This however creates too long names and would likely create confusion as user would expect all systems to share a Silverblue base, which is not the case.

References:

• https://blog.verbum.org/2020/08/22/immutable-%e2%86%92-reprovisionable-anti-hysteresis/
• https://theevilskeleton.gitlab.io/2023/08/29/misconceptions-about-immutable-distributions.html
• https://gitlab.com/fedora/websites-apps/fedora-websites/fedora-websites-3.0/-/issues/251
• https://fedoraproject.org/wiki/Changes/Silverblue
• https://discussion.fedoraproject.org/t/i-am-ok-with-fedora-atomic-brand-now/86235
• https://discussion.fedoraproject.org/t/creating-the-fedora-atomic-desktops-sig/90757
• https://fedoraproject.org/wiki/SIGs/AtomicDesktops

Benefit to Fedora

The main benefits are: less confusion for users / podcasters / reviewers, better branding / marketing.

Scope

• Proposal owners: Submit / review pull-requests to update the name on the Fedora Website
• Other developers: N/A
• Release engineering: N/A
• Policies and guidelines: N/A
• Trademark approval: #361
• Alignment with Community Initiatives: N/A

Upgrade/compatibility impact

No technical changes so not impact on users.

How To Test

Nothing to test beyond the website changes.

User Experience

This should not be noticeable by users from a technical perspective.

Dependencies

N/A

Contingency Plan

• Contingency mechanism: Everything stays as is.
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? No

Documentation

We'll try to update the documentation and figure out a way to share more of the content between those variants.

Release Notes

To be done.