fidzu : Fedora

31 Dec 2025 2:15pm GMT

It's the end of the year, which I suppose means it's time for the now-traditional look at my predictions.

Software supply chain

I was right that this would continue to be an area of interest in the open source world, just as it was in 2024 (and - spoiler alert! - it will be in 2026). I wrote "In 2025, I expect to see a marked split between "hobbyist" and "professional" open source projects." That's probably not as true as my ego would like, but I do think we're trending that direction, in part due to the inequality I address in the next section.

It's true that supply chain issues have not stopped in 2025. The Shai-Hulud worm spread through the NPM ecosystem in September (with a similar attack in November). Debian images on Docker Hub contained the XZ backdoor more than a year after it was discovered. Phishing attacks spoofing PyPI in July resulted in the compromise of four accounts, allowing the attackers to upload malicious packages.

But the news wasn't all bad. GitHub rolled out a immutable releases feature that protects against attackers re-tagging previously-good releases with malicious code. crates.io (Rust), npm (Node.js), and NuGet (.NET) added support for trusted publishing. New tools and frameworks came out to help maintainers better understand and address risks, including the OSPS Baseline and Kusari Inspector (disclosure: I am a Kusari employee).

Inequity

This section had two parts. First, I wrote:

I think we'll see a growing separation between the haves and have-nots. The projects that enterprises see as critical will get funding and effort. The other projects, whether or not they're actually important to enterprises, will be left to the increasingly scarce efforts of volunteers.

This held true. Two big examples are the temporary pause of the Kubernetes External Secrets Operator project and Nick Wellnhofer resigning as the sole maintainer of libxml2. Both of these were due to a maintenance burden that exceeded the capacity of the maintainers. Josh Bressers found that almost half of npm packages with a million-plus monthly downloads have a single maintainer. This is likely generalizable across all ecosystems, so it's no surprise that we'd see this. Some in the FFmpeg community took public issue with Google, suggesting the giant should provide more support or stop sending bugs.

The other part of this prediction concerned events:

Events where companies can make sales will do well. Community events will suffer from a lack of sponsorship and attendance due to lack of travel funding. I think we'll start to see a shift from global events toward regional events in the community space.

I was wrong here, as far as I can tell. US-based events struggled somewhat, in part due to geopolitics, but European events seem to be doing well. Larger community events, from what I gathered, have done well, although the finances are not what they used to be. Smaller events, though, are struggling. DevOpsDays Detroit, as one example, didn't accept my talk proposal because the conference was shuttered instead. Many of the local and regional events rely on a small number of committed people to keep going. Just like in software projects, these people are getting burnt out.

The general idea of the prediction seems to be holding up well enough. I've heard the phrase "K-shaped economy" approximately a million times in financial news this year. The open source world has seen it, too.

Artificial intelligence

I'll admit to being wrong on this one, too:

If the bubble doesn't burst this year, the hype at least slows way down…it will lead to a leveling off in AI-generated code and bug report "contributions" as vendors start charging more money for services.

I maintain that my wrongness is more a matter of timing than anything. Generative AI continues to lose money, but the price increases are not here. While some have expressed concerns about the circular dealing in the sector, it seems like the fallout has mostly been contained to Oracle (whose share price is down over 40% since an early-September high) for the time being. The hype may be slowing, but it's a little hard to say that with certainty just yet. There's definitely no indication of a slowdown in AI-generated bug reports in curl's data.

Vibe check

I called my 2025 predictions "a little bleak," and I think the vibe was spot on. One thing that didn't fit well into any of the prediction categories was the attempt by Synadia to un-contribute NATS to the CNCF. Thankfully, that went nowhere. Unfortunately, so did the careers of many in the industry as job cuts continued at companies large and small.

If 2025 was bleak for you, rest assured that it is almost over. I truly appreciate everyone who has read these posts, bought a copy of Program Management for Open Source Projects, subscribed to the DAA newsletter, or in any other way made my year a little less bleak with your presence. Here's hoping for an improved 2026!

This post's featured photo by Agence Olloweb on Unsplash.

The post Reviewing open source trends in 2025 appeared first on Duck Alignment Academy.

31 Dec 2025 12:00pm GMT

