We are happy to announce the general availability of Fedora Asahi Remix 44. This release brings Fedora Linux 44 to Apple Silicon Macs.

Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. This release incorporates all of the exciting improvements brought by Fedora Linux 44.  Fedora Asahi Remix 44 also retires our vendored Mesa and virglrenderer packages. Users who have not already manually done so will be automatically transitioned to the upstream Mesa and virglrenderer packages provided by the upstream Fedora repositories.

Fedora Asahi Remix offers KDE Plasma 6.6 as our flagship desktop experience, with all of the new and exciting features brought by Fedora KDE Plasma Desktop 44.  Plasma Setup replaces the previous Calamares-based setup wizard, providing a Plasma-native experience for user account creation and system setup. Additionally, Plasma Login Manager is now the default greeter and session manager, replacing SDDM. This applies to new installs only; users upgrading from previous versions of Fedora Asahi Remix will not have their configuration changed.

A GNOME variant is also available, featuring GNOME 50, with both desktop variants matching what Fedora Linux offers. Fedora Asahi Remix also provides a Fedora Server variant for server workloads and other types of headless deployments. Finally, we offer a Minimal image for users that wish to build their own experience from the ground up.

You can install Fedora Asahi Remix today by following our installation guide. Existing systems running Fedora Asahi Remix 42 or 43 can be updated following the usual Fedora upgrade process. Upgrades via GNOME’s Software application are unfortunately not supported; either KDE’s Plasma Discover or DNF’s System Upgrade command must be used.

Please report any Remix-specific issues in our tracker, or reach out in our Discourse forum or our Matrix room for user support.

Fedora has released Fedora KDE Plasma Desktop Edition 44 to the public.

The Fedora KDE Plasma Desktop Edition is suitable for many needs.  It combines the reliable and trusted Fedora Linux base with the KDE Plasma Desktop environment.  It provides a selection of KDE applications that are simple by default, but powerful when needed.

KDE Plasma 6.6

The KDE community makes your life easier with the latest release of KDE Plasma. It builds upon the foundations of Plasma 6 to provide a seamless, friendly, and familiar experience.

Fedora KDE 44 ships with Plasma 6.6.4 featuring:

• Custom global theme creation by saving the current theme setup
• More options for using color accent in windows with tint intensity for window frames
• Support for connecting to Wi-Fi networks by scanning QR codes
• Per-application volume adjustment from the task manager
• New grayscale filter for colorblindness correction
• New screen magnifier feature that tracks the mouse pointer
• New “Slow keys” and “reduced motion” settings
• Spectacle can do OCR scanning of images to capture text
• Per-window filter from screencast through the menu in the title bar

There’s so much more detail available in the Plasma 6.6 release announcement.

Fedora KDE 44 specific updates

Beyond just the updates included in KDE Plasma 6.6, there are some major new features with Fedora KDE on Fedora Linux 44.

• Fresh installations now use the brand-new Plasma Setup and Plasma Login Manager. These provide a more cohesive and integrated experience from the moment the computer is powered on the first time. The installation process has been simplified. It now enables you to easily set up a computer with Fedora KDE Plasma Desktop for a friend or a loved one.
• The on-screen keyboard uses the new Plasma Keyboard, providing a fresh and future-forward implementation for keyboard input.

Fedora Linux 44 general updates

Some broader changes in Fedora Linux also directly impact Fedora KDE Plasma Desktop Edition, notably:

• PackageKit now uses version 5 of the DNF package manager as the backend.
• Support for select Qualcomm-based laptops.
• The /etc/pki/tls/cert.pem file no longer exists by default. This may impact some programs that expect this file to provide system CA certificates instead of leveraging behaviors built into cryptographic security libraries to offer this information.

Fedora Ready is ready for Fedora KDE

The Fedora KDE Plasma Desktop 44 edition is fully supported within the Fedora Ready program. Fedora KDE is actively engaging with hardware vendors to support Fedora KDE Plasma Desktop on their devices.

We are pleased to announce that Star Labs offers preinstalled Fedora KDE Plasma Desktop as an option for their portfolio of devices. As makers of computers with an open source ethos embedded into the core of their products with even open source firmware powered by Coreboot, they share many of the same principles the Fedora community values. This is a very exciting moment for Fedora KDE and we look forward to deepening our collaboration with Fedora Ready participants and extending to other vendors. If you are a vendor potentially interested in Fedora Ready, please reach out!

Wrap-up

The Fedora KDE SIG hopes that you’ll find the Fedora KDE Plasma Desktop 44 to be a wonderful experience. When you’re ready to try it, click here for download links and verification instructions. If you’d like to learn more, check out the Fedora KDE Plasma Desktop website.

I’m happy to announce that we have sealed bootable container images ready for testing for the Fedora Atomic Desktops!

What are sealed bootable container images?

Sealed bootable container images include all the components needed to create a fully verified boot chain, from the firmware to the operating system composefs image. This relies on Secure Boot and thus only supports system booting with UEFI on x86_64 & aarch64.

The components are:

• systemd-boot as bootloader
• a Unified Kernel Image (UKI) which includes the Linux kernel, an initrd and the kernel command line
• a composefs repository with fs-verity enabled. This is managed by bootc.

Both systemd-boot and the UKI are signed for Secure Boot. The images are test images so the components are not signed with the official keys from Fedora.

The main direct benefit that we will get from this support is that we will be able to enable passwordless disk unlocking using the TPM in a way that will be reasonably secure by default.

How do I test those images?

See the instructions at github.com/travier/fedora-atomic-desktops-sealed on how to give the pre-built container and disk images a try and how to build your own.

We welcome testing and feedback! Please see the list of known issues and report new issue at github.com/travier/fedora-atomic-desktops-sealed. We’ll redirect them as needed to the right upstream projects.

Beware, those are testing images. The root account does not have a password set and sshd is enabled, by default, to make debugging easier. The UKI and systemd-boot are signed for Secure Boot but, since those are test images, they are not signed with the official keys from Fedora. Don’t use those images in production.

Where can I get more details about how this works?

If you want to know more about how sealed images work (i.e. how we make bootable containers, UKI and composefs work together to create a verified boot chain), see the following presentations and documentation:

• “Signed, Sealed, and Delivered”, with UKIs and composefs, from Allison and Timothée at FOSDEM 2025
• UKIs and composefs support for Bootable Containers, from Timothée at Devconf.cz 2025
• UKI, composefs and remote attestation for Bootable Containers, from Pragyan, Vitaly and Timothée at ASG 2025
• composefs backend documentation in bootc

Thanks to all the contributors that made this possible, notably (but non exhaustively) from the following projects: bootc & bcvk, composefs & composefs-rs, chunkah, podman & buildah and systemd.

Fedora Linux 44 has been released!  So, let’s see what is included in this new release for the Fedora Atomic Desktop variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).

Changes for all Atomic Desktops

Issue tracker moved to the new Fedora forge

We have moved the cross-variants issue tracker to the new Fedora forge. This is the best place to file issues that impacts all variants or to coordinate work between all of them. If you have issues specific to a given desktop environment then we usually prefer to track them in each respective SIG trackers. These are available on the README for the atomic-desktops organization.

Unified documentation, hosted on the new forge

The unified documentation for all Atomic Desktops is finally live! Unfortunately the translations have not been migrated so we will need help to re-translate everything again, once the translation setup is ready with the new forge. It should be mostly copy/paste from the previous docs and this time we will only have to translate the docs once and not for every (new) variant.

See the tracking issue atomic-desktops#10.

Removal of FUSE version 2 libraries

FUSE version 2 has been deprecated and unmaintained for a while so we have removed it from the images. In practice, this means two things:

• If you are using AppImages, some of them may not work anymore.
• If you are using legacy backends with Plasma Vault on Kinoite, you need to migrate your data.

See the Fedora Change and the tracking issue atomic-desktops#50. The implications are detailed below.

AppImages and the FUSE 2 libraries

Some AppImages are still using an old AppImage runtime that relies on FUSE 2 libraries being available on the host. See the Discussion thread for examples on how to check the runtime of an AppImage.

If some of your AppImages do not work on Fedora Atomic Desktops 44, we recommend:

• Looking for a Flatpak for the application and giving it another try. Consider helping upstream package their application as a Flatpak.
• Reporting the issue upstream so that they are aware that they should use a newer runtime. Consider helping upstream with this as well.

EncFS or CryFS backends for Plasma Vaults are removed

KDE upstream no longer recommends using the EncFS nor CryFS backends for Plasma Vaults, notably because they rely on the FUSE 2 libraries. If you are using one of those backends, you should migrate your data to a new vault using the only maintained backend (gocryptfs). Ideally this should occur before the update to Fedora Linux 44. If you have already updated to Fedora Linux 44 and need access to your data, you can layer the needed packages (cryfs or fuse-encfs) using rpm-ostree install <package>, then migrate your data and finally reset the layers with rpm-ostree reset.

Dropping compatibility for pkla Polkit rules

Support for the legacy pkla Polkit rules format has been removed. It is unlikely that you were relying on support for those rules as most of the ecosystem has moved on to the new JavaScript based format.

See the Fedora Change and the tracking issue atomic-desktops#102.

What’s New in Silverblue

GNOME 50

Fedora Silverblue comes with the latest GNOME 50 release. For more details about the changes that occur alongside GNOME 50, see What’s New in Fedora Workstation 44 on the Fedora Magazine.

What’s New in Kinoite

KDE Plasma 6.6

Fedora Kinoite ships with Plasma 6.6, Frameworks 6.24 and Gear 25.12.

See also What’s New in Fedora KDE Plasma Desktop 44 in the Fedora Magazine.

KDE Plasma Login Manager replaces SDDM

The brand new Plasma Login Manager replaces SDDM to provide a more integrated experience with systemd and the KDE Plasma session.

See the Fedora Change.

Unified out of the box experience with KDE Plasma Setup (OEM installation)

Thanks to the new Plasma Setup, it is now possible to install the system with Anaconda with minimal configuration and then complete the installation on the first boot by creating a new user and selecting the timezone. This is great when you want to install Fedora Kinoite on a computer and don’t want to setup a user in advance.

See the Fedora Change.

What’s New in Sway Atomic

Nothing specific for this release.

What’s New in Budgie Atomic

Fedora Budgie Atomic comes with the latest 10.10.2 Budgie release. This release brings Wayland support to Budgie Atomic. See the 10.10 release announcement for more details.

What’s New in COSMIC Atomic

Fedora COSMIC Atomic comes with the latest 1.0.8 release of the COSMIC desktop. This is now considered stable.

Universal Blue, Bluefin, Bazzite and Aurora

Our friends in the Universal Blue project (Bazzite, Bluefin, Aurora) have prepared the update to Fedora Linux 44. Look for upcoming announcements in their Discourse.

As always, I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA drivers, extra media codec, out of tree kernel drivers, etc.).

