Fedora : testing basic example with python SELinux package.

Fedora : Fedora SilverBlue 44 and distrobox tool.

Distrobox on Fedora is a lightweight, rootless way to run any Linux distribution inside a tightly‑integrated container, powered by Podman. It’s more flexible than Fedora’s native Toolbox because it can pull any OCI image (Ubuntu, Arch, Debian, openSUSE, Alpine, etc.)

What Distrobox Does on Fedora

• Runs any distro inside your terminal using Podman or Docker.
• Integrates with the host: shared $HOME, USB devices, audio, GUI apps (X11/Wayland).
• No root needed — perfect for immutable Fedora variants like Silverblue/Kinoite.
• Exports apps from the container back to Fedora using distrobox-export.

Install Distrobox on Silverblue

rpm-ostree install distrobox
systemctl reboot

Create and enter a Gentoo container

distrobox create -i gentoo/stage3:latest -n gentoo
distrobox enter gentoo

Sync and update Gentoo

emerge --sync
emerge --ask --update --deep --newuse @world
...

Gentoo inside Distrobox is source‑based, this means:

Compiling packages happens inside the container

CPU and RAM usage will be high

Builds may take a long time (depending on your hardware)

Silverblue’s immutability does not affect Gentoo’s compilation.

Fedora : Fedora SilverBlue 44 on VirtualBox 7.2.10 - first commands to start .

Fedora Silverblue is an immutable desktop operating system built on top of rpm‑ostree. Instead of traditional package-based upgrades, Silverblue uses atomic deployments, making the system extremely stable, reliable, and easy to roll back. This blog-style guide shows you how to update your system, manage deployments, upgrade to new Fedora versions, and keep Flatpak applications current — all using simple terminal commands. Tested on VirtualBox.

Check your current system state

Before updating, it is useful to inspect your current deployment and any layered packages.

rpm-ostree status

Most apps in Silverblue come from Flatpak.

sudo su
flatpak update

Perform a standard system update

This updates your Silverblue installation to the latest available deployment for your current Fedora release.

sudo rpm-ostree upgrade
systemctl reboot

Clean up old deployments

Silverblue keeps multiple system deployments so you can roll back if needed. You can safely clean older ones to free space and reduce clutter.

rpm-ostree status
sudo rpm-ostree cleanup -p
sudo rpm-ostree cleanup -m

Roll back if something breaks

If an update causes issues, you can revert to the previous deployment quickly and safely.

rpm-ostree status
sudo rpm-ostree rollback
systemctl reboot

Rebase to a new Fedora Silverblue version

Major upgrades are done via rebase. Replace 41 with your target Fedora version. I used Fedora 44 and I keep that version.

rpm-ostree status
sudo rpm-ostree rebase fedora:fedora/41/x86_64/silverblue
systemctl reboot

Manage layered RPM packages

Although Silverblue is immutable, you can still layer RPM packages on top of the base image. Here is how to inspect and remove them.

rpm-ostree status
sudo rpm-ostree uninstall package-name
systemctl reboot

Troubleshooting tips

If updates fail or downloads hang, you can refresh metadata or inspect rpm-ostree logs.

sudo rpm-ostree refresh-md
journalctl -u rpm-ostreed

News : start translation updates was due to the migration on Fedora

Updates to translations of Fedora Documentation are again available. As announced on March 3rd, the unavailability of translation updates was due to the migration of the translation repositories and necessary tools from Pagure to the Fedora Forge. It took longer than expected but we are pleased to report this undertaking came finally to the end.

See the official website.

Fedora : Fedora SilverBlue 44 on VirtualBox 7.2.10 - fast video tutorial.

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 : 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.

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 : Fedora 43 comes without Xorg.

Fedora 43 won't support Xorg, the distro's. All GNOME X11 session users will be migrated to the Wayland session.

Fedora 43 will ship with Python 3.14, Linux Kernel 6.17, KDE 6.4, and RPM 6.0. It will come with Mesa 25.1.4 graphics drivers. Beta builds of Fedora 43 Workstation, KDE Plasma Desktop, Server, IoT, and Cloud are available for download on the distro's website.

News : Fedora 42 (Adams) !

Fedora 42 is a version of Fedora released to the public on 15 April 2025[1], under the codename "Adams". This version is notably the first version since Fedora 23 to use a codename. This version updates GNOME to version 48.

See the wikipedia article.

Yesterday I installed the Fedora Linux distro with version 42 also known as Adams, on the old Cosmic environment.

The packages were installed correctly and updated to version 42. The Cosmic environment, although it has a pretty good design, is just as poor as some of the implemented applications. I tried with about three screenshot applications to take a screenshot and I couldn't succeed. I noticed some packages for basic and cosmic implementation, but they didn't solve anything. Moreover, it seems that cosmic is related to rust and it's throwing me some strange messages!!!

I had to take a picture of the screen for this installation ... after all, it is a test version from the Fedora team based on RedHat linux!

News : Fedora team schedule for a long period of time .

It remains my favorite linux distribution so far. I didn't have time to work with Fedora, I see the development team initiated a larger plan over a longer period of time, which is very good.

Fedora Linux 41 End of Life will be on Wed 2025-11-19 and Fedora Linux 43 End of Life will be on Wed 2026-12-02.

Now : Notify Mirrors of Final Release , see this schedule.

• Fedora Linux 43
• Fedora Linux 42
• Fedora Linux 41
• Fedora Linux 40
• Fedora Linux 39