Anaconda installer now supports installation of bootc based bootable container images using the new bootc command. It has supported several types of payload to populate the root file system during installation. These include RPM packages (likely the most widely used option), tarball images you may know from Fedora Workstation, ostree, and rpm-ostree containers. The newest addition to the family, from a couple of weeks ago, is bootc-based bootable containers.

The difference is under the hood

We have added a new bootc kickstart command to Anaconda to support the new feature. This is very similar to the ostreecontainer command that has been present for some time. From the user's perspective the two are very similar. The main difference, however, is under the hood.

One of the most important setup steps for a deployment is to create a requested partitioning in both cases. When the partitioning is ready, the ostreecontainer command makes Anaconda deploy the image onto the root filesystem using the ostree tool. It also executes the bootupctl tool to install and set up the bootloader. By contrast, with bootc containers installed using the bootc kickstart command, both the filesystem population and bootloader configuration is performed via the bootc tool. This makes the deployment process even more integrated.

The content of the container images used for installation is another difference. The bootc-enabled images are somewhat more versatile. Apart from installation using Anaconda, they provide a self-installing option via the bootc command executed from within a running container.

On the other hand, both options provide you with a way to install an immutable system based on a container image. This option may be useful for particular use cases where regular installation from RPM packages is not desired. This might be due to potentially lower deployment speed or inherent mutability of the resulting system.

A simple how-to

In practice, you'd likely use a custom container with pre-configured services, user accounts and other configuration bits and pieces. However, if you want to quickly try out how the new Anaconda's feature works, you just need to follow a few simple steps. Starting with a Fedora Rawhide ISO:

First, take an existing container from a registry and create a minimal kickstart file instructing Anaconda to install the bootable container image:

# Beware that this kickstart file will wipe out the existing disk partitions.
# Use it only in an experimental/isolated environment or edit it accordingly!
zerombr
clearpart --all --initlabel
autopart

lang en_US.UTF-8
keyboard us

timezone America/New_York --utc
rootpw changeme

bootc --source-imgref=registry:quay.io/fedora/fedora-bootc:rawhide

As a next step, place the kickstart file in some reachable location (e. g. HTTP server), point Anaconda to it by appending the following on the kernel command line:

inst.ks=http://url/to/kickstart 

Now start the installation.

Alternatively, you may use the mkksiso tool provided by the lorax package to embed the kickstart file into the installation ISO.

When installation and reboot is complete, you are presented with an immutable Fedora Rawhide system. It will be running on your hardware (or VM) installed from a bootable container image.

Is there anything more about bootc in Anaconda?

You may ask if this option is limited to Fedora Rawhide container images. Technically speaking, you can use the Fedora Rawhide installation ISO to install, for instance, a CentOS Stream container image:

bootc --source-imgref=registry:quay.io/centos-bootc/centos-bootc:stream10

Nevertheless, keep in mind that for now Anaconda will handle it as Fedora installation in such a case. This is because it runs from a Fedora Rawhide boot ISO. This may result in unforeseen problems, such as getting a btrfs-based partitioning that CentOS Stream won't be able to boot from. This particular issue is easily overcome by explicitly telling Anaconda to use some different partitioning type, e. g. autopart -fstype=xfs. We would like to address the lack of container images handling based on the contained operating system or flavour in the future. For now, one just needs to take the current behavior into consideration when using the bootc command.

There are a couple more known limitations in Anaconda or bootc at this point in time. These include lack of support for partitioning setups spanning multiple disks, support for arbitrary mount points, or for installation from authenticated registries. But we hope it won't take long to solve those shortcomings. There are also plans to make the new bootc command available even on the RHEL-10 platform.

We invite you to try out this new feature and share your experience, ideas or comments with the Installer team. We are looking forward to hearing from you in a thread on discussion.fedoraproject.org!

31 Dec 2025 8:00am GMT

After my talk about TeX syntax-highlighting font at TUG2025 conference, then vice-president of TeX Users Group, Boris Veytsman approached me with a proposal to develop a Math counterpart for the beautiful Arsenal font designed by Andrij Shevchenko.