What’s Next

Helping us with a few nasty bugs

If you have an interest in contributing to Fedora Atomic Desktops, here are some bugs that we will have to fix in the short term. We would greatly appreciate help with:

• Fixing root mount options (atomic-desktops#72): This is a long standing and mostly invisible bug that impacts performance.
• Moving away from nss-altfiles (atomic-desktops#108): This is another long standing source of issues that new users regularly face.

Sealed Fedora Atomic Desktop bootable container images

Sealed images are now ready for testing! See the other article for all the details.

Road map to Bootable Containers

A lot of work is happening to make the transition to Bootable Containers as smooth as possible for our existing users. You can look at the road map for this transition at atomic-desktops#26.

One of the tasks is to move away from our unmaintained installation ISO building scripts to the new image-builder tooling. This is planned for Fedora Linux 45 for the ostree variants and support for Bootable Container will follow right after.

Another task is to start building the Fedora Atomic Desktops Bootable Container images using the Fedora Konflux instance.

Where to reach us

We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.

• Atomic Desktops SIG: Organization on Fedora’s Forge, #atomic-desktops:fedoraproject.org
• Silverblue: Workstation Working Group, #silverblue:fedoraproject.org
• Kinoite: KDE SIG, #kinoite:fedoraproject.org
• Sway Atomic: Sway SIG, #sway:fedoraproject.org
• Budgie Atomic: Budgie SIG, #budgie:fedoraproject.org
• COSMIC Atomic: COSMIC SIG, #cosmic:fedoraproject.org

Fedora Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. If you want to rebase to Fedora Linux 44 on your Fedora Silverblue system, this article tells you how. It not only shows you what to do, but also how to revert things if something unforeseen happens.

Update your existing system

Prior to actually doing the rebase to Fedora Linux 44, you should apply any pending updates. Enter the following in the terminal:

$ rpm-ostree update

or install updates through GNOME Software and reboot.

Note

rpm-ostree is the underlying atomic technology that all the Fedora Atomic Desktops use. The techniques described here for Silverblue will apply to all of them with proper modifications for the appropriate desktop.

Rebasing using GNOME Software

GNOME Software shows you that there is new version of Fedora Linux available on the Updates screen.

First thing to do is download the new image, so select the Download button. This will take some time. When it is done you will see that the update is ready to install.

Select the Restart & Upgrade button. This step will take only a few moments and the computer will restart when the update has completed. After the restart you will end up in a new and shiny release of Fedora Linux 44. Easy, isn’t it?

Rebasing using terminal

If you prefer to do everything in a terminal, then this part of the guide is for you.

Rebasing to Fedora Linux 44 using the terminal is easy. First, check if the 44 branch is available:

$ ostree remote refs fedora

You should see the following in the output:

fedora:fedora/44/x86_64/silverblue

If you want to pin the current deployment (meaning that this deployment will stay as an option in GRUB until you remove it), you can do this by running this command:

# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0

To remove the pinned deployment use the following command:

# 2 is entry position in rpm-ostree status 
$ sudo ostree admin pin --unpin 2

Next, rebase your system to the Fedora Linux 44 branch.

$ rpm-ostree rebase fedora:fedora/44/x86_64/silverblue

Finally, the last thing to do is restart your computer and boot to Fedora Linux 44.

How to roll back

If anything bad happens (for instance, if you can’t boot to Fedora Linux 44 at all) it’s easy to go back. At boot time, pick the entry in the GRUB menu for the version prior to Fedora Linux 44 and your system will start in that previous version rather than Fedora Linux 44. If you don’t see the GRUB menu, try to press ESC during boot. To make the change to the previous version permanent, use the following command:

$ rpm-ostree rollback

That’s it. Now you know how to rebase Fedora Silverblue to Fedora Linux 44 and roll back. So why not do it today?

FAQ

Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.

Question: Can I skip versions during a rebase of Fedora Linux? For example from Fedora Silverblue 41 to Fedora Silverblue 44?

Answer: Although it could sometimes be possible to skip versions during rebase, it is not recommended. You should always update to one version prior (41->42->43->44 for example) to avoid unnecessary errors.

Question: I have rpm-fusion layered and I get errors during rebase. How should I do the rebase?

Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:

$ rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release

After doing this you can follow the guide in this blog post.

Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?

Yes, you can follow the Rebasing using the terminal part of this guide for every Fedora Atomic Desktop. Just use the corresponding branch. For example, for Kinoite use fedora:fedora/44/x86_64/kinoite

This article highlights a few noteworthy changes in the latest release of Fedora Workstation that we think you will love. Upgrade today from the official website, or upgrade your existing install using GNOME Software or through the terminal with dnf system-upgrade.

GNOME 50

Fedora Linux 44 Workstation ships with the latest GNOME release, GNOME 50. This comes with a long list of refinements to your desktop, including everything from accessibility, to color management and remote desktop.

As part of the Digital Wellbeing initiative, new native Parental Controls let you set screen time limits and bedtimes directly from Settings.

Many of the applications that are installed by default on the Fedora Workstation have also seen improvements, from the Document Viewer to the File Manager and the Calendar.

To learn more about these and other changes, you can read the GNOME 50 release notes.

Wrap-up

Be sure to check out the Fedora Linux 44 Change Set wiki for even more details about all the features and changes that went into Fedora Linux 44. Use the Fedora Discussion forum or Fedora’s Matrix chat server if you want to converse with the Fedora community about this new release!

I’m excited to announce that Fedora Linux 44 is here! Keep reading to discover highlights of Fedora Linux 44, or if you are ready, just jump right in and give Fedora Linux 44 a try!

Thanks to everyone who helped!

Thank you and congrats to everyone who has contributed to this release. And thanks to everyone who showed up for the virtual release party last Friday. We celebrated a little early this year, just after the go/no-go meeting made the release official. If you weren’t able to join us live, you can watch the recording and hear about some of the great work from the contributors involved.

Looking to upgrade?

If you have an existing system, Upgrading Fedora Linux to a New Release is easy. In most cases, it’s not very different from just rebooting for regular updates, except you’ll have a little more time to grab a coffee.

Ready to Fresh Install?

If this is your first time running Fedora Linux, or if you just want to start fresh with Fedora, download the install media for our flagship Editions (Workstation, KDE Plasma Desktop, Cloud, Server, CoreOS, IoT), or one of our Atomic Desktops (Silverblue, Kinoite, Cosmic, Budgie, Sway), or alternate desktop options (like Cinnamon, Xfce, Sway, or others).

What’s new?

As usual with Fedora Linux, there are just too many individual changes and improvements to go over in detail. You’ll want to take a look at the release notes for that.

Notable User Visible Changes

Anaconda

For those of you installing fresh Fedora Linux 44 Spins, you may notice a change in how Anaconda handles network devices. Anaconda now only creates network profiles for devices configured during installation (by boot options, kickstart, or interactively in UI) instead of providing default profiles for all devices. This change will simplify post-installation network configuration for users who need to customize after installation.

Workstation

Fedora Linux 44 Workstation ships with the latest GNOME release, GNOME 50. This comes with a long list of refinements to your desktop, including everything from accessibility to color management and remote desktop. Many of the applications that are installed by default on Fedora Workstation have also seen improvements, from Document Viewer to File Manager and Calendar. To learn more about these and other changes, you can read the GNOME 50 release notes.

KDE Plasma Desktop

KDE Plasma Desktop: If you are a KDE user, you should also notice a couple of very obvious changes. Fedora KDE Plasma Desktop 44 is based on the latest Plasma 6.6, which includes the new Plasma Login Manager and Plasma Setup to provide a more cohesive and integrated experience from the moment the computer is powered on for the first time. The installation process has been simplified, enabling you to easily set up Fedora KDE Plasma Desktop for a computer for a friend or a loved one.
 

Plumbing Upgrades

Beyond the user-visible changes, there are some important plumbing changes user should be aware of.

OpenSSL Cert File Handling Improvements

The loading time of OpenSSL has been improved by making use of directory-hash support for ca-certificates. This improvement required changes to where some certificate bundles are stored on the filesystem. You can read the specific Change details for more information.

The MariaDB default version is now 11.8

MariaDB packages use a versioned package layout, which allows Fedora to deliver both, mariadb-10.11 and mariadb-11.8 for users.  The “distribution default” unversioned MariaDB packages now install the 11.8 versions in Fedora Linux 44. User doing upgrades to Fedora Linux 44 won’t notice the change in the default. For new users installing MariaDB for the first time, unless you specify the version, you’ll now get 11.8 by default.

Wine NTSYNC

The NTSYNC kernel module is enabled for select packages by package recommendation (notably Wine and Steam), which can improve compatibility and performance when running Windows applications (especially games).  When packages that recommend the wine-ntsync package are installed, the package recommendation ensures NTSYNC is configured automatically on subsequent boots, so that users don’t have to manually enable NTSYNC.

Fedora Cloud boot partition using Btrfs

The /boot partition has been replaced with a Btrfs subvolume for Fedora Cloud images that support it.  This results in better space utilization and smaller images.

If you hit a snag

If you run into a problem, visit our Ask Fedora user support forum. This forum includes a category where we collect common issues and solutions or work-arounds.

Just drop by and say “hello”

Drop by our “virtual watercooler” on Fedora Discussion and join a conversation, share something interesting, and introduce yourself. We’re always glad to see new people!

Fedora Linux 44 is almost officially here! While our release engineering team and packagers focus on the final touches for F44, it is nearly time for the usual tradition of a Global Virtual Release Party! It is almost time to celebrate! For this release, we will celebrate Fedora Linux 44 slightly ahead of its actual final release.

Regardless of the final calendar date of any Fedora Linux release, every release represents months of hard work, testing, and collaboration from our global community. Whether you are a long-time package maintainer, a dedicated documentation writer, a creative graphic artist, or a brand-new user firing up a Fedora Atomic Desktop for the very first time, this release belongs to you.

To mark the occasion, we are hosting the Fedora Linux 44 Virtual Release Party this Friday, April 24, 2026.

Join us for a half-day of live sessions, recorded deep-dives, and community socialization. We have packed the schedule with updates from the Fedora Project Leader, behind-the-scenes looks at new features like Nix integration and DNF5, and a sneak peek at our upcoming Flock conference!

How to Attend

The event is 100% free and open to everyone, but registration is required to access the virtual venue. We are also happy to continue using our chat communication provider, Element Creations, as the virtual venue for the Global Virtual Release Parties. Thanks Element & Matrix.org for providing us the great tools to bring our global community together!

Register for the Fedora Linux 44 Release Party live event on Matrix!

Event Schedule

All times are listed in US Eastern (UTC-4) and UTC.

Time (EDT)	Time (UTC)	Session	Speaker(s)	Description
09:00 AM	13:00	Opening Remarks	Jef Spaleta, Justin Wheeler	Join the Fedora Project Leader and Community Architect as we kick off the celebration, look back on the last release cycle, and share news from around the project.
09:15 AM	13:15	FPL Update	Jef Spaleta	Jef Spaleta shares his reflections on Fedora Linux 44, what this release means for the project, and his vision for what lies ahead.
09:30 AM	13:30	Packit as Fedora dist-git CI	František Lachman, Laura Barcziova, Maja Massarini, Matej Focko, Nikola Forro	The Packit team walks through how Packit is taking over Fedora dist-git CI, what this change means for contributors, and what’s next.
09:45 AM	13:45	Adding Nix to Fedora: we did a thing	Jens Petersen	A behind-the-scenes look at bringing the Nix package tool to Fedora 44 — what it took, what it unlocks, and what it means for reproducible environments.
10:00 AM	14:00	PackageKit with DNF5 and KDE Integration	Neal Gompa	Dive into the integration of PackageKit with DNF5 and KDE in F44, what changed under the hood, and what it means for the desktop experience.
10:15 AM	14:15	Server WG	Peter Boy	An overview of the Server Working Group’s initiative to create a dedicated home server spin, driven by community home lab feedback.
10:30 AM	14:30	Break	None	Take a screen break, grab some coffee, or merge that Pull Request. We will be back with more programming soon!
11:00 AM	15:00	Fedora Docs	Petr Bokoc, Peter Boy	An update on the state of Fedora Docs and the ongoing Docs Initiative — where things stand today, and how you can get involved.
11:15 AM	15:15	What’s new and what’s next for the Fedora Atomic Desktops	Timothée Ravier	Discover what is new across the Fedora Atomic Desktops family (Silverblue, Kinoite, Sway, Budgie, COSMIC) and the roadmap toward Bootable Containers.
11:30 AM	15:30	Flock Preview	Justin Wheeler	With Flock just weeks away, get an early look at what to expect — sessions, highlights, and reasons to get excited about this June’s event.
11:45 AM	15:45	TBA	TBA	Stay tuned!

See you there!

Don’t miss out on the chance to connect with the people who build Fedora. Grab your ticket, share the link with your friends, and get ready to celebrate Fedora Linux 44.

Claim your free ticket now!

---

The author of this article utilized generative AI (Google Gemini 3.1 Pro) to assist in part of the drafting and editing process.

One of the main abilities of a debugger is setting breakpoints.
GDB: The GNU Project Debugger now introduces an experimental feature
called source-tracking breakpoints that tracks the source line a breakpoint
was set to.

Introduction

Imagine you are debugging: you set breakpoints on a bunch of
source lines, inspect some values, and get ideas about how to change your
code. You edit the source and recompile, but keep your GDB session running
and type run to reload the newly compiled executable. Because you changed
the source, the breakpoint line numbers shifted. Right now, you have to
disable the existing breakpoints and set new ones.

GDB source-tracking breakpoints change this situation. When you set a
breakpoint using file:line notation, when this feature is enabled, GDB
captures a small window of the surrounding source code. When you recompile
and reload the executable, GDB adjusts any breakpoints whose lines shifted
due to source changes. This is especially helpful in ad-hoc debug sessions
where you want to keep debugging without manually resetting breakpoints
after each edit-compile cycle.

Setting a source-tracking breakpoint

To enable the source-tracking feature, run:

(gdb) set breakpoint source-tracking enabled on

Set a breakpoint using file:line notation:

(gdb) break myfile.c:42
Breakpoint 1 at 0x401234: file myfile.c, line 42.

GDB now tracks the source around this line. The info breakpoints command
shows whether a breakpoint is tracked:

(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000401234 in calculate at myfile.c:42
source-tracking enabled (tracking 3 lines around line 42)

Now edit the source — say a few lines are added above the breakpoint,
shifting it from line 42 to line 45. After recompiling and reloading the
executable with run, GDB resets the breakpoint to the new line and displays:

Breakpoint 1 adjusted from line 42 to line 45.

Run info breakpoints again to confirm the new location:

(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000401256 in calculate at myfile.c:45
source-tracking enabled (tracking 3 lines around line 45)

As you can see, GDB updated the breakpoint line to match the new location.

Limitations

The matching algorithm requires an exact string match of the captured source
lines. Whitespace-only changes or trivial reformatting of the tracked lines
will confuse the matcher and may cause the breakpoint not to be found.

GDB only searches within a 12-line window around the original location. If
the code shifted by more than that — for example, because a large block was
inserted above — the breakpoint will not be found. GDB will keep the
original location and print a warning:

warning: Breakpoint 1 source code not found after reload, keeping original
location.

Source context cannot be captured when a breakpoint is created pending
(e.g., with set breakpoint pending on), because no symbol table is available
yet. When the breakpoint later resolves to a location, it will not be
source-tracked.

Source tracking is not supported for ranged breakpoints (set with
break-range).

Breakpoints on inline functions that expand to multiple locations are not
source-tracked, as each location may have moved differently.

How to try this experimental feature

This feature is not yet available in a stable GDB release. There are two
ways to try it.

Install from COPR (for Fedora users)

A pre-built package is available through a COPR repository. Enable it and
install:

sudo dnf copr enable ahajkova/GDB-source-tracking-breakpoints
sudo dnf upgrade gdb

To disable the repository again after testing:

sudo dnf copr disable ahajkova/GDB-source-tracking-breakpoints

The COPR project page is at:
https://copr.fedorainfracloud.org/coprs/ahajkova/GDB-source-tracking-breakpo
ints/

Build from source

1. Clone the GDB repository:
   git clone git://sourceware.org/git/binutils-gdb.git
   cd binutils-gdb
2. Download and apply the patch from the upstream mailing list:
   https://sourceware.org/pipermail/gdb-patches/2026-April/226349.html
3. Build GDB:
   mkdir build && cd build
   ../configure --prefix=/usr/local
   make -j$(nproc) all-gdb
4. Run the newly built GDB:
   ./gdb/gdb

Conclusion

GDB source-tracking breakpoints are an experimental feature currently under
upstream review and not yet available in a stable GDB release. This link
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Set-Breaks.html
covers all available breakpoint commands. If you try this feature out and
hit any kind of unexpected behavior, feedback is very welcome — you can
follow and respond to the upstream patch discussion on the GDB mailing list
at https://sourceware.org/pipermail/gdb-patches/2026-April/226349.html

It’s time to show our appreciation of the amazing contributors who help shape the Fedora community.

The Fedora Project thrives through the devotion, guidance, and tireless drive of the contributors who consistently perform. From developing testcases to onboarding contributors, from technical writing to coordinating events, it is these vital champions who ensure that the community flourishes. In coordination with the Fedora Mentor Summit 2026, we will be returning to Flock To Fedora 2026 to announce the winners. This wiki reflects the deep gratitude and careful thought behind this community recognition program.

As we prepare to spotlight exceptional mentors and contributors across the Fedora Project, we invite you to help us appreciate the amazing contributors who help shape the community. Whether it is a veteran mentor who helped you begin your journey or a contributor whose efforts have truly reshaped the community’s landscape, now is the moment to celebrate them! Discover more about the nomination guidelines and submit your entry using the link provided below:

Find more information here: https://fedoraproject.org/wiki/Contributor_Recognition_Program_2026
Submit your nominations here: https://forms.gle/mBAVKw4qLu14R5YY7

Deadline: 15th May 2026

Let us appreciate the amazing contributors who help shape the community. Your nomination could be the recognition that might enable them to do more – and a moment of achievement for the entire community.

In this article you will learn how TLS (Transport Layer Security) and SSH (Secure SHell) use public/private key-pairs to authenticate web servers you visit and linux machines you log in to. You will also learn how the TLS framework installed by default in mainstream web browsers fails to prevent MITM (Man In The Middle) attacks in critical ways. Then we will walk through setting up a private .FEDORA TLD (Top Level Domain), setting up your own private CA with the smallstep package, and using the acme-tiny package to issue certificates for a website under that private TLD.

I will not cover setting up a simple “Hello World” website using your favorite web server packaged with Fedora. This needs to be up and running on HTTP to follow along. For this article, the website will be named hello.fedora.

Sadly, we will also explain how this does not completely solve the MITM problem – but this is already a big article. Click here to skip the background and motivation and go directly to the HowTo.

How Public Keys Prevent Man-In-The-Middle Attacks

While NSA director Admiral Bobby revealed that intel agencies were aware of two key, or public-key cryptography since the 1960s, the first unclassified paper was published by Whitfield Diffie and Martin E. Hellman in 1976. In college, I remember playing with cryptosystems based on the knapsack problem. These had various vulnerabilities. What revolutionized the field was publication of the RSA algorithm in 1977. I vividly remember where I sat in the college library when I read the paper. There was some controversy over “you can’t patent algorithms”. However RSA patented their implementation (which is already protected by copyright – but that is another discussion). Yes, you can whip up a 1 line Perl implementation in a few minutes (we all did) – but a secure implementation that does not leak the private key through various side channels is NOT trivial.

The original concept of public keys was to look up a recipient’s pubkey in a directory, and use it to encrypt a message that only the possessor of the corresponding private key can decrypt. This can also be used to authenticate a correspondent via a protocol that proves they hold the corresponding private key. The basic idea is to encrypt a random token with a pubkey, the recipient decrypts the token and sends it back encrypted by your pubkey. The details are not trivial. The primary concern is MITM attacks. SSH and TLS support several widely accepted algorithms for authentication and key exchange.

The Directory of Pubkeys is Critical

If you think about it, that “directory” is all important. Suppose you have a “secure” phone app (without naming names) that uses a public directory to map telephone number to pubkey. Whoever runs that directory can return their own pubkey (likely a different one for each telephone number), decrypt the data, and send it on, re-encrypted to the real pubkey of the intended recipient (and the same for the other direction). I.e. – the classic MITM attack. This is why such secure applications usually provide a way to verify you have the real pubkey via an in-person meeting or alternate medium.

So how do you know the real pubkey for a secure (https) website? Websites provide a “certificate” saying “this pubkey is for these domain names” (and other information we are not concerned with here). Well, anyone can create such a certificate – in fact we will do so in this article – so how do you know it is truthful? The certificate is “signed” by a Certificate Authority (CA). Pubkeys can be used to sign data. For RSA, the basic concept is to compute a secure “hash” (e.g. SHA256) of the certificate data, and “decrypt” it using the private key of the CA. The signature can be verified by using the pubkey of the CA to “encrypt” the result, – which should match the hash of the signed data. RSA is nice in that decryption and encryption are symmetrical – verifying a signature is the same operation as encrypting the signature to the owner of the privkey for the pubkey . So now, instead of every web user maintaining a private database of pubkeys for domain names, the browser has a list of trusted CAs which sign website certificates after verifying them in some way. In case a private key is compromised, CAs publish a Revocation List (which regular people rarely use) and TLS certificates always have an expiration date.

Note that CAs can certify data other than domain names, like the name of a company or individual. Commercial CAs generally charge a premium for this, but there are also non-profit CAs like cacert.org that certify personal details via in-person meetings.

How Mainstream Browsers Know Which CAs to Trust

Regular Joes (“normies”) do not keep track of all this, so where does that “list of trusted CAs” come from? Well, there is a CA and Browser forum with representatives from popular browser software makers and commercial CAs. They maintain a list of trusted CAs, and changes are voted on in public meetings with minutes published on their web page. Fedora installs this list in /usr/share/pki. Browsers may have their own copy. Users may add additional trusted CAs to /usr/share/pki or /etc/pki/ca-trust and browsers may have their own way of adding additional trusted CAs.

This all sounds well and good, BUT. The critical flaw could be called serial reliability. The trusted CAs are trusted for any domain. So any trusted CA (including any you add) can forge a certificate for any website. DNS vulnerabilities (cache poisoning and such) are beyond the scope of this article. But we will set up a private CA which you could use to forge any website cert and fool anyone you convince to trust your CA (and can hack their DNS and/or IP routing). The cabforum is very careful about their list. As part of hostilities, forum CAs stopped certifying .RU domains (ISO TLD for Russia). Russia promptly put up their own national CAs, which anyone can add to their browser trust store. Normies were warned NOT to do this, as the Russian CAs could then forge certs for any domain. But a moment’s thought reveals that ANY cabforum CA could go “rogue” and do the same thing. It only takes one.

There are solutions to this blanket trust problem, but that will require another article.

Create a private TLD with bind

For illustration, we will create the .FEDORA TLD. Everyone following along will create a different instance of that TLD, and hostnames under .FEDORA will resolve to different IPs (or NXDOMAIN) depending on whose DNS server you point that TLD at. This was the motivation for creating ICANN – a worldwide centralized DNS root (list of official TLDs). This provides a consistent namespace at the expense of absolute power (to cancel domains and TLDs) invested in ICANN. Before ICANN, admins all maintained their own DNS root, and periodically updated (manually or automatically) nameservers for well known TLDs like .COM etc. ISO defined an official list of TLDs, including country code TLDs (like .US). That worked well. The problem came with more obscure TLDs like .FREE. Companies trying to be “cool” were upset that not all customers got the same IPs for .FREE hostnames. Also admins liked having “someone else” maintain the DNS root. Hence, ICANN. There is also Opennic which likewise has “someone else” (volunteers) maintain a root zone, with fallback to ICANN, and has its own “forum” (existing TLDs vote) to approve new TLDs.

Here is a bind zonefile for .FEDORA:

$TTL 2H
; hello.fedora
@               IN      SOA     ns1     hostadmin.hello.fedora. (
                        2025122600 ; serial
                        1H ; refresh
                        15M ; retry
                        14D ; expire
                        6H ; default_ttl
                        )
@               IN      NS      ns1.fedora.
@               IN      TXT     "v=spf1 -all"
hello		IN      A	192.168.100.31
ns1		IN	A	192.168.100.31
ca		IN	A	192.168.100.31

But that was a bait and switch. Setting up DNS for a private TLD is its own article. If you know how to add such a zone to your self hosted DNS – then do so. For the rest, we’ll use an even older hostname/IP map that predates DNS: as root, edit the file /etc/hosts on the system you will run step-ca on and append these lines:

# smallstep article
192.168.100.31	hello.fedora
192.168.100.31	ca.fedora

Replace 192.168.100.31 with the IP of the system you are trying all this out on. Step-ca must be able to lookup the hello.fedora hostname it is certifying to do the ACME protocol. We will use the /.well-known/acme-challenge method, which does not require real DNS. The system you run acme-tiny on also needs to lookup ca.fedora.

Run a private CA with step-ca

If the smallstep package is still under review when you read this, you’ll need to enable the copr repo (otherwise skip this step):

sudo dnf copr enable @fedora-review/fedora-review-2418762-smallstep

Create root CA

First, we need to create our root CA. In production, this should be on a separate offline machine. For small operations, the secondary CAs can be automated, and you sign the certificates for these secondaries manually with the root CA. I would keep the root CA password on paper – can’t be hacked (but watch out for cameras). Do NOT skip the password for the root CA. Some number of systems will trust that CA for any domain. If the private key leaks, you end up with a situation like Dell faced in 2015.

Let’s put the manual root CA in /etc/pki/CA and generate the root cert. Openssl will ask you for a key passwd, and what x509 calls “subject identifiers”. I left the state and email blank, and set city to Fedora City, organization to Fedora Project, organizational unit to ca, and common name to ca.example.org. The “-days 3650” sets the expiration to 10 years from now. The second command shows the “Issuer” information end-users will see when they ask for the issuer in an app like Firefox. The common name should normally be the hostname of the root CA, but it doesn’t really matter when the root CA is offline – and example.org is coincidentally offline by convention.

$ sudo mkdir /etc/pki/CA
$ cd /etc/pki/CA
$ sudo install --mode=644 /dev/stdin root_ca.fedora.ext <<EOF
subjectAltName=DNS:ca.example.org
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:1
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
EOF
$ sudo mkdir -m 0700 private
$ sudo openssl req -new -keyout private/root_ca.key -out root_ca.csr
...
$ sudo openssl x509 -req -in root_ca.csr -key private/root_ca.key -out root_ca.crt -days 3652 -sha256 -extfile root_ca.fedora.ext
Enter pass phrase for private/root_ca.key:
Certificate request self-signature ok
subject=C=US, L=Fedora City, O=Fedora Project, OU=ca, CN=ca.example.org

Create intermediate certificate and install smallstep

Then install the smallstep package with step-ca binary and supporting files:

$ sudo dnf install smallstep

The package installs a skeleton config for a step-ca service in /var/lib/step-ca. Let’s flesh out the config as step-ca and generate an intermediate cert request (“csr”).

$ cd /var/lib/step-ca
$ sudo -u step-ca bash -l
$ ls
certs  config  db  secrets  templates
$ cp /etc/pki/CA/root_ca.crt certs
$ openssl req -new -keyout secrets/intermediate_ca.key -out intermediate_ca.csr
...
$ nano config/ca.json
$ exit

Again, openssl will ask for subject identifiers. I used the same as for the root CA, but with the common name ca.fedora. Use your favorite text editor; “nano” is beginner friendly. Change MYCABAL to FEDORA and ca.mycabal.org to ca.fedora. If you provided a password for intermediate_ca.key, put it in the “password” field of ca.json. Do not set the password in ca.json to the empty string. This will make step-ca try to prompt for it at startup – which is not allowed under systemd, and fails with an error opening /dev/tty. For the intermediate cert, the common name is important. Smallstep will auto generate a host cert for “ca.fedora” (it is, after all, a certificate authority), and it must match the hostname ACME clients use to sign certs. Now we need to sign the intermediate cert with the root CA. 1825 days is 5 years. Intermediate certs should be shorter lived than the root CA. Not too short, if you are manually resigning the certs.

$ cd /etc/pki/CA
$ sudo install --mode=644 /dev/stdin ca.fedora.ext << EOF
subjectAltName=DNS:ca.fedora
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
EOF
$ sudo openssl x509 -req -in /var/lib/step-ca/intermediate_ca.csr -CA root_ca.crt -CAkey private/root_ca.key -CAcreateserial -out intermediate_ca.crt -days 1825 -sha256 -extfile ca.fedora.ext
$ sudo -u step-ca cp intermediate_ca.crt /var/lib/step-ca/certs
$ sudo systemctl start step-ca
$ sudo systemctl status step-ca
...
Mar 31 15:18:56 test.gathman.org step-ca[2814912]: 2026/03/31 15:18:56 Serving HTTPS on :9000 ...

Use httpd to serve hello.fedora web page

Running a web server was a prerequisite. I’ll use apache as an example, and hopefully users of nginx and others can translate. First, /etc/httpd/conf.d/hello.conf

<VirtualHost *:80>
ServerName      hello.fedora
DocumentRoot    "/var/www/html/hello"
#RedirectMatch ^((?!\/\.well-known\/).*)$ https://hello.fedora$1
<Location "/.well-known/acme-challenge/">
        Options -Indexes
        Order allow,deny
        Allow from all
</Location>
   <Location "/">
        Options FollowSymLinks Indexes
        Require all granted
    </Location>
</VirtualHost>

The redirect is commented out until we have a signed cert. Assuming httpd is already running, use sudo apachectl graceful to load the changes. Then a simple document in /var/www/html/hello/index.html

<html>
	<head>
		<title> Hello Fedora </title>
	</head>
	<body>
		<h1> Hello Fedora! </h1>
	</body>
</html>

Use acme-tiny to sign a TLS cert with step-ca

Add private root CA

Acme-tiny needs to trust the root CA to use the ACME service. The step-ca service provides a handy API to fetch the root ca:

$ cd /etc/pki/ca-trust/source/anchors
$ sudo curl https://ca.fedora:9000/roots.pem -o fedora_ca.crt
curl: (60) SSL certificate problem: unable to get local issuer certificate

Ooops! Catch 22. You need the root CA to use the handy API that gets the root CA. So we’ll have to tell curl to accept the strange root cert. (Or use rsync, cp on the same machine, copy/paste between terminal windows, or other more secure method.)

$ sudo curl -k https://ca.fedora:9000/roots.pem -o fedora_ca.crt
$ sudo update-ca-trust extract

Now, we are ready to run acme-tiny. Once again, openssl req will prompt for subject identifiers. The only one browsers care about is Common Name, which should be “hello.fedora”. However, users may care about the other fields when they use browser features to inspect certs.

$ sudo dnf install acme-tiny
$ sudo apachectl graceful
$ cd /var/lib/acme
$ sudo -u acme bash -l
$ ls
certs  csr  private
$ /usr/libexec/acme-tiny/sign  # NOTE: generates account.key if needed
$ ls private
account.key
$ openssl req -new -passout pass:'' -keyout private/hello.key -out csr/hello.csr
$ /usr/sbin/acme_tiny --account-key private/account.key --csr csr/hello.csr --acme-dir /var/www/challenges/ --ca https://ca.fedora:9000/acme/FEDORA >certs/hello.crt
$ exit
$ sudo nano /etc/httpd/conf.d/hello.conf

Now uncomment the Redirect Match and append the below SSL virtual host definition to hello.conf. Use apachectl graceful to load the changes.

<VirtualHost *:443>
ServerName      hello.fedora:443
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA
DocumentRoot    "/var/www/html/hello"
SSLCertificateFile /var/lib/acme/certs/hello.crt
SSLCACertificateFile /var/lib/acme/certs/hello.crt
SSLCertificateKeyFile /var/lib/acme/private/hello.key
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
   <Location "/">
        Options FollowSymLinks Indexes
    </Location>
</VirtualHost>

The current acme-tiny package auto-renews certs only for the letsencrypt.org CA. That should be extended soon. Meanwhile, feel free to add something hacky. (I’ll try to have it lookup tlds in /etc/sysconfig or something to get custom CA url.)

Use a browser to display the web page

On the machine with your web browser, you need 2 things: the new root CA and some way to lookup names in the .FEDORA TLD, either by pointing DNS to the server you set up with the private zone, or by appending the lines to /etc/hosts for ca.fedora and hello.fedora.

Now the curl should work without -k. And your browser should work to display https://hello.fedora, although you might have to restart it. If it doesn’t read Fedora ca-trust store on startup, you might need to find an option to import CA on the browser menu.

$ curl https://hello.fedora
<html>
	<head>
		<title> Hello Fedora </title>
	</head>
	<body>
		<h1> Hello Fedora! </h1>
	</body>
</html>

Now, that your root CA is up and running, don’t lose sight of what can be done by having it go rogue. Get lots of people to install it so they can access your cool new TLDS. Then start forging certs for arbitrary web sites, and conquer the world!! Bwa! ha! ha! (A future article can address PKCS#11 and restricting how you trust CAs in browsers and other software.)

The Fedora CoreOS and QA teams are gearing up for Fedora 44, and we need your help! We are organizing a Test Week running from March 23 to March 27, 2026.

This event is a nice opportunity for the community to test Fedora CoreOS (FCOS) based on Fedora 44 content before it officially reaches the testing and stable streams. By participating, you help us ensure a smooth and reliable experience for all users.

How does a Test Week work?

A Test Week is an event where anyone can help verify that the upcoming release works as expected. If you’ve been looking for a way to get started with Fedora contribution, this is the perfect entry point.

To participate, you simply need to:

• Download the FCOS test images.
• Follow the step-by-step test cases provided.
• Report whether the tests passed or failed on your hardware or VM.

The Wiki Page is your primary source of information for this event. Once you have completed your tests, please log your results here! Your contribution, big or small, makes a huge difference. Let’s work together to make this release a great one. Happy testing!

Join the Live Sync Session

Want to chat with the team? We are hosting a virtual in-person session on Tuesday, March 24, from 3:00 PM – 4:30 PM UTC. Drop in to ask questions and get help with testing!

Video Meeting: meet.google.com/ufp-bwsb-zwh

We are happy to announce the general availability of Fedora Asahi Remix 43. This release brings Fedora Linux 43 to Apple Silicon Macs.

Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. This release incorporates all the exciting improvements brought by Fedora Linux 43. Notably, package management is significantly upgraded with RPM 6.0 and the new DNF5 backend for PackageKit for Plasma Discover and GNOME Software ahead of Fedora Linux 44. It also continues to provide extensive device support. This includes newly added support for the Mac Pro, microphones in M2 Pro/Max MacBooks, and 120Hz refresh rate for the built-in displays for MacBook Pro 14/16 models.

Fedora Asahi Remix offers KDE Plasma 6.6 as our flagship desktop experience. It contains all of the new and exciting features brought by Fedora KDE Plasma Desktop 43. It also features a custom Calamares-based initial setup wizard. A GNOME variant is also available, featuring GNOME 49, with both desktop variants matching what Fedora Linux offers. Fedora Asahi Remix also provides a Fedora Server variant for server workloads and other types of headless deployments. Finally, we offer a Minimal image for users that wish to build their own experience from the ground up.

You can install Fedora Asahi Remix today by following our installation guide. Existing systems running Fedora Asahi Remix 41 or 42 should be updated following the usual Fedora upgrade process. Upgrades via GNOME’s Software application are unfortunately not supported. Either KDE’s Plasma Discover or DNF’s System Upgrade command must be used.

Please report any Remix-specific issues in our tracker, or reach out in our Discourse forum or our Matrix room for user support.

Introduction

Writing a real-time audio plugin on Linux often conjures up images of a complex environment: C++, toolchains, CMake, CLAP / VST3 / LV2 SDK, ABI…

However, there is a much simpler approach : JSFX

This article offers a practical introduction to JSFX and YSFX on Fedora Linux: we’ll write some small examples, add a graphical VU meter, and then see how to use it as an CLAP / VST3 plugin in a native Linux workflow.

JSFX (JesuSonic Effects – created by REAPER [7]) allows you to write audio plugins in just a few lines, without compilation, with instant reloading and live editing.

Long associated with REAPER, they are now natively usable on Linux, thanks to YSFX [3], available on Fedora Linux in CLAP and VST3 formats via the Audinux repository ([4], [5]).

This means it’s possible to write a functional audio effect in ten lines, then immediately load it into Carla [8], Ardour [9], or any other compatible host, all within a PipeWire / JACK [11] environment.

A citation from [1] (check the [1] link for images):

In 2004, before we started developing REAPER, we created software designed for creating and modifying FX live, primarily for use with guitar processing.

The plan was that it could run on a minimal Linux distribution on dedicated hardware, for stage use. We built a couple of prototypes.

These hand-built prototypes used mini-ITX mainboards with either Via or Intel P-M CPUs, cheap consumer USB audio devices, and Atmel AVR microcontrollers via RS-232 for the footboard controls.

The cost for the parts used was around $600 each.

In the end, however, we concluded that we preferred to be in the software business, not the hardware business, and our research into adding multi-track capabilities in JSFX led us to develop REAPER. Since then, REAPER has integrated much of JSFX’s functionality, and improved on it.

So, as you can see, this technology is not that new. But the Linux support via YSFX [3] is rather new (Nov 2021, started by Jean-Pierre Cimalando).

A new programming language, but for what ? What would one would use JSFX for ?

This language is dedicated to audio and with it, you can write audio effects like an amplifier, a chorus, a delay, a compressor, or you can write synthesizers.

JSFX is good for rapid prototyping and, once everything is in place, you can then rewrite your project into a more efficient language like C, C++, or Rust.

JSFX for developers

Developing an audio plugin on Linux often involves a substantial technical environment. This complexity can be a hindrance when trying out an idea quickly.

JSFX (JesuSonic Effects) offers a different approach: writing audio effects in just a few lines of interpreted code, without compilation and with instant reloading.

Thanks to YSFX, available on Fedora Linux in CLAP and VST3 formats, these scripts can be used as true plugins within the Linux audio ecosystem.

This article will explore how to write a minimal amplifier in JSFX, add a graphical VU meter, and then load it into Carla as a CLAP / VST3 plugin.

The goal is simple: to demonstrate that it is possible to prototype real-time audio processing on Fedora Linux in just a few minutes.

No compilation environment is required: a text editor is all you need.

YSFX plugin

On Fedora Linux, YSFX comes in 3 flavours :

• a standalone executable ;
• a VST3 plugin ;
• a CLAP plugin.

YSFX is available in the Audinux [5] repository. So, first, install the Audinux repository:

$ dnf copr enable ycollet/audinux

Then, you can install the version you want:

$ dnf install ysfx
$ dnf install vst3-ysfx
$ dnf install clap-ysfx

Here is a screenshot of YSFX as a VST3 plugin loaded in Carla Rack [8]:

You can :

• Load a file ;
• Load a recent file ;
• Reload a file modified via the Edit menu ;
• Zoom / Unzoom via the 1.0 button ;
• Load presets ;
• Switch between the Graphics and Sliders view.

Here is a screenshot of the Edit window:

The  Variables  column displays all the variables defined by the loaded file.

Examples

We will use the JSFX documentation available at [4].

JSFX code is always divided into section.

• @init : The code in the @init section gets executed on effect load, on samplerate changes, and on start of playback.
• @slider : The code in the @slider section gets executed following an @init, or when a parameter (slider) changes
• @block : The code in the @block section is executed before processing each sample block. Typically a block is the length as defined by the audio hardware, or anywhere from 128-2048 samples.
• @sample : The code in the @sample section is executed for every PCM (Pulse Code Modulation) audio sample.
• @serialize : The code in the @serialize section is executed when the plug-in needs to load or save some extended state.
• @gfx [width] [height] : The @gfx section gets executed around 30 times a second when the plug-ins GUI is open.

A simple amplifier

In this example, we will use a slider value to amplify the audio input.

desc:Simple Amplifier
slider1:1<0,4,0.01>Gain

@init
gain = slider1;

@slider
gain = slider1;

@sample
spl0 *= gain;
spl1 *= gain;

slider1, @init, @slider, @sample, spl0, spl1 are JSFX keywords [1].

Description:

• slider1: create a user control (from 0 to 4 here);
• @init: section executed during loading;
• @slider: section executed when we move the slide;
• @sample: section executed for each audio sample;
• spl0 and spl1: left and right channels.
• In this example, we just multiply the input signal by a gain.

Here is a view of the result :

An amplifier with a gain in dB

This example will create a slider that will produce a gain in dB.

desc:Simple Amplifier (dB)
slider1:0<-60,24,0.1>Gain (dB)

@init
gain = 10^(slider1/20);

@slider
gain = 10^(slider1/20);

@sample
spl0 *= gain;
spl1 *= gain;

Only the way we compute the gain changes.

Here is a view of the result :

An amplifier with an anti-clipping protection

This example adds protection against clipping and uses a JSFX function for that.

desc:Simple Amplifier with Soft Clip
slider1:0<-60,24,0.1>Gain (dB)

@init
gain = 10^(slider1/20);

@slider
gain = 10^(slider1/20);
function softclip(x) (
  x / (1 + abs(x));
);

@sample
spl0 = softclip(spl0 * gain);
spl1 = softclip(spl1 * gain);

Here is a view of the result :

An amplifier with a VU meter

This example is the same as the one above, we just add a printed value of the gain.

desc:Simple Amplifier with VU Meter
slider1:0<-60,24,0.1>Gain (dB)

@init
rms = 0;
coeff = 0.999; // RMS smoothing
gain = 10^(slider1/20);

@slider
gain = 10^(slider1/20);

@sample
// Apply the gain
spl0 *= gain;
spl1 *= gain;
// Compute RMS (mean value of the 2 channels)
mono = 0.5*(spl0 + spl1);
rms = sqrt((coeff * rms * rms) + ((1 - coeff) * mono * mono));

@gfx 300 200 // UI part
gfx_r = 0.1; gfx_g = 0.1; gfx_b = 0.1;
gfx_rect(0, 0, gfx_w, gfx_h);

// Convert to dB
rms_db = 20*log(rms)/log(10);
rms_db < -60 ? rms_db = -60;

// Normalisation for the display
meter = (rms_db + 60) / 60;
meter > 1 ? meter = 1;

// Green color
gfx_r = 0;
gfx_g = 1;
gfx_b = 0;

// Horizontal bar
gfx_rect(10, gfx_h/2 - 10, meter*(gfx_w-20), 20);

// Text
gfx_r = gfx_g = gfx_b = 1;
gfx_x = 10;
gfx_y = gfx_h/2 + 20;
gfx_printf("Level: %.1f dB", rms_db);

The global structure of the code:

• Apply the gain
• Compute a smoothed RMS value
• Convert to dB
• Display a horizontal bar
• Display a numerical value

Here is a view of the result :

An amplifier using the UI lib from jsfx-ui-lib

In this example, we will use a JSFX UI library to produce a better representation of the amplifier’s elements.

First, clone the https://github.com/geraintluff/jsfx-ui-lib repository and copy the file ui-lib.jsfx-inc into the directory where your JSFX files are saved.

desc:Simple Amplifier with UI Lib VU
import ui-lib.jsfx-inc
slider1:0<-60,24,0.1>Gain (dB)

@init
freemem = ui_setup(0);
rms = 0;
coeff = 0.999;
gfx_rate = 30; // 30 FPS

@slider
gain = 10^(slider1/20);

@sample
spl0 *= gain;
spl1 *= gain;
mono = 0.5*(spl0 + spl1);
rms = sqrt(coeff*rms*rms + (1-coeff)*mono*mono);

// ---- RMS computation ----
level_db = 20*log(rms)/log(10);
level_db < -60 ? level_db = -60;

@gfx 300 200
ui_start("main");

// ---- Gain ----
control_start("main","default");
control_dial(slider1, 0, 1, 0);
cut = (level_db + 100) / 200 * (ui_right() - ui_left()) + ui_left();

// ---- VU ----
ui_split_bottom(50);
ui_color(0, 0, 0);
ui_text("RMS Level: ");
gfx_printf("%d", level_db);
ui_split_bottom(10);
uix_setgfxcolorrgba(0, 255, 0, 1);
gfx_rect(ui_left(), ui_top(), ui_right() - ui_left(), ui_bottom() - ui_top());
uix_setgfxcolorrgba(255, 0, 0, 1);
gfx_rect(ui_left(), ui_top(), cut, ui_bottom() - ui_top());
ui_pop();

The global structure of the example:

• Import and setup: The UI library is imported and then allocated memory (ui_setup) using @init;
• UI controls: control_dial creates a thematic potentiometer with a label, integrated into the library;
• Integrated VU meter: A small graph is drawn with ui_graph, normalizing the RMS value between 0 and 1;
• UI structure: ui_start(“main”) prepares the interface for each frame. ui_push_height / ui_pop organize the vertical space.

Here is a view of the result :

A simple synthesizer

Now, produce some sound and use MIDI for that.

The core of this example will be the ADSR envelope generator ([10]).

desc:Simple MIDI Synth (Mono Sine)
// Parameters
slider1:0.01<0.001,2,0.001>Attack (s)
slider2:0.2<0.001,2,0.001>Decay (s)
slider3:0.8<0,1,0.01>Sustain
slider4:0.5<0.001,3,0.001>Release (s)
slider5:0.5<0,1,0.01>Volume

@init
phase = 0;
note_on = 0;
env = 0;
state = 0; // 0=idle,1=attack,2=decay,3=sustain,4=release

@slider
// Compute the increment / decrement for each states
attack_inc = 1/(slider1*srate);
decay_dec = (1-slider3)/(slider2*srate);
release_dec = slider3/(slider4*srate);

@block
while (
  midirecv(offset, msg1, msg23) ? (
    status = msg1 & 240;
    note = msg23 & 127;
    vel = (msg23/256)|0;
    // Note On
    status == 144 && vel > 0 ? (
      freq = 440 * 2^((note-69)/12);
      phase_inc = 2*$pi*freq/srate;
      note_on = 1;
      state = 1;
    );
    // Note Off
    (status == 128) || (status == 144 && vel == 0) ? (
      state = 4;
    );
  );
);

@sample
// ADSR Envelope []
state == 1 ? ( // Attack
  env += attack_inc;
  env >= 1 ? (
    env = 1;
    state = 2;
  );
);

state == 2 ? ( // Decay
  env -= decay_dec;
  env <= slider3 ? (
    env = slider3;
    state = 3;
  );
);

state == 3 ? ( // Sustain
  env = slider3;
);

state == 4 ? ( // Release
  env -= release_dec;
  env <= 0 ? (
    env = 0;
    state = 0;
  );
);

// Sine oscillator
sample = sin(phase) * env * slider5;
phase += phase_inc;
phase > 2*$pi ? phase -= 2*$pi;

// Stereo output
spl0 = sample;
spl1 = sample;

Global structure of the example:

• Receives MIDI via @block;
• Converts MIDI note to frequency (A440 standard);
• Generates a sine wave;
• Applies an ADSR envelope;
• Outputs in stereo.

Here is a view of the result :

Comparison with CLAP / VST3

JSFX + YSFX

Advantages of JSFX:

• No compilation required;
• Instant reloading;
• Fast learning curve;
• Ideal for DSP prototyping;
• Portable between systems via YSFX.

Limitations:

• Less performant than native C++ for heavy processing;
• Less suitable for “industrial” distribution;
• Simpler API, therefore less low-level control.

CLAP / VST3 in C/C++

Advantages:

• Maximum performance;
• Fine-grained control over the architecture;
• Deep integration with the Linux audio ecosystem;
• Standardized distribution.

Limitations:

• Requires a complete toolchain;
• ABI management/compilation;
• Longer development cycle.

Conclusion

A functional audio effect can be written in just a few lines, adding a simple graphical interface, and then loaded this script as an CLAP / VST3 plugin on Fedora Linux. This requires no compilation, no complex SDK, no cumbersome toolchain.

JSFX scripts don’t replace native C++ development when it comes to producing optimized, widely distributable plugins. However, they offer an exceptional environment for experimentation, learning signal processing, and rapid prototyping.

Thanks to YSFX, JSFX scripts now integrate seamlessly into the Linux audio ecosystem, alongside Carla, Ardour, and a PipeWire-based audio system.

For developers and curious musicians alike, JSFX provides a simple and immediate entry point into creating real-time audio effects on Fedora Linux.

Available plugins

ysfx-chokehold

A free collection of JS (JesuSonic) plugins for Reaper.

Code available at: https://github.com/chkhld/jsfx

To install this set of YSFX plugins:

$ dnf install ysfx-chokehold

YSFX plugins will be available at /usr/share/ysfx-chokehold.

ysfx-geraintluff

Collection of JSFX effects.

Code available at: https://github.com/geraintluff/jsfx

To install this set of YSFX plugins:

$ dnf install ysfx-geraintluff

YSFX plugins will be available at /usr/share/ysfx-geraintluff.

ysfx-jesusonic

Some JSFX effects from Cockos.

Code available at: https://www.cockos.com/jsfx

To install this set of YSFX plugins:

$ dnf install ysfx-jesusonic

YSFX plugins will be available at /usr/share/ysfx-jesusonic.

ysfx-joepvanlier

A bundle of JSFX and scripts for reaper.

Code available at: https://github.com/JoepVanlier/JSFX

To install this set of YSFX plugins:

$ dnf install ysfx-joepvanlier

YSFX plugins will be available at /usr/share/ysfx-joepvanlier.

ysfx-lms

LMS Plugin Suite – Open source JSFX audio plugins

Code available at: https://github.com/LMSBAND/LMS

To install this set of YSFX plugins:

$ dnf install ysfx-lms

YSFX plugins will be available at /usr/share/ysfx-lms.

ysfx-reateam

Community-maintained collection of JS effects for REAPER

Code available at: https://github.com/ReaTeam/JSFX

To install this set of YSFX plugins:

$ dnf install ysfx-reateam

YSFX plugins will be available at /usr/share/ysfx-reateam.

ysfx-rejj

Reaper JSFX Plugins.

Code available at: https://github.com/Justin-Johnson/ReJJ

To install this set of YSFX plugins:

$ dnf install ysfx-rejj

And all the YSFX plugins will be available at /usr/share/ysfx-rejj.

ysfx-sonic-anomaly

Sonic Anomaly JSFX scripts for Reaper

Code available at: https://github.com/Sonic-Anomaly/Sonic-Anomaly-JSFX

To install this set of YSFX plugins:

$ dnf install ysfx-sonic-anomaly

YSFX plugins will be available at /usr/share/ysfx-sonic-anomaly.

ysfx-tilr

TiagoLR collection of JSFX effects

Code available at: https://github.com/tiagolr/tilr_jsfx

To install this set of YSFX plugins:

$ dnf install ysfx-tilr

YSFX plugins will be available at /usr/share/ysfx-tilr.

ysfx-tukan-studio

JSFX Plugins for Reaper

Code available at: https://github.com/TukanStudios/TUKAN_STUDIOS_PLUGINS

To install this set of YSFX plugins:

$ dnf install ysfx-tukan-studio

YSFX plugins will be available at /usr/share/ysfx-tukan-studio.

Webography

[1] – https://www.cockos.com/jsfx

[2] – https://github.com/geraintluff/jsfx

[3] – https://github.com/JoepVanlier/ysfx

[4] – https://www.reaper.fm/sdk/js/js.php

[5] – https://audinux.github.io

[6] – https://copr.fedorainfracloud.org/coprs/ycollet/audinux

[7] – https://www.reaper.fm/index.php

[8] – https://github.com/falkTX/Carla

[9] – https://ardour.org

[10] – https://en.wikipedia.org/wiki/Envelope_(music)

[11] – https://jackaudio.org

What are GNOME Shell extensions?

Imagine that Fedora Workstation is your desk, and GNOME Shell extensions are small accessories you add to make it feel more personal. It’s like placing a pencil case on the right side, a lamp that helps you focus, or a small cabinet to keep your things from getting scattered. It’s the same desk—GNOME stays clean and minimal—but a few additions can make your routine more comfortable.

Extensions work on the GNOME interface: the top panel, the way you open applications, how notifications appear, and small details that usually stay hidden. These simple changes can be enough to make your Fedora Workstation feel different. With just one extension, you can make Fedora feel more “you.”

But like any accessories, choose only what truly helps—don’t install everything. Too many extensions can clutter your desktop or make things feel unstable. The goal isn’t to chase excitement, but to find a few small add-ons that better fit the way you work in Fedora Workstation.

Note: The user will need to enable Flathub/Third Party Repos in order to get Extension Manager.

Why use Extension Manager?

Once you see extensions as small “accessories” for GNOME, a question comes up fast: how do you install them without the hassle? This is where Extension Manager helps.

Instead of opening many browser tabs, you can do everything in one place. You can browse extensions. You can search for what you need. You can also read a short description before installing. As a result, the whole process feels calmer and more familiar.

More importantly, Extension Manager makes it easier to experiment safely. For example, you can try one extension to make the top panel more useful. If it doesn’t feel right, you can simply turn it off. Or you can uninstall it in seconds. That way, you stay in control.

Also, you’re not “modding” your whole system. You’re only adding small features. And if you change your mind, you can always go back to GNOME’s clean default look.

In short, Extension Manager is like a small drawer on your desk. It keeps your extensions in one spot. So they’re easy to find, easy to try, and easy to tidy up again.

Install Extension Manager

Let’s move to the easiest part: installing Extension Manager with just a few clicks. Open the Software app on Fedora Workstation, then search for Extension Manager using the search bar. Select the app and click Install. That’s it.

Once the installation is complete, open it from the app menu—look for Extension Manager. Now you’re ready to customize. Start slowly: try one extension first, then see if it fits your daily routine.

Find and Install an Extension

After you open Extension Manager, it can feel like opening an “accessories shop” for your Fedora Workstation. There are many options, from small tweaks to extensions that can change how you work.

Start with the search bar. Think about what you most often need in your day-to-day routine. For example, you might want quicker access to apps, tray icons for indicators, or a more informative top panel. When you find an extension that looks interesting, open its page for a moment. Read the short description, look at the screenshots, and then ask yourself whether it will really help your work flow.

If you’re sure, just click Install. In a few seconds, it will be installed, and you’ll notice the change right away. However, if it doesn’t feel right, don’t hesitate to uninstall it. At this stage, you’re simply trying things out—like picking the accessories that best fit your desk.

Enable/disable and adjust settings

After you install a few extensions, you don’t have to stick with all of them. Sometimes an extension is useful, but you don’t need it all the time. That’s the nice thing about Extension Manager: you can enable or disable extensions at any time, without any drama.

Think of it like accessories on your desk. Some days you need a desk lamp to help you focus. On other days, you want your desk to stay clean and simple. Extensions work the same way. You can turn one on when you need it, and turn it off when you’re done.

If an extension has options, you’ll usually see a Settings or Preferences button. From there, you can tweak small details to match your style—icon placement, button behaviour, panel appearance, and more. This is what makes extensions feel personal. You’re not just installing something and forgetting it; you’re shaping it around your workflow.

And if one day your Fedora starts to feel too crowded, don’t panic. Just open the list of installed extensions and disable the ones you don’t need. Take it slow. The best customization isn’t about how many extensions you have, but how well they fit your daily activities.

Keep it safe: a few practical tips

At this point, you might start thinking, “Wow, there are so many things I can change.” And that’s true. However, if you want Fedora Workstation to stay light and comfortable, there are a few simple habits worth keeping in mind.

First, install extensions the same way you choose tools: only when you truly need them. If you stop using an extension after a few days, it’s better to disable it or remove it. A comfortable desktop isn’t the most crowded one—it’s the one with fewer distractions.

Second, try extensions one by one. If you install many at once, it’s hard to tell which one causes a problem. On the other hand, if you take it slowly, you can quickly feel what fits and what doesn’t.

Finally, remember that GNOME keeps evolving. Sometimes after a major update, an extension may not be ready yet. If something feels odd after an update, the safest move is simple: open Extension Manager and disable the extension you suspect. Once things are back to normal, you can wait for an update or choose an alternative.

In the end, Extension Manager isn’t a ticket to customize without limits. It’s more like a clean toolbox. If you use it with care and focus on what you really need, customization can stay enjoyable—without losing the clean, stable feel of Fedora Workstation.

Wrapping up: share your favorite extensions

Now you know how to customize your Fedora Workstation with Extension Manager. You’ve learned how to install the app, try a few extensions, and adjust their settings. And here’s the fun part: everyone ends up with a different mix of extensions, because we all have different needs and work styles.

If you have a favorite extension, share it. Which one do you rely on most, and what do you use it for? Maybe it helps you stay focused during presentations. Or maybe it makes the top panel more informative, brings back tray icons, or simply speeds up your work flow. Tell us why you like it, so others can picture the benefit.

Who knows—your list might inspire someone else. And you might also discover a new extension that fits your daily routine even better.

Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. This article provides the steps to rebase to the newly released Fedora Linux 44 Beta, and how to revert if anything unforeseen happens.

NOTE: Before attempting an upgrade to the Fedora Linux 44 Beta, apply any pending upgrades to your current system.

Updating using the terminal

Because Fedora Linux 44 Beta is not available in GNOME Software, the whole process must be done through a terminal.

First, check if the 44 branch is available, which should be true now:

$ ostree remote refs fedora

You should see the following line in the output:

fedora:fedora/44/x86_64/silverblue

If you want to pin the current deployment (this deployment will stay as an option in GRUB until you remove it), you can do it by running:

# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0

To remove the pinned deployment use the following command ( “2” corresponds to the entry position in the output from rpm-ostree status ):

$ sudo ostree admin pin --unpin 2

Next, rebase your system to the Fedora 44 branch.

$ rpm-ostree rebase fedora:fedora/44/x86_64/silverblue

The final thing to do is restart your computer and boot to Fedora Silverblue 44 Beta.

How to revert

If anything bad happens — for instance, if you can’t boot to Fedora Silverblue 44 Beta at all — it’s easy to go back. Pick the previous entry in the GRUB boot menu (you need to press ESC during boot sequence to see the GRUB menu in newer versions of Fedora Silverblue), and your system will start in its previous state. To make this change permanent, use the following command:

$ rpm-ostree rollback

That’s it. Now you know how to rebase to Fedora Silverblue 44 Beta and fall back. So why not do it today?

Known issues

• PAM Lastlog change crashing gdm

FAQ

Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.

Question: Can I skip versions during rebase of Fedora Linux? For example from Fedora Silverblue 42 to Fedora Silverblue 44?

Answer: Although it could be sometimes possible to skip versions during rebase, it is not recommended. You should always update to one version above (42->43 for example) to avoid unnecessary errors.

Question: I have rpm-fusion layered and I got errors during rebase. How should I do the rebase?

Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:

rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release

After doing this you can follow the guide in this article.

Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?

Yes, you can follow the Updating using the terminal part of this guide for every ostree edition of Fedora. Just use the corresponding branch. For example for Kinoite use fedora:fedora/44/x86_64/kinoite

On Tuesday, 10 March 2026, it is our pleasure to announce the availability of Fedora Linux 44 Beta! As with every beta release, this is your opportunity to contribute by testing out the upcoming Fedora Linux 44 Beta release. Testing the beta release is a vital way you can contribute to the Fedora Project. Your testing is invaluable feedback that helps us refine what the final F44 experience will be for all users.

We hope you enjoy this latest beta version of Fedora!

How to get the Fedora Linux 44 Beta release

You can download Fedora Linux 44 Beta, or our pre-release edition versions, from any of the following places:

• Fedora Workstation 44 Beta
• Fedora KDE Plasma Desktop 44 Beta
• Fedora Server 44 Beta
• Fedora IoT 44 Beta
• Fedora Cloud 44 Beta

The Fedora CoreOS “next” stream rebases to Fedora beta content on the same day as the beta release. To try out Fedora Linux 44-based CoreOS, try out the Fedora CoreOS “next” stream today.

You can also update an existing system to the beta using DNF system-upgrade.

The Fedora Linux 44 Beta release content may also be available for Fedora Spins and Labs.

Fedora Linux 44 Beta highlights

Like every Beta release, the Fedora Linux 44 Beta release is packed with changes. The following are highlights from the full set of changes for F44. They are ready for you to test drive in the Fedora Linux 44 Beta.

Installer and desktop Improvements

Goodbye Anaconda Created Default Network Profiles: This change impacts how Anaconda populates network device profiles. Only those devices configured during installation (by boot options, kickstart or interactively in UI) become part of the final system install. This behavior change addresses some long standing issues caused by populating network profiles for all network devices. These made it difficult to correctly reconfigure devices post-install.

Unified KDE Out of the Box Experience: This change introduces the post-install Plasma Setup application for all Fedora KDE variants. In the variants making use of this new setup application, the Anaconda configuration will be adjusted to disable redundant configuration stages that duplicate the functionality exposed in the setup application.

KDE Plasma Login Manager: This change introduced the Plasma Login Manager (PLM) for Fedora KDE variants instead of SDDM for the default login manager.

Reworked Games Lab: This change modernizes the Games Lab deliverable by leveraging the latest technologies. This offers a high quality gaming and game development experience. It includes a change from Xfce to KDE Plasma to take advantage of the latest and greatest Wayland stack for gaming.

Budgie 10.10: Budgie 10.10 is the latest release of Budgie Desktop. Budgie 10.10 migrates from X11 to Wayland. This ensures a viable long-term user experience for Fedora Budgie users and lays groundwork for the next major Budgie release.

LiveCD Improvements

Automatic DTB selection for aarch64 EFI systems: This change intends to make the aarch64 Fedora Live ISO images work out of the box on Windows on ARM (WoA) laptops. This will automatically select the right DTB at boot.

Modernize Live Media: This change modernizes the live media experience by switching to the “new” live environment setup scripts provided by livesys-scripts and leverage new functionality in dracut to enable support for automatically enabling persistent overlays when flashed to USB sticks.

System Enhancements

GNU Toolchain Update: The updates to the GNU Toolchain ensure Fedora stays current with the latest features, improvements, and bug and security fixes from the upstream gcc, glibc, binutils, and gdb projects. They guarantee a working system compiler, assembler, static and dynamic linker, core language runtimes, and debugger.

Reproducible Package Builds: Over the last few releases, we changed our build infrastructure to make package builds reproducible. This is enough to reach 90%. The remaining issues need to be fixed in individual packages. With this change, all package builds are expected to be reproducible in the F44 final release. Bugs will be filed against packages when an irreproducibility is detected. The goal is to have no fewer than 99% of package builds reproducible.

Packit as a dist-git CI: This change continues down the path of modernizing the Fedora CI experience by moving forward with the final phase of the plan to integrate Packit as the default CI for Fedora dist-git.

Remove Python Mock Usage: python-mock was deprecated with Fedora 34. However, it is still in use in many packages. We plan to go through the remaining usages and clean them up, with the goal of retiring python-mock from Fedora.

Adoption of new R Packaging Guidelines: This change introduces new rpm macros to help standardize and automate common R language packaging tasks resulting in a simplification of the rpm spec files.

Introduction of Nix Developer Tool: This change adds the nix package manager developer tool to Fedora.

Hardlink identical files in packages by default: With this change, all fedora packages will automatically hardlink files under /usr by default as a post install action. The mechanism introduced in this change is designed specifically to address reproducibility validation race conditions found in use by traditional hardlinking approaches.

Fedora Linux 44 Beta upgrades and removals

Golang 1.26: Fedora users will receive the most current and recent Go release. Being close to upstream allows us to avoid security issues and provide more updated features. Consequently, Fedora will provide a reliable development platform for the Go language and projects written in it.

MariaDB 11.8 as Distribution Default Version: The distribution default for MariaDB packaging will switch to 11.8. Multiple versions of the MariaDB packages will continue to be available. This change only impact which of the versioned packages presents itself as the unversioned “default”

IBus 1.5.34: Fedora users will benefit from better support of Wayland and Emoji features.

Django 6.x: Fedora Users can make use of the latest Django version; users who use Django add-ons that are not ready for 6.0 yet should be able to switch it out for python3-django5

TagLib 2: This change puts Fedora on the latest supported version, and it will benefit from improvements in future minor releases with a simple update.

Helm 4: Helm 4 has been released upstream with intentional backwards-incompatible changes relative to Helm 3. To ensure a smooth transition for Fedora, this Change introduces Helm 4 as the default helm package, while providing a parallel-installable helm3 package for users and tooling that still rely on Helm 3.

Ansible 13: Update from Ansible 11 and Ansible Core 2.18 to Ansible 13 and Ansible Core 2.20. This includes major robustness and security fixes to the templating engine which might break existing playbooks that had incorrect behavior. This was silently ignored in previous releases.

TeXLive 2025: With this change, we update to the latest version of TeXLive (2025). We also move to a modularized packaging system, which splits the “texlive” SPEC into a set of collection and scheme packages. This reflects the categorization that TeXLive upstream defines. Each collection package will package the immediate component dependencies as subpackages.

Drop QEMU 32-bit Host Builds: Fedora will stop building QEMU on i686 architecture. This change brings Fedora inline with the QEMU upstream project decision to deprecate support for 32-bit host builds. Upstream intends to start removing 32-bit host build support code in a future release and will assume 64-bit atomic ops in all builds.

Drop FUSE 2 libraries in Atomic Desktops: Remove FUSE 2 binaries and libraries from all Atomic Desktops

Drop compatibility for pkla polkit rules in Atomic Desktops: Remove support for deprecated pkla polkit rules from all Fedora Atomic Desktops

More information about Fedora Linux 44 Beta

Details and more information on the many great changes landing in Fedora Linux 44 are available on the Change Set page.

---

Editor’s Notes

1. Previously, it was noted that Fedora CoreOS “next” stream releases a week after the beta. This was a publishing error. The Fedora CoreOS “next” stream releases on the same day as the beta release. The article was edited to clarify this error.

Fedora is heading back to sunny Southern California! As we gear up for SCaLE 23x, we are thrilled to announce a special edition of Fedora Hatch. This is taking place on Friday, March 6 as an embedded track at SCALE.

Whether you’re a long-time contributor, a curious user, or someone looking to make your very first pull request, Fedora Hatch is designed for you. This is our way of bringing the experience of Flock (our annual contributor conference) to a local level. It focuses on connection, collaboration, and community growth.

What’s Happening?

This year, Fedora has secured a dedicated track on Friday at SCALE. We’ve curated a line-up that balances technical deep dives with essential community initiatives.

When: Friday, March 6, 2026

Where: Room 208, Pasadena Convention Center

Who: You! (And a bunch of friendly Fedorans)

The Schedule Highlights

We have a packed morning featuring five talks and a hands-on workshop:

• Getting Started in Open Source and Fedora (Amy Marrich): Are you new to the world of open source? Or are you looking to make your first contribution? This session will provide a guide for beginners interested in contributing to open source projects. It will focus on the Fedora project. We’ll cover a variety of topics, like finding suitable projects, making your first pull request, and navigating community interactions. Attendees will leave with practical tips, resources, and the confidence to embark on their open source journey.
• Fedora Docs Revamp Initiative (Shaun McCance): The Fedora Council recently approved an initiative to revamp the Fedora docs. The initiative aims to establish a support team to maintain a productive environment for writing docs. It will establish subteams with subject matter expertise to develop docs in specific areas of interest. We’ll describe some of the challenges the Fedora docs have faced, and present the progress so far in improving the docs. You’ll also learn how you can help Fedora have better docs.
• A Brief Tour of the Age of Atomic (Laura Santamaria): Ever wished to try a number of different desktop experiences quickly in your homelab? Maybe it’s time to explore Fedora Atomic or Universal Blue! The tour starts with what makes these experiences special. It will then review the options including Silverblue, Cosmic, Bluefin and Bazzite (yes, the gaming OS). We’ll briefly get under the hood to explore bootc, the technology powering Atomic. Finally, we’ll explore how you can contribute to the future of Fedora Atomic.
• Accelerating CentOS with Fedora (Davide Cavalca): This talk will explore how CentOS SIGs are able to leverage the work happening in Fedora to improve the quality and velocity of packages in CentOS Stream. We’ll cover how the CentOS Hyperscale SIG is able to deliver faster-moving updates for select packages, and how the CentOS Proposed Updates SIG integrates bugfixes and improves the contribution process to the distribution.
• Agentic Workloads on Linux: Btrfs + Service Accounts Architecture (David Duncan): As AI agents become more prevalent in enterprise environments, Linux systems need architectural patterns that provide isolation, security, and efficient resource management. This session explores an approach, using BTRFS subvolumes combined with dedicated service accounts, to build secure, isolated environments for autonomous AI agents in enterprise deployment.
• RPM Packaging Workshop (Carl George): While universal package formats like Flatpak, Snap, and AppImage have gained popularity for their cross-distro support, native system packages remain a cornerstone of Linux distributions. These native formats offer numerous benefits. Understanding them is essential for those who want to contribute to the Linux ecosystem at a deeper level. In this hands-on workshop, we’ll explore RPM, the native package format used by Fedora, CentOS, and RHEL. RPM is a powerful and flexible tool. It plays a vital role in the management and distribution of software for these operating systems.

Don’t forget to swing by the Fedora Booth in the Expo Hall! Our team will be there all weekend (March 6–8) with live demonstrations of Fedora Linux 43, GNOME 49 improvements, and plenty of fresh swag to go around.

Registration Details

To join us at the Hatch, you’ll need a SCaLE 23x pass.

• Location: Pasadena Convention Center, 300 E Green St, Pasadena, CA.
• Tickets: Available at the official SCaLE website.

We can’t wait to see you there. Let’s make SCaLE 23x the best one yet!

The Podman team and the Fedora Quality Assurance team are organizing a Test Week from Friday, February 27 through Friday, March 6, 2026. This is your chance to get an early look at the latest improvements coming to Podman and see how they perform on your machine.

What is Podman?

For those new to the tool, Podman is a daemonless, Linux-native engine for running, building, and sharing OCI containers. It offers a familiar command-line experience but runs containers safely without requiring a root daemon.

What’s Coming in Podman 5.8?

The upcoming release includes updates designed to make Podman faster and more robust. Here is what you can look forward to, and what you can try out during this Fedora Test Day.

A Modern Database Backend (SQLite)

Podman is upgrading its internal storage logic by transitioning to SQLite. This change modernizes how Podman handles data under the hood, aiming for better stability and long-term robustness.

Faster Parallel Pulls

This release brings optimizations to how Podman downloads image layers, specifically when pulling multiple images at the same time. For a deep dive into the engineering behind this, check out the developer blog post on Accelerating Parallel Layer Creation.

Experiment and Explore: Feel free to push the system a bit and try pulling several large images simultaneously to see if you notice the performance boost. Beyond that, please bring your own workflows. Don’t just follow the wiki instructions. Run the containers and commands you use daily. Your specific use cases are the best way to uncover edge cases that standard tests might miss.

What do I need to do?

• Make sure you have a Fedora Account (FAS).
• Download test materials in advance where applicable, which may include some large files.
• Follow the steps on the wiki test page one by one.
• Send us your results through the app.

Details on how to test and report results are available at the Wiki Test Day site for Podman 5.8 test day:
https://fedoraproject.org/wiki/Test_Day:2026-02-27_Podman_5.8

Test Week runs from Friday, February 27 through Friday, March 6, 2026

Thank you for taking part in the testing of Fedora Linux 44!

Mrhbaan, Fedora community! I am happy to share that as of 10 February 2026, Fedora is now available in Syria. Last week, the Fedora Infrastructure Team lifted the IP range block on IP addresses in Syria. This action restores download access to Fedora Linux deliverables, such as ISOs. It also restores access from Syria to Fedora Linux RPM repositories, the Fedora Account System, and Fedora build systems. Users can now access the various applications and services that make up the Fedora Project. This change follows a recent update to the Fedora Export Control Policy. Today, anyone connecting to the public Internet from Syria should once again be able to access Fedora.

This article explains why this is happening now. It also covers the work behind the scenes to make this change happen.

Why Syria, why now?

You might wonder: what happened? Why is this happening now? I cannot answer everything in this post. However, the story begins in December 2024 with the fall of the Assad regime in Syria. A new government took control of the country. This began a new era of foreign policy in Syrian international relations.

Fast-forward to 18 December 2025. The United States signed the National Defense Authorization Act for Fiscal Year 2026 into law. This law repealed the 2019 Caesar Act sanctions. This action removed Syria from the list of OFAC embargoed countries. The U.S. Department of the Treasury maintains this list.

This may seem like a small change. Yet, it is significant for Syrians. Some U.S. Commerce Department regulations remain in place. However, the U.S. Department of the Treasury’s policy change now allows open source software availability in Syria. The Fedora Project updated its stance to welcome Syrians back into the Fedora community. This matches actions taken by other major platforms for open source software, such as Microsoft’s GitHub.

Syria & Fedora, behind the scenes

Opening the firewall to Syria took seconds. However, months of conversations and hidden work occurred behind the scenes to make this happen. The story begins with a ticket. Zaid Ballour (@devzaid) opened Ticket #541 to the Fedora Council on 1 September 2025. This escalated the issue to the Fedora Council. It prompted a closer look at the changing political situation in Syria.

Jef Spaleta and I dug deeper into the issue. We wanted to understand the overall context. The United States repealed the 2019 Caesar Act sanctions in December 2025. This indicated that the Fedora Export Policy Control might be outdated.

During this time, Jef and I spoke with legal experts at Red Hat and IBM. We reviewed the situation in Syria. This review process took time. We had to ensure compliance with all United States federal laws and sanctions. The situation for Fedora differs from other open source communities. Much of our development happens within infrastructure that we control. Additionally, Linux serves as digital infrastructure. This context differs from a random open source library on GitHub.

However, the path forward became clear after the repeal of the 2019 Caesar Act. After several months, we received approval. Fedora is accessible to Syrians once again.

Opening the door to Syria

Some folks may have noticed the Fedora Infrastructure ticket last week. It requested the removal of the firewall block. We also submitted a Fedora Legal Docs Merge Request to change the Fedora Export Control Policy.

We wanted to share this exciting announcement now. It aligns with our commitment to the Fedora Project vision:

“The Fedora Project envisions a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities.“

We look forward to welcoming Syrians back into the Fedora community and the wider open source community at large. Mrhbaan!