Fedora immutable : Immutable Linux distributions and their development by the Fedora team.

What Are Immutable Linux Versions?

• Immutable Linux distributions are operating systems where the core system is read-only and cannot be modified directly by the user.
• Examples include Fedora Silverblue (GNOME-based) and Fedora Kinoite (KDE Plasma-based) ...
• The system is built from atomic images, similar to how mobile operating systems update.
• Applications and development tools run in containers instead of modifying the base system.

Main Characteristics and Functionality

• The base system is read-only, preventing accidental or harmful changes.
• Updates are atomic: the entire system updates as one unit and can be rolled back instantly.
• Applications are installed through Flatpak or container environments like Toolbox and Distrobox.
• System integrity is preserved because the OS image remains consistent across reboots.

Security Features

• The read-only system reduces the attack surface by preventing unauthorized modifications.
• Atomic updates ensure that incomplete or corrupted updates do not break the system.
• Containerized applications isolate software from the core system, improving security.
• Rollback capability allows users to revert to a previous working state after a failed update.

Hardware and Software Limitations

• Some proprietary drivers may require manual workarounds because the base system cannot be modified directly.
• Legacy hardware may not be fully supported due to the modern design of immutable systems.
• Traditional package managers like dnf or apt cannot install software into the base system.
• Advanced system customization is limited because configuration files are protected.

Advantages

• High stability due to the read-only system design.
• Fast and reliable updates with rollback support.
• Improved security through isolation and immutability.
• Ideal for developers using container-based workflows.
• Consistent system state across reboots and installations.

Disadvantages

• Less flexibility for users who want to modify system internals.
• Some software may not work if it requires direct system-level installation.
• Learning curve for users unfamiliar with Flatpak or container tools.
• Not ideal for niche hardware requiring custom drivers.

Immutable Fedora Linux Versions: Silverblue and Kinoite

What Are Immutable Linux Versions?

• Immutable Linux distributions are operating systems where the core system is read-only and cannot be modified directly by the user.
• Examples include Fedora Silverblue (GNOME-based) and Fedora Kinoite (KDE Plasma-based).
• The system is built from atomic images, similar to how mobile operating systems update.
• Applications and development tools run in containers instead of modifying the base system.

Main Characteristics and Functionality

• The base system is read-only, preventing accidental or harmful changes.
• Updates are atomic: the entire system updates as one unit and can be rolled back instantly.
• Applications are installed through Flatpak or container environments like Toolbox and Distrobox.
• System integrity is preserved because the OS image remains consistent across reboots.

Security Features

• The read-only system reduces the attack surface by preventing unauthorized modifications.
• Atomic updates ensure that incomplete or corrupted updates do not break the system.
• Containerized applications isolate software from the core system, improving security.
• Rollback capability allows users to revert to a previous working state after a failed update.

Hardware and Software Limitations

• Some proprietary drivers may require manual workarounds because the base system cannot be modified directly.
• Legacy hardware may not be fully supported due to the modern design of immutable systems.
• Traditional package managers like dnf or apt cannot install software into the base system.
• Advanced system customization is limited because configuration files are protected.

Advantages

• High stability due to the read-only system design.
• Fast and reliable updates with rollback support.
• Improved security through isolation and immutability.
• Ideal for developers using container-based workflows.
• Consistent system state across reboots and installations.

Disadvantages

• Less flexibility for users who want to modify system internals.
• Some software may not work if it requires direct system-level installation.
• Learning curve for users unfamiliar with Flatpak or container tools.
• Not ideal for niche hardware requiring custom drivers.

Why Fedora Atomic Desktop Versions Lag Behind Workstation

Fedora Atomic Desktops (immutable editions - 40) do not follow the same release pace as Fedora Workstation 44 – April 2026. While Workstation receives a new version every six months, the immutable editions often remain several versions behind. This happens because immutable systems require additional testing, image validation, and stability checks before release.

Main Reasons for Version Differences

• Immutable systems use rpm-ostree, which requires more complex testing than traditional package-based systems.
• Atomic updates and rollback functionality must be verified for every release.
• Desktop environments must be adapted to work correctly in a read-only system.
• The Fedora Atomic team is smaller and focuses on stability over rapid version progression.
• New immutable editions (Onyx, Aurora, Sericea) increased development workload.

Current Immutable Editions

• Fedora Silverblue (immutable, GNOME)
• Fedora Kinoite (immutable, KDE Plasma)
• Fedora Sericea (immutable, Sway)
• Fedora Onyx (immutable, Budgie)
• Fedora Aurora (immutable, LXQt)