News : Bluefin Linux from Fedora Silverblue.

Fedora 41 : evtest basic tool for linux devices.

The evtest is c - Input device event monitor and query tool.

root@fedora:/home/mythcat# dnf5 install evtest
Updating and loading repositories:
Repositories loaded.
Package                                           Arch         Version                                           Repository                      Size
Installing:
 evtest                                           x86_64       1.35-8.fc41                                       fedora                      63.0 KiB

Transaction Summary:
 Installing:         1 package

Total size of inbound packages is 30 KiB. Need to download 30 KiB.
After this operation, 63 KiB extra will be used (install 63 KiB, remove 0 B).
...
root@fedora:/home/mythcat# evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:	Sleep Button
/dev/input/event1:	Lid Switch
/dev/input/event10:	HDA Intel Line
/dev/input/event11:	HDA Intel Headphone
/dev/input/event12:	PixArt USB Optical Mouse
/dev/input/event2:	Power Button
/dev/input/event3:	AT Translated Set 2 keyboard
/dev/input/event4:	SynPS/2 Synaptics TouchPad
/dev/input/event5:	Video Bus
/dev/input/event6:	ST LIS3LV02DL Accelerometer
/dev/input/event7:	Quickstart Button 1
/dev/input/event8:	HP WMI hotkeys
/dev/input/event9:	HDA Intel Mic
Select the device event number [0-12]:

Fedora 41 : the pref tool under Fedora.

Today I tested the perf tool in Fedora 41 and it is a bit difficult to use. I documented myself and found some information on the web and in the online linux community. Here is what I thought was worth remembering and what I tested.

The performance of Python with `perf` support is not great, and is going to get a lot worse.

Python - pref profiling

perf engineering with python

The pref tool can't run anyway:

mythcat@fedora:~/PythonProjects$ perf record -e cache-misses,page-faults,minor-faults,major-faults,cpu-migrations,L1-dcache-load-misses,L1-dcache-store-misses,L1-icache-load-misses,LLC-load-misses,LLC-store-misses,dTLB-load-misses,dTLB-store-misses,iTLB-load-misses
Error:
Access to performance monitoring and observability operations is limited.
Enforced MAC policy settings (SELinux) can limit access to performance
monitoring and observability operations. Inspect system audit records for
more perf_event access control information and adjusting the policy.
Consider adjusting /proc/sys/kernel/perf_event_paranoid setting to open
access to performance monitoring and observability operations for processes
without CAP_PERFMON, CAP_SYS_PTRACE or CAP_SYS_ADMIN Linux capability.
More information can be found at 'Perf events and tool security' document:
https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html
perf_event_paranoid setting is 2:
  -1: Allow use of (almost) all events by all users
      Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK
>= 0: Disallow raw and ftrace function tracepoint access
>= 1: Disallow CPU event access
>= 2: Disallow kernel profiling
To make the adjusted perf_event_paranoid setting permanent preserve ...

I used with sudo , wait and Ctrl + C to stop:

mythcat@fedora:~/PythonProjects$ sudo perf record -e cache-misses,page-faults,minor-faults,major-faults,cpu-migrations,L1-dcache-load-misses,L1-dcache-store-misses,L1-icache-load-misses,LLC-load-misses,LLC-store-misses,dTLB-load-misses,dTLB-store-misses,iTLB-load-misses ...

To get the accurate number of events count then number of results:

mythcat@fedora:~/PythonProjects$ perf report -D -i perf.data | grep RECORD_SAMPLE | wc -l
22461

I get my pref data and I saw all my system data with:

mythcat@fedora:~/PythonProjects$ sudo perf report -f -i perf.data 

Fedora 41 : NVim from sources or packages !

Today I tried the nvim and saw this big issue:

root@fedora:/home/mythcat# dnf5 install neovim
...
Package                     Arch     Version                     Repository          Size
Installing:
 neovim                     x86_64   0.10.2-1.fc41               fedora          29.1 MiB
...
Installing weak dependencies:
 nodejs                     x86_64   1:22.11.0-3.fc41            updates        148.5 KiB
 nodejs-docs                noarch   1:22.11.0-3.fc41            updates         91.9 MiB
 nodejs-full-i18n           x86_64   1:22.11.0-3.fc41            updates         29.3 MiB
 nodejs-npm                 x86_64   1:10.9.0-1.22.11.0.3.fc41   updates          9.4 MiB
 ripgrep                    x86_64   14.1.1-1.fc41               updates          4.7 MiB
 tree-sitter-cli            x86_64   0.23.2-1.fc41               updates         12.4 MiB
 wl-clipboard               x86_64   2.2.1-3.fc41                fedora         140.9 KiB
 xsel                       x86_64   1.2.1-2.fc41                fedora          47.9 KiB

You can see comes with nodejs. I remove the nodejs and I tested nvim and works.

Using the source code works also well:

root@fedora:/home/mythcat# curl -LO https://github.com/neovim/neovim/releases/latest/download/nvim-linux64.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 11.4M  100 11.4M    0     0  5739k      0  0:00:02  0:00:02 --:--:-- 14.1M
root@fedora:/home/mythcat# sudo rm -rf /opt/nvim
root@fedora:/home/mythcat# sudo tar -C /opt -xzf nvim-linux64.tar.gz
root@fedora:/home/mythcat# export PATH="$PATH:/opt/nvim-linux64/bin"
root@fedora:/home/mythcat# nvim