What followed was a deep dive into the TeXbook to learn about math font parameters, OpenType Math specification, and related documentation & resources. Fortunately, FontForge has really good support for editing Math tables; and the base font used (KpMath-Sans by Daniel Flippo) already had all the critical parameters set (which needed slight adjustments). I started the development of Arsenal Math by integrating the glyphs for Latin letters, Arabic numerals, some symbols etc. and with proper scaling & stem thickness corrections, for regular, bold, italic and bolditalic variants, plus math calligraphic letters. In addition, a lot of Math kerning (known as 'cut-ins' in OpenType parlance) was added to improve the spacing.

Being an OpenType font - XeTeX, LuaTeX or some Unicode math typesetting engine (e.g. MS Word) is required to use Arsenal Math. Boris did testing and provided many feedback, and Vaishnavy Murthy graciously reviewed the glyph changes I made. The CTAN admins were quite helpful to get the font accepted into the repository. There is a style file and fontspec file supplied with the fonts to make the usage easy. The sources are available at RIT fonts repository.

Boris also donated funding for the project, but he had already paid me many folds be mailing The TeXbook autographed by Donald Knuth for me, so I requested the LaTeX devfund team to use it for another project. Karl Berry suggested to write an article about the development process, which is published in the issue 46:3 of the TUGboat journal, and has a lot more technical details.

The learning experience of Math typesetting internals, and contributing to the TeX ecosystem has been a fulfilling spare-time work for me in 2025. Many thanks to all those involved!

30 Dec 2025 12:30pm GMT

29 Dec 2025 6:05pm GMT

2025 is almost gone now, so I thought I would look back on the year for some interesting high and low lights. I'm sure to miss some things here, or miss mentioning someone who did a bunch of work on something, but I will do my best.

27 Dec 2025 7:59pm GMT

At the TUG2025 conference, I presented a talk about the development of a new colour font, which does automatic syntax highlighting for TeX documents/snippets. The idea was floated by CVR, and was inspired by a prior-art of HTML/CSS syntax highlighting font by Heikki Lotvonen.

Syntax highlighting is achieved by specialized grammar files or packages on desktop applications, code editors, the Web, and typesetting systems like TeX. Some of these tools are heavy (e.g. prism.js or pygmentize package). A light-weight alternative would be a font that uses recent OpenType technologies to do syntax highlighting of code snippets. I developed such a font, for highlighting TeX code snippets.

There are some novelties in the developed font:

1. It supports both COLRv0 and COLRv1 colour format specifications (separate fonts, but generated from the same source).
2. Supports plain TeX, LaTeX2 and LaTeX3 macro names.
3. A novel set of OpenType shaping rules for TeX syntax colouring.

The base font used is M+ Code Latin by Coji Morishita. The details of the development, use cases, and limitations can be found in the 46:2 issue of the TUGboat journal publication. The binary font and sources are available at RIT fonts repository.

27 Dec 2025 7:47am GMT

Este ano fomos a algumas celebrações de Natal. E ideia super original que as pessoas tinham em todas as festas era "botaê uma playlist de Natal". Aí por isso ouvi algumas dezenas de vezes as mesmas canções de Natal em inglês. Dezenas de vezes Wham, dezenas de vezes a mesma Mariah Carey, dezenas de Sias.

No auge da minha náusea musical eu interceptava o alto-falante e trocava para O Quebra Nozes de Tchaikovsky - a mais típica música de Natal -, ou uma bela seleção de música instrumental brasileira, ou alguma playlist variada de clássicos de Natal. Eu acho importante ser música instrumental, não ter ninguém cantando, prá não atrapalhar a conversa das pessoas na festa.

Não passava nem 4 minutos para que algum arrombado reclamasse que a música tava baixo astral.

E lá vamos nós ouvir de novo Bublé, Mariah, Sia, Wham. Repetidamente.

Não me entenda mal, gosto muito de todos esses artistas pop. O que me dá náuseas é a falta de abertura para ouvir coisas fora do núcleo duro selecionado pelo jabá.

26 Dec 2025 5:36pm GMT

26 Dec 2025 12:51pm GMT

26 Dec 2025 12:51pm GMT

26 Dec 2025 12:51pm GMT

26 Dec 2025 12:51pm GMT

26 Dec 2025 12:51pm GMT

26 Dec 2025 12:51pm GMT

26 Dec 2025 12:51pm GMT

26 Dec 2025 12:51pm GMT