Release Timeline for Immutable Editions

• Fedora releases occur twice per year: April and October.
• Workstation versions advance regularly (e.g., Fedora 44 in 2026).
• Immutable editions often remain at older versions (e.g., Silverblue 40) until stability is guaranteed.
• Development for immutable editions happens first in Rawhide, then moves to a stable branch.
• Version numbers for immutable editions may skip or delay compared to Workstation.

Development

• Atomic Rawhide (future Fedora 41 Atomic)
• Rawhide is the testing ground for all new immutable features.
• New images are built and validated before becoming a stable release.

How Development Works for Immutable Fedora

• All new changes are introduced in Rawhide, the rolling development branch.
• The system is built as an OSTree image instead of traditional packages.
• Each image must pass atomic update and rollback validation.
• Flatpak integration and container tools (Toolbox, Distrobox) must be tested for compatibility.
• Only after stability is confirmed, the immutable edition receives a new version number.

Why Immutable Editions Prioritize Stability

• Atomic systems must guarantee that updates never break the OS.
• Rollback must work flawlessly for every release.
• Desktop environments must behave correctly in a read-only environment.
• Consistency and reliability are more important than rapid version progression.

News : UEFI Secure Boot keys are expiring in June 2026.

UEFI Secure Boot keys, used to sign the first stage boot loader, are expiring in June 2026.

You can read more on the fedora magazine article.

News : Linux 7.2 kernel big changes without 486 and new Panther Lake changes.

The x86/cpu changes have been merged for the Linux 7.2 kernel.

In Linux 7.1 the Intel 486 CPU support was retired and began to see the code removed.

This pull request also includes Panther Lake R as the new version of Panther Lake.

See the real kernel progress on the git area.

The full list of x86/cpu changes for Linux 7.2 can be found on this pull from mingo@kernel.org to torvalds@linux-foundation.org.

Thank you. Good work!

News : F44 Election Results ...

I saw a few days ago that there was a vote, but I didn't vote. I didn't participate nor did I follow what the fedora team was working on. From past experiences I can say that it is a very refined distribution. I use it all the time. It should be emphasized that each Linux distribution has different characteristics and specifications. Good luck.

The F44 election cycle has concluded. Below are the results. We are posting the results early this year as we are currently on the eve of Flock to Fedora 2026 and the results were ready. Thank you to all candidates and voters, and congratulations to the newly elected members!

See the official website.

News : Fedora 45 wants PURL Metadata.

The Package-URL (PURL) standard privides a "standardized URL-based syntax that uniquely identifies software packages, independent of their ecosystem or distribution channel"

This Change aims at making it easier and more reliable to identify which packages contain code from what projects. This allows for more reliable identification of packages affected by security vulnerabilities. Additionally, this metadata might be interesting for generating SBOMs for content included in (container) images.

See this discussion at fedoraproject community.

News : The new RISC-V images of Fedora 44 .

Fedora-Server-Host-Generic: This image uses the standard 6.19 kernel, 6.19.8-200.0.riscv64.fc43.riscv64. This kernel is very close to upstream, and will work on Vision Five 2, Orange Pi RV, Milk-V Mars, and probably other boards.

Fedora-Server-Host-Omni: New in Fedora 44! This image uses the Fedora “Omni” kernel, 7.0.11-200.0.riscv64.omni.fc44.riscv64, which aims to work on a wider range of RISC-V boards. Some patches in this kernel are still under review upstream. For details on the list of boards the Omni kernel

The RISC-V images of Fedora 44 are now available for container, server, and cloud variants. The Fedora 44 RISC-V material is considered non-official and community-contributed alternate images currently with Fedora Linux.

The Fedora 44 Server images for RISC-V use a Linux 6.19 based kernel close to upstream and have been tested on the Vision Five 2, Orange Pi RV, and Milk-V Mars.

See the discussion on fedoraproject.org.

News : HandBrake 1.11.2 added WebM MIME type to the list of the supported formats.

HandBrake 1.11.2 has been released with WebM MIME type to the list of supported formats on Linux systems, improve the Core Audio AAC encoder 7.1 channel layout, improve handling of unsupported presets on macOS and Windows systems, and improve queue low space pause behaviour on Windows systems.

See the GitHub project.

News : Release v0.15.1 for Black Box .

Black Box is a native terminal emulator for GNOME that offers superb theming options.

With Black Box you can:

• Set colors schemes and integrate them with the rest of the window
• Customize font and size
• Customize keyboard shortcuts
• Render Sixel escape sequences
• Fully hide the window headerbar
• Quickly open links and files by ctrl+clicking file paths and URLs
• Easily paste file paths by dragging them into the window

See the official gitlab repo project.

Fedora 44 : the Zert plugin manager.

Zert is a pure-Zsh plugin manager built around a simple idea: your plugins should be declared directly in your .zshrc, pinned to exact commits, and reproducible on any machine just like npm does for Node projects.

This project can be found on this GitHub repo.

Let's see some commands:

zert zert                           # zert manages itself
zert use ohmyzsh                     # enable Oh-My-Zsh compatibility
zert ohmyzsh lib/clipboard           # OMZ library
zert use prezto                      # enable Prezto compatibility
zert prezto modules/utility          # Prezto module
zert zsh-users/zsh-autosuggestions   # GitHub shorthand
zert https://github.com/user/repo    # full URL
zert user/repo --branch dev          # track a branch
zert /home/me/my-plugin              # local plugin

zert user/plugin --pin abc123        # pin to commit
zert user/plugin --branch dev         # track branch
zert user/plugin --no-alias           # skip aliases
zert user/plugin --no-completion      # skip completions
zert user/plugin --only-completion    # completions only

zert list      # show installed plugins
zert update    # update all plugins
zert prune     # remove unused plugins

Fedora 44 : testing Django 6.0.4 .

Today I used Fedora 44 beta 12 server on VirtualBox, and I wanted to test how Python works with Django on this Linux distribution. In the Fedora distribution, I have Python version 3.14.3 and Django version 6.0.4. I created a basic project with multiple pages, CSS, JavaScript, and an admin interface. It seems that Django is functional, and the result is very good for a basic project.:

Fedora 44 : Fedora 44 Server with budgie ...

The old laptop on which I was running Fedora broke down. That didn't stop me from testing Fedora Server version 44 beta 12 with the Budgie environment in VirtualBox, and I also made a beginner tutorial video that I share on my YouTube channel - Catalin George Festila.

See this video:

News : Fedora Budgie Spin intro

Today, I saw this good environment and will test with Fedora server on virtualbox because I don't have hardware to test it.

You can see more about this with the Fedora Spin.

The Fedora Budgie Spin showcases the Budgie Desktop, a feature-rich, modern desktop designed to keep out the way of the user. Budgie Desktop uses common desktop design metaphors while offering users sophisticated functionality such as its Raven widget and notification center, and an approachable method to personalization.

Fedora 38: First official release of Fedora Budgie Spin was on 2023.

Fedora 39–44: Continuous updates, better Wayland support, and alignment with upstream Budgie.

Fedora 44 Beta: Ships with Budgie 10.10 and improved integration.

The basic commands for install this fedora package with gdm.

$sudo dnf5 install @budgie-desktop-environment
$sudo dnf5 install budgie-desktop
$sudo dnf5 install @base-x gdm
$sudo systemctl set-default graphical.target
$sudo systemctl enable gdm --now
$sudo reboot

NOTE: If these commands not work then you need to make one update with all packages.

News : the new Linux 7.0 kernel series.

Good news for linux users, see the official website:

From Linus Torvalds Date Sun, 22 Feb 2026 14:40:09 -0800 Subject Linux 7.0-rc1 You all know the drill by now: two weeks have passed, and the kernel merge window is closed. We have a new major number purely because I'm easily confused and not good with big numbers. We haven't done releases based on features (or on "stable vs unstable") for a long long time now. So that new major number does *not* mean that we have some big new exciting feature, or that we're somehow leaving old interfaces behind. It's the usual "solid progress" marker, nothing more. With our normal release schedule of 5-6 releases per year and my antipathy to big version numbers, you should basically expect us to bump the major number roughly every 3.5 years. And yeah, I don't have a solid plan for when the major number itself gets big. But doing the math - by that time, I expect that we'll have somebody more competent in charge who isn't afraid of numbers past the teens. So I'm not going to worry about it. Anyway - despit eany lingering ".0 release" worries that people might have due to experiences with other projects, this was one of those fairly smooth merge window for me. I define those as the merge windows where I don't have to bisect boot failures on any of my machines. Admittedly this time around that was because I caught one failure case early before I *actually* booted into it, but hey, that still technically counts as "smooth" to me. But your milage may vary. Which is why you should now all drop everything, run to your computers, and test-build and test-boot a shiny new kernel. The fact that it all works for *me* is good, but let's make sure it works for others too, ok? Just kidding. A leisurely stroll after you've finished chewing is fine. ...