13 Mar 2026
Fedora People
Fedora Magazine: JSFX on Fedora Linux: an ultra-fast audio prototyping engine

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 [10]
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
13 Mar 2026 8:00am GMT
Remi Collet: ⚙️ PHP version 8.4.19 and 8.5.4
RPMs of PHP version 8.5.4 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.4.19 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
ℹ️ These versions are also available as Software Collections in the remi-safe repository.
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ There is no security fix this month, so no update for versions 8.2.30 and 8.3.30.
Version announcements:
ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.
Replacement of default PHP by version 8.5 installation (simplest):
On Enterprise Linux (dnf 4)
dnf module switch-to php:remi-8.5/common
On Fedora (dnf 5)
dnf module reset php dnf module enable php:remi-8.5 dnf update
Parallel installation of version 8.5 as Software Collection
yum install php85
Replacement of default PHP by version 8.4 installation (simplest):
On Enterprise Linux (dnf 4)
dnf module switch-to php:remi-8.4/common
On Fedora (dnf 5)
dnf module reset php dnf module enable php:remi-8.4 dnf update
Parallel installation of version 8.4 as Software Collection
yum install php84
And soon in the official updates:
- Fedora Rawhide now has PHP version 8.5.4
- Fedora 44 - PHP 8.5.4
- Fedora 43 - PHP 8.4.19
- Fedora 42 - PHP 8.4.19
⚠️ To be noticed :
- EL-10 RPMs are built using RHEL-10.1
- EL-9 RPMs are built using RHEL-9.7
- EL-8 RPMs are built using RHEL-8.10
- intl extension now uses libicu74 (version 74.2)
- mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
- oci8 extension now uses the RPM of Oracle Instant Client version 23.26 on x86_64 and aarch64
- A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page
ℹ️ Information:
- Migrating from PHP 8.2.x to PHP 8.3.x
- Migrating from PHP 8.3.x to PHP 8.4.x
- Migrating from PHP 8.4.x to PHP 8.5.x
Base packages (php)
Software Collections (php83 / php84 / php85)
13 Mar 2026 5:32am GMT
Fedora Magazine: Customize Fedora Linux Workstation with Extension Manager

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.
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.
13 Mar 2026 12:25am GMT
12 Mar 2026
Fedora People
Christof Damian: Friday Links 26-09
12 Mar 2026 11:00pm GMT
11 Mar 2026
Fedora People
Peter Czanik: The syslog-ng Insider 2026-03: 4.11.0 release; OpenSearch; ElasticSearch
11 Mar 2026 12:01pm GMT
10 Mar 2026
Fedora People
Fedora Magazine: How to rebase to Fedora Silverblue 44 Beta

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
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
10 Mar 2026 7:29pm GMT
Marcin Juszkiewicz: RISC-V is sloooow
About 3 months ago I started working with RISC-V port of Fedora Linux. Many things happened during that time.
Triaging
I went through the Fedora RISC-V tracker entries, triaged most of them (at the moment 17 entries left in NEW) and tried to handle whatever possible.
Fedora packaging
My usual way of working involves fetching sources of a Fedora package (fedpkg clone -a) and then building it (fedpkg mockbuild -r fedora-43-riscv64). After some time, I check did it built and if not then I go through build logs to find out why.
Effect? At the moment, 86 pull requests sent for Fedora packages. From heavy packages like the "llvm15" to simple ones like the "iyfct" (some simple game). At the moment most of them were merged, and most of these got built for the Fedora 43. Then we can build them as well as we follow 'f43-updates' tag on the Fedora koji.
Slowness
Work on packages brings the hard, sometimes controversial, topic: speed. Or rather lack of it.
You see, the RISC-V hardware at the moment is slow. Which results in terrible build times - look at details of the binutils 2.45.1-4.fc43 package I took from koji (Fedora and RISC-V Fedora):
| Architecture | Cores | Memory | Build time |
|---|---|---|---|
| aarch64 | 12 | 46 GB | 36 minutes |
| i686 | 8 | 29 GB | 25 minutes |
| ppc64le | 10 | 37 GB | 46 minutes |
| riscv64 | 8 | 16 GB | 143 minutes |
| s390x | 3 | 45 GB | 37 minutes |
| x86_64 | 8 | 29 GB | 29 minutes |
That was StarFive VisionFive 2 board, while it has other strengths (such as upstreamed drivers), it is not the fastest available one. I asked around and one of porters did a built on Milk-V Megrez - it took 58 minutes.
Also worth mentioning is that the current build of RISC-V Fedora port is done with disabled LTO. To cut on memory usage and build times.
RISC-V builders have four or eight cores with 8, 16 or 32 GB of RAM (depending on a board). And those cores are usually compared to Arm Cortex-A55 ones. The lowest cpu cores in today's Arm chips.
The UltraRISC UR-DP1000 SoC, present on the Milk-V Titan motherboard should improve situation a bit (and can have 64 GB ram). Similar with SpacemiT K3-based systems (but only 32 GB ram). Both will be an improvement, but not the final solution.
Hardware needs for Fedora inclusion
We need hardware capable of building above "binutils" package below one hour. With LTO enabled system-wide etc. to be on par with the other architectures. This is the speed-related requirement.
There is no point of going for inclusion with slow builders as this will make package maintainers complain. You see, in Fedora build results are released into repositories only when all architectures finish. And we had maintainers complaining about lack of speed of AArch64 builders in the past. Some developers may start excluding RISC-V architecture from their packages to not have to wait.
And any future builders need to be rackable and manageable like any other boring server (put in a rack, connect cables, install, do not touch any more). Because no one will go into a data centre to manually reboot an SBC-based builder.
Without systems fulfilling both requirements, we can not even plan for the RISC-V 64-bit architecture to became one of official, primary architectures in Fedora Linux.
I still use QEMU for local testing
Such long build times make my use of QEMU useful. My AArch64 desktop has 80 cores, so with the use of QEMU userspace riscv64 emulation, I can build the "llvm15" package in about 4 hours. Compare that to 10.5 hours on a Banana Pi BPI-F3 builder (it may be quicker on a P550 one).
And LLVM packages make real use of both available cores and memory. I am wondering how fast would it go on 192/384 cores of Ampere One-based system.
Still, I used QEMU for local builds/testing only. Fedora, like several other distributions, does native builds only.
Future plans
We plan to start building Fedora Linux 44. If things go well, we will use the same kernel image on all of our builders (the current ones use a mix of kernel versions). LTO will still be disabled.
When it comes to lack of speed… There are plans to bring new, faster builders. And probably assign some heavier packages to them.
10 Mar 2026 5:53pm GMT
Tim Waugh: Searching Logseq by Concept, Not Keystrokes
Logseq is great for dumping daily notes, but finding them again later can be a pain. If you're looking for notes on a "connection timeout" but originally wrote "increasing the socket keepalive", a standard keyword search will give you nothing. You end up having to guess the exact phrasing your past self used.
I wanted a way to search my graph by concept rather than exact text matches. That's why I put together the Logseq Semantic Search plugin.
The upcoming database version of Logseq actually has semantic search built-in. But since I'm still using the standard Markdown version for my day-to-day workflow, I wanted to get that capability right now.
Indexing the hierarchy
The plugin uses text embeddings to find conceptually similar blocks. But just embedding individual bullet points doesn't work well for outliners. A block that just says "needs refactoring" is useless on its own.
If you've seen my Logsqueak project, you'll recognise the indexing approach here. Every block is indexed along with its complete structural lineage-the page name, properties, and the full chain of parent blocks above it.
Because it captures this nested context, the search index knows that a vague bullet point nested under billing-service → Database Connection Pool is actually about your Postgres setup. Searching for "optimizing billing db" will pull that specific child block right to the top of the results.
Running it locally
Since a Logseq graph is essentially a private brain dump, I wanted this to run entirely locally. By default, the plugin connects to Ollama using the lightweight nomic-embed-text model. It's smart enough to only re-embed blocks that have changed, so it's relatively fast even without a GPU. (If you prefer, you can also point it at any OpenAI-compatible endpoint in the settings).
I run Fedora Workstation and prefer to keep my host system clean, so I run Ollama via Podman. It's incredibly straightforward to set up:
# Start the Ollama container, exposing the default port and persisting data
podman run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama docker.io/ollama/ollama
# Pull the lightweight embedding model
podman exec -it ollama ollama pull nomic-embed-text
Because we mapped port 11434, the Semantic Search plugin can talk to the container seamlessly at http://localhost:11434 right out of the box. No dependency issues, just a private embedding server ready to run in the background.
Usage
You can grab the plugin directly from the Logseq Marketplace. Once it's installed, hit Alt+K (or click the toolbar icon) to open the search modal. Try typing a natural language query-like "notes about debugging pipeline failures"-and it will surface the relevant blocks even if you didn't use the word "debugging."
The source code is up on GitHub if you want to poke around or contribute.
The post Searching Logseq by Concept, Not Keystrokes appeared first on PRINT HEAD.
10 Mar 2026 1:46pm GMT
Peter Czanik: New toy: Installing FreeBSD on the HP Z2 Mini
10 Mar 2026 12:13pm GMT
Fedora Magazine: Announcing Fedora Linux 44 Beta

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
- 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.
10 Mar 2026 8:00am GMT
09 Mar 2026
Fedora People
Kushal Das: In the land of XML
09 Mar 2026 7:22am GMT
Miroslav Vadkerti: Silencing Alerts During OpenShift Cluster Upgrades with Prometheus and Alertmanager
09 Mar 2026 12:00am GMT
08 Mar 2026
Fedora People
Ben Cotton: You’d better start believing in supply chains because you’re in one (SCaLE 23x)
At SCaLE 23x, I debuted "You'd better start believing in supply chains because you're in one." This is my first talk that started as a silly joke, but it covers a serious and timely topic.

Abstract: "I'm not a supplier!" open source maintainers correctly say. When a large company comes in making unfunded demands, it drives volunteer maintainers away. But supply chain attacks are a reality and they don't just affect megacorps. As an open source maintainer, you have a supply chain, too.
Improving your security improves safety for everyone. But how can volunteer maintainers who aren't security experts do this work? This talk introduces easy practices and tools to address common software supply chain concerns. Attendees will also learn how to address supply chain and regulatory concerns from their downstreams.
Date: 8 March 2026
Location: Pasadena, CA, US
Resources
Looking for links to the tools I mentioned in the talk, perhaps because you're sitting in the audience right now?
- 2020 State of the Octoverse Report
- Best Practices Badge
- Cyber Resilience Act
- Dependabot
- Docker Scout
- Food, Drug, & Cosmetics Act § 524B
- GitHub Immutable Releases
- GUAC
- Kusari Inspector
- LFX Insights
- Minder
- npm audit
- OMB Memorandum M-26-05
- OpenSSF Scorecard
- OSPS Baseline
- OWASP Dependency-Check
- Trusted Publishers
- Zizmor
The post You'd better start believing in supply chains because you're in one (SCaLE 23x) appeared first on Duck Alignment Academy.
08 Mar 2026 7:53pm GMT
07 Mar 2026
Fedora People
Kevin Fenzi: misc fedora bits first week of march 2026
Here we are in the first week of March 2026 already. This was a pretty quiet week for me, partly due to the Fedora 44 Beta freeze and partly I think due to people traveling/being away. In any case it was welcome to me to have a chance to work on some planned work instead of day to day or fighting fires.
GPU machine
This week I finally got our gpu machine all setup, which has been a very long road. Last year we thought it would be very handy to have a machine that has desktop GPUs in it that we could use to test / build / explore things that could use those. We didn't want a server with fancy datacenter gpus, we wanted things that Fedora users might have. This of course is tricky, since that entails a desktop like machine in a datacenter.
After some looking around, we found the Dell Precision 7960 Rack, which is a rackmount machine, but sort of a desktop too.
We got a loaner to test things out with, and finally decided to buy it and use it. There have been so many little delays with this thing ( wrong network card, need a new one. Time of people involved to setup the testing. Drac license was wrong and I couldn't install it, and more).
But finally this week it's up. We will see how useful it becomes and what new exciting things it opens up.
Fedora 44 Beta is GO for release next tuesday
We had our Fedora 44 Beta go/nogo meeting on thursday and amazinly we were go for release on tuesday. The second beta candidate had no accepted blockers. I'm always a bit surprised when things go so smoothly, but I will take it!
Secure boot signing
I also made some more progress on my secure boot signing setup, but then i hit a blocker. I was able to sign grub and kernel for aarch64, but it doesn't actually boot. (I have my lenovo slim7x and also another aarch64 box that supports secure boot to test with). Hopefully we can get to the bottom of that soon so we can switch things on. I really hope we can have it running before Fedora 44 final freeze.
This also has been a long road.
Just missed it
I'm getting a solar system with batteries and home backup installed late this month, and I'm really looking forward to it.
Unfortunately, my electic coop just informed me that there is going to be a 4 hour power outage on monday for maint work. If it had only been next month, I could have just ignored it. Oh well, one more time for the generator! :)
comments? additions? reactions?
As always, comment on mastodon: https://fosstodon.org/@nirik/116189196834124254
07 Mar 2026 5:27pm GMT
Avi Alkalay: Ideal Laptop
Do you remember the most important characteristics you should look for in a good laptop? In the following order:
1⃣ A high-resolution, high-density display: 3K or 4K, far beyond HD or Full HD
2⃣ A battery that lasts all day
3⃣ Fast storage (SSD)
4⃣ Light, thin, and elegant
It's not the CPU.
It's not AI.
It's not having huge storage capacity.
It's not a large physical size.
It's not having more than 8 GB of memory (memory is not storage).
It's not having a stylus, tablet convertible, or having a detachable or articulated keyboard.
And it's definitely not having a numeric keypad on the side.
Until last week, the best and most affordable laptop on the market with these characteristics was the $1100 MacBook Air. But now Apple has launched the MacBook Neo, which delivers all these qualities - display, battery, storage, lightness, and elegance for 45% less: $600.
❝A laptop for me is just for browsing the internet, email, editing documents, messaging, watching movies, and relaxing with games like Solitaire or Roblox.❞
Congratulations, you're like 99.9% of humanity. The MacBook Neo delivers the best value for you.
In the Windows laptop universe, these truly important characteristics (display quality, lightness, etc.) are usually found only in the most expensive product lines. To justify the high price, their marketing shifts the focus to things that are largely irrelevant: unnecessarily powerful CPUs, unnecessarily large storage, unnecessarily large memory, tablet modes, styluses, and so on.
All unnecessary for 99.9% of humanity.
And even in those expensive lines, the battery rarely lasts more than two hours, let alone all day. The reason: inefficient CPU.
Don't be misled when choosing your next laptop. Pay attention to the characteristics that really matter: hires display, battery duration, fast storage, lightness, and elegance. General rule is to avoid laptops that use Intel CPUs.
This also applies to the laptops that companies give to their employees.
Also in my Instagram, Facebook and LinkedIn.
07 Mar 2026 8:15am GMT
Avi Alkalay: Laptop ideal
Lembra quais são as características mais importantes que você deve procurar num bom laptop? 1⃣ tela de alta resolução e densidade, 3K ou 4K, bem mais que HD ou full HD; 2⃣ bateria que dura o dia todo; 3⃣ armazenamento rápido (SSD); 4⃣ leve, fino e elegante.
Não é CPU.
Não é IA.
Não é armazenamento grande.
Não é ter tamanho físico grande.
Não é ter mais do que 8GB de memória (memória não é armazenamento).
Não é ter caneta, virar tablet, teclado removível ou articulado.
E definitivamente não é ter teclado numérico lateral.
Até semana passada, o melhor e mais barato laptop do mercado com essas características era o MacBook Air de $1100. Mas agora a Apple lançou o MacBook Neo que entrega todas essas características de tela, bateria, armazenamento, leveza e elegância, 45% mais barato: $600.
❝Laptop prá mim é só prá navegar na internet, e-mail, editar documentos, mandar mensagem, assistir filmes, me distrair jogando paciência e Roblox❞. Parabéns, você é como 99,9% da humanidade. O MacBook Neo entrega o melhor custo-benefício para você.
No universo dos laptops Windows, essas características importantes (tela, leveza etc), só se encontram nas linhas mais caras dos fabricantes. E para justificar o alto preço, seu marketing procura mudar o foco para coisas completamente irrelevantes, como CPU desnecessariamente poderosa, armazenamento desnecessariamente alto, memória desnecessariamente grande, virar tablet, ter caneta etc. Desnecessário para 99,9% da humanidade. E mesmo assim, nem nessas linhas mais caras a bateria dura mais do que 2 horas (motivo: CPU ineficiente), quanto menos o dia todo.
Não seja ludibriado ao escolher seu próximo laptop. Preste atenção nas características que realmente importam: tela, bateria, armazenamento rápido, leveza e elegância. A regra geral é evitar laptops com CPUs Intel.
Isso vale também para laptops que empresas dão a seus funcionários.
Também no meu Instagram, Facebook e LinkedIn.
07 Mar 2026 7:56am GMT