Hello everyone! Current Fedora Project Leader Matthew Miller here, with some exciting news!
A little while ago, I announced that it’s time for a change of hats. I’m going to be moving on to new things (still close to Fedora, of course). Today, I’m happy to announce that we’ve selected my successor: long-time Fedora friend Jef Spaleta.
Some of you may remember Jef’s passionate voice in the early Fedora community. He got involved all the way back in the days of fedora.us, before Red Hat got involved. Jef served on the Fedora Board from July 2007 through the end of 2008. This was the critical time after Fedora Extras and Fedora Core merged into one Fedora Linux where, with the launch of the “Features” process, Fedora became a truly community-led project.
Of course, things have changed a little around here since then. The Council replaced the Board, the Features process has changed (to “Changes“, of course), and … a few other things. Jef has been busy with various day jobs, but has always kept up with Fedora. I’m glad we’re now able to let him give his full attention to the next years of Fedora success.
Jef starts full-time at Red Hat in May. Then, after a few weeks for orientation, I’ll officially pass the torch at Flock in the beginning of June. Please join me in welcoming him back into the thick of things in Fedora-land in the Fedora Discussion thread for this post.
Speaking of Flock (our annual contributor conference)… we’re getting the final schedule lined up! We have an excellent slate of talks and speakers. Perhaps even more importantly, we have some of the best Fedora swag ever made. If you can, join us from June 5–8. Find more information, including registration links, on the Flock website. Prague is a great city, and particularly lovely in June, so if you’ve been looking for an excuse to visit, this is it!
Oh, and one more thing… if you’re really into curling, Jef will be very happy to talk to you about it!
This article is a tutorial on using UV to enhance or improve your Python work flow.
If you work with Python you most likely have used one or all of the following tools:
Pip to install packages or pipx to install them on virtual environments.
Anaconda to install packages, custom Python versions and manage dependencies
Poetry (and pipx), to manage your Python project and packaging.
Why do you need another tool to manage your Python packaging or install your favorite Python tools? For me, using uv was a decision based on the following features:
Simplicity: uv can handle all the tasks for packaging or installing tools with a very easy-to-use CLI.
Improved dependency management: When there are conflicts, the tool does a great job explaining what went wrong.
Speed: If you ever used Anaconda to install multiple dependencies like PyTorch, Ansible, Pandas, etc. you will appreciate how fast uv can do this.
Easy to install: No third-party dependencies to install, comes with batteries included (this is demonstrated in the next section).
Documentation: Yes, the online documentation is easy to follow and clear. No need to have a master degree in the occult to learn how to use the tool.
Now let’s be clear from the beginning, there is no one-size-fits-all tool that fixes all the issues with Python workflows. Here, I will try to show you why it may make sense for you to try uv and switch.
You will need a few things to follow this tutorial:
A Linux installation: I use Fedora but any other distribution will work pretty much the same.
An Internet connection, to download uv from their website.
Be familiar with pip and virtual environments: This is optional but it helps if you have installed a Python package before.
Python programming experience: We will not code much here, but knowing about Python modules and how to package a project using pyproject.toml with frameworks like setuptools will make it easier to follow.
Optionally, elevated privileges (SUDO), if you want to install binaries system-wide (like RPMS).
Let’s start by installing uv, if you haven’t done so already.
Installing UV
If you have a Linux installation you can install uv like this:
# The installer has options and an unattended installation mode, won't cover that here
curl -LsSf https://astral.sh/uv/install.sh | sh
Using an RPM? Fedora lists several packages since version 40. So there you can do something like this:
# Fedora RPM is slightly behind the latest version but it does the job
sudo dnf install -y uv
Or make yourself an RPM using the statically compiled binaries from Astral and a little help from Podman and fpm:
josevnz@dmaf5 docs]$ podman run --mount type=bind,src=$HOME/tmp,target=/mnt/result --rm --privileged --interactive --tty fedora:37 bash
[root@a9e9dc561788 /]# gem install --user-install fpm
...
[root@a9e9dc561788 /]# curl --location --fail --remote-name https://github.com/astral-sh/uv/releases/download/0.6.9/uv-x86_64-unknown-linux-gnu.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 15.8M 100 15.8M 0 0 8871k 0 0:00:01 0:00:01 --:--:-- 11.1M
[root@a9e9dc561788 /]# fpm -t rpm -s tar --name uv --rpm-autoreq --rpm-os linux --rpm-summary 'An extremely fast Python package and project manager, written in Rust.' --license 'Apache 2.0' --version v0.6.9 --depends bash --maintainer 'Jose Vicente Nunez <kodegeek.com@protonmail.com>' --url https://github.com/astral-sh/uv uv-x86_64-unknown-linux-gnu.tar.gz
Created package {:path=>"uv-v0.6.9-1.x86_64.rpm"}
mv uv-v0.6.9-1.x86_64.rpm /mnt/result/
# exit the container
exit
You can then install it on /usr/local, using --prefix:
sudo -i
[root@a9e9dc561788 /]# rpm --force --prefix /usr/local -ihv /mnt/result/uv-v0.6.9-1.x86_64.rpm
Verifying... ################################# [100%]
Preparing... ################################# [100%]
Updating / installing...
1:uv-v0.6.9-1 ################################# [100%]
[root@a9e9dc561788 /]# rpm -qil uv-v0.6.9-1
Name : uv
Version : v0.6.9
Release : 1
Architecture: x86_64
Install Date: Sat Mar 22 23:32:49 2025
Group : default
Size : 40524181
License : Apache 2.0
Signature : (none)
Source RPM : uv-v0.6.9-1.src.rpm
Build Date : Sat Mar 22 23:28:48 2025
Build Host : a9e9dc561788
Relocations : /
Packager : Jose Vicente Nunez <kodegeek.com@protonmail.com>
Vendor : none
URL : https://github.com/astral-sh/uv
Summary : An extremely fast Python package and project manager, written in Rust.
Description :
no description given
/usr/local/usr/lib/.build-id
/usr/local/usr/lib/.build-id/a1
/usr/local/usr/lib/.build-id/a1/8ee308344b9bd07a1e3bb79a26cbb47ca1b8e0
/usr/local/usr/lib/.build-id/e9
/usr/local/usr/lib/.build-id/e9/4f273a318a0946893ee81326603b746f4ffee1
/usr/local/uv-x86_64-unknown-linux-gnu/uv
/usr/local/uv-x86_64-unknown-linux-gnu/uvx
Again, you have several choices.
Now it is time to move to the next section and see what uv can do to make Python workflows faster.
Using UV to run everyday tools like Ansible, Glances, Autopep8
One of the best things about uv is that you can download and install tools on your account with less typing.
One of my favorite monitoring tools, glances, can be installed with pip on the user account:
pip install --user glances
glances
But that will pollute my Python user installation with glances dependencies. So the best next thing is to isolate it on a virtual environment:
You can see now where this is going. Instead, I could do the following with uv:
uv tool run glances
That is a single line to run and install glances. This creates a temporary environment which can be discarded once we’re done with the tool.
Let me show you the equivalent command, it is called uvx:
uvx --from glances glances
If the command and the distribution match then we can skip explicitly where it comes ‘–from’:
uvx glances
Less typing, uv created a virtual environment for me and downloaded glances there. Now say that I want to use a different Python, version3.12, to run it:
uvx --from glances --python 3.12 glances
If you call this command again, uvx will re-use the virtual environment it created, using the Python interpreter of your choice.
You just saw how uv allows you to install custom Python interpreters. This topic is covered in a bit more detail in the following section.
Is it a good idea to install custom Python interpreters?
Letting Developers and DevOps install custom Python interpreters can be a time-saver, given that no elevated privileges are required and the hassle of making an RPM to distribute a new Python is gone.
Where was it installed? Let’s search for it and run it:
# It is not the system python3 [josevnz@dmaf5 ~]$ which python3 /usr/bin/python3
# And not in the default PATH [josevnz@dmaf5 ~]$ which python3.13 /usr/bin/which: no python3.13 in (/home/josevnz/.cargo/bin:/home/josevnz/.local/bin:/home/josevnz/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/josevnz/.local/share/JetBrains/Toolbox/scripts)
# Ah it is inside /home/josevnz/.local/share/uv/python, Let's run it: [josevnz@dmaf5 ~]$ /home/josevnz/.local/share/uv/python/cpython-3.13.1-linux-x86_64-gnu/bin/python3.13 Python 3.13.1 (main, Jan 14 2025, 22:47:38) [Clang 19.1.6 ] on linux Type "help", "copyright", "credits" or "license" for more information. >>>
Interesting, a custom location that is not in the PATH, that allows you to mix and match Python versions.
Let’s see if uv can re-use installations now. Imagine, now, that I want to install the tool autopep8 (used to correct style issues on Python code) using Python 3.13:
Did the new autopep8 installation re-use the Python3.13 we installed before?
[josevnz@dmaf5 ~]$ which autopep8
~/.local/bin/autopep8
[josevnz@dmaf5 ~]$ head -n 1 ~/.local/bin/autopep8
#!/home/josevnz/.local/share/uv/tools/autopep8/bin/python
[josevnz@dmaf5 ~]$ ls -l /home/josevnz/.local/share/uv/tools/autopep8/bin/python
lrwxrwxrwx. 1 josevnz josevnz 83 Mar 22 16:50 /home/josevnz/.local/share/uv/tools/autopep8/bin/python -> /home/josevnz/.local/share/uv/python/cpython-3.13.1-linux-x86_64-gnu/bin/python3.13
Yes it did, very good, we are not wasting space with duplicate Python interpreter installations.
But what if we want to re-use the existing system python3? If we force the installation, will we have a duplicate (newly downloaded and existing system-wide installation)?
My system has Python 3.11, let’s force the autopep8 install and see what happens:
josevnz@dmaf5 ~]$ uv tool install autopep8 --force --python 3.11 Resolved 2 packages in 3ms Uninstalled 1 package in 1ms Installed 1 package in 3ms ~ autopep8==2.3.2 Installed 1 executable: autopep8
# Where ia autopep8 [josevnz@dmaf5 ~]$ which autopep8 ~/.local/bin/autopep8
# What python is used to run autopep8? Check the Shebang on the script [josevnz@dmaf5 ~]$ head -n 1 ~/.local/bin/autopep8 #!/home/josevnz/.local/share/uv/tools/autopep8/bin/python3
# Where does that Python point to? [josevnz@dmaf5 ~]$ ls -l /home/josevnz/.local/share/uv/tools/autopep8/bin/python3 lrwxrwxrwx. 1 josevnz josevnz 6 Mar 22 16:56 /home/josevnz/.local/share/uv/tools/autopep8/bin/python3 -> python [josevnz@dmaf5 ~]$ ls -l /home/josevnz/.local/share/uv/tools/autopep8/bin/python lrwxrwxrwx. 1 josevnz josevnz 19 Mar 22 16:56 /home/josevnz/.local/share/uv/tools/autopep8/bin/python -> /usr/bin/python3.11
uv is smart enough to use the system Python.
Now say that you want to make this Python3 version the default for your user. There is a way to do that using the experimental flags --preview (add to the PATH location) and --default (make a link to python3):
[josevnz@dmaf5 ~]$ uv python install 3.13 --default --preview
Installed Python 3.13.1 in 23ms
+ cpython-3.13.1-linux-x86_64-gnu (python, python3, python3.13)
# Which one is now python3
[josevnz@dmaf5 ~]$ which python3
~/.local/bin/python3
# Is python3.13 our default python3?
[josevnz@dmaf5 ~]$ which python3.13
~/.local/bin/python3.13
If you want to enforce a more strict control on what interpreters can be installed, you can create a $XDG_CONFIG_DIRS/uv/uv.toml or ~/.config/uv/uv.toml file and you can put the following settings there:
# Location: ~/.config/uv/uv.toml or /etc/uv/uv.toml
# https://docs.astral.sh/uv/reference/settings/#python-preference: only-managed, *managed*, system, only-system
python-preference = "only-system"
# https://docs.astral.sh/uv/reference/settings/#python-downloads: *automatic*, manual or never
python-downloads = "manual"
Now we can call it without using uv or uvx, as long as long as you add ~/.local/bin in your PATH environment variable. You can confirm if that is the case by using which:
which ansible-playbook
~/.local/bin/ansible-playbook
Another advantage of using ‘tool install‘ is that if the installation is big (like Ansible), or you have a slow network connection, you only need to install once, since it is cached locally and ready for use the next time.
The last trick for this section, is if you installed several Python tools using uv, you can upgrade them all in one shot with the --upgrade flag:
We have seen, so far, how to manage someone else’s packages, what about our own? The next section explores that.
Managing your Python projects with UV
Eventually, you will find yourself packaging a Python project that has multiple modules, scripts and data files. Python offers a rich ecosystem to manage this scenario and uv takes away some of the complexity.
Our small demo project will create an application that will use the ‘Grocery Stores‘ data from the Connecticut Data portal. The data file is updated every week and is in JSON format. The application takes that data and displays it in a terminal as a table.
‘Uv init‘ allows me to initialize a basic project structure, which we will improve on shortly. I always like to start a project with a description and a name:
[josevnz@dmaf5]$ uv init --description 'Grocery Stores in Connecticut' grocery_stores Initialized project `grocery_stores` at `/home/josevnz/tutorials/docs/Enhancing_Your_Python_Workflow_with_UV_on_Fedora/grocery_stores`
uv created a few files here:
[josevnz@dmaf5 Enhancing_Your_Python_Workflow_with_UV_on_Fedora]$ ls -a grocery_stores/
. .. hello.py pyproject.toml .python-version README.md
The most important part, for now, is pyproject.toml. It has a full description of your project among other things:
[project]
name = "pretty-csv"
version = "0.1.0"
description = "Grocery Stores in Connecticut"
readme = "README.md"
requires-python = ">=3.13"
dependencies = []
Also created is .python-version which has the version of Python supported by this project. This is how uv enforces the Python version used in this project.
Another file is hello.py. You can get rid of it, it has a hello world in Python. We will also later fill the README.md with proper content.
Back to our script, we will use a TUI framework called Textual that will allow us to take the JSON file and show the contents as a table. Because we know that dependency, let’s use uv to add it to our project:
We downloaded textual and their transitive dependencies
pyproject.toml was updated and now the dependencies section has values (go ahead and open the file) and see:
[project]
name = "pretty-csv"
version = "0.1.0"
description = "Simple program that shows contents of a CSV file as a table on the terminal"
readme = "README.md"
requires-python = ">=3.13"
dependencies = [
"textual==2.1.2",
]
uv created a uv.lock file next to the pyproject.toml. This file has the exact version of all the packages used in your project, which ensures consistency.
You can see uv.lock is very explicit, as its purpose is to be as specific and unambiguous as possible. This file is meant to be added to your repository on git, same as ‘.python-version’ . It will allow developers across your team to have a consistent tool set installed.
Let’s also add the ‘httpx‘ library, so we can download the grocery data asynchronously:
These are runtime dependencies, but what if we want to use tools to do things like linting, or profiling? We will explore that in the next section.
Development dependencies
You may want to use some tools while developing your application, like pytest to run unit tests or pylint to check the correctness of the code. But you don’t want to deploy those tools in your final version of the application.
This is a development dependency, and you can add them to a special ‘–dev‘ section of your project like this :
This produces the following section on my pyproject.toml file:
[dependency-groups]
dev = [
"pylint==3.3.6",
"pytest==8.3.5",
]
Writing a JSON-to-Table display Python application
The first step is to have the code that loads the data, then renders the Grocery store raw data as a table. I will let you read the Textual tutorial on how to do this and instead will share the bulk of the code I wrote in a file called ‘groceries.py‘:
"""
Displays the latest Grocery Store data from
the Connecticut Data portal.
Author: Jose Vicente Nunez <kodegeek.com@protonmail.com>
Press ctrl+q to exit the application.
"""
import httpx
from httpx import HTTPStatusError
from textual.app import App, ComposeResult
from textual.widgets import DataTable, Header, Footer
from textual import work, on
from orjson import loads
GROCERY_API_URL = "https://data.ct.gov/resource/fv3p-tf5m.json"
class GroceryStoreApp(App):
def compose(self) -> ComposeResult:
header = Header(show_clock=True)
yield header
table = DataTable(id="grocery_store_table")
yield table
yield Footer()
@work(exclusive=True)
async def update_grocery_data(self) -> None:
"""
Update the Grocery data table and provide some feedback to the user
:return:
"""
table = self.query_one("#grocery_store_table", DataTable)
async with httpx.AsyncClient() as client:
response = await client.get(GROCERY_API_URL)
try:
response.raise_for_status()
groceries_data = loads(response.text)
table.add_columns(*[key.title() for key in groceries_data[0].keys()])
cnt = 0
for row in groceries_data[1:]:
table.add_row(*(row.values()))
cnt += 1
table.loading = False
self.notify(
message=f"Loaded {cnt} Grocery Stores",
title="Data loading complete",
severity="information"
)
except HTTPStatusError:
self.notify(
message=f"HTTP code={response.status_code}, message={response.text}",
title="Could not download grocery data",
severity="error"
)
def on_mount(self) -> None:
"""
Render the initial component status, show an initial loading message
:return:
"""
table = self.query_one("#grocery_store_table", DataTable)
table.zebra_stripes = True
table.cursor_type = "row"
table.loading = True
self.notify(
message=f"Retrieving information from CT Data portal",
title="Loading data",
severity="information",
timeout=5
)
self.update_grocery_data()
@on(DataTable.HeaderSelected)
def on_header_clicked(self, event: DataTable.HeaderSelected):
"""
Sort rows by column header
"""
table = event.data_table
table.sort(event.column_key)
if __name__ == "__main__":
app = GroceryStoreApp()
app.title = "Grocery Stores"
app.sub_title = "in Connecticut"
app.run()
Now that we have some code, let’s test it. First using an editable mode (in a way similar to using pip):
My test code just simulates starting the application and pressing ctrl-q to exit it. Not very useful but this next test gives you an idea what you can to do to test your application simulating keystrokes:
"""
Unit tests for Groceries application
https://textual.textualize.io/guide/testing/
"""
import pytest
from grocery_stores_ct.groceries import GroceryStoreApp
@pytest.mark.asyncio
async def test_groceries_app():
groceries_app = GroceryStoreApp()
async with groceries_app.run_test() as pilot:
await pilot.press("ctrl+q") # Quit
Now run the tests:
[josevnz@dmaf5 grocery_stores]$ uv run --dev pytest test_groceries.py
================================================= 1 passed in 1.17s ==================================================
Packaging and uploading to your Artifact repository
It is time to package our new application. Let’s try to build it:
[josevnz@dmaf5 grocery_stores]$ uv build
Building source distribution...
error: Multiple top-level modules discovered in a flat-layout: ['groceries', 'test_groceries'].
To avoid accidental inclusion of unwanted files or directories,
setuptools will not proceed with this build.
...
Not so fast. uv is getting confused as we have 2 main modules, instead of one. The right thing to do is to setup a src-layout for our project, so we move some files around.
After moving groceries.py to a module called ‘src/grocery_stores_ct’ and tests_groceries to test:
uv pip install --editable .[dev]
uv run --dev pytest test/test_groceries.py
uv run --with 'pylint==3.3.6' pylint src/grocery_stores_ct/groceries.py
And now build it again:
[josevnz@dmaf5 grocery_stores]$ uv build
Building source distribution...
running egg_info
writing src/grocery_stores.egg-info/PKG-INFO
writing dependency_links to src/grocery_stores.egg-info/dependency_links.txt
removing build/bdist.linux-x86_64/wheel
Successfully built dist/grocery_stores-0.1.0.tar.gz
Successfully built dist/grocery_stores-0.1.0-py3-none-any.whl
Now comes the time when you want to share your application with others.
Uploading to a custom index
I don’t want to pollute the real pypi.org with a test application, so instead I will set my index to be something else, like test.pypi.org. In your case this can be a Nexus 3 repository, an Artifactory repository, or whatever artifact repository you have set up in your company.
For pypi, add the following to your pyproject.toml file:
# URL match your desired location
[[tool.uv.index]]
name = "testpypi"
url = "https://test.pypi.org/simple/"
publish-url = "https://test.pypi.org/legacy/"
explicit = true
You will also need to generate an application token (this varies by provider and won’t be covered here). Once you get your token, call uv publish --index testpypi $token:
[josevnz@dmaf5 grocery_stores]$ uv publish --index testpypi --token pypi-AgENdGVzdC5weXBpLm9yZwIkYzFkODg5ODMtODUxZS00ODc2LWFhYzMtZjhhNWFmNjZhODJmAAIqWzMsIjZmZGNjMzc1LTYxNmEtNDA5Zi1hNTJkLWJhMDZmNWQ3N2NlZSJdAAAGIG3wrTZdgmOBlahBlahBlah
warning: `uv publish` is experimental and may change without warning
Publishing 2 files https://test.pypi.org/legacy/
Uploading grocery_stores-0.1.0-py3-none-any.whl (2.7KiB)
Uploading grocery_stores-0.1.0.tar.gz (2.5KiB)
Other things that you should have on your pyproject.toml
UV does a lot of things but doesn’t do everything. There is a lot of extra Metadata that you should have on your pyproject.toml file. I’ll share some of the essentials here:
If you do not want a project to be uploaded to Pypi by accident, add the following classifier: ‘Private :: Do Not Upload‘.
You will need to bump the version, rebuild and upload again after making any changes, like adding keywords (useful to tell the world where to find your app).
These 8 lines at the begining of the script indicates that this is the embedded metadata.
If you remember our pyproject.toml file, these are the instructions used by package managers like setuptools and uv to handle the project dependencies, like python versions and required libraries to run. This is powerful, since tools capable of reading this inline metadata (between the `///` sections) do not need to check an extra file.
Now, uv (has a flag) called `–script` which allows it to interpret the inline metadata on the script. For example, this will update the dependencies for the `example` script, by reading them from the script directly:
uv add --script example.py 'requests<3' 'rich' uv run example.py
This is convenient. If we combine both inline dependencies and uv we can have a self executable script that can also download its own dependencies:
#!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.13" # dependencies = [ # "httpx==0.28.1", # "orjson==3.10.15", # "textual==2.1.2", # ] # /// """ Displays the latest Grocery Store data from the Connecticut Data portal. Author: Jose Vicente Nunez <kodegeek.com@protonmail.com> This version of the script uses inline script metadata: https://packaging.python.org/en/latest/specifications/inline-script-metadata/ Press ctrl+q to exit the application. """
import httpx from httpx import HTTPStatusError from textual.app import App, ComposeResult from textual.widgets import DataTable, Header, Footer from textual import work, on # pylint: disable=no-name-in-module from orjson import loads
@work(exclusive=True) async def update_grocery_data(self) -> None: """ Update the Grocery data table and provide some feedback to the user :return: """ table = self.query_one("#grocery_store_table", DataTable)
async with httpx.AsyncClient() as client: response = await client.get(GROCERY_API_URL) try: response.raise_for_status() groceries_data = loads(response.text) table.add_columns(*[key.title() for key in groceries_data[0].keys()]) cnt = 0 for row in groceries_data[1:]: table.add_row(*(row.values())) cnt += 1 table.loading = False self.notify( message=f"Loaded {cnt} Grocery Stores", title="Data loading complete", severity="information" ) except HTTPStatusError: self.notify( message=f"HTTP code={response.status_code}, message={response.text}", title="Could not download grocery data", severity="error" )
def on_mount(self) -> None: """ Render the initial component status :return: """ table = self.query_one("#grocery_store_table", DataTable) table.zebra_stripes = True table.cursor_type = "row" table.loading = True self.notify( message="Retrieving information from CT Data portal", title="Loading data", severity="information", timeout=5 ) self.update_grocery_data()
def sort_reverse(self, sort_type: str): """ Determine if `sort_type` is ascending or descending. """ reverse = sort_type in self.current_sorts if reverse: self.current_sorts.remove(sort_type) else: self.current_sorts.add(sort_type) return reverse
if __name__ == "__main__": app = GroceryStoreApp() app.title = "Grocery Stores" app.sub_title = "in Connecticut" app.run()
This is the same script we wrote before, except that we use the last big of magic here:
!/usr/bin/env -S uv run --script
We call env (part of coreutils) to split arguments (-S) to call uv with the --script flag. Then uv reads the inline metadata and downloads the required python with all the dependencies automatically:
[josevnz@dmaf5 Enhancing_Your_Python_Workflow_with_UV_on_Fedora]$ chmod a+xr inline_script_metadata/groceries.py [josevnz@dmaf5 Enhancing_Your_Python_Workflow_with_UV_on_Fedora]$ ./inline_script_metadata/groceries.py Installed 18 packages in 29ms # And here the script starts running!!!
It doesn’t get simpler than this. This is great, for example, to run installer scripts.
Learning more
A lot of material is covered here but there is still more to learn. As with everything, you will need to try to see what better fits your style and available resources.
Below is a list of links I found useful and may also help you:
The official uv documentation is very complete, and you will most likely spend your time going back and forth reading it.
Users of older Fedora distributions may take a look at the UV Source RPM. Lots of good stuff, including Bash auto-completion for UV.
Anaconda and miniconda also have counter parties written in rust (mamba and micromamba), in case you decide jumping to uv is too soon. These are backward compatible and much faster.
Did you remember the file uv.lock we discussed before? Now Python has agreed to a way to manage dependencies (PEP 751) in a much more powerful way than the pip requirements.txt file. Keep an eye on packaging.python.org for more details.
I showed you how to use pylint to check for code smells. I would strongly recommend you try ruff. It is written in rust and it is pretty fast:
[josevnz@dmaf5 grocery_stores]$ uv tool install ruff@latest Resolved 1 package in 255ms Prepared 1 package in 1.34s Installed 1 package in 4ms ruff==0.11.2 Installed 1 executable: ruff # The lets check the code [josevnz@dmaf5 grocery_stores]$ ruff check src/grocery_stores_ct All checks passed!
Remember: “perfect is the enemy of good”, so try uv and other tools and see what is best for your Python workflow needs.
Last week, I posted about running nightly syslog-ng container images on arm64. However, you can also install syslog-ng directly on the host (in my case, a Raspberry Pi 3), running the latest Raspberry OS.
Important projects for getting Windows applications up and running on Linux
Let's find out why we need another game launcher for Linux and why famous developers invest their time to create it. The first question from newcomers will probably be "What does the word UMU even mean? UMU comes from Polynesian culture and means hot volcanic stones that are good for cooking. So this project is definitely hot.
Linux as a platform for games is very promising - Valve, CodeWeavers (founders of Wine, the most important application for running Windows software on Linux) and other companies and developers have invested a lot in the ability to run Windows applications and Linux graphics stack. And this is not only about games - Wine is able to run Adobe Suite (Photoshop, Illustrator, InDesign), Microsoft Office and many other applications.
The Steam storefront
For the average Linux user, there is a landscape of tools that make life easier:
Wine, developed by CodeWeavers and the open source community.
Proton - a fork of Wine, created by Valve and also developed with the help of the open source community.
At first sight, these two projects are competitors, but this is not true. Both have the same root and success of one is also success of the other, so cooperation is profitable for both.
Additional tools:
DXVK - Vulkan-based implementation of D3D8, 9, 10 and 11 for Linux and Wine.
VK3D - is a 3D graphics library based on Vulkan with an API very similar to Direct3D 12.
VKD3D-proton - VK3D fork from Valve
winetricks - an easy way to work around problems in Wine
protontricks - wrapper that does Winetricks things for Proton-enabled games, also requires Winetricks.
Finally, the peak of the iceberg - game launchers:
Lutris
PlayOnLinux
Bottles
Heroic Games Launcher
Faugus Launcher and many more.
There are a lot of launchers - everyone wants to make life easier for their users. Steam is a launcher too, with the store, community, achievements and a lot of stuff inside. Two negative Steam moments - it's a proprietary 32-bit application. Why open source is better than proprietary is obvious - you can improve it and analyze possible security issues. 32-bit application is painful for Linux maintainers because they have to provide additional 32-bit libraries as dependencies, update them and do QA.
So can we use Proton without Steam for a more open source gaming environment? Short answer - yes, but not without problems. Proton is developed with full Steam compatibility and uses Steam Runtime - this is a compatible environment for running Steam games on various Linux distributions. Here UMU wins advanced score because it is nothing else than modified Steam Runtime Tools and Steam Linux Runtime that Valve uses for Proton.
More competition is always better for customers, so more game launchers will bring more unique features to the Linux ecosystem. Some launchers already support UMU: Lutris, Heroic Games Launcher or Faugus Launcher. Also, UMU works inside Snap or Flatpak packages, but doesn't provide it's own package for both yet.
Who stays behind of UMU
UMU was created by important figures from Linux gaming scene:
GloriousEggroll - main contributor of Nobara Linux, proton-ge, wine-ge.
They have very different levels of commitment, but just the fact that they are all involved sends a good signal to all of us.
Go hard or go home - how UMU can win the game
Many years ago, when I first tried Wine to run a game on Linux, the algorithm was this:
Install Wine and run wine game.exe.
If it doesn't work, analyze the log and use winetricks to install the correct library.
If it fails, go to the Wine Application Database also called AppDB to find the right way.
UMU is well designed by people with the above experience, so they decided to create UMU Database, which contains all the information needed to run games successfully. There are also differences between game versions: games from Steam and Epic Games Store are not exactly the same and may need different fixes for successful gameplay. The UMU game fixes are called protonfixes and their repository can be found here.
For example, let's search for Grand Theft Auto V in the UMU database. This is the very popular game that doesn't need any advertising:
TITLE,STORE,CODENAME,UMU_ID,COMMON ACRONYM (Optional),NOTE (Optional)
Grand Theft Auto V,egs,9d2d0eb64d5c44529cece33fe2a46482,umu-271590,gtav,
Grand Theft Auto V,none,none,umu-271590,gtav,Standalone Rockstar installer
Grand Theft Auto V Enhanced on Steam
As you can see this is the same game with id umu-271590 but from different stores: Epic Games and Rockstar. Currently the UMU database has 1090 games, this is a good result because the first UMU release was in February 2024.
Non-Steam Games
First you need to install Proton. You can do it using Steam or in case of Proton GE use it's README. You don't need to worry about the Steam Runtime, the latest version will be downloaded to $HOME/.local/share/umu.
Now start with no options:
$ umu-run game.exe
UMU will automatically set Proton and create a Wine prefix. It will work in some cases, but many games will need more tuning. The next command will run Star Citizen, apply protonfix and create Wine prefix in a different location:
If you want to run native Linux game and disable Proton there's special option for it:
UMU_NO_PROTON=1 umu-run game.sh
Steam Games
They are supported - run games from any store just like you do on Steam. The main difference from doing it manually with Wine or Proton is that UMU can automatically apply Proton fixes to the game title. When Steam runs a game through Proton, it shares some data about specific game title and personal configuration that title needs - for example, does it need OpenGL or Vulkan. UMU is able to talk to Proton in the same way Steam does.
Final Note
Unsplash / Uriel Soberanes
UMU is the unified launcher for Linux that allows you to run Windows games outside of Steam and does the heavy lifting of setting up the game environment correctly. It has a large database of games with preconfigured protonfixes for each, but also supports many flags and environment variables for complex configurations. You can use UMU as a standalone launcher or together with other launchers like Lutris to get a stable Proton environment for many games. Thank the contributors and remember - you can win even faster with open source software!
We did another mass update/reboot cycle. We try and do these every so often,
as the fedora release schedule permits. We usually do all our staging hosts
on a monday, on tuesday a bunch of hosts that we can reboot without anyone
really noticing (ie, we have HA/failover/other paths or the service is just
something that we consume, like backups), and finally on wednsday we do
everything else (hosts that do cause outages).
Things went pretty smoothly this time, I had several folks helping out this
time and thats really nice. I have done them all by myself, but it takes a while.
We also fixed a number of minor issues with hosts: serial consoles not working right
and nbde not running correctly and also zabbix users being setup correctly locally.
There was also a hosted server where reverse dns was wrong, causing ansible to
have the wrong fqdn and messing up our update/reboot playbook.
Thanks James, Greg and Pedro!
I also used this outage to upgrade our proxies from Fedora 40 to Fedora 41.
After that our distribution of instances is:
number / ansible_distribution_version
252 41
105 9.5
21 8.10
8 40
2 9
1 43
It's interesting that we now have 2.5x as many Fedora instances as RHEL.
Although thats mostly the case due to all the builders being Fedora.
The Fedora 40 GA compose breakage
Last week we got very low on space on our main fedora_koji volume.
This was mostly caused by the storage folks syncing all the content
to the new datacenter, which meant that it kept snapshots as it
was syncing.
In an effort to free space (before I found out there was nothing we
could do but wait) I removed an old composes/40/ compose. This was the
final compose for Fedora 40 before it was released and the reason in
the past that we kept it was to allow us to make delta rpms more easily.
It's the same content as the base GA stuff, but it's in one place instead
of split between fedora and fedora-secondary trees. Unfortunately,
there were some other folks using this. Internally they were using it
for some things and iot also was using it to make their daily image updates.
Fortunately, I didn't actually fully delete it, I just copied it to
an archive volume, so I was able to just point the old location
to the archive and everyone should be happy now.
Just goes to show you if you setup something for yourself, often
unknown to you others find it helpfull as well, so retiring things
is hard. :(
New pagure.io DDoS
For the most part we are handling load ok now on pagure.io. I think
this is mostly due to us adding a bunch of resources, tuning things
to handle higher load and blocking some larger abusers.
However, on friday we got a new fun one: A number of ip's were crawling
an old (large) git repo grabbing git blame on ever rev of every file.
This wasn't causing a problem on the webserver or bandwith side,
but instead causing problems for the database/git workers. Since
they had to query the db on every one of those and get a bunch
of old historical data, it saturated the cpus pretty handily.
I blocked access to that old repo (thats not even used anymore)
and that seemed to be that, but they may come back again doing the
same thing. :(
We do have a investigation open for what we want to do long term.
We are looking at anubis, rate limiting, mod_qos and other options.
I really suspect these folks are just gathering content which they
plan to resell to AI companies for training. Then the AI company
can just say they bought it from bobs scraping service and 'openwash'
the issues. No proof of course, but just a suspicion.
Final freeze coming up
Finally the final freeze for Fedora 42 starts next tuesday,
so we have been trying to land anything last minute.
If you're a maintainer or contributor working on Fedora 42,
do make sure you get everthing lined up before the freeze!
On this day in 1943 Vangelis was born. The very first CD I bought over three decades ago was composed by him: Chariots of Fire. After so many years, I still love his music.
My Vangelis collection
As you can see, I do not have everything by him. I do not like his earliest and latest works that much, but almost everything in between. Unfortunately I could not find everything on CD. For example, I loved “Soil Festivities”, especially since I was a soil engineer during my college years. But not only is it not available on CD (even used), it is also missing from streaming services.
Several times I learned years later that the music I was listening to was actually a movie soundtrack. Chariots of Fire is one of them, as well as Blade Runner. It became one of my favorite movies, and it’s the only movie I have on 4K bluray.
I’m listening to Vangelis right now and expect to listen to a few more of his albums today :-)
For the last few months, one of the things I’ve been working on in Fedora is
adding support for SecureBoot on Arm64. The details of that work will be the
subject of a later post, but as part of this work I’ve become somewhat familiar
with the signing infrastructure in Fedora and how it works. This post
introduces the various pieces of the current infrastructure, and how they fit
together.
Signed?
Pretty much anything Fedora produces and distributes is digitally signed so
users can verify it did, in fact, come from the Fedora project. Perhaps the
most obvious example of this is the RPM packages Fedora produces. However,
plenty of other artifacts are also signed, like OSTree commits.
Signing works using public-key
cryptography. We have the
private key that we need to keep secret, and we distribute the public keys to
users so they can verify the artifact.
Robosignatory
Signing is (mostly) an automated process. A service, called
robosignatory, connects to an AMQP
message broker and subscribes to several message topics. When an artifact is
created that needs signing, the creator of the artifact sends a message to the
AMQP broker using one of these topics.
Robosignatory does not sign artifacts itself. It collects requests from various
other services and submits them to the signing server on behalf of those
systems. The signing server is the system that contains and protects the
private keys.
Sigul
Sigul is the signing server that holds the private
keys and performs signing operations. It is composed of three parts: the
client, the bridge, and the server.
The Server
The Sigul server is designed to control access to signing keys and to provide a
minimal attack surface. It does not behave like a traditional server in that it
does not accept incoming network connections. Instead, it connects to the Sigul
bridge, and the bridge forwards requests to it via that connection.
This allows the firewall to be configured to allow outgoing traffic to a single
host, and to block all incoming connections. This does mean that the host
cannot be managed via normal SSH operations. Instead this is done in Fedora via
the host’s out-of-band management console.
Private keys are encrypted on disk. When users are granted access to keys, the
key is encrypted for that particular user.
The Bridge
The Sigul bridge acts as a specialized proxy. Both the client and server connect
to the bridge, and it forwards requests and responses between them.
Unlike the typical proxy, the Sigul bridge does a few interesting things.
Firstly, it requires the client to authenticate via TLS certificates. The
client then sends the bridge the request it wishes to make. The bridge forwards
that request to the server. The bridge then expects the client and server to
send an arbitrary amount of data to each other. This arbitrary data is framed
as chunks and it forwards that data back and forth until an end of stream
signal is sent by the server and client.
Finally, it forwards the server’s response to the client.
The Client
The client is a command-line interface that sends requests to the server via
the bridge. This client can be used to create users and keys, grant and revoke
access to keys, and request signatures in various formats. Robosignatory
invokes the CLI to sign artifacts.
The client connects to the bridge as described above. After authenticating with
the bridge and sending the request, it begins a second TLS connection
configured with the Sigul server’s hostname, and sends and receives data on
this connection over the TLS connection it has with the Sigul bridge. It relies
on this inner TLS connection to send a set of session keys to the server
without the bridge being able to intercept them. These session keys are used to
sign the Sigul server’s responses so the client can be sure the bridge did not
tamper with them.
After it has established a set of secrets with the server, the remainder of the
interaction occurs over the TLS connection with the bridge, but since the
responses are signed both the client and server can be confident the bridge has
not tampered with the conversation.
Conclusion
It’s an interesting setup, and has served Fedora for many years. There is
plenty of code in Sigul which dates back to 2009, not long after Python 2.6 was
released with exciting new features like the standard library json module. It
was likely developed for RHEL 5 which means Python 2.4.
Unfortunately, at least one of the libraries (python-nss) it depends on to work
are not maintained and not in Fedora 42, so something will have to be done in
the near future. Still, it’s not ready to sign off just yet.
“What? A MacBook Air cheaper than a Windows laptop? Impossible!”
Well, if you look in the Wintel (Windows + Intel) universe for a laptop with the same features as Apple’s entry-level laptop — the MacBook Air — the Wintel version will be more expensive.
A basic laptop today should have a 3K or 4K display (Full HD is already obsolete), solid-state storage, high-quality camera, microphone, and audio, and be thin, lightweight, and stylish. Most importantly, the battery should last all day. This last feature is not possible in Intel-based laptops, where, in practice, the battery lasts no more than 90 minutes. A modern laptop is used like a smartphone: unplugged from the outlet, carried around all day, and recharged while you have lunch or sleep.
So yes, you can find cheaper laptops, but they will have worse features than the minimum standard. They also use lower-quality components (camera, microphone, display) and outdated technology (storage, CPU).
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 24 Mar – 28 Mar 2025
Infrastructure & Release Engineering
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). List of planned/in-progress issues
Fedora test days are events where anyone can help make certain that changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed to Fedora before, this is a perfect way to get started.
There are three test periods occurring in the coming days:
Monday March 31 through April 7, is to test the KDE Desktop and Apps
Wednesday April 2 through April 6, is to test Upgrade Test Days
Saturday April 5 through April 7, is to test Virtualization
Come and test with us to make Fedora 42 even better. Read more below on how to do it.
KDE Plasma and Apps
The KDE SIG is working on final integration for Fedora 42. Some of the app versions were recently released and will soon arrive in Fedora Linux 42. As a result, the KDE SIG and QA teams have organized a test week from Monday, March 31, 2025, through Monday, April 07, 2025. The wiki page contains links to the test images you’ll need to participate.
Upgrade test day
As we approach the Fedora Linux 42 release date, it’s time to test upgrades. This release has many changes, and it becomes essential that we test the graphical upgrade methods as well as the command-line methods.
This test period will run from Wednesday, April 2 through Sunday, April 6. It will test upgrading from a fully updated F40 or F41 to F42 for all architectures (x86_64, ARM, aarch64) and variants (WS, cloud, server, silverblue, IoT). See this wiki page for information and details. For this test period, we also want to test DNF5 Plugins before and after upgrade. Recently noted regressions resulted in a Blocker Bug. The DNF5 Plugin details are available here.
Virtualization test day
This test period will run from Saturday, April 5 through Monday, April 7 and will test all forms of virtualization possible in Fedora 42. The test period will focus on testing Fedora Linux, or your favorite distro, inside a bare metal implementation of Fedora Linux running Boxes, KVM, VirtualBox and whatever you have. The test cases outline the general features of installing the OS and working with it. These cases are available on the results page.
How do test days work?
A test period is an event where anyone can help make certain that changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. Test days are the perfect way to start contributing if you not in the past.
The only requirement to get started is the ability to download test materials (which include some large files) and then read and follow directions step by step.
Detailed information about all the test days are on the wiki page links provided above. If you are available on or around the days of the events, please do some testing and report your results
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.
RPMs of PHP version 8.4.6RC1 are available
as base packages in the remi-modular-test for Fedora 40-42 and Enterprise Linux≥ 8
as SCL in remi-test repository
RPMs of PHP version 8.3.20RC1 are available
as base packages in the remi-modular-test for Fedora 40-42 and Enterprise Linux≥ 8
as SCL in remi-test repository
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ PHP version 8.2 is now in security mode only, so no more RC will be released.
The Fedora Infrastructure Team is announcing the end of OpenID in Fedora Account System (FAS). This will occur on 20th May 2025.
Why the change?
OpenID is being replaced by OpenIDConnect (OIDC) in most of the modern web and most of the Fedora infrastructure is already using OIDC as the default authentication method. OIDC offers better security by handling both authentication and authorization. It also allows us to have more control over services that are using Fedora Account System (FAS) for authentication.
What will change for you?
With the End Of Life of OpenID we will switch to OIDC for everything and no longer support authentication with OpenID.
If your web or service is already using OIDC for authentication nothing will change for you. If you are still using OpenID open a ticket on Fedora Infrastructure issue tracker and we will help you with migration to OIDC.
For users using FAS as authentication option there should be no change at all.
How to check if a service you maintain is using OpenID?
You may quickly check if your service is using OpenID for FAS authentication by looking at where you are redirected when logging in with FAS.
We will be reaching out directly to services we identify as using OpenID. But since we don’t have control over OpenID authentication, we can’t identify everyone.
If you are interested in following this work feel free to watch this ticket.
Our everyday scientific and educational work relies heavily on hardware, software, and, in modern times, cloud services. The equipment that we will mention below is specific to our group; common services used by university and/or faculty employees will not be specifically mentioned here.
Last December, the CD shop where I bought most of my collection closed its doors for good. I had seen it coming — the owner had been gradually winding down the business in preparation for retirement — but after nearly 30 years of shopping there, it was still a tough moment.
Stereo logo
This logo belongs to Periferic Records - Stereo Kft.. Back in the nineties, during my university years, I used to look for this logo at concerts, always hoping to spot a bearded man selling an incredible selection of CDs. Imagine my surprise when, in 2002, I attended a concert and discovered that the organizer was none other than that same bearded man — who also happened to be one of my second cousins!
From that moment on, I became a regular at the shop. The owner was a publisher of some of my favorite music, including Hungarian progrock and piano albums. Some standout names: After Crying, Vedres Csaba, and Solaris. While the shop specialized in progrock — with a selection unlike anywhere else — it also offered a wide variety of other genres.
When I received my first big paycheck, I went straight to the store and bought dozens of CDs. Today, streaming services like TIDAL and Spotify have recommendation engines, but back then, nothing could beat the personalized recommendations from the shop’s staff. More than once, I walked out with a free CD as a bonus, one of which became an all-time favorite: Townscream – Nagyvárosi Ikonok.
Unlike many music shops that play background music on low-quality systems, Stereo had StandArt speakers from Heed Audio. These speakers, almost as old as the shop itself, created an immersive listening experience. Though I often rushed in just to pick up an order, on the rare occasion that I had time, I would linger to listen — sometimes discovering new music to take home.
The website still exists, and you can get an ever shorter list of available CD titles by e-mail. In December, I spent most of my free time going through their list of albums, listening to samples on TIDAL and YouTube — nearly 1,500 albums in total. Through this process, I found some rare gems, including one CD I bought purely for its intriguing title: God-Sex-Money. Well, actually the description, “Recommended for Wakeman/Emerson fans,” sealed the deal :-)
Even now, whenever I’m near the old shop, I instinctively start walking toward it — only to remember that an important part of my life is gone forever. But it lives on in my CD collection and my memories.
Open Source Survival Guide provides practical rules for navigating the open source ecosystem. Learn how to balance community collaboration with business goals, contribute effectively, build trust, and maintain your sanity in the complex world of open source software development.
Recently we enabled nightly syslog-ng builds and container builds for arm64. It means that from now on, you can run the latest syslog-ng on 64bit ARM platforms. For this test, I used a Raspberry Pi 3 running the latest Raspberry Pi OS. As I use Podman everywhere else (I am an openSUSE / Fedora guy), I also installed it here for container management.
I am told, by friends who have spent time at Google, about the reason Google Reader finally disappeared. Apparently it had become a 20% Project for those who still cared about it internally, and there was some major change happening to one of it upstream dependencies that was either going to cause a significant amount of work rearchitecting Reader to cope, or create additional ongoing maintenance burden. It was no longer viable to support it as a side project, so it had to go. This was a consequence of an internal culture at Google where service owners are able to make changes that can break downstream users, and the downstream users are the ones who have to adapt.
My experience at Meta goes the other way. If you own a service or other dependency and you want to make a change that will break things for the users, it’s on you to do the migration, or at the very least provide significant assistance to those who own the code. You don’t just get to drop your new release and expect others to clean up; doing that tends to lead to changes being reverted. The culture flows the other way; if you break it, you fix it (nothing is someone else’s problem).
There are pluses and minuses to both approaches. Users having to drive the changes to things they own stops them from blocking progress. Service/code owners having to drive the changes avoids the situation where a wildly used component drops a new release that causes a lot of high priority work for folk in order to adapt.
I started thinking about this in the context of Debian a while back, and a few incidents since have resulted in my feeling that we’re closer to the Google model than the Meta model. Anyone can upload a new version of their package to unstable, and that might end up breaking all the users of it. It’s not quite as extreme as rolling out a new service, because it’s unstable that gets affected (the clue is in the name, I really wish more people would realise that), but it can still result in release critical bugs for lots other Debian contributors.
A good example of this are toolchain changes. Major updates to GCC and friends regularly result in FTBFS issues in lots of packages. Now in this instance the maintainer is usually diligent about a heads up before the default changes, but it’s still a whole bunch of work for other maintainers to adapt (see the list of FTBFS bugs for GCC 15 for instance - these are important, but not serious yet). Worse is when a dependency changes and hasn’t managed to catch everyone who might be affected, so by the time it’s discovered it’s release critical, because at least one package no longer builds in unstable.
Commercial organisations try to avoid this with a decent CI/CD setup that either vendors all dependencies, or tracks changes to them and tries rebuilds before allowing things to land. This is one of the instances where a monorepo can really shine; if everything you need is in there, it’s easier to track the interconnections between different components. Debian doesn’t have a CI/CD system that runs for every upload, allowing us to track exact causes of regressions. Instead we have Lucas, who does a tremendous job of running archive wide rebuilds to make sure we can still build everything. Unfortunately that means I am often unfairly grumpy at him; my heart sinks when I see a bug come in with his name attached, because it often means one of my packages has a new RC bug where I’m going to have to figure out what changed elsewhere to cause it. However he’s just (very usefully) surfacing an issue someone else created, rather than actually being the cause of the problem.
I don’t know if I have a point to this post. I think it’s probably that I wish folk in Free Software would try and be mindful of the incompatible changes they might introducing, and the toil they create for other volunteer developers, often not directly visible to the person making the change. The approach done by the Debian toolchain maintainers strikes me as a good balance; they do a bunch of work up front to try and flag all the places that might need to make changes, far enough in advance of the breaking change actually landing. However they don’t then allow a tardy developer to block progress.
Linux distributions come in two main release models: fixed release and rolling release. Each has its own advantages and drawbacks, making the choice between them dependent on user needs, preferences, and use cases. In this article, we’ll dive into the history of Linux releases, explain both models in detail, provide examples of each, and help you determine which one suits you best.
A Brief History of Linux Releases
The Linux operating system was first developed by Linus Torvalds in 1991, and soon after, various distributions (distros) began emerging to make Linux more accessible to users. Early distributions followed a fixed release cycle, similar to traditional commercial software, providing stable versions with long-term support.
As Linux usage grew, developers and power users sought an alternative release model that allowed them to receive continuous updates without waiting for major version upgrades. This led to the birth of the rolling release model, which delivers updates as soon as they are available, without the need for reinstalling or upgrading to a new version.
What is a Fixed Release Distribution?
A fixed release distribution follows a structured development cycle, with periodic major releases that bundle all updates, improvements, and new features into one package. These releases are well-tested before being distributed to users.
Examples of Fixed Release Distros:
Ubuntu – Releases a new version every six months, with Long-Term Support (LTS) versions every two years.
Debian – Has three main branches: Stable (fixed release), Testing, and Unstable.
Fedora – Releases a new version approximately every six months.
openSUSE Leap – A stable release that is synchronized with SUSE Linux Enterprise.
Linux Mint – Based on Ubuntu LTS releases, focusing on stability and user-friendliness.
Pros of Fixed Release Distros:
Stable and reliable: Thoroughly tested before release.
Long-term support (LTS versions): Security updates for many years.
Predictable update cycles: Users know when a new version will be available.
Ideal for production environments and enterprises.
Cons of Fixed Release Distros:
Software can become outdated between releases.
Requires major upgrades to move to a new version.
May lack the latest features and improvements available in newer software.
What is a Rolling Release Distribution?
A rolling release distribution continuously updates packages as soon as they are available, rather than waiting for a scheduled release. This means that the operating system is always up to date without needing periodic major upgrades.
Examples of Rolling Release Distros:
Arch Linux – A minimalist and highly customizable distribution.
openSUSE Tumbleweed – A rolling release counterpart to openSUSE Leap.
Gentoo Linux – Source-based rolling release with maximum flexibility.
EndeavourOS – A user-friendly Arch-based distro.
Manjaro – Based on Arch but with added stability and ease of use.
Pros of Rolling Release Distros:
Always up to date: No need to wait for major releases.
Access to the latest software and kernel versions.
No system reinstallation required to upgrade. Ideal for developers and enthusiasts who want cutting-edge software.
Cons of Rolling Release Distros:
Can be less stable due to frequent updates.
Updates may occasionally break the system if not managed carefully.
Requires more maintenance and troubleshooting knowledge.
Fixed vs. Rolling Release: Which One Should You Choose?
Choosing between a fixed release and a rolling release distribution depends on your needs:
Criteria
Fixed Release
Rolling Release
Stability
More stable
Less stable (but up to date)
Software updates
Periodic major updates
Continuous updates
Ease of use
Easier, especially for beginners
Requires more maintenance
Security
Long-term security patches
Security updates arrive faster
Ideal for
Enterprises, production environments, beginners
Developers, power users, enthusiasts
If you prefer a stable and predictable system with fewer maintenance requirements, a fixed release distribution like Ubuntu LTS, Debian Stable, or Linux Mint is a great choice.
If you want cutting-edge software, continuous updates, and don’t mind occasional troubleshooting, a rolling release distribution like Arch Linux, Manjaro, or openSUSE Tumbleweed will suit you better.
Both fixed and rolling release distributions have their place in the Linux ecosystem. Understanding their differences allows you to make an informed choice based on your workflow, experience level, and expectations. Whether you prioritize stability or cutting-edge software, there’s a Linux distribution that fits your needs.
Fedora 42 Beta was released on tuesday. Thanks to everyone in the Fedora community
that worked so hard on it. It looks to be a pretty nice relase, lots of things in
it and working pretty reasonably already. Do take it for a spin if you like:
https://fedoramagazine.org/announcing-fedora-linux-42-beta/
Of course with the Beta out the door, our infrastructure freeze is lifted and
so I merged 11 PR's that were waiting for that on Wed. Also, next week we are
going to get in a mass update/reboot cycle before the final freeze the week after.
Ansible galaxy / collections fun
One of the things I wanted to clean up what the ansible collections that were installed
on our control host. We have a number that are installed via rpm (from EPEL).
Those are fine, we know they are there and what version, etc.
Then, we have some that are installed via ansible. We have a requirements.txt file and
running the playbook on the control host installs those exact versions of
roles/collections from ansible galaxy. Finally we had a few collections installed
manually. I wanted to get those moved into ansible so we would always know what
we have installed and what version it was. So, simple right? Just put them in
requirements.txt. I added them in there and... it said they were just not found.
The problem turned out to be that we had roles in there, but no collections anymore
so I had not added a 'collections:' section, and it was trying to find 'roles'
with those collection names. The error "not found" was 100% right, but it took
me a few to realize why they were not found. :)
More A.I. Scrapers
AI scrapers hitting open source projects is getting a lot of buzz. I hope that
some of these scraper folks will realize it's counterproductive to scrape
things at a rate that makes them not work, but I'm not holding my breath.
We ran into some very heavy traffic and I had to end up blocking brazil for a while
to pagure.io. We also added some CPU's and adjusted things to handle higher load.
So far we are handling things ok now and I removed the brazil blockage.
But no telling when they will be back. We may well have to look at something
like anubis, but I fear the scrapers would just adjust to not be something it
can catch. Time will tell.
It has been a year and a half since my previous GNOME core apps update. Last time, for GNOME 45, GNOME Photos was removed from GNOME core without replacement, and Loupe and Snapshot (user-facing names: Image Viewer and Camera) entered, replacing Eye of GNOME and Cheese, respectively. There were no core app changes in GNOME 46 or 47.
Now for GNOME 48, Decibels (Audio Player) enters GNOME core. Decibels is intended to close a longstanding flaw in GNOME’s core app set: ever since Totem (Videos) hid its support for opening audio files, there has been no easy way to open an audio file using GNOME core apps. Totem could technically still do so, but you would have to know to attempt it manually. Decibels fixes this problem. Decibels is a simple app that will play your audio file and do nothing else, so it will complement GNOME Music, the music library application. Decibels is maintained by Shema Angelo Verlain and David Keller (thank you!) and is notably the only GNOME core app that is written in TypeScript.
Looking to the future, the GNOME Incubator project tracks future core apps to ensure there is sufficient consensus among GNOME distributors before an app enters core. Currently Papers (future Document Viewer, replacing Evince) and Showtime (future Videos or possibly Video Player, replacing Totem) are still incubating. Applications in Incubator are not yet approved to enter core, so it’s not a done deal yet, but I would expect to see these apps enter core sooner rather than later, hopefully for GNOME 49. Now is the right time for GNOME distributors to provide feedback on these applications: please don’t delay!
On a personal note, I have recently left the GNOME release team to reduce my workload, so I no longer have any direct role in managing the GNOME core apps or Incubation process. But I think it makes sense to continue my tradition of reporting on core app changes anyway!
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 17 Mar – 21 Mar 2025
Infrastructure & Release Engineering
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). List of planned/in-progress issues
Stable and reliable: Thoroughly tested before release. 
Software can become outdated between releases. 
comments? additions? reactions?
As always, comment on mastodon: https://fosstodon.org/@nirik/114247602988630824