Planet Ubuntu

Ubuntu Blog: Native integration available between Canonical LXD and HPE Alletra MP B10000

Mon, 15 Dec 2025 15:57:28 +0000

The integration combines efficient open source virtualization with high performance, enterprise-grade storage

We are pleased to announce a new, native integration between Canonical LXD and HPE Alletra. This integration brings together Canonical’s securely designed, open source virtualization platform with HPE’s enterprise-grade storage to deliver a simple, scalable, high-performance experience.

Enterprise-grade storage meets efficient open source virtualization

HPE Alletra is designed to deliver mission-critical storage at mid range economics, with a consistent data experience across various cloud environments. With this integration, Canonical LXD and MicroCloud users can now provision and manage Alletra block storage directly through the LXD interface, without the need for any third-party plugins or additional abstraction layers.

The integration enables users to seamlessly create, attach, snapshot, and manage thin-provisioned block volumes as easily as working with local storage, while retaining the full performance, resilience, and enterprise data services of HPE Alletra.

Simplified operations and scalable performance

HPE Alletra NVMe-based architecture ensures sub-millisecond latency for demanding workloads, with built-in services such as thin-provisioning and data deduplication minimizing storage costs while maintaining consistent performance. Paired with LXD’s lightweight control plane and streamlined UI, users can easily operate their environments, combining the best of open source with enterprise storage functionality.

As demands grow, new volumes and storage capacity can be allocated on the fly. Alletra’s scale-out, modular architecture ensures the platform can expand without disrupting running workloads.

A foundation for modern infrastructure deployments

LXD provides a unified open source virtualization platform to run system containers and virtual machines with a focus on efficiency, security, and ease of management. With native support for HPE Alletra, enterprises can now build, deploy, and manage their workloads with enterprise storage guarantees, whether in private clouds, on-premises data centers, or edge environments.

The combined solution empowers teams to deliver predictable performance for critical and data-intensive workloads while reducing complexity and ensuring agility.

Availability

The integration between LXD and HPE Alletra is available starting with the LXD 6.6 feature release, and requires a HPE Alletra WSAPI version 1. LXD currently supports connecting to HPE Alletra storage through NVMe/TCP or iSCSI protocols. For detailed information, visit Canonical’s LXD documentation.

Ubuntu Blog: Why you should retire your Microsoft Azure Consumption Commitment (MACC) with Ubuntu Pro

Sat, 13 Dec 2025 00:07:17 +0000

When your organization first signed its Microsoft Azure Consumption Commitment (MACC), it was a strategic step to unlock better pricing and enable cloud growth. However, fulfilling that commitment efficiently requires planning. Organizations often look for ways to retire their MACC that drive strategic value, rather than simply increasing consumption to meet a deadline.

The goal is to meet your commitment while delivering long-term benefits to the business.

With Ubuntu Pro in the Azure Marketplace, you can retire your MACC at 100% of the pretax purchase amount. In practice, this allows you to meet consumption goals on your standard Azure invoice, while securing your open source supply chain and automating compliance.

Turn a spend target into an open source security strategy

Instead of simply increasing consumption to hit a target, effective IT and FinOps teams align their MACC with broader strategic goals. Open source support and security maintenance is a priority for enterprises, as a recent Linux Foundation report shows: 54% of enterprises want long-term guarantees, and 53% expect rapid security patching.

Ubuntu Pro offers both. By choosing software that strengthens your security and operations, you can retire your MACC while funding capabilities your organization prioritizes.

Allocating MACC to Ubuntu Pro is a direct investment in your open source estate:

Expanded Security Maintenance (ESM): extend security coverage to the critical open source applications running above the operating system layer. ESM provides up to 15 years of security updates for the OS, plus tens of thousands of packages. You might already see alerts for these missing updates in your Azure portal – learn how to check your exposure in our blog: [A complete security view for every Ubuntu LTS VM on Azure].
Kernel Livepatch: reduce maintenance windows by applying critical kernel patches without requiring a reboot for most workloads.
Compliance tooling: access options for CIS hardening and FIPS 140-3 validated cryptographic modules to support meeting compliance and regulatory needs.
Optional enterprise support: add enterprise SLAs, direct access to Canonical engineers for break-fix and bug-fix, and guidance on operating Ubuntu and ESM-covered packages on Azure.

By choosing Ubuntu Pro, you convert your MACC spend into a maintained open source foundation across the development lifecycle.

Maximize value and streamline procurement

Retiring your commitment should be financially efficient and administratively simple. While standard Marketplace listings are MACC-eligible, many organizations use private offers to secure tailored commercial terms, like custom pricing or volume discounts, without sacrificing eligibility.

We support both standard private offers and multiparty private offers for rollouts involving resellers in the US/UK. In all cases, checking that your purchase counts toward your commitment is straightforward:

Confirm Eligibility: verify the listing or private offer is marked as “Azure benefit-eligible.”
Purchase Correctly: execute the transaction in the Azure portal under the tenant and subscription tied to your MACC agreement.

This approach guarantees that every dollar spent satisfies your financial goals while delivering the specific security coverage your organization needs.

Ready to align Ubuntu Pro with your MACC? Talk to our team.

Ubuntu Studio: Coming to 26.04 LTS: Three Layouts

Thu, 11 Dec 2025 18:41:20 +0000

Xfce Legacy

A lot of people have asked us why Ubuntu Studio comes with a panel on top as the default. For that, it’s a simple answer: Legacy.

When Ubuntu Studio 12.04 LTS (Precise Pangolin) released over 13 years ago, it was released with a top panel by default as that was the default for our desktop envirionment: Xfce.

Fast-forward eight years to 20.10 and Xfce was no longer our default desktop environment: we had switched to KDE’s Plasma Desktop. Plasma has a bottom panel by default, similar to Windows. However, to ease the transition for our long-time users, we kept the panel on top by default, resizing it to be similar to the default top panel of Xfce.

A macOS-Like Layout

With 25.10’s release, we included an additional layout: two panels. One panel is on top with a global menu, and the bottom contains some default applications, a trash can, and a full-screen application launcher. This is a way to feel familiar to those with a similar layout from where they may be coming from, being an operating system for creativity: macOS.

Familiarity and Traditionalism: Windows-like Layout

Starting with 26.04 LTS, we’ll also include one more layout: a bottom, Windows 10-like layout. This is to ease the transition for those coming from Windows, and due to popular request and reports.

Should We Change The Default?

It has been 13 years since we defaulted to a top panel, but is that the right idea anymore?

Right now, on the Ubuntu Discourse, we have a poll to decide if we should change the default layout starting with 26.04 LTS. This will not affect layouts for anyone upgrading from a prior release, but only new installations or new users going forward.

If you would like to participate in the poll, head on over to the Ubuntu Discourse and cast a vote!

Podcast Ubuntu Portugal: E368 Ensino De TIC, Com Artur Coelho

Thu, 11 Dec 2025 00:00:00 +0000

Desta feita, raptámos…errr…recebemos um convidado muito especial: Artur Coelho. Professor de TIC, formador, apaixonado pela educação e criatividade com robótica, IA, 3D e programação de software, mantém uma visão crítica, actual e informada sobre o ensino das Tecnologias de Informação e Comunicação (TIC) nas escolas portuguesas - onde foi pioneiro na introdução de diversas tecnologias e construiu um percurso invejável, influenciando positivamente um grande número de alunos e professores. A conversa foi tão longa e interessante que vamos tentar rapt…convidá-lo outra vez no futuro.

Já sabem: oiçam, subscrevam e partilhem!

Artur Coelho:
- https://masto.pt/@arturcoelho
- https://intergalacticrobot.blogspot.com/
- https://3dalpha.blogspot.com/
ANPRI: https://anpri.edu.pt/
O Robô Anprino:
- https://www.anpri.pt/anprino/index.php/componentes-do-robot/
- https://sketchfab.com/3d-models/anprino-f2c430c0b17d4124b7824ec8b3bf5670
Fundação Microbit para a educação:
- https://microbit.org/
- https://microbit.org/projects/make-it-code-it/
- https://microbit.org/buy/
Pocket Code: https://catrobat.org/pocket-code/
Scratch: https://scratch.mit.edu/about
Ubuntu Touch: https://www.ubuntu-touch.io/
Sessão sobre Ubuntu Touch no LCD Porto (27 e 29 de Novembro): https://porto.ectl.softwarelivre.eu/pt/schedule/2025/
«Ubuntu Touch e o seu ecossistema», com Diogo Constantino e António Aragão: https://youtu.be/GCiLd02G74g
Uncomplicated Firewall (UFW): https://wiki.ubuntu.com/UncomplicatedFirewall
Gufw, UFW com interface gráfico: https://help.ubuntu.com/community/Gufw
Debian 13 Trixie: https://www.debian.org/releases/trixie/
KDE Plasma 6: https://kde.org/announcements/megarelease/6/
Noughty Linux:
- https://noughtylinux.org/
- https://github.com/noughtylinux
Nicholas Negroponte: https://en.wikipedia.org/wiki/Nicholas_Negroponte
Seymour Papert:
- Sítio internet: http://papert.org/
- Obras publicadas: http://papert.org/works.html
- Biografia: https://en.wikipedia.org/wiki/Seymour_Papert
- «20 coisas para fazer com um computador» (Papert, Seymour A.; Solomon, Cynthia, 1971): https://dspace.mit.edu/handle/1721.1/5836
OLPC: https://en.wikipedia.org/wiki/One_Laptop_per_Child
Magalhães (Intel Classmate) PC: https://en.wikipedia.org/wiki/Classmate_PC
Linux Caixa Mágica: https://en.wikipedia.org/wiki/Linux_Caixa_M%C3%A1gica
Alberto, o dicionário aberto: https://snapcraft.io/alberto
Projecto Natura: https://natura.di.uminho.pt/wiki/doku.php?id=ProjectoNatura
Faruk, uma mascote de Luís Louro para o Software Freedom Day: https://digitalfreedoms.org/en/sfd/blog/sfd-mascot-challenge-winners-2025
Sobre Wernher Von Braun: https://youtu.be/TjDEsGZLbio
O foguetão Vergeltungswaffe 2: https://youtu.be/jePOQuFTXy4
LoCo PT: https://loco.ubuntu.com/teams/ubuntu-pt/
Mastodon: https://masto.pt/@pup
Youtube: https://youtube.com/PodcastUbuntuPortugal

Atribuição e licenças

Este episódio foi produzido por Diogo Constantino, Miguel e Tiago Carrondo e editado pelo Senhor Podcast. O website é produzido por Tiago Carrondo e o código aberto está licenciado nos termos da Licença MIT. (https://creativecommons.org/licenses/by/4.0/). A música do genérico é: “Won’t see it comin’ (Feat Aequality & N’sorte d’autruche)”, por Alpha Hydrae e está licenciada nos termos da CC0 1.0 Universal License. Os separadores de péssima qualidade foram tocados ao vivo e sem rede pelo Miguel, pelo que pedimos desculpa pelos incómodos causados. Este episódio está licenciado nos termos da licença: Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0), cujo texto integral pode ser lido aqui. Estamos abertos a licenciar para permitir outros tipos de utilização, contactem-nos para validação e autorização. A arte de episódio foi criada pelo Luís Louro - a mascote Faruk - vencedora do terceiro lugar no concurso de mascote para o Software Freedom Day.

Salih Emin: Fix Broken Updates: uCareSystem New Release uCareSystem v25.12

Sat, 06 Dec 2025 15:59:58 +0000

Let’s be honest. Dealing with broken updates is a nightmare. We’ve all experienced that moment of panic when you run an update, step away for coffee, and return to a terminal screen full of angry red error messages. That is exactly why uCareSystem exists, and today, it gets even better at preventing these issues.

Fix Broken Updates: uCareSystem New Release

I’m thrilled to announce the latest release of uCareSystem. As the sole developer, I feel the pain of broken updates personally. For this version, I spent a lot of time under the hood, focusing on making sure the tool doesn’t just work when everything is perfect, but proactively fixes issues before they break your system.

Here is why you should upgrade to the new version and say goodbye to broken updates for good:

Prevent Broken Updates with Pre-flight Checks

The most frustrating broken updates are the ones that fail because of something that happened last week.

The new uCareSystem introduces automated pre-flight checks. Think of it as a bouncer for your update process. Before it lets any new packages in, it checks the ID of your system to prevent broken updates. It now automatically detects and attempts to fix:

Those annoying stale dpkg locks that require a reboot.
Installations that were interrupted (ghosts of updates past).
Broken dependencies that threaten to ruin your day.

The goal is simple: You press the button, and it actually works.

A UI Upgrade for Better Monitoring

While staring at scrolling walls of monochrome text makes us feel like hackers in a 90s movie, it’s not great for spotting errors.

I’ve given the uCareSystem terminal interface a significant makeover. With improved color coding, better progress indicators, and real-time output logging, you’ll now have a much clearer idea of the process, helping you catch potential issues that could lead to broken updates.

Robustness: Avoiding Broken Updates in Containers

Linux runs everywhere now. To keep up, uCareSystem needs to be flexible.

Containers & WSL: I’ve improved systemd detection so the tool plays nicely even in environments like Docker containers and Windows Subsystem for Linux (WSL).
Internet Reality Check: I added better connectivity checks. Trying to download updates without a stable connection is a common cause of broken updates, and we now handle that gracefully.
Auto-Recovery: If a dpkg process trips and falls midway, the software now has mechanisms to help pick it back up automatically.

Spring Cleaning the Code with ShellCheck

For the code-peepers out there who like to look under the hood: I did some massive spring cleaning. Extensive refactoring and complying with ShellCheck standards mean the codebase is now cleaner and safer. This ensures better maintainability and fewer bugs in the future.

Give the new version a spin. Hopefully, it makes your system maintenance totally boring—and completely free of broken updates.

By the Numbers

This was a significant undertaking, reflected in the statistics for this release:

38 files changed:
2,030 additions,
718 deletions

Please take a look to a comprehensive Release note in the repository: https://github.com/Utappia/uCareSystem/releases/tag/v25.12.04

This release is a testament to my commitment to quality and my vision for the future of uCareSystem as a one-stop system maintenance tool Debian Ubuntu. I am confident that I laid a stronger foundation that will allow for even more exciting features and faster development in the future.

I am deeply grateful to the community members who supported the previous development cycle through donations or code contributions:

P. Laoughman (Thanks for your continued support)
W. Schreinemachers (Thanks for your continued support)
D. Luchini (Thanks for your continued support)
M. Van Hoof
Frankie P.
M. Ryser
Th. Ploumis
M. Stade
K. J. Rasmussen

Every version, has also a code name dedicated as a release honored to one of the contributors. For historical reference, you can check all previous honored releases.

Where can I download uCareSystem ?

As always, I want to express my gratitude for your support over the past 15 years. I have received countless messages from inside and outside Greece about how useful they found the application. I hope you find the new version useful as well.

If you’ve found uCareSystem to be valuable and it has saved you time, consider showing your appreciation with a donation. You can contribute via PayPal or Debit/Credit Card by clicking on the banner.

Pay what you want	Maybe next time
Click the donate button and enter the amount you want to donate. Then you will be navigated to the page with the latest version to download the installer	If you don’t want to Donate this time, just click the download icon to be navigated to the page with the latest version to download the installer

Once installed, the updates for new versions will be installed along with your regular system updates.

The post Fix Broken Updates: uCareSystem New Release uCareSystem v25.12 appeared first on Utappia.

Colin Watson: Free software activity in November 2025

Thu, 04 Dec 2025 17:55:59 +0000

My Debian contributions this month were all sponsored by Freexian. I had a bit less time than usual, because Freexian collaborators gathered in Marseille this month for our yearly sprint, doing some planning for next year.

You can also support my work directly via Liberapay or GitHub Sponsors.

OpenSSH

I began preparing for the second stage of the GSS-API key exchange package split (some details have changed since that message). It seems that we’ll need to wait until Ubuntu 26.04 LTS has been released, but that’s close enough that it’s worth making sure we’re ready. This month I just did some packaging cleanups that would otherwise have been annoying to copy, such as removing support for direct upgrades from pre-bookworm. I’m considering some other package rearrangements to make the split easier to manage, but haven’t made any decisions here yet.

This also led me to start on a long-overdue bug triage pass, mainly consisting of applying usertags to lots of our open bugs to sort them by which program they apply to, and also closing a few that have been fixed, since some bugs will eventually need to be reassigned to GSS-API packages and it would be helpful to make them easier to find. At the time of writing, about 30% of the bug list remains to be categorized this way.

Python packaging

I upgraded these packages to new upstream versions:

aioftp
basemap (fixing Cython 3.1 compatibility)
billiard
black
django-phonenumber-field
flask-security
flufl.i18n
langtable
mariadb-connector-python
peewee (fixing Cython 3.1 compatibility)
pydantic
pydantic-core
pydantic-settings
pylsqpack
pymongo
pymssql
pyodbc
python-auditwheel (contributed follow-up fix upstream)
python-avro
python-bleach
python-btrees
python-certifi
python-charset-normalizer
python-colorlog
python-django-channels
python-django-constance
python-django-contact-form
python-django-hashids
python-djvulibre (fixing Cython 3.1 compatibility)
python-evalidate
python-legacy-cgi
python-openstep-plist (fixing Cython 3.1 compatibility)
python-pytest-run-parallel
python-pytokens
python-tblib
python-webargs
pyupgrade
sqlfluff
trove-classifiers
ttconv
wcwidth
zope.hookable
zope.i18nmessageid (removing run-time dependency on setuptools)
zope.interface
zope.proxy
zope.security (removing run-time dependency on setuptools)
zope.sqlalchemy

I packaged django-pgtransaction and backported it to trixie, since we plan to use it in Debusine; and I adopted python-certifi for the Python team.

I fixed or helped to fix several other build/test failures:

kivy
mypy
pytest-mypy-testing (contributed upstream)
python-cytoolz
python-discord
python-ncls, fixing some failures in pyranges
pyxdg
traitlets
twine

I fixed a couple of other bugs:

Other bits and pieces

Code reviews

base-passwd: French translation (merged and uploaded)
cdebconf: Consider using the standard dh sequence in d/rules (merged and uploaded)
cdebconf: Multiple select is not right aligned in Hebrew (patch fails to build; asked reporter for an update)
cdebconf: Allow building without libglib2.0-dev (merged and uploaded)
pydantic-core (merged and uploaded)
pymongo (sponsored adoption by Aryan Karamtoth)
python-maturin: Add missing build dependencies (merged and uploaded)

Stéphane Graber: Announcing Incus 6.19

Mon, 01 Dec 2025 17:17:41 +0000

The Incus team is pleased to announce the release of Incus 6.19!

This is a slightly less busy release than usual as we’ve recently been spending quite a bit of time smoothing some of the initial rough edges from the IncusOS release.

That said, it still contains quite a few nice improvements and quite a lot of bugfixes!

The highlights for this release are:

Initial SELinux support
Improved Windows agent support
Serial devices in the resources API
Bandwidth limits on OVN NICs
Support for multi-object deletion in most CLI commands
Ability to turn off passthrough of PCI firmware to VM
PKCS12 generation in the CLI
Option for raw units in CLI CSV output

The full announcement and changelog can be found here.
And for those who prefer videos, here’s the release overview video:

You can take the latest release of Incus up for a spin through our online demo service at: https://linuxcontainers.org/incus/try-it/

And as always, my company is offering commercial support on Incus, ranging from by-the-hour support contracts to one-off services on things like initial migration from LXD, review of your deployment to squeeze the most out of Incus or even feature sponsorship. You’ll find all details of that here: https://zabbly.com/incus

Donations towards my work on this and other open source projects is also always appreciated, you can find me on Github Sponsors, Patreon and Ko-fi.

Enjoy!

Launchpad News: Introducing Webhooks for Package Uploads in PPAs

Mon, 01 Dec 2025 09:02:23 +0000

We have extended our webhooks capabilities to be able to trigger webhooks on successful and unsuccessful package uploads to Personal Package Archives (PPAs).

When a new source package is uploaded to one of your PPAs, the system can now send an instant webhook notification to an endpoint you control. This will make it easier to build automations around package uploads and binary package builds in your PPAs.

The webhook configuration includes scopes so you can configure to only trigger on successful use cases, or vice versa. Each webhook payload includes essential metadata about the upload – more details in the Webhooks page of our user documentation.

To try it out, you can add a webhook to your archive via the API (API reference), or via the UI by going to “Manage Webhooks” in your archive’s page.

If you have ideas or feedback, reach out to us!

Podcast Ubuntu Portugal: E367 a Todo O Vapor

Thu, 27 Nov 2025 00:00:00 +0000

Nesta semana e seguintes, vamos apostar no Ubuntu Touch e trazer o Software Livre nos telefones para as massas! O Miguel resolveu problemas com a ajuda da comunidade, o Diogo vai ao Porto evangelizar à bruta com o Ruben Carneiro e o sol brilhará para todos nós. A Canonical promete suporte para 15 anos; o Xubuntu foi hackeado porque não usa Hugo (womp, womp); o Miguel agora usa mano e bro em cada frase por causa de impressoras e vai converter-se ao Debian com Plasma e MEU DEUS, AS MÁQUINAS DA STEAM SÃO LINDAS!! FUUUUYYYYYOOOOH!!!

Já sabem: oiçam, subscrevam e partilhem!

Ubuntu Touch: https://www.ubuntu-touch.io/
Sessão sobre Ubuntu Touch no LCD Porto (27 e 29 de Novembro): https://porto.ectl.softwarelivre.eu/pt/schedule/2025/
Ruben Carneiro: https://rubencarneiro.github.io/rubencarneiro.io/
Bugs do UT no Gitlab: https://gitlab.com/ubports/development/ubuntu-touch
Pesquisar sem IA: https://noai.duckduckgo.com
Canon Pixma, controladores para Linux: https://www.canon.pt/support/consumer/products/printers/pixma/ts-series/pixma-ts3150.html?type=drivers&os=Linux%20(64-bit)
CUPS? Temos tudo: https://openprinting.github.io/cups/
Mais apps? Não, obrigado: https://youtu.be/kfgtqNrGAFs
Câmara da UBports: https://open-store.io/app/camera.ubports
Manigâncias para o Mistério da Câmara Desaparecida: https://forums.ubports.com/topic/10425/camera-app-cannot-be-installed/30
Podcat: https://open-store.io/app/podcat.cibersheep
Podbird: https://open-store.io/app/com.mikeasoft.podbird
Debian 13 Trixie: https://www.debian.org/releases/trixie/
KDE Plasma 6: https://kde.org/announcements/megarelease/6/
João Gabriel Ribeiro (Shifter.pt): https://shifter.pt/author/joao-gabriel-ribeiro/
Uncle Roger, embaixador da cozinha oriental, originário da Malásia: https://www.youtube.com/channel/UCVjlpEjEY9GpksqbEesJnNA
Tio Roger num casamento Bengali em Sintra: https://youtu.be/wJoLjhgguwA
O site do Xubuntu foi hackeado e distribuiu malware:
- https://www.omgubuntu.co.uk/2025/10/xubuntu-website-malware-hack
- https://www.omgubuntu.co.uk/2025/11/xubuntu-website-breach-report
- https://lists.ubuntu.com/archives/xubuntu-users/2025-November/012210.html
A Canonical oferece suporte para 15 anos:
- https://discourse.ubuntu.com/t/foundations-team-updates-2025-11-20/72480/3?u=d0od
- https://www.omgubuntu.co.uk/2025/11/ubuntu-lts-releases-15-years-of-support
- https://ubuntu.com/blog/canonical-expands-total-coverage-for-ubuntu-lts-releases-to-15-years-with-legacy-add-on
Steam da Valve; hardware para fartura de jogos em Linux: https://store.steampowered.com/sale/hardware
Steam Machine:
- https://youtu.be/VkW3wTHT-p8
- https://youtu.be/g3FkuZNSGkw
Steam Frame:
- https://youtu.be/b7q2CS8HDHU
- https://youtu.be/dU3ru09HTng
NeXT computer (1988): https://en.wikipedia.org/wiki/NeXT_Computer
LoCo PT: https://loco.ubuntu.com/teams/ubuntu-pt/
Mastodon: https://masto.pt/@pup
Youtube: https://youtube.com/PodcastUbuntuPortugal

Atribuição e licenças

Este episódio foi produzido por Diogo Constantino, Miguel e Tiago Carrondo e editado pelo Senhor Podcast. O website é produzido por Tiago Carrondo e o código aberto está licenciado nos termos da Licença MIT. (https://creativecommons.org/licenses/by/4.0/). A música do genérico é: “Won’t see it comin’ (Feat Aequality & N’sorte d’autruche)”, por Alpha Hydrae e está licenciada nos termos da CC0 1.0 Universal License. Os separadores de péssima qualidade foram tocados ao vivo e sem rede pelo Miguel, pelo que pedimos desculpa pelos incómodos causados. Os efeitos sonoros têm os seguintes créditos: [patrons laughing.mp3 by pbrproductions] (https://freesound.org/s/418831/) – License: Attribution 3.0. Concurso: [01 WINNER.mp3 by jordanielmills] – (https://freesound.org/s/167535/) – License: Creative Commons 0. Este episódio e a imagem utilizada estão licenciados nos termos da licença: Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0), cujo texto integral pode ser lido aqui. Estamos abertos a licenciar para permitir outros tipos de utilização, contactem-nos para validação e autorização. A arte de episódio foi criada por encomenda pela Shizamura - artista, ilustradora e autora de BD. Podem ficar a conhecer melhor a Shizamura na Ciberlândia e no seu sítio web.

Balint Reczey: Think you can’t interpose static binaries with LD_PRELOAD? Think again!

Thu, 20 Nov 2025 20:56:17 +0000

Well, you are right, you can’t. At least not directly. This is well documented in many projects relying on interposing binaries, like faketime.

But what if we could write something that would take a static binary, replace at least the direct syscalls with ones going through libc and load it with the dynamic linker? We are in luck, because the excellent QEMU project has a user space emulator! It can be compiled as a dynamically linked executable, honors LD_PRELOAD and uses the host libc’s syscall – well, at least sometimes. Sometimes syscalls just bypass libc.

The missing piece was a way to make QEMU always take the interposable path and call the host libc instead of using an arch-specifix assembly routine (`safe_syscall_base`) to construct the syscall and going directly to the kernel. Luckily, this turned out to be doable. A small patch later, QEMU gained a switch that forces all syscalls through libc. Suddenly, our static binaries started looking a lot more dynamic!

$ faketime '2008-12-24 08:15:42'  qemu-x86_64 ./test_static_clock_gettime
2008-12-24 08:15:42.725404654
$ file test_static_clock_gettime 
test_clock_gettime: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, ...

With this in place, Firebuild can finally wrap even those secretive statically linked tools. QEMU runs them, libc catches their syscalls, LD_PRELOAD injects libfirebuild.so, and from there the usual interposition magic happens. The result: previously uncachable build steps can now be traced, cached, and shortcut just like their dynamic friends.

There is one more problem though. Why would the static binaries deep in the build be run by QEMU? Firebuild also intercepts the `exec()` calls and now it rewrites them on the fly whenever the executed binary would be statically linked!

$ firebuild -d comm bash -c ./test_static
...
FIREBUILD: fd 9.1: ({ExecedProcess 161077.1, running, "bash -c ./test_static", fds=[0: {FileFD ofd={FileO
FD #0 type=FD_PIPE_IN r} cloexec=false}, 1: {FileFD ofd={FileOFD #3 type=FD_PIPE_OUT w} {Pipe #0} close_o
n_popen=false cloexec=false}, 2: {FileFD ofd={FileOFD #4 type=FD_PIPE_OUT w} {Pipe #1} close_on_popen=fal
se cloexec=false}, 3: {FileFD NULL} /* times 2 */]})
{
    "[FBBCOMM_TAG]": "exec",
    "file": "test_static",
    "// fd": null,
    "// dirfd": null,
    "arg": [
        "./test_static"
    ],
    "env": [
        "SHELL=/bin/bash",
 ...
        "FB_SOCKET=/tmp/firebuild.cpMn75/socket",
        "_=./test_static"
    ],
    "with_p": false,
    "// path": null,
    "utime_u": 0,
    "stime_u": 1017
}
FIREBUILD: -> proc_ic_msg()  (message_processor.cc:782)  proc={ExecedProcess 161077.1, running, "bash -c 
./test_static", fds=[0: {FileFD ofd={FileOFD #0 type=FD_PIPE_IN r} cloexec=false}, 1: {FileFD ofd={FileOF
D #3 type=FD_PIPE_OUT w} {Pipe #0} close_on_popen=false cloexec=false}, 2: {FileFD ofd={FileOFD #4 type=F
D_PIPE_OUT w} {Pipe #1} close_on_popen=false cloexec=false}, 3: {FileFD NULL} /* times 2 */]}, fd_conn=9.
1, tag=exec, ack_num=0
FIREBUILD:   -> send_fbb()  (utils.cc:292)  conn=9.1, ack_num=0 fd_count=0
Sending message with ancillary fds []:
{
    "[FBBCOMM_TAG]": "rewritten_args",
    "arg": [
        "/usr/bin/qemu-user-interposable",
        "-libc-syscalls",
        "./test_static"
    ],
    "path": "/usr/bin/qemu-user-interposable"
}
...
FIREBUILD: -> accept_ic_conn()  (firebuild.cc:139)  listener=6
...
FIREBUILD: fd 9.2: ({Process NULL})
{
    "[FBBCOMM_TAG]": "scproc_query",
    "pid": 161077,
    "ppid": 161073,
    "cwd": "/home/rbalint/projects/firebuild/test",
    "arg": [
        "/usr/bin/qemu-user-interposable",
        "-libc-syscalls",
        "./test_static"
    ],
    "env_var": [
        "CCACHE_DISABLE=1",
...
        "SHELL=/bin/bash",
        "SHLVL=0",
        "_=./test_static"
    ],
    "umask": "0002",
    "jobserver_fds": [],
    "// jobserver_fifo": null,
    "executable": "/usr/bin/qemu-user-interposable",
    "// executed_path": null,
    "// original_executed_path": null,
    "libs": [
        "/lib/x86_64-linux-gnu/libatomic.so.1",
        "/lib/x86_64-linux-gnu/libc.so.6",
        "/lib/x86_64-linux-gnu/libglib-2.0.so.0",
        "/lib/x86_64-linux-gnu/libm.so.6",
        "/lib/x86_64-linux-gnu/libpcre2-8.so.0",
        "/lib64/ld-linux-x86-64.so.2"
    ],
    "version": "0.8.5.1"
}

The QEMU patch is forwarded to qemu-devel. If it lands, anyone using QEMU user-mode emulation could benefit — not just Firebuild.

For Firebuild users, though, the impact is immediate. Toolchains that mix dynamic and static helpers? Cross-builds that pull in odd little statically linked utilities? Previously “invisible” steps in your builds? All now fair game for caching.

Firebuild 0.8.5 ships this new capability out of the box. Just update, make sure you’re using a patched QEMU, and enjoy the feeling of watching even static binaries fall neatly into place in your cached build graph. Ubuntu users can get the prebuilt patched QEMU packages from the Firebuild PPA already.

Static binaries, welcome to the party!

Colin Watson: Free software activity in October 2025

Sun, 09 Nov 2025 15:33:33 +0000

About 95% of my Debian contributions this month were sponsored by Freexian.

You can also support my work directly via Liberapay or GitHub Sponsors.

OpenSSH

OpenSSH upstream released 10.1p1 this month, so I upgraded to that. In the process, I reverted a Debian patch that changed IP quality-of-service defaults, which made sense at the time but has since been reworked upstream anyway, so it makes sense to find out whether we still have similar problems. So far I haven’t heard anything bad in this area.

10.1p1 caused a regression in the ssh-agent-filter package’s tests, which I bisected and chased up with upstream.

10.1p1 also had a few other user-visible regressions (#1117574, #1117594, #1117638, #1117720); I upgraded to 10.2p1 which fixed some of these, and contributed some upstream debugging help to clear up the rest. While I was there, I also fixed ssh-session-cleanup: fails due to wrong $ssh_session_pattern in our packaging.

Finally, I got all this into trixie-backports, which I intend to keep up to date throughout the forky development cycle.

Python packaging

For some time, ansible-core has had occasional autopkgtest failures that usually go away before anyone has a chance to look into them properly. I ran into these via openssh recently and decided to track them down. It turns out that they only happened when the libpython3.13-stdlib package had different versions in testing and unstable, because an integration test setup script made a change that would be reverted if that package was ever upgraded in the testbed, and one of the integration tests accidentally failed to disable system apt sources comprehensively enough while testing the behaviour of the ansible.builtin.apt module. I fixed this in Debian and contributed the relevant part upstream.

We’ve started working on enabling Python 3.14 as a supported version in Debian. I fixed or helped to fix a number of packages for this:

cxxopt
cython
m2crypto
pymongo (already fixed by Alexandre Detiste, but after checking this I took the opportunity to simplify its arrangements for disabling broken tests and to switch to autopkgtest-pkg-pybuild)
python-cytoolz
python-lz4
python-msgspec

I upgraded these packages to new upstream versions:

aiomysql (fixing CVE-2025-62611)
audioread
bitstruct
black (fixing a build failure)
blake3-py
buildbot (fixing a regression)
cxxopt
django-cte
django-pipeline
django-q
isort
khard
lazy-object-proxy (fixing a build failure)
psycopg3 (fixing a build failure)
pydantic
pydantic-core
pydantic-extra-types
pytest-mock
pytest-rerunfailures
python-bcrypt
python-bitarray
python-confluent-kafka (#1089748)
python-crispy-bootstrap4
python-crispy-bootstrap5
python-django-mptt
python-ewoksppf (fixing a build failure)
python-greenlet (fixing a build failure on powerpc and a Python 3.14 build failure)
python-gssapi
python-holidays
python-persistent
python-pyluach
python-pytest-asyncio
python-pytest-run-parallel
python-pytokens (contributed supporting fix upstream)
python-semantic-release
python-stdlib-list
python-tblib
python-telethon
python-treq
python-typing-inspection
python-watchfiles
pyupgrade
rpds-py (fixing a build failure)
zope.hookable
zope.schema
zope.testrunner (removing run-time dependency on setuptools)

I packaged python-blockbuster and python-pytokens, needed as new dependencies of various other packages.

Santiago Vila filed a batch of bugs about packages that fail to build when using the nocheck build profile, and I fixed several of these (generally just a matter of adjusting build-dependencies):

pastedeploy (#1116833)
python-ewokscore (#1116858)
python-ewoksdask (#1116859)
python-ewoksorange (#1116862)
python-odmantic (#1116866)
python-processview (#1116871)
python-semantic-release (#1116881)
sqlfluff (#1116916)

I helped out with the scikit-learn 1.7 transition:

I fixed or helped to fix several other build/test failures:

beangulp (contributed upstream)
beanquery
buildbot (contributed upstream)
celery (contributed upstream)
cython (only on i386; involved a rather slow bisection process first)
django-measurement
django-select2
ocrmypdf (partial investigation, still open)
poetry-plugin-export
pytest-aiohttp
python-aiohttp-session
python-cups (cross-building)
python-django-postgres-extra (actually needed a fix in python-django)
python-fabio
python-jellyfish (contributed upstream)
python-maturin (thanks to a patch from Peter Michael Green in #1115459)
python-requests-oauthlib
python-telethon
python-webargs
silx
sphinx-inline-tabs

I fixed some other bugs:

I investigated a python-py build failure, which turned out to have been fixed in Python 3.13.9.

I adopted zope.hookable and zope.location for the Python team.

Following an IRC question, I ported linux-gpib-user to pybuild-plugin-pyproject, and added tests to make sure the resulting binary package layout is correct.

Rust packaging

Another Pydantic upgrade meant I had to upgrade a corresponding stack of Rust packages to new upstream versions:

rust-idna
rust-jiter
rust-pyo3
rust-regex
rust-regex-automata
rust-speedate
rust-uuid

I also upgraded rust-archery and rust-rpds.

Other bits and pieces

I fixed a few bugs in other packages I maintain:

I investigated a malware report against tini, which I think we can prove to be a false positive (at least under the reasonable assumption that there isn’t malware hiding in libgcc or glibc). Yay for reproducible builds!

I noticed and fixed a small UI deficiency in debbugs, making the checkboxes under “Misc options” on package pages easier to hit. This is merged but we haven’t yet deployed it.

I notced and fixed a typo in the Being kind to porters section of the Debian Developer’s Reference.

Code reviews

base-passwd: Add clock group (rejected)
debbugs: Fix dep8 autopkgtests, make Salsa CI fully green (reviewed, awaiting revisions)
python-gmpy2: FTBFS (sponsored fix for Martin Kelly)

Stéphane Graber: Introducing IncusOS!

Fri, 07 Nov 2025 09:33:48 +0000

After over a year of work, I’m very excited to announce the general availability of IncusOS, our own immutable OS image designed from the ground up to run Incus!

IncusOS is designed for the modern world, actively relying on both UEFI Secure Boot and TPM 2.0 for boot security and for full disk encryption. It’s a very locked down environment, both for security and for general reliability. There is no local or remote shell, everything must be done through the (authenticated) Incus API.

Under the hood, it’s built on a minimal Debian 13 base, using the Zabbly builds of both the Linux kernel, ZFS and Incus, providing the latest stable versions of all of those. We rely a lot on the systemd tooling to handle image builds (mkosi), application installation (sysext), system updates (sysupdate) and a variety of other things from network configuration to partitioning.

I recorded a demo video of its installation and basic usage both in a virtual machine and on physical hardware:

Full release announcement: https://discuss.linuxcontainers.org/t/announcing-incusos/25139

The Fridge: Ubuntu Weekly Newsletter Issue 916

Mon, 03 Nov 2025 23:53:15 +0000

Welcome to the Ubuntu Weekly Newsletter, Issue 916 for the week of October 26 – November 1, 2025. The full version of this issue is available here.

In this issue we cover:

Upgrades to 25.10 (Questing Quokka) are now live!
Ubuntu Stats
Hot in Support
Other Meeting Reports
Upcoming Meetings and Events
LoCo Events
Ubuntu Project docs: That’s a wrap!
Introducing architecture variants: amd64v3 now available in Ubuntu 25.10
[Ubuntu Studio] Upgrading from 25.04 to 25.10
Other Community News
What Say You
Ubuntu Cloud News
Canonical News
In the Press
In the Blogosphere
In Other News
Featured Audio and Video
Updates and Security for Ubuntu 22.04, 24.04, 25.04 and 25.10
And much more!

The Ubuntu Weekly Newsletter is brought to you by:

Krytarik Raido
Bashing-om
Chris Guiver
Wild Man
irihapeti
And many others

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Scarlett Gately Moore: A New Chapter: Career Transition Update

Fri, 31 Oct 2025 15:38:55 +0000

I’m pleased to share that my career transition has been successful! I’ve joined our local county assessor’s office, beginning a new path in property assessment for taxation and valuation. While the compensation is modest, it offers the stability I was looking for.

My new schedule consists of four 10-hour days with an hour commute each way, which means Monday through Thursday will be largely devoted to work and travel. However, I’ll have Fridays available for open source contributions once I’ve completed my existing website maintenance commitments.

Open Source Priorities

Going forward, my contribution focus will be:

Ubuntu Community Council
Kubuntu/Debian
Snap packages (as time permits)

Regarding the snap packages: my earlier hope of transitioning them to Carl hasn’t worked out as planned. He’s taken on maintaining KDE Neon single-handedly, and understandably, adding snap maintenance on top of that proved unfeasible. I’ll do what I can to help when time allows.

Looking for Contributors

If you’re interested in contributing to Kubuntu or helping with snap packages, I’d love to hear from you! Feel free to reach out—community involvement is what makes these projects thrive.

Thanks for your patience and understanding as I navigate this transition.

Ubuntu Studio: Upgrading from 25.04 to 25.10

Wed, 29 Oct 2025 20:08:52 +0000

An issue has been identified

The Ubuntu Release team has now enabled upgrades from 25.04 to 25.10! This is great news! In fact, you may have noticed this icon on your toolbar and a notification to upgrade.

However, upon doing so, you may have noticed something a little more unfortunate:

Yep, we know. This tells you nothing about what is wrong. What is wrong is slightly more technical. As it turns out, the backend application that actually performs the upgrade removed an argument from its command line unannounced during the Plucky Puffin release cycle, approximately a year ago.

As our project leader, Erich Eickmeyer, maintains the upgrade notifier widget for both Ubuntu Studio and Kubuntu, he woke up and immediately got to work identifying what’s wrong and how to patch the Plasma widget in question to correctly execute the upgrade process. He has uploaded the fix, and it was accepted by a member of the Ubuntu Stable Release Updates team.

At the moment, the fix needs to be tested and verified. In order to test it, one must install the fix from the plucky-proposed repository. In order for it to be available, it must build for all architectures and, as of this writing, is awaiting building on riscv64 which has a 40-hour backlog.

The Workaround

If you wish to begin the upgrade process manually rather than waiting on the upgrade notifier fix to be implemented, feel free to make sure you are fully updated, type alt-space to execute Krunner, and paste this:

do-release-upgrade -f DistUpgradeViewKDE

This is the exact command that will be executed by the notifier widget as soon as it is updated.

Of course, if you’re in no hurry, feel free to wait until the notifier is updated and use that method. Do bear in mind, though, that as of this writing, you have exactly 90 days to perform the upgrade to 25.10 before your system will no longer be supported. At that time, you’ll risk being unable to upgrade at all unless certain procedures for End-Of-Life Upgrades are done, which can be tedious for those uncomfortable in a command line as it will require modifying system files.

Mea Culpa

We do apologize for the inconvenience. Testing upgrade paths like this are hard to do and things go missed, especially when teams don’t communicate with each other. We’re try to identify things before they happen but, unfortunately, certain items cannot be foreseen.

This issue has now been added to the Ubuntu Studio 25.10 Release Notes.

Launchpad News: Make fetch service opt-in

Tue, 28 Oct 2025 11:31:12 +0000

Launchpad Builders do not have direct access to the Internet. To reach external resources, they must acquire an authentication token that allows access to a restricted set of URLs via a proxy. This can either be a custom authenticated builder proxy or the fetch service.

The fetch service is a custom sophisticated context-aware forward proxy. Whereas the builder proxy allows requests to allowlisted URLs, the fetch service also keeps track of requests and dependencies for a build.

Users can now opt-in to use the fetch service while building snaps, charms, rocks and sourcecraft packages. You can read more about the fetch service here.

Why is the fetch service important?

To achieve traceability and reproducibility, artifact dependencies retrieved during a build must be identified. The fetch service mediates network access between the build host and the outside world, examining the request protocol, creating a manifest of the downloaded artifacts, and keeping a copy of the artifacts for archival and metadata extraction for each package build.

How to use the fetch service?

To be able to use the fetch service, users must opt-in. For snaps, charms, rocks and sourcecraft packages, the use_fetch_service flag should be set to true in the API. For snaps and charms, this setting is also available in the Edit Recipe UI page.

The fetch service can be run in two modes, “strict” and “permissive”, where it defaults to the former. Both modes only allow certain resources and formats, as defined by inspectors which are responsible for inspecting the requests and the various downloads that are made during the build, ensuring that the requests are permitted.

The “strict” mode errors out if any restrictions are violated. The “permissive” mode works similarly, but only logs a warning when encountering any violations. The mode can be configured using the fetch_service_policy option via the API. For snaps and charms, the mode can also be selected from a dropdown on the Edit Recipe UI page.

When to use the fetch service?

Use the fetch service when you need to keep track of requests and dependencies for a build, e.g., when you need to verify that the artifacts belong to secure, trusted sources.

The Fridge: Ubuntu Weekly Newsletter Issue 915

Mon, 27 Oct 2025 21:51:36 +0000

Welcome to the Ubuntu Weekly Newsletter, Issue 915 for the week of October 19 – 25, 2025. The full version of this issue is available here.

In this issue we cover:

Enabling updates on Ubuntu 25.10 systems
[Updated] Questing Quokka Release Notes
Resolute Raccoon is now open for development
Ubuntu Stats
Hot in Support
Rocks Public Journal; 2025-21-10
Other Meeting Reports
Upcoming Meetings and Events
Vote result: LoCo rebranding and rescoping resolution
Discover your fully open source robotics observability at ROSCon 2025
Ubuntu 25.10 Release Party @ Taipei
LoCo Events
TPM-backed FDE: Take 2 minutes to help widen Ubuntu compatibility with your TPM configuration!
Canonical’s new design system : towards a design system ontology
Other Community News
Canonical News
In the Press
In the Blogosphere
Other Articles of Interest
Featured Audio and Video
Updates and Security for Ubuntu 22.04, 24.04, 25.04 and 25.10
And much more!

The Ubuntu Weekly Newsletter is brought to you by:

Krytarik Raido
Bashing-om
Chris Guiver
Wild Man
Cristovao Cordeiro (cjdc) – Rocks
irihapeti
And many others

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Paul Tagliamonte: It's NOT always DNS.

Mon, 27 Oct 2025 17:15:00 +0000

I’ve written down a new rule (no name, sorry) that I’ll be repeating to myself and those around me. “If you can replace ‘DNS’ with ‘key value store mapping a name to an ip’ and it still makes sense, it was not, in fact, DNS.” Feel free to repeat it along with me.

Sure, the “It’s always DNS” meme is funny the first few hundred times you see it – but what’s less funny is when critical thinking ends because a DNS query is involved. DNS failures are often the first observable problem because it’s one of the first things that needs to be done. DNS is fairly complicated, implementation-dependent, and at times – frustrating to debug – but it is not the operational hazard it’s made out to be. It’s at best a shallow take, and at worst actively holding teams back from understanding their true operational risks.

IP connectivity failures between a host and the rest of the network is not a reason to blame DNS. This would happen no matter how you distribute the updated name to IP mappings. Wiping out all the records during the course of operations due to an automation bug is not a reason to blame DNS. This, too, would happen no matter how you distribute the name to IP mappings. Something made the choice to delete all the mappings, and it did what you asked it to do

There’s plenty of annoying DNS specific sharp edges to blame when things do go wrong (like 8.8.8.8 and 1.1.1.1 disagreeing about resolving a domain because of DNSSEC, or since we’re on the topic, a DNSSEC rollout bricking prod for hours) for us to be cracking jokes anytime a program makes a DNS request.

We can do better.

Julian Andres Klode: Sound Removals

Sat, 18 Oct 2025 19:37:17 +0000

Problem statement

Currently if you have an automatically installed package A (= 1) where

A (= 1) Depends B (= 1)
A (= 2) Depends B (= 2)

and you upgrade B from 1 to 2; then you can:

Remove A (= 1)
Upgrade A to version 2

If A was installed by a chain initiated by Recommends (say X Rec Y, Y Depends A), the solver sometimes preferred removing A (and anything depending on it until it got).

I have a fix pending to introduce eager Recommends which fixes the practical case, but this is still not sound.

In fact we can show that the solver produces the wrong result for small minimal test cases, as well as the right result for some others without the fix (hooray?).

Ensuring sound removals is more complex, and first of all it begs the question: When is a removal sound? This, of course, is on us to define.

An easy case can be found in the Debian policy, 7.6.2 “Replacing whole packages, forcing their removal”:

If B (= 2) declares a Conflicts: A (= 1) and Replaces: A (= 1), then the removal is valid. However this is incomplete as well, consider it declares Conflicts: A (< 1) and Replaces: A (< 1); the solution to remove A rather than upgrade it would still be wrong.

This indicates that we should only allow removing A if the conflicts could not be solved by upgrading it.

The other case to explore is package removals. If B is removed, A should be removed as well; however it there is another package X that Provides: B (= 1) and it is marked for install, A should not be removed. That said, the solver is not allowed to install X to satisfy the depends B (= 1) - only to satisfy other dependencies [we do not want to get into endless loops where we switch between alternatives to keep reverse dependencies installed].

Proposed solution

To solve this, I propose the following definition:

Definition (sound removal): A removal of package P is sound if either:

A version v is installed that package-conflicts with B.
A package Q is removed and the installable versions of P package-depends on Q.

where the other definitions are:

Definition (installable version): A version v is installable if either it is installed, or it is newer than an installed version of the same package (you may wish to change this to accomodate downgrades, or require strict pinning, but here be dragons).

Definition (package-depends): A version v package-depends on a package B if either:

there exists a dependency in v that can be solved by any version of B, or
there exists a package C where v package-depends C and any (c in C) package-depends B (transitivity)

Definition (package-conflicts): A version v package-conflicts with an installed package B if either:

it declares a conflicts against an installable version of B; or
there exists a package C where v package-conflicts C, and b package-depends C for installable versions b.

Translating this into a (modified) SAT solver

One approach may be to implement the logic in the conflict analysis that drives backtracking, i.e. we assume a package A and when we reach not A, we analyse if the implication graph for not A constitutes a sound removal, and then replace the assumption A with the assumption A or "learned reason.

However, while this seems a plausible mechanism for a DPLL solver, for a modern CDCL solver, it’s not immediately evident how to analyse whether not A is sound if the reason for it is a learned clause, rather than a problem clause.

Instead we propose a static encoding of the rules into a slightly modified SAT solver:

Given c1, …, cn that transitive-conflicts A and D1, …, Dn that A package-depends on, introduce the rule:

A unless c1 or c2 or ... cn ... or not D1 or not D2 ... or not Dn

Rules of the form A... unless B... - where A... and B... are CNF - are intuitively the same as A... or B..., however the semantic here is different: We are not allowed to select B... to satisfy this clause.

This requires a SAT solver that tracks a reason for each literal being assigned, such as solver3, rather than a SAT solver like MiniSAT that only tracks reasons across propagation (solver3 may track A depends B or C as the reason for B without evaluating C, whereas MiniSAT would only track it as the reason given not C).

Is it actually sound?

The proposed definition of a sound removal may still proof unsound as I either missed something in the conclusion of the proposed definition that violates my goal I set out to achieve, or I missed some of the goals.

I challenge you to find cases that cause removals that look wrong :D

Kubuntu General News: Kubuntu 25.10 “Questing Quokka” Released:

Fri, 10 Oct 2025 13:48:07 +0000

October 9, 2025 – The Kubuntu team is thrilled to announce the release of Kubuntu 25.10, codenamed “Questing Quokka”!

As a community-driven flavor of Ubuntu, Kubuntu continues its mission to deliver the cutting-edge KDE software ecosystem on top of Ubuntu’s rock-solid foundation. This interim release, aligned with Ubuntu’s six-month cycle, packs in the freshest updates to Plasma, Frameworks, and applications, ensuring a smooth, performant desktop experience for millions of users worldwide.

Building on the Ubuntu 25.10 base released today by Canonical, Kubuntu 25.10 introduces Plasma 6.4 as the flagship update, alongside Qt 6.9, KDE Frameworks 6.17.0, and the latest KDE Gear 25.08 suite.

We’ve also upgraded to Linux kernel 6.17 for enhanced hardware support and efficiency. Whether you’re a developer, creator, or everyday user, this release emphasizes Wayland adoption, modern security, and seamless integration with the open source world.

Kubuntu remains completely free to download, use, and share—empowering our global community to innovate without barriers. Download it now from kubuntu.org/getkubuntu and join the conversation in our forums or IRC channels.

Three Exciting New Features for Kubuntu Users

Here are three standout enhancements that Kubuntu 25.10 brings to your desktop, designed to make your workflow faster, more secure, and visually stunning:

KDE Plasma 6.4: A Refined and Responsive Desktop Dive into the fifth feature release of Plasma 6, complete with Qt 6.8 and Frameworks 6.17.0. This update refines the desktop with smoother animations, improved widget customization, and better multi-monitor handling. It’s a big win for productivity, letting you tailor your environment like never before while enjoying the stability of Ubuntu’s core.
Plasma Wayland as Default Session Say goodbye to legacy X11 limitations—Wayland is now the go-to session for superior graphics rendering, reduced latency, and enhanced security. With hardware-accelerated compositing baked in, you’ll notice snappier video playback and app responsiveness. (X11 fans, no worries: it’s still available via a simple package install.) This shift future-proofs your setup for the next era of Linux desktops.
Rust-Powered sudo-rs for Safer System Management Leveraging Ubuntu’s new memory-safe implementations, Kubuntu defaults to sudo-rs—a Rust-based reimplementation of sudo. It slashes vulnerabilities common in traditional tools, making privilege escalation quicker and more secure without compromising usability. Paired with NTS-enabled NTP for tamper-proof time syncing, your system stays locked down while you focus on what matters.

What’s New Under the Hood

Beyond these highlights, Kubuntu 25.10 inherits Ubuntu’s robust platform upgrades:

Linux Kernel 6.17: Better Arm and RISC-V support, nested virtualization, and Intel TDX for confidential computing—ideal for developers and edge deployments.
Updated Developer Tools: OpenJDK 25, Python 3.14 RC3, Golang 1.25, GCC 15, and Rust 1.85 (with 1.88 available) to supercharge your coding sessions.
Enhanced Security and Accessibility: Experimental TPM-backed full disk encryption with recovery options, improved Bluetooth audio (AAC codecs via restricted extras), and broader accessibility features to meet global standards.
KDE Applications Galore: Everything from Dolphin file manager to Konsole terminal refreshed to 25.08 versions, plus legacy Qt5/KF5 support for your favorite older apps.

This release underscores Kubuntu’s commitment to being at the heart of the open source ecosystem—pushing boundaries with KDE while riding Ubuntu’s reliable waves. A huge thank you to our volunteer contributors, testers, and the upstream KDE team for making this possible.

Ready to quokka-hop into the future? Upgrade today or install fresh. Questions? Head to https://discourse.ubuntu.com/c/flavors/kubuntu/187 or ping us on Matrix at #kubuntu:matrix.org.

Stay tuned for the Ubuntu Summit on October 23-24, where we’ll showcase more on Kubuntu’s role in open source innovation

P.S New updated website coming soon…. keep an eye on kubuntu.org for when we switch

Erich Eickmeyer: Why I Won’t Be Attending or Speaking at Ubuntu Summit 25.10

Thu, 09 Oct 2025 22:01:09 +0000

Ubuntu Summit’s decision to go exclusively online, with the exception of those speaking at the Summit in London, UK, is anti-collaborative and turns its back on the very people who make Ubuntu what it is: its community of volunteers and developers. Ubuntu Summit was created from the dust of the Ubuntu Developer Summit in 2022 to recognize the community. It no longer serves that purpose.

As many know, I have been the lead of Ubuntu Studio for more than 7 years. I’m the longest-tenured Ubuntu Studio lead. I owe much of the foundation that was built to my predecessors: Luke Yelavich (founder), Scott Lavender, Kaj Ailomaa, and Set Halstrom. It is a true labor of love for me, and is the foundation for much of what I do.

I have worked myself through the ranks of Ubuntu, becoming a small-time packager for a small set of Ubuntu packages, then the Ubuntu Studio packageset, moving up to MOTU (Master of the Universe). I also served on the Ubuntu Community Council and am a current Discourse moderator.

Community and the love of people is a huge motivation for me. Granted, for those first four years, I hadn’t ever met the people I was collaborating with to make Ubuntu Studio what it is.

Then in August 2022, I was invited to attend the first ever Ubuntu Summit 2022 in Prague, Czechia. Having never travelled abroad before and never having even been off the continent of North America, itself a challenge as getting a U.S. passport is neither cheap nor easy, I was reluctant at first. Then I managed to get my passport, as well as the funds and passports to bring my wife and son to Ubuntu Summit.

That experience changed my life and the life of my entire family. My son, 10 at the time, was the youngest registered attendee. My wife was inspired to bring back Edubuntu, which had been defunct for nine long years by the time it was revived that following spring.

These are the things that happen when you have personal connections with people. If you’ve never read the book before, I encourage you to read Hardwired to Connect, which is a research paper published by a bunch of scientists. In essence, it says that people’s brains are wired, from birth, to engage in communities in for personal, in-person connections. It’s a scientific study that took years and is an excellent introduction to why we are the way we are.

Much of my education revolves around the very idea of building personal communities, which is one reason I was appalled when Ubuntu Summit, starting with 25.10, while it would be twice a year, it would be online-only except for the speakers. Having spoken at the past three, I was planning to take a year off from speaking, while still being there to represent as an Ubuntu Flavor Lead with my wife, also a now Flavor Lead.

If it weren’t for that initial Ubuntu Summit, in person, my wife and son would not have been as interested or as involved as they are today. The subsequent years only strengthened that involvement.

Now, it’s going to be an online-focused approach. I get it. It’s cheaper and easier. Also, those attending online were just watching a livestream anyhow. The Local Communities (LoCos) can get together on their own if they want to do a big event. It’s easier to reach more people if you do everything online.

Except it’s not.

For instance, the nearest active LoCo to me, in the Seattle-Tacoma area, is the Southern California LoCo. Meetups with them are logistically impossible. Same if I were to go to the Arizona LoCo; it’s just not possible. Most of the states in the United States are huge, so if there were one LoCo per state, it wouldn’t be correct. To be honest, I have no desire, time, or energy left to start and lead a LoCo in my area. Besides that, there used to be one for my state, but it’s long gone.

Furthermore, with the exception of me and my wife, us flavor leads are scattered to the globe. It used to be that we would meet online throughout the year every other month and then meet together once a year at Ubuntu Summit. That’s gone now.

Again, I get it. Canonical is a company that is and always has been majority remote work. Except for one thing: they get together twice a year in-person, and are even given T-Shirts to celebrate the immediately-prior release which was partially built by volunteers. Those of us who give our time, energy, and effort to the Ubuntu community aren’t given that in-person experience, let alone a T-Shirt. The very lifeblood of what makes Ubuntu so great isn’t given the ability to meet in-person. That’s been stripped from us, and it came as a complete surprise.

I’m not without ideas for solutions to problems, though. Rather than be completely destructive in this post, I can be constructive. My solution to this would be a compromise:

Have the Summit be in-person once a year following the yy.04 release
- Have that one go back to being what it was. It can either have booths like 2024 did or go back to being talk/workshop-focused like years prior. It doesn’t matter, it just needs to be in-person.
Have the Summit be online once a year following the yy.10 release

I don’t think this is too much to ask. The reward of personal connections when doing something remote for most of the year is a small price to pay, no matter the cost. Personal connections are tantamount to a healthy community.

I think my compromise would prevent the Summit from dying just like the Ubuntu Developer Summit did once it went online-only. The way I see it is with the current status-quo, history is repeating itself.

I’m sure people at Canonical don’t see it this way because they meet with the people they work with the most twice a year. Those of us from the Ubuntu community that are developers aren’t given that luxury. We’re not even given that luxury once a year now. We’re not even given a T-Shirt!

Am I angry? A little. Do I feel betrayed by the very community I have given so much to over the years? Absolutely. Either way, I believe an online-only Summit is anti-collaborative in that it removes personal connections from the equation, which goes against the very fiber of my being.

Thank you for reading this, and I hope this reaches the people I’m trying to reach and have it speak for those who either won’t speak-up or don’t think they can make a difference.

Lubuntu Blog: Lubuntu 25.10 (Questing Quokka) Released!

Thu, 09 Oct 2025 14:05:30 +0000

The Lubuntu Team is proud to announce Lubuntu 25.10, codenamed Questing Quokka. Lubuntu 25.10 is the 29th release of Lubuntu, the 15th release of Lubuntu with LXQt as the default desktop environment. Download and Support Lifespan With 25.10 being an interim release, it will follow the standard non-LTS support period of nine months; this means […]

Sean Davis: Xubuntu 25.10 "Questing Quokka"

Thu, 09 Oct 2025 06:58:43 +0000

A Critical Moment and a Glimpse of the Future

Xubuntu 25.10, codenamed "Questing Quokka," is the fortieth release of the Xfce-powered Ubuntu flavor. Built on the 6.17 Linux kernel, Xfce 4.20, MATE 1.26, and GNOME 49, this release continues to deliver the fast, tightly-integrated, and user-friendly experience that Xubuntu users expect, even on modest hardware.

Today, I&aposll explore where Xubuntu stands as it approaches its twentieth anniversary and share what&aposs new (and what&aposs still rough around the edges) in this release.

Xubuntu 25.10 "Questing Quokka": A screenshot of the desktop.

A Critical Juncture

The "Questing Quokka" arrives at a pivotal time in Xubuntu&aposs history. In just six months, we&aposll celebrate Xubuntu&aposs twentieth anniversary (technically eight months: 6.06 marks the only time Ubuntu was released in June).

In recent years, our small development team has faced the same challenges as many open-source projects: contributors stepping back, real-world responsibilities growing, and less time to dedicate to day-to-day development.

Beyond that, our involvement with the upstream Xfce project has slowed. Many of us, myself included, once played major roles in shaping Xfce’s direction, contributing countless hours to its design, code, and outreach. Those efforts helped establish the strong foundation Xfce enjoys today.

While we remain proud supporters and collaborators, Xubuntu’s continued growth depends on fresh energy and new contributors. If you’ve ever wanted to make a tangible impact on an open-source desktop environment, this is your moment. Visit the Get Involved page to learn how to help with artwork, development, documentation, QA, marketing, and more.

Now, let’s look at what’s new (and what still needs work) in 25.10.

Xubuntu 25.10: A Snapshot of the Future

As mentioned, Xubuntu 25.10 ships with Xfce 4.20, GNOME 49, and MATE 1.26. Like other Ubuntu flavors, it also introduces the new Rust-based sudo-rs.

If you’re upgrading from Xubuntu 25.04, you’ll find the experience familiar. Most applications have received incremental updates, theming remains consistent, and there are few new user-facing features. The most noticeable changes this cycle? The bugs. 🐞

Known Issues (and What to Expect)

libadwaita Apps and the Case of the Missing Close Button

Late in the cycle, we discovered that several GNOME and libadwaita-based apps have empty window close buttons when using the elementary-xfce icon theme. This affects Disk Usage Analyzer (baobab), Document Scanner (simple-scan), Fonts (gnome-font-viewer), Mines (gnome-mines), and Sudoku (gnome-sudoku).

Modern GNOME applications are missing the close window icon. Can&apost see it? Neither can I.

Missing Icon for Document Scanner&aposs Scan Options

The Scan Options menu icon in Document Scanner is currently invisible. This issue has been reported upstream to the elementary-xfce GitHub tracker.

To the right of the Scan button is a menu button for the Scan Options. Invisible unless you hover it.

Flatpak Packages Cannot Be Installed

Due to a Fuse/AppArmor conflict in Ubuntu 25.10, installing Flatpak packages currently fails. Work is underway to resolve this, and Flatpak support should return soon.

Graphical SSH Agent Unavailable

Xubuntu 25.10’s graphical SSH agent isn’t functioning as expected. Without it, SSH key passphrases must be entered each time. Investigation continues, and a fix may land before the next release.

Double Network Icons (Sometimes)

Some users may see duplicate network icons, especially in virtual machines. One appears via the Xfce Indicator Plugin and the other via the Systray Plugin. Removing the Indicator Plugin resolves this... something we’re considering doing by default for 26.04.

Some users may be confused to see two network icons that look nearly identical and function the same.

Screensaver Wallpaper Discrepancy

When first locking your screen, you might notice that the lock screen wallpaper defaults to Xfce’s background instead of Xubuntu’s. Changing (and reapplying) your wallpaper fixes the mismatch.

If you lock your screen before changing your wallpaper, you&aposll be greeted by Xfce&aposs wallpaper.

Looking Ahead

At first glance, Xubuntu 25.10 might seem rough around the edges: more bugs than usual, fewer active contributors, and an LTS release on the horizon. But known issues are solvable issues. With six months until 26.04, we have time to address these challenges, polish the experience, and deliver a release worthy of Xubuntu’s twentieth anniversary.

If you want to help shape that milestone release—whether through code, documentation, design, or outreach—please reach out. Together, we can ensure Xubuntu continues to thrive for another twenty years.

Everyone can participate in the Xubuntu community on many levels, from simply giving advice to fellow Xubuntu users to becoming a maintainer of core packages. Any contribution, even the smallest, is valued.

Get Involved

Xubuntu: Xubuntu 25.10 released!

Thu, 09 Oct 2025 01:06:35 +0000

The Xubuntu team is happy to announce the immediate release of Xubuntu 25.10.

Xubuntu 25.10, codenamed Questing Quokka, is a regular release and will be supported for 9 months, until July 2026.

Xubuntu 25.10, featuring the latest updates from Xfce 4.20 and GNOME 49.

Xubuntu 25.10 features the latest Xfce 4.20 and GNOME 49 updates. Xfce 4.20 updates feature stability improvements and enhanced Wayland support, for those adventurous enough to use it. GNOME 49 apps have received further polish and are well-suited for Xubuntu. MATE 1.26 apps are still included to round out Xubuntu’s office suite.

The final release images for Xubuntu Desktop and Xubuntu Minimal are available as torrents and direct downloads from xubuntu.org/download/.

As the main server might be busy the first few days after the release, we recommend using the torrents if possible.

We want to thank everybody who contributed to this release of Xubuntu!

Highlights and Known Issues

Highlights

Xfce 4.20 components have received several stability improvements. Minor integration issues persist in Xubuntu 25.10 and will be addressed for 26.04, scheduled for release in April.
GNOME 49 apps are further refined with new features and usability improvements.

Known Issues

Some missing icons mean that libadwaita apps (modern GNOME style) have graphical glitches. Notably, the window close icons are blank (LP: #2125025), and Document Scanner is missing an icon for the scanner options (LP: #2127071).
The graphical SSH agent is unavailable due to a change in the GNOME Keyring Daemon (LP: #2125549).
Flatpak packages will refuse to install due to a conflict between AppArmor and libfuse (LP: #2122161). A fix is in progress.

Please refer to the Xubuntu Release Notes for more obscure known issues, information on affecting bugs, bug fixes, and a list of new package versions.

The main Ubuntu Release Notes cover many other packages we carry and more generic issues.

Support

For support with the release, navigate to Help & Support for a complete list of methods to get help.

David Mohammed: Ubuntu Budgie 25.10 release notes

Wed, 08 Oct 2025 17:26:51 +0000

Ubuntu Budgie 25.10 (Questing Quokka) is a Standard Release with 9 months of support by your distro maintainers and Canonical, from Oct 2025 to July 2026. These release notes showcase the key takeaways for 25.04 upgraders to 25.10. Please note – there is no direct upgrade path from 24.04.3 to 25.10; you must uplift to 24.10 first or perform a fresh install. In these release notes the areas…

Source

Julian Andres Klode: Dependency Tries

Sat, 27 Sep 2025 14:32:19 +0000

As I was shopping groceries I had a shocking realization: The active dependencies of packages in a solver actually form a trie (a dependency A|B - “A or B” - of a package X is considered active if we marked X for install).

Consider the dependencies A|B|C, A|B, B|X. In most package managers these just express alternatives, that is, the “or” relationship, but in Debian packages, it also expresses a preference relationship between its operands, so in A|B|C, A is preferred over B and B over C (and A transitively over C).

This means that we can convert the three dependencies into a trie as follows:

Solving the dependency here becomes a matter of trying to install the package referenced by the first edge of the root, and seeing if that sticks. In this case, that would be ‘a’. Let’s assume that ‘a’ failed to install, the next step is to remove the empty node of a, and merging its children into the root.

For ease of visualisation, we remove “a” from the dependency nodes as well, leading us to a trie of the dependencies “b”, “b|c”, and “b|x”.

Presenting the Debian dependency problem, or the positive part of it as a trie allows us for a great visualization of the problem but it may not proof to be an effective implementation choice.

In the real world we may actually store this as a priority queue that we can delete from. Since we don’t actually want to delete from the queue for real, our queue items are pairs of a pointer to dependency and an activitity level, say A|B@1. Whenever a variable is assigned false, we look at its reverse dependencies and bump their activity, and reinsert them (the priority of the item being determined by the leftmost solution still possible, it has now changed). When we iterate the queue, we remove items with a lower activity level:

Our queue is A|B@1, A|B|C@1, B|X@1
Rejecting A bump the activity for its reverse dependencies and reinset them: Our queue is A|B@1, A|B|C@1, (A|)B@2, (A|)B|C@2, B|X@1
We visit A|B@1 but see the activity of the underlying dependency is now 2 and remove it Our queue is A|B|C@1, (A|)B@2, (A|)B|C@2, B|X@1
We visit A|B|C@1 but see the activity of the underlying dependency is now 2 and remove it Our queue is (A|)B@2, (A|)B|C@2, B|X@1
We visit A|B@2, see the activity matches and find B is the solution.

Aaron Rainbolt: Setting up a weird dual-boot DOS workstation

Sun, 21 Sep 2025 18:04:21 +0000

I’ve been wanting to create some Bible study software for DOS for a while now. Why target DOS? Because it’s a cool platform, it’s still in use in some areas of the world, and I haven’t been able to find readily available Bible software for DOS, whether open-source or not. Over the weekend, I was thinking about this project again, and decided that, for the sake of development ease and avoiding emulator quirks, I should set up a DOS installation on physical hardware and create the software on that machine.

I have tons of old computers in varying states of decay or usefulness; three of them still work pretty well. I decided to pick the weakest of the three for this project since it probably had more than enough grunt for the project at hand, but wouldn’t be useful for much else. The chosen system was a Compaq Presario 6000 desktop, featuring some iteration of an AMD Athlon XP processor, 256 MB RAM, a 20 GB hard drive (which I was about to expand for reasons I’ll get into later), a floppy drive, and dual optical drives (only one of which works). This particular system is a bit strange since its USB controller and network card are both NVIDIA hardware, even though NVIDIA is typically associated with graphics cards. Beyond that though, the system was pretty typical for the kind of hardware you’d see in the early 2000s - all of the drives use IDE to communicate with the motherboard, and most of the expansion slots are PCI (except for a couple of mystery slots, one of them might be AGP, and another one seems to be intentionally blocked off and I can’t tell what it is). The back panel features PS/2 ports for a mouse and keyboard, a parallel port and a serial port, a VGA port for the monitor, and a few USB (probably USB 2) ports. There was also a 3Com network card installed in one of the slots, which I had put there when experimenting with OpenBSD on this system. The front panel had a couple more USB ports.

One downside of using DOS for development is a lack of good source code versioning systems. Git doesn’t exist for DOS, and I don’t have the time or willingness to learn RCS or similar (maybe I should?), so I decided I would implement version control by just copying the project every so often to a backup location, probably zipping it in the process. Anticipating that this would probably require a hefty chunk of disk space, I decided to add a 40 GB Maxtor drive taken from a Pentium 4 desktop I had laying around. Getting the drive installed was a bit of a challenge; many older computers have the drives slide out backwards into the system, but this Compaq has them slide out forward out the front of the machine. This meant I had to get the front panel off of the machine, which was hard because it was held on by four extremely stiff plastic latches that had to all be disengaged at the same time. Thankfully the plastic of the front panel was able to bend enough that I could disengage each latch individually, then keep it that way while I worked on another latch.

After getting the cover off, I had to fight with Compaq’s drive mounting hardware. Rather than just screwing the drives directly into the bay like a normal computer would, Compaq elected to use a system of rails and latches to keep the drives fully hooked into the machine. The screws had very thick heads, and were intended to slide along the rails and then latch in place once inserted far enough. As strange as this already was, there was also the problem that the secondary drive bay had a malformed rail, that was just barely too narrow for the mounting screws to actually slide in. There were also separate screw types for the optical drives and the hard drives. What I ended up doing was using optical drive screws on the Maxtor hard drive, which seemed to fit correctly and were able to latch in place. After getting this kludgy setup to work, I then remembered that I needed to set jumpers on the drives to configure them as “master” and “slave” properly, so I then took both drives out, reconfigured the jumpers, and slid them back in. After a bit of cable routing shenanigans (including removing a rather unfortunately located zip tie), I finally had both drives installed.

To confirm that I hadn’t made a total mess of my drive configuration, I decided to take some time to power the system on and check the BIOS. I had an old PS/2 Microsoft keyboard, and a small, 4:3 aspect ratio flatscreen display with a built-in VGA cable, so I decided to use those for the project. Nothing caught fire when I plugged it in and powered it on, and after getting into the BIOS settings I found that both drives appeared to be properly recognized. I also saw “Removable Media Boot”, which made me hopeful that this machine might support USB boot. I turned off a bunch of settings related to “fast startup” to minimize the chances of having issues, then saved my changes and exited.

Since I thought USB boot might work, I downloaded the FreeDOS 1.4 FullUSB and flashed it to a USB drive. Unfortunately, my hopes were soon dashed; the USB drive did not appear in the BIOS’s boot order settings. Crud.

I don’t generally like burning CD-Rs if I don’t have to, since they can’t be rewritten, they probably won’t keep being manufactured for much longer, and I only had 48 of my original stack of 50 left (oh horror!), but I didn’t see another good option at this point, so I dragged out one of the other working old computers, a Panasonic Toughbook that had an old-ish install of Void Linux on it. This particular machine looks like it’s been through a warzone, but it still works well enough, and most importantly, the CD burner in it seems to work flawlessly. In the hopes of not having to waste any further CDs in the future, I decided to burn Plop Boot Manager to the disc rather than burning FreeDOS itself. The burn went smoothly enough, the Compaq was happy to boot from it, and next thing I knew I was able to boot into FreeDOS from the USB! Woohoo!…

…or…. not. FreeDOS itself seemed to run without issues, and partitioning and formatting the drives wasn’t a problem, but for some reason FreeDOS’s installer didn’t work when booted in this way. Despite the fact that it was installing to what it considered drive D:, it kept trying to write files to drive C:, which was the read-only volume on the USB drive. This resulted in lots of “Abort, Retry, Ignore, Fail?” error messages, and while the installer did seem to work (kinda) if I just "ignored” all the errors, I didn’t trust the finished installation was going to work. I also couldn’t just sit there and press and hold the “I” key to keep ignoring errors, since doing so slowed the copy process down (probably because it was spamming the keyboard interrupt, I would guess). So, one CD-R apparently wasted. Next!

Back on the Toughbook, I used wget to download both the FreeDOS 1.4 LiveCD and BonusCD. I needed both discs, since the OS was on the LiveCD and the development tools (like the C compiler I wanted to use) was on the BonusCD. Burning the discs was pretty easy, and FreeDOS seemed much happier installing from a CD than trying to install from a USB. Soon enough I had a working FreeDOS installation, and a little bit later I had a good text editor and the Open Watcom 1.9 compiler installed.

At this point I was almost ready to sit down and start coding, but decided I had better figure out how to get data off the system before I dedicated a bunch of time working on my project. I didn’t want it to just rot on the machine it was coded on. At this point I discovered two frustrating facts:

The USB driver included with FreeDOS only works with UHCI controllers, but the controller in this system is an OHCI controller.
The network card wasn’t supported out of the box - there were packet drivers out there for it most likely, but those weren’t very useful since I couldn’t get outside data onto the machine since USB didn’t work.

(At this point one might reasonably ask why I don’t just use the floppy disk drive. That’s because I have exactly one functional computer with a floppy disk drive, that being the Compaq I was setting up. I can use floppies as storage if I’m willing to risk catastrophic data loss, but they’re useless as a data transfer mechanism. There are also OHCI drivers for DOS available online, even open-source drivers, but of course those would have to be transferred to the system in order to use them.)

At this point what a normal person probably would do is accept the fact that they’re going to have to burn some more CD-Rs, and proceed to get some USB and network drivers onto the machine. But due to being paranoid about running out of CD-Rs, that was an absolutely unacceptable solution to me. I had the OpenBSD disc I used some months ago laying around, so…

Dual-booting FreeDOS and OpenBSD didn’t end up being all that hard. For one, BSD’s partitioning system actually works really well for multibooting. Even though OpenBSD generally uses a whole bunch of partitions, it doesn’t try to create them all directly on the drive. Instead, it creates one “container” partition, and then creates a bunch of OpenBSD-specific partitions within that container, separate from the drive’s usual partitioning scheme. On top of that, the installer is pretty straightforward (once you realize that you need to skip all forms of network setup if you don’t intend to plug the machine into a network), and an OpenBSD installation without an X server or games fits in 3 GB of disk space with a bit of wiggle room to spare. I don’t expect I’ll be able to update this installation without pain, but since all I need it to do is let me move files to and from a USB drive, I don’t need to update it (and won’t be connecting it to a network).

The only really painful part of the installation process was partitioning - every operating system seems to have a radically different idea of how fdisk is supposed to work, and OpenBSD’s idea of fdisk is the most… um… interesting one I’ve seen to date. Rather than working in terms of unallocated space and partition creation, OpenBSD’s fdisk just acts as if all four partitions MBR allows for always exist at all times. You don’t create a partition, you just configure each of the partition slots you’re interested in working with. If you don’t want a partition to exit, you set its type code to “00” (unused). If you do want a partition to exist, you set its type code to whatever’s appropriate for your use case, define a start and end sector, and you’re done. I’m guessing this is probably a more accurate model of how MBR actually works, but it was nonetheless surprising to me. More surprising is that there don’t seem to be any safeguards to make sure you don’t do something completely ridiculous like define partitions that overlap each other, or put sector 0 as part of a partition. OpenBSD’s fdisk also does not try to guess things like how large you want the partition to be, so you have to calculate everything by hand and double-check your work to keep from making a mess. To be honest, I actually kind of like this system, it was just very unexpected.

After fighting with the partitioner a bit, I made a 3 GB partition at the end of the 40 GB Maxtor drive to install OpenBSD to. The remaining 37 GB would still be dedicated to a FAT32 DOS system. (In retrospect, I wish I had split the drive 50-50 between DOS and OpenBSD so I could play with both, and in all likelihood I’ll probably go back and do that at some point in the future, but this is the setup I have now.) Once that was done, OpenBSD installed just fine…

…and then I realized that the BIOS in this machine doesn’t allow me to specify which hard drive I want to boot from. The boot order settings fail to list the secondary drive anywhere, and there’s no boot menu button.

Thankfully there was a good workaround. Remember the Plop Boot Manager disc I burned near the beginning of this ordeal? Turns out it had no problem recognizing all of the partitions on all of the drives in this system. All I have to do is just leave the Plop CD in the bootable drive, and then I can choose whether i want to boot into FreeDOS or OpenBSD effortlessly.

That pretty much describes where my setup is at so far. I have been able to successfully transfer files between my main work laptop and the FreeDOS system using this OpenBSD “shim”. I haven’t gotten USB working in FreeDOS yet, and I haven’t managed to get either of the network cards to work yet, but the system does work, and I had a lot of fun using “edit” and “fed” to write up a README.TXT for the Bible software project that inspired this whole endeavor. There’s still more to do for setting up the workstation though:

I really would like to have working USB in FreeDOS. There’s a Panasonic driver floating around the Internet that people claim to have success with, I’ll probably end up using that.
I should replace the broken optical drive. Then I can have both Plop Boot Manager and the FreeDos 1.4 BonusCD inserted at the same time, which would make life quite a bit easier.
I’m already regretting only giving OpenBSD 3 GB of space on the secondary drive. I’d like to be able to use it to chat on IRC, which means connecting it to the Internet, which means keeping it up-to-date, so I’ll probably repartition the drive, allocate 20 GB to OpenBSD, and leave 20 GB for DOS. Even that’s probably huge, but we’ll find out. (I don’t intend to connect FreeDOS to the Internet since I’m a bit scared of the security issues of doing that.)
Embarrassingly, I’m using a Chromebook to let me look at Open Watcom’s documentation in a web browser. I should set things up so that I can read the documentation from within DOS itself.

Other than the above points though, the system is working quite well, and I’m happy with it. Hopefully I won’t end up spending so much time setting it up that I never use it for its intended purpose! :P

Lubuntu Blog: Lubuntu Questing Beta Released!

Thu, 18 Sep 2025 21:42:05 +0000

Thanks to all the hard work from our contributors, Lubuntu 25.10 Beta has been released. With the codename Questing Quokka, Lubuntu 25.10 will be the 29th release of Lubuntu, the fifteenth release of Lubuntu with LXQt as the default desktop environment. Support lifespan With 25.10 being an interim release, it will follow the standard non-LTS […]

Jonathan Riddell: Adios Chicos, 25 Years of KDE

Sun, 14 Sep 2025 20:56:35 +0000

It was the turn of the millenium when I got my first computer fresh at university. Windows seemed uninteresting, it was impossible to work out how it worked or write programs for it. SuSE Linux 6.2 was much more interesting to try and opened a world of understanding how computers worked and wanting to code on them. These were the days of the .com boom and I went to big expos in London where they showered you with freebies and IBM competed with SuSE and Red Hat for the biggest stall. IBM said that Linux had made it on the server and now was going to take over the desktop so I realised that working with KDE would be a good idea. And as a novice coder it was very perfect for learning Qt and how open development worked and I loved the free software ideals. Going to the pre-Akademy conference (it was called Kastle then) in Nove Hrady was a great intro to the community in person and in some ways I learnt more about software development in a week there then my years at uni.

So clearly this was a good way to make a career. I dossed around for a year until the Quaker geek collective heard tale of an African Spaceman who was funding a new Linux distro called SSDS (Shuttleworth’s Super Secret Debian Startup) so I got into Debian packaging and made a point that KDE should be involved. Before long they came knocking and I went to the first Ubuntu conference in Australia. I spent about ten amazing years brining KDE to Ubuntu or bringing Ubuntu to KDE for what was already called Kubuntu (not my name choice), a successful community project I’m really proud of. At one point Nokia wanted to use it alongside Plasma Active to sell on a tablet thing along with phones, this could well have taken over the world but y’know, iPhone happened and Kubuntu never found a commercial use after that although it still gets used in big places like Google or the City of Munich or Weta digital (watch those Hobbit DVD extras). I loved being invited out to Nigeria or India to give talks and spread the world of open software. Looking back there’s probably a million business cases that would have been possible but I’m not the best at being a future visionary. Eventually Canonical decided to stop funding it which is fair enough.

But then Blue Systems came along, another nice guy with deep pockets wanting to help and we carried on. When Canonical decided to kill off lots of community projects we came up with the idea of moving directly into KDE to make KDE neon. It has always been crazy how open source communities like KDE are reliant on separate companies to take their software out to the world so we wanted to change that, and I like to think we succeeded. Using CI systems we could create a much more manageable setup. Still the system was never as resiliant as it should have been and several times KDE neon ended up shipping a duff update which will have been very painful for users. We had three people working full time on it at the start but before long it was just me and a volunteer and the quality suffered as a result.

Last winter I drove to the Blue Systems schoße for a routine conference and was organising people to give talks when the guy who pays us started off by saying he was dying and the company would be shutting down. Which was very sad but it makes sense to end it on a high. After years of having no business modal and not knowing what the aims of the company were, which caused several people to genuinely go mad, we finally had a business model of sorts with Valve paying us to make Plasma up to the standards needed to ship it as Desktop Scope on the Valve Steam Deck games console. Nate had been given advanced notice of the company shutting down and had already started another company, Tech Paladin, to take on the business. Shouldn’t this be run as a cooperative we wondered? No that was too complex he said. The next day I ended up at a funeral for some German accountants and when I came back there had been some more discussion and we watched a video about Igalia who make the other operating system for Valve. They are a cooperative socialist paradise and Nate said he’d look into doing that instead of the setup where he had full control and all the profit. It was clear there was to be no other discussion on the matter of our future.

A few weeks later we had an online meeting where I proposed a useful agenda but was ignored, instead Nate gave his updated plan for a business which was to give Dave a slice of the profit and otherwise he’d keep all the profit and all the control. So I gave my proposal I’d been working on for a company with equal ownership, equal profit, a management structure and workers rights. A couple weeks later we had anther video call but Nate called me first and told me I’d be excluded from it. No explanation was given beyond I had “made some comments and would not be happy”. If someone is telling you what your emotions that is when controlling behaviour starts to become abusive. And thus ended my 25 years with KDE.

And what of my colleagues? Surely they wouldn’t want a setup where they have no control over their professional life and all their profit goes to one person? Well dunno, they’ve stopped speaking to me. Nothing. Silence. Nil. Not so much as a “cheereo”, nor “sorry we chose the option were you got excluded” and certainly no explanation. From people who I have worked with for some twenty years in some cases that hurts. I don’t know why they stopped talking to me, I can only speculate and I don’t want to do that.

We never had workers rights at Blue Systems, we were all on self employment contracts. This will continue at Tech Paladin. It is illegal but unenforceable when done on an international setup. But employment rights are not a luxury you can chose to do without if you enjoy your job and want some more flexibility in your work day. They are fundamental and life altering rights that change people’s lives as I discovered when my adopted children were taken away from me. Nobody should be doing business with or taking money from Tech Paladin else be party to illegal workers rights abuses.

Then I started to get sad, being cut off from my life for the last 25 years was too much for me. All things come to an end and I’ve seen plenty people had to leave KDE because the money ran out or maybe they had a disagreement with someone in the project, but never a profiteering control struggle like this. I struggled to get out of bed on some days. I’ve given my life to KDE, I’ve seen it gone from a sure fire project to take over the world to being one open desktop project in a world of many to seeing the revival in recent years where we can honestly say we make some of the best software out there. I like to think I’ve been part of keeping it alive, progressing, relevant and at the forefront of commercial, government and community usage. It’s been an amazing ride full of opportunities and adventures the likes of which I’m sure my peers from my university course have never had.

But in the end I lost my friends, my colleagues, my job, my career and my family. What’s a spod who just tried to do the right thing for society to do? Dunno. For now, if you want me, you can find me surfing the endless wave whenever the sun sets over my digital nomad coliving paddleshack at the end of the world.

Sunset surfs at the digital nomad coliving paddleshack at the end of the world

Xubuntu: Guide Terbaru Slot Online, Versi Demo Tanpa Deposit, serta Platform Slot Online Gacor Versi Update

Wed, 10 Sep 2025 17:39:35 +0000

Panduan Asik Slot Online 2025

Saat ini, demo slot pragmatic semakin booming di para pecinta hiburan. Ada banyak alasan yang bikin game slot jadi favorit, mulai dari praktis dimainkan, koleksi slot bejibun, hingga hadiah besar yang bikin penasaran. Gak heran kalau slot gacor selalu jadi buruan utama bagi pemain baru maupun pemain pro.

Mengenal Game Slot

Permainan slot online adalah bentuk digital dari mesin slot klasik yang dulunya cuma ada di rumah judi. Lewat internet, setiap orang bisa menikmati slot online hanya dengan laptop mereka. Inilah alasan game slot menjadi tren, karena gampang dimengerti, fleksibel, serta bikin nagih.

Daya tarik slot online juga ada di visual kece, soundtrack epik, dan koleksi tema unik. Dari retro vibes sampai slot modern, semua ada. Bahkan banyak developer game bikin slot bertema anime. Jadi, user bisa tentuin game favorit dengan bebas.

Manfaat Slot Demo

Mode gratis berguna banget buat pemula yang baru kenal slot. Dengan mode ini, pemain bisa mengetes mekanisme slot tanpa resiko kehilangan saldo. Mereka juga bisa belajar fitur scatter. Bahkan player berpengalaman sering menggunakan demo slot untuk uji RTP sebelum main sungguhan.

Kesimpulannya, slot demo adalah alat belajar yang bikin nyaman, bukan hanya untuk player baru tapi juga user senior. Dengan begitu, saat masuk ke slot online, mereka lebih paham.

Fenomena Slot Gacor

Di kalangan penggemar slot, istilah slot hoki jadi bahan obrolan. Banyak yang yakin kalau ada periode spesial di mana slot kasih big win. Walaupun hasilnya RNG, kemenangan besar bikin pemain makin percaya ada slot gacor. Itulah kenapa akses slot gacor selalu heboh pemain.

Tips Cari Situs Slot Aman

Platform permainan slot ada banyak banget sekarang, tapi gak semuanya aman. Makanya pemain wajib cermat sebelum main. Beberapa hal penting yang patut diperhatikan antara lain:

Proteksi data biar informasi pribadi tetap terjaga.
Support 24 jam yang cepat tanggap buat bantu masalah pemain.
Review positif supaya user lebih percaya diri saat main.
Transaksi lancar agar gak ribet untuk semua pemain.

Tren Toto Slot

Game toto belakangan makin naik daun. Fitur inovatif dari jenis ini ada di bonus spesial yang seru. Berbeda dengan slot klasik, toto slot sering ngasih free spin, bikin user merasa semakin enjoy tiap kali nyoba.

Panduan Bermain Slot Santai

Supaya main makin menyenangkan, ada beberapa trik yang bisa diterapkan:

Mulai dari slot demo biar ngerti cara main dulu.
Kontrol budget dengan hati-hati, jangan terlalu napsu.
Jangan lupa, permainan slot itu bergantung hoki, jadi fokus ke hiburan daripada ngejar profit.

Penutup

Game slot digital makin seru dengan teknologi baru. Dari demo slot untuk latihan, slot mudah jackpot yang banyak dicari, sampai toto slot yang lagi trend, semua tersedia buat pengguna. Yang penting, mainlah santai, pilih situs aman, dan selalu sadari kalau keseruan lebih utama daripada cari profit.

Andrea Corbellini: Testing crash recovery features in a CI environment

Tue, 09 Sep 2025 00:05:00 +0000

About two years ago I wrote a Rust crate to fulfill this promise:

If a crash occurs while updating a file, the file either contains the old contents, or the new contents, nothing in between.

This crate essentially solves the following problem: when you update a file, generally you open it, truncate it, write to it block-by-block, and eventually close it. The problem with this process is that if a crash occurs at any point during this process (the program segfaults, the kernel panics, the machine loses power, …), your file will be left in an intermediate state where the old contents are completely lost, and the new contents are only partially written (if at all). My crate solves this problem by making file updates atomic.

This crate is publicly available as atomic-write-file and you can read its description for more details (sorry, I’m very bad at naming things).

The way the crate works is simple:

Instead of opening the target file directly, the crate opens a temporary file.
You write to the temporary file.
Once all changes are in, the temporary file contents are synced to the storage, and it is atomically renamed so that it replaces the target file.

This is not by any chance a new technique that I invented, and it’s a very common strategy to solve the problem. This technique guarantees that if a crash occurs at or before step 3, then the file will have the old contents, unchanged. If a crash occurs after step 3, then the file will have the new contents.

There’s a small caveat with this technique: if a crash occurs between steps 1 and 3, then the crate will leave behind a temporary file that occupies some space on the storage device with no purpose.

This is where Linux anonymous temporary files come into play: this Linux-specific feature allows you to create temporary files that are written on the filesystem, but are not given a path in the filesystem. If a crash occurs between step 1 and 3, the temporary file will simply be forgotten into oblivion.

Meet the opponent: btrfs

Using Linux anonymous temporary files seemed very appealing for atomic-write-file to avoid leaving leftovers behind, although I knew that they’re not the perfect solution: there’s limited support (they’re supported only on Linux, and only on some filesystems), they require the use of Linux features that may not be available all the time (the /proc filesystem), and they also have the problem that, sooner or later, they will need to be given a name if we want to be able to replace the target file, and this leaves a small time window during which we could leave some cruft behind.

But none of these are huge problems, and in fact atomic-write-file is able to do a best effort attempt at using anonymous temporary files, and reverting to regular files if that doesn’t work.

One day I was notified about an issue on using my crate on the btrfs file system: after a crash, my crate could break its promise and leave the file contents empty. I did some investigation on the issue that you can read about if you’re interested, and then fixed it.

This problem was specific to btrfs, and I argue that it’s actually caused by a btrfs bug, rather than a bug in the crate itself, but nonetheless this issue had revealed a critical flaw of my crate: I did not have any tests to check if my crate was fulfilling its promise or not!

Therefore I decided to create a small test suite for Linux to simulate crashes and inspect the contents of files after those crashes occurred on a variety of filesystems, which is what this blog post is about. This test suite now runs on my laptop and on GitHub Actions, and potentially any other CI environment.

Testing strategy

Here’s the idea I came up with: I can create a virtual machine, with a virtual storage device attached to it, and a filesystem initialized with a file. The virtual machine updates the file using atomic-write-file, and then triggers a kernel panic. After that, the file is inspected for consistency.

So here is how it works in practice: there are 3 main pieces: 1. A test binary that is responsible for updating the test file using atomic-write-file. 1. An init.sh script that runs inside the virtual machine. 1. The run-tests.sh script that puts everything together and starts up the virtual machine.

The test binary

The test binary that is a short Rust program that I can paste here:

use atomic_write_file::AtomicWriteFile;
use std::io::Write;

fn main() {
    let mut file = AtomicWriteFile::open("/test/file").expect("open failed");
    file.write_all(b"hello").expect("write failed");
    file.commit().expect("commit failed");
}

Nothing special to see here: this is the minimal code required to use atomic-write-file.

The init.sh script

The init.sh script is more interesting: this script in fact is meant to run twice. The first time it runs, init.sh will run the test binary above and trigger the kernel panic. The second time, it will read the test file contents and report them back run-tests.sh script for inspection.

Let’s take a closer look at what it does: first, it mounts the /proc and /sys virtual filesystems. These are needed for some basic system functions, and also to enable the Linux anonymous temporary file feature.

mount -t proc none /proc
mount -t sysfs none /sys

Then it mounts the filesystem containing the test file. Before it can do that, however, it needs to load the correct kernel module for the filesystem. Nothing too fancy here: the filesystem type is simply specified on the kernel command line (read through /proc/cmdline):

fstype=$(grep -Eo 'test.fs=\w+' /proc/cmdline | cut -d= -f2)
modprobe "$fstype" || true
mount -t "$fstype" /dev/sdb /test

Then, if this script is run for the first time, it will run the test executable and quit:

echo 'Running test binary'
atomic-write-file-test

init.sh (as the name suggests) is run as the init script of the virtual machine. In Linux, if the init script quits without invoking the proper shutdown sequence, the kernel will panic. So we don’t actually need to do anything special to trigger a panic. I could have inserted a echo c > /proc/sysrq-trigger line to make it more explicit, but then I figured that having that line wouldn’t be nice for people who want to test the script on their system.

You might ask: how does init.sh know if it’s the first time it gets called or the second? Again, nothing fancy here: run-tests.sh gives that hint using a kernel command line argument:

if grep -q test.verify /proc/cmdline; then
  # ...
fi

If test.verify is specified on /proc/cmdline, then it means this is the second time this script is run. In that case, the file contents are just printed on the console:

if grep -q test.verify /proc/cmdline; then
  echo 'Verifying test file contents'
  echo '-----'
  xxd /test/file
  echo '-----'
  poweroff -f
fi

This uses xxd so in case there are garbled characters on screen, we can comfortably analyze the output and figure out what happened. At the end, the system is more gracefully shut down using poweroff to avoid another kernel panic (this is not really necessary).

The run-tests.sh script

And then there’s the run-tests.sh script that crates the virtual storage, launches the virtual machine, and inspects the file contents. This is where most the complexity is, so let’s go step-by-step (the code below has been simplified from the original for readability):

The first thing it does is compiling the test binary above. The virtual machine runs in a very barebone environment, so I used static linking to avoid having to copy additional libraries like libc:

target=$(uname -m)-unknown-linux-gnu
RUSTFLAGS='-C target-feature=+crt-static' cargo build --release --features "$cargo_features" --target "$target"

Then run-tests.sh creates a minimal initramfs for the virtual machine. The initramfs is a filesystem that gets mounted by Linux early at boot. It’s generally used by Linux distributions to load the main operating system, but in my case the initramfs contains everything needed for the test. In particular, it contains:

The test binary.
The init.sh script.
BusyBox, to get the needed utilities like xxd and poweroff.
The kernel modules to mount filesystems and their dependencies.

The first 3 items are easy to set up:

cp "init.sh" -T "$initramfs_build_dir/sbin/init"
cp "atomic-write-file-test" -t "$initramfs_build_dir/bin"
cp "$(which busybox)" -t "$initramfs_build_dir/bin"
"$busybox" --install -s "$initramfs_build_dir/bin"

The kernel modules are a bit more complicated. First of all: where can we get them from? Ideally, I would have liked to download them from some minimal Linux distribution, but this turned out to be more complicated than expected. In the end, I decided to just steal them from the host operating system:

modules=/usr/lib/modules/$(uname -r)
cp -a "$modules" -t "$initramfs_build_dir/lib/modules"

while read -r mod_path; do
  if [[ "$mod_path" = *.ko.gz ]]; then
    gunzip "$mod_path" -o "$mod_path.uncompressed"
  elif [[ "$mod_path" = *.ko.xz ]]; then
    unxz "$mod_path" -o "$mod_path.uncompressed"
  elif [[ "$mod_path" = *.ko.zst ]]; then
    unzstd "$mod_path" -o "$mod_path.uncompressed"
  else
    continue
  fi
  mv "$mod_path.uncompressed" "$mod_path"
done < <(modprobe --dirname "$initramfs_build_dir" --show-depends "$filesystem_type" | grep ^insmod | cut -d' ' -f2)

What this does is copying all the module files from the host, getting all the dependencies for the filesystem module using modprobe, and then uncompressing those modules if they’re compressed (I found this much easier than adding compression support in the virtual machine). An alternative approach would be to simply decompress all the modules, but that’s much slower.

Once everything has been copied over and uncompressed, the initramfs is created:

initramfs=rootfs.img
mksquashfs "$initramfs_build_dir" "$initramfs"

Now it’s time to create the virtual storage device with the filesystem, which is a trivial task:

testfs=testfs.img
dd if=/dev/zero of="$testfs" bs=1M count=300
"mkfs.$filesystem_type" "$testfs"

Finally, we can start our VM using QEMU:

qemu=qemu-system-$(uname -m)
kernel=/boot/vmlinuz-$(uname -r)

"$qemu" \
  -kernel "$kernel" \
  -append "root=/dev/sda ro panic=-1 console=ttyS0 quiet test.fs=$filesystem_type" \
  -drive "index=0,media=disk,format=raw,file=$initramfs" \
  -drive "index=1,media=disk,format=raw,file=$testfs" \
  -no-reboot \
  -nographic

Again we’re stealing the kernel from the host operating system, which is also where the kernel modules come from. The drive with index=0 is the initramfs and will be visible as /dev/sda in the guest; the other drive with index=1 is our test storage and will be visible as /dev/sdb.

root=/dev/sda tells the kernel to boot from our initramfs image. panic=-1 tells the kernel not to reboot in case of a panic (panic=N specifies the number of seconds to wait before rebooting in case of kernel panic; specifying a negative value blocks that behavior). console=ttyS0 allows us to capture the output printed by the init script. test.fs=... is the option that init.sh is going to look for to understand what filesystem type to use.

Once that runs, the virtual machine is expected to do its job and crash with a kernel panic. We then need to restart it to verify the file contents. The QEMU command is exactly the same except for the additional test.verify option:

output=output.txt

"$qemu" \
  -kernel "$kernel" \
  -append "root=/dev/sda ro panic=-1 console=ttyS0 quiet test.fs=$filesystem_type test.verify" \
  -drive "index=0,media=disk,format=raw,file=$initramfs" \
  -drive "index=1,media=disk,format=raw,file=$testfs" \
  -no-reboot \
  -nographic \
  | tee "$output"

The output from this command is captured in a file that can be analyzed. If you remember how init.sh is written, you might have noticed that it writes the test file contents between two markers:

echo '-----'
xxd /test/file
echo '-----'

So what we have to do to verify the contents of the file is simply look for those two ----- markers, get the content in between, and parse it through xxd -r:

if [[ $(sed -n '/-----/, /-----/p' "$output" | xxd -r) = hello ]]; then
  echo "Success"
else
  echo "Failure"
  exit 1
fi

And that’s it!

Running in GitHub Actions

The next step for me was to set up some automation to make sure that my test script was run whenever I made any change to the crate. Because my project was already hosted on GitHub, I decided to go with GitHub Actions. I was a bit worried that I would have had to struggle to make it work because my script works by stealing the kernel from the host, and I thought that the GitHub runners could have some protections in place to prevent me from reading the kernel. To my surprise, there were no such restrictions. In fact, I did not have to modify a single line of code to make my tests work in GitHub Actions: check out the workflow file if you’re curious.

Result

In the end, the test suite was able to reproduce the issue with btrfs and anonymous temporary files, as well as show that the fix was working as intended. This is what it looks like (output in the screenshot was trimmed down a bit):

Output from the run-test.sh script before applying the fix, showing a failure.

Output from the run-test.sh script after applying the fix, showing a success.

Future

I’m pretty satisfied with the general approach of running in a virtual machine and simulating a crash, but the implementation has a huge limitation: because it steals the kernel from the host, it cannot simulate crashes on other kernels, operating systems, or platforms.

I think in the future I’m going to take a look at cross-rs, a cross-platform tool for Rust crates. Cross-rs works kinda in a similar way as my test suite, in that it uses QEMU emulation to run tests. Maybe I can reuse their QEMU images and tweak them to run my crash tests. If that is feasible, then I will be able to extend my test suite to all major platforms and operating systems.

Dougie Richardson: CLI Corner: rsync

Sun, 31 Aug 2025 10:38:37 +0000

Synchronise two directories, e.g. Nextcloud and an encrypted USB drive with archive, recursive, partial, and progress flags:

rsync -varP src destination

Scarlett Gately Moore: A Bittersweet Farewell: My Final KDE Snap Release and the End of an Era

Mon, 25 Aug 2025 15:42:29 +0000

Today marks both a milestone and a turning point in my journey with open source software. I’m proud to announce the release of KDE Gear 25.08.0 as my final snap package release. You can find all the details about this exciting update at the official KDE announcement.

After much reflection and with a heavy heart, I’ve made the difficult decision to retire from most of my open source software work, including snap packaging. This wasn’t a choice I made lightly – it comes after months of rejections and silence in an industry I’ve loved and called home for over 20 years.

Passing the Torch

While I’m stepping back, I’m thrilled to share that the future of KDE snaps is in excellent hands. Carlos from the Neon team has been working tirelessly to set up snaps on the new infrastructure that KDE has made available. This means building snaps in KDE CI is now possible – a significant leap forward for the ecosystem. I’ll be helping Carlos get the pipelines properly configured to ensure a smooth transition.

Staying Connected (But Differently)

Though I’m stepping away from most development work, I won’t be disappearing entirely from the communities that have meant so much to me:

Kubuntu: I’ll remain available as a backup, though Rik is doing an absolutely fabulous job getting the latest and greatest KDE packages uploaded. The distribution is in capable hands.
Ubuntu Community Council: I’m continuing my involvement here because I’ve found myself genuinely enjoying the community side of things. There’s something deeply fulfilling about focusing on the human connections that make these projects possible.
Debian: I’ll likely be submitting for emeritus status, as I haven’t had the time to contribute meaningfully and want to be honest about my current capacity.

The Reality Behind the Decision

This transition isn’t just about career fatigue – it’s about financial reality. I’ve spent too many years working for free while struggling to pay my bills. The recent changes in the industry, particularly with AI transforming the web development landscape, have made things even more challenging. Getting traffic to websites now requires extensive social media work and marketing – all expected to be done without compensation.

My stint at webwork was good while it lasted, but the changing landscape has made it unsustainable. I’ve reached a point where I can’t continue doing free work when my family and I are struggling financially. It shouldn’t take breaking a limb to receive the donations needed to survive.

A Career That Meant Everything

These 20+ years in open source have been the defining chapter of my professional life. I’ve watched communities grow, technologies evolve, and witnessed firsthand the incredible things that happen when passionate people work together. The relationships I’ve built, the problems we’ve solved together, and the software we’ve created have been deeply meaningful.

But I also have to be honest about where I stand today: I cannot compete in the current job market. The industry has changed, and despite my experience and passion, the opportunities just aren’t there for someone in my situation.

Looking Forward

Making a career change after two decades is terrifying, but it’s also necessary. I need to find a path that can provide financial stability for my family while still allowing me to contribute meaningfully to the world.

If you’ve benefited from my work over the years and are in a position to help during this transition, I would be forever grateful for any support. Every contribution, no matter the size, helps ease this difficult period: https://gofund.me/a9c55d8f

Thank You

To everyone who has collaborated with me, tested my packages, filed bug reports, offered encouragement, or simply used the software I’ve helped maintain – thank you. You’ve made these 20+ years worthwhile, and you’ve been part of something bigger than any individual contribution.

The open source world will continue to thrive because it’s built on the collective passion of thousands of people like Carlos, Rik, and countless others who are carrying the torch forward. While my active development days are ending, the impact of this community will continue long into the future.

With sincere gratitude and fond farewells,

Scarlett Moore

Andrea Corbellini: It will take decades to undo the damage done by "AI"

Wed, 20 Aug 2025 17:17:00 +0000

Many business owners in the software development industry are investing a lot into LLM bots, marketed as “generative AI”. Some of them go as far as forcing software developers to use such tools under the threat of being fired if they don’t comply. After all, why shouldn’t they? This technology has a catchy name, it produces very convincing output that sometimes is correct (or close to being correct), and companies producing these tools are very good at downplaying their limitations and at promising that the “next version” will be astonishingly better than the one before.

My day-to-day experience, and scientific research, however show a quite big problem: while senior developers get little or no gain from “generative AI” (1, 2, 3, 4), junior developers get massive boosts in productivity. Why am I describing a boost in productivity as a problem? Well, it’s simple: the new generations of software developers (the ones that are just entering the job market, and the ones that are still in school) are relying heavily on these LLM tools for nearly all work-related tasks. And, again, why shouldn’t they? The entire world is telling them to do so! And as a result of that, they are advancing without gaining any actual skill.

Me and other (ex-)coworkers have seen it first hand: a junior developer completes a task using an LLM bot. More senior developers find major problems with the result. Junior developers go back to the LLM tool asking for a fix, wasting hours or days without a positive outcome. Junior developers are becoming unable to perform tasks independently.

In addition to that, there’s a problem that I feel like is not talked about extensively: these LLM tools can only regurgitate what they’ve been trained with. They’re good at finding patterns and re-applying strategies that have been used in prior work, but by their nature they cannot create or innovate. So, if this trend continues, the new generations of software developers are not just going to be skill-less, they’re also going to be incapable of solving new problems that haven’t been seen before.

My prediction? Within 10 or 20 years, the older generation of software developers will be asked to come out of retirement to fix the unmaintainable mess created by the newer generations, and to make advancements in the information technology sector. A bit like old COBOL developers are asked to come out of retirement to maintain banking systems, but on a much larger scale. This, unless there will be advancements towards true Artificial Intelligence, or unless the current trend in education is broken.

Now don’t get me wrong: I’m not opposed to LLM bots (although I’m against calling them “AI”, because they’re very far from fulfilling the AI promise), and I think they can be very powerful tools. What I’m worried about is that new generations are being told to rely on them almost exclusively, and this can only lead to an evident skill gap. In fact, I think that if there’s a country that in the future will be able to harness the power of the LLM bots and at the same time maintain a good enough level of education, thus addressing the skill gap problem, they will be the dominant economic power of the future, because they will be able to automate tasks that are time/energy-consuming for humans, while at the same time use the human brain to innovate and advance.

Erich Eickmeyer: Raspberry Pi as a Networked Audio Interface

Tue, 19 Aug 2025 19:48:23 +0000

I haven’t posted for quite some time, and a lot has happened. For instance, my wife revived Edubuntu and my work with Ubuntu Studio now spans over 7 years.

Recently, I became the proud owner of a Behringer X-Air XR18. This became the key to opening a new business, which I’ll announce at a later date. I’m working on acquiring more equipment to make this work.

As many people know, the XR18 is a stagebox-style mixer in which the mixer is physically on the stage with no controls but controlled with an iPad or Android tablet. However, as the owner of a Behringer X-Touch, which integrates seamlessly with an X-Air mixer via either MIDI or Network connections. In my situation, this gives the ability to have a physical front-of-house setup, with a computer showing the X-Air Edit application.

However, what if I want to multi-track record or add custom effects via Ubuntu Studio? This is where it would get complicated as I would then have to run a prohibitively-long USB cable from my computer to the XR18 on the stage. This would not be ideal.

As many people know, MIDI can be routed via network, which is the way the X-Touch, XR18, and X-Air app work together. A simple WiFi router and ethernet cable wouild be a great solution to this problem, but that also leaves an Ethernet cable prone to being tripped-over by audience members (unless one were to gaff it down). So, since we’ve already got WiFi, let’s take advantage of that.

To expose the audio ports to the WiFi, we’re going to have to bridge it. But… how? Most people would tell me just to use Dante but, unfortunately, Audinate refuses to support Linux, and AES67 support in PipeWire is very young. However, it turns out, JackTrip is in the Ubuntu repositories and, as its name would imply, integrates seamlessly with JACK and, therefore, PipeWire.

Setting this up is rather simple, and I’m documenting the process here.

Prerequisites

A Raspberry Pi 4 or higher (I have a late 2023 Raspberry Pi 5)
A micro SD card (16GB or larger)
Ubuntu Server for Raspberry Pi (I used 24.04, linked here).
Optional: Ubuntu Pro (for the RealTime Ubuntu Raspberry Pi Kernel)

Here we go…

The first thing I did was install the downloaded preinstalled server image to a micro SD card. This is accomplished using Raspberry Pi Imager. I used the Snap version maintained by Dave Jones of Canonical, part of Canonical’s Raspberry Pi team. If you’ve never met Dave, he does all of his computing via Raspberry Pi, and it’s a sight to behold!

To get that, it’s as easy as sudo snap install rpi-imager.

I made sure to set the server to automatically detect my WiFi, but if you plan to use a hard Ethernet connection, this isn’t necessary. Just be sure you can SSH into the machine as this is key (pre-set a user and set the machine name).

Once the SD card is imaged, I SSH’d into the machine (ssh erich@{computer-name}.local). The first thing I did was install jackd2 and jacktrip:

sudo apt install --no-install-recommends jackd2 jacktrip

One must use the --no-install-recommends option to avoid installing unecessary graphical tools as jackd2 will want to install qjackctl which is the GUI application to control JACK. We don’t need it here. JackTrip has an option to automatically connect to all inputs and outputs, so we’ll use that here.

To automatically start JACK upon boot, I modified this systemd unit file to be custom for my setup. You’ll notice I made the buffer 256 (-p 256) with 3 periods per buffer (-n 3) as gives the highest reliablility on a USB connection. Additionally, the highest frequency an XR18 runs at is 48000 Hz, so I made sure to set the frequency there (-r 48000). Also, we want the process to run in realtime and directly to ALSA (--realtime -dalsa):

[Unit]
Description=JACK server using %i user profile
Documentation=man:jackd(1)
After=sound.target local-fs.target

[Service]
User=%i
Group=%i
#Type=notify
EnvironmentFile=-/etc/jack/alsa.conf
#EnvironmentFile=-%h/.config/jack/%i.conf
ExecStart=/usr/bin/jackd --realtime -dalsa -p 256 -n 3 -r 48000
# -d $DEVICE $DRIVER_SETTINGS
LimitRTPRIO=95
LimitRTTIME=infinity
LimitMEMLOCK=infinity
# Caution: use on memory-limited devices only
# OOMScoreAdjust=-1000

[Install]
WantedBy=multi-user.target

I installed this to /usr/lib/systemd/system/jackd@.service.

Next, I created a systemd unit file to start JackTrip. I needed this to be a server (-s), with 18 inputs and outputs (for an XR18, -n 18) and automatically connect upon start (-q auto):

[Unit]
Description=JackTrip Audio Network Service
After=network.target sound.target jackd@%i.service
Wants=network-online.target

[Service]
# Run as a specific user who has JACK permissions
User=%i
Group=%i

ExecStart=jacktrip -s -n 18 -q auto --udprt
Restart=always
RestartSec=5

# Optional: environment for JACK if needed
#Environment=JACK_NO_AUDIO_RESERVATION=1

# Give JACK/JackTrip real-time priority
LimitRTPRIO=infinity
LimitMEMLOCK=infinity

[Install]
WantedBy=multi-user.target

I installed this to /usr/lib/systemd/system/jacktrip@.service.

Next, to make sure this runs as my user, I did the following:

sudo systemctl enable jackd@erich.service
sudo systemctl enable jacktrip@erich.service

Optionally, since this will be used as a headless appliance, one can use Ubuntu Pro to get the RealTime Kernel. This is accomplished by the following with an Ubuntu One account:

pro attach
pro enable realtime-kernel

To make sure everything worked, check pro status.

You can have up to 5 machines running Ubuntu Pro for free. In my case, as an Ubuntu Member, I can have up to 50 machines for free, and this is only my third one!

Once this is done, reboot. On your other machine, install jacktrip-gui. (This will be in Ubuntu Studio 25.10 and higher by default!): sudo apt install jacktrip-gui.

Opening it, it will ask you if you want to sign in with a Virtual Studio account. This is because JackTrip allows you to collaborate across the entire internet with fellow musicians with very low latency! It’s pretty cool! However, we don’t need that for this purpose. Instead, we’re going to say “No” and simply connect to the server as a P2P client:

Enter the computer name with .local afterwards, and it should find it as long as your desktop or laptop is connected to the same network as the Raspberry Pi.

After you click “Connect”, you should see this:

As you can see, this has audio coming in from a microphone already.

Back in X-Air Edit, already connected to the mixer, I changed my routing so channels 1 and 2 were being sent to the aux, so I can then use my computer’s audio there for music from e.g. Spotify:

Next I started a Dummy Audio Device from Ubuntu Studio Audio Configuration and made it the main output for the computer. I then connected the monitor of the dummy output to channels 1 and 2 of JackTrip using Patchance:

…and VIOLA! Even testing my microphone, there was so little latency it was imperceivable.

I’m envisioning a setup like this:

I’m excited to test this further! Overall, I feel like I’ve found a way to do a Dante-less audio-over-ethernet setup that cost me nothing!

Jonathan Carter: Debian 13

Sun, 10 Aug 2025 14:53:36 +0000

Debian 13 has finally been released!

One of the biggest and under-hyped features is support for HTTP Boot. This allows you to simply specify a URL (to any d-i or live image iso) in your computer’s firmware setup and then you can boot to it directly over the Internet, so no need to download an image, write it to flash disk and then boot from the flash disk on computers made in the last ~5 years. This is also supported on the Tianocore free EFI firmware, which is useful if you’d like to try it out on QEMU/KVM.

More details about Debian 13 available on the official press release.

The default theme for Debian 13 is Ceratopsian, designed by Elise Couper. I’ll be honest, I wasn’t 100% sure it was the best choice when it won the artwork vote, but it really grew on me over the last few months, and it looked great in combination with all kinds of other things during DebConf too, so it has certainly won me over.

And I particularly like the Plymouth theme. It’s very minimal, and it reminds me of the Toy Story Trixie character, it’s almost like it helps explain the theme:

Plymouth (start-up/shutdown) theme.

Trixie, the character from Toy Story that was chosen as the codename for Debian 13.

Debian Local Team ISO testing

Yesterday we got some locals together for ISO testing and we got a cake with the wallpaper printed on it, along with our local team logo which has been a work in progress for the last 3 years, so hopefully we’ll finalise it this year! (it will be ready when it’s ready). It came out a lot bluer than the original wallpaper, but still tasted great.

For many releases, I’ve been the only person from South Africa doing ISO smoke-testing, and this time was quite different, since everyone else in the photo below tested an image except for me. I basically just provided some support and helped out with getting salsa/wiki accounts and some troubleshooting. It went nice and fast, and it’s always a big relief when there are no showstoppers for the release.

My dog was really wishing hard that the cake would slip off.

Packaging-wise, I only have one big new package for Trixie, and that’s Cambalache, a rapid application design UI builder for GTK3/GTK4.

The version in trixie is 0.94.1-3 and version 1.0 was recently released, so I’ll get that updated in forky and backport it if possible.

I was originally considering using Cambalache for an installer UI, but ended up going with a web front-end instead. But that’s moving firmly towards forky territory, so more on that another time!

Thanks to everyone who was involved in this release, so far upgrades have been very smooth!

Thomas Bechtold: Streamline Root Filesystem Modifications with chimg

Thu, 31 Jul 2025 18:15:36 +0000

During the last year I developed as a side project a new tool called chimg . That tool is useful to modify a given rootfs chroot directory in a declarative way. It can replace a kernel within a chroot, preseed snaps, install debian packages, add PPAs and more (documentation is in git but not yet published).

The nice thing about this is, that this tool can be integrated into livecd-rootfs (the tool that is usually used to build Ubuntu images) or future tools which might use the craft framework to build images. chimg automatically detects already bind-mounted filesystems (eg. /sys, /proc, …), detects already preseeded snaps and usually does that same thing that livecd-rootfs currently does when eg. replacing an already installed kernel.

Install chimg with:

sudo snap install chimg --classic

An example configuration (eg. config.yaml) to modify a rootfs chroot directory looks like this:

---
kernel: linux-aws
debs:
  - name: shim-signed
  - name: grub-pc
  - name: grub2-common
  - name: ubuntu-cloud-minimal
snap:
  assertion_brand: canonical
  assertion_model: aws-classic
  snaps:
    - name: hello
      channel: latest/stable
files:
  -
    destination: /etc/default/grub.d/70-mysettings.cfg
    content: |+
      GRUB_TIMEOUT=0

cmds_post:
  -
    cmd: |
      echo "Everything done"

This config (stored in config.yaml in this example) can be applied to a newly created (or existing) root filesystem directory. Let’s create one in /tmp/chimg-noble:

sudo mmdebstrap --variant=apt --verbose noble /tmp/chimg-noble

Let’s apply the config changes now:

sudo chimg --log-console chrootfs config.yaml /tmp/chimg-noble

That’s it. The modifications are now applied to the /tmp/chimg-noble directory.

Oliver Grawert: Rooming with Mark

Tue, 29 Jul 2025 13:26:03 +0000

Yesterday, exactly twenty years ago my mobile rang while I was walking the dog.

I had just returned from Sydney about a week ago (still battling with the last remains of my Jet-lag (I had never left Europe before!)) where I had attended the UbuntuDownUnder summit and had a 30min interview on the last day (that was literally rather like having a coffee with friends after lunch) with Mark Shuttleworth and Matt Zimmerman (back then Canonicals CTO) on a nice hotel terrace directly under a tree with a colony of flying foxes sleeping above our heads.

There was Jane Silber (CEO) on the phone, telling me: “I’m so happy to tell you you are hired! In your new role we want you to create an educational flavor of Ubuntu, there will be a debian-edu/skolelinux gathering in Bergen in Norway from the 10th to 12th of June, are you okay flying there with Mark?”

I rushed back home and told my girlfriend: “I’m hired, and I’ll fly Canonical One on my first business trip next month!” (Canonical One was the name of Marks plane). I learned the next weeks that Canonical had indeed booked a generic scheduled flight for me and we’d only meet at the venue

The flight was a disaster, after we were boarding that small 20-seater 2 prop plane that was supposed to get us from Cologne to Amsterdam and the pilot started the engine my window all of a sudden was soaked in oil. We had to stay in the plane out on the filed while the mechanics were fixing the engine for like 2-3h so indeed I missed the connection in Amsterdam and had to stay for the night instead of arriving in Bergen the evening before the event started.

When I arrived at the venue everyone was already busy hacking on stuff and I jumped right in alongside, finally meeting some users of LTSP (Linux Terminal Server Project) which I was upstream for at that time and working with them on the problems they faced in debian with it, tinkering with moodle as a teaching support system and looking at other edu software, meanwhile Mark was sitting on a bar-stool in a corner with his laptop hacking on launchpad code.

When we went to our hotel in the evening it turned out they did not have our booking at all and were completely overbooked due to a jewelry exhibition they had in the house for that week. I talked like 15min to the lady behind the counter, showed her my booking confirmation PDF on the laptop, begged and flirted a lot and eventually she told us “We do have an exhibition room that we keep as spare, it only has one bed but you can have it and we will add a folding bed”. The room was actually a normal hotel room but completely set up with wallpaper tables all around the walls.

Mark insisted to take the folding bed and I can tell you, he does not snore … (well, he didn’t back then)

This was only the first of a plethora of adventures that followed in the upcoming 20 years, that phone call clearly changed my life and the company gave me the opportunity to work with the brightest, sharpest and most intelligent people on the planet in and outside of Canonical.

It surely changed a lot over these years (when I started we were building the distro with 18 people in the distro team and did that for quite a few years before it actually got split into server, foundations, kernel and desktop teams) but it never lost its special spirit of having these exceptional people with such a high focus on bringing opensource to everyone and making it accessible to everyone.
Indeed, with growth comes the requirement to make more money to pay the people, the responsibility to give your employees a certain amount of security and persistence grows, but Canonical and especially Mark have always managed to keep the balance to not lose that focus and do the right thing in the end.

Ten years ago I said “onward to the next ten!!”, I won’t really say “onward to the next 20!” today, not because I ever plan to resign but simply because I doubt I still want to work full time when I’m 75

Thank you Mark for dragging me into this adventure and thank you for still having me! I still love the ride!!

Dimitri John Ledkov: Achieving actually full disk encryption of UEFI ESP at rest with TCG OPAL, FIPS, LUKS

noreply@blogger.com (Dimitri John Ledkov) — Mon, 28 Jul 2025 11:13:30 +0000

Achieving full disk encryption using FIPS, TCG OPAL and LUKS to encrypt UEFI ESP on bare-metal and in VMs

Many security standards such as CIS and STIG require to protect information at rest. For example, NIST SP 800-53r5 SC-28 advocate to use cryptographic protection, offline storage and TPMs to enhance protection of information confidentiality and/or integrity.

Traditionally to satisfy such controls on portable devices such as laptops one would utilize software based Full Disk Encryption - Mac OS X FileVault, Windows Bitlocker, Linux cryptsetup LUKS2. In cases when FIPS cryptography is required, additional burden would be placed onto these systems to operate their kernels in FIPS mode.

Trusted Computing Group works on establishing many industry standards and specifications, which are widely adopted to improve safety and security of computing whilst keeping it easy to use. One of their most famous specifications them is TCG TPM 2.0 (Trusted Platform Module). TPMs are now widely available on most devices and help to protect secret keys and attest systems. For example, most software full disk encryption solutions can utilise TCG TPM to store full disk encryption keys providing passwordless, biometric or pin-base ways to unlock the drives as well as attesting that system have not been modified or compromised whilst offline.

TCG Storage Security Subsystem Class: Opal Specification is a set of specifications for features of data storage devices. The authors and contributors to OPAL are leading and well trusted storage manufacturers such as Samsung, Western Digital, Seagate Technologies, Dell, Google, Lenovo, IBM, Kioxia, among others. One of the features that Opal Specification enables is self-encrypting drives which becomes very powerful when combined with pre-boot authentication. Out of the box, such drives always and transparently encrypt all disk data using hardware acceleration. To protect data one can enter UEFI firmware setup (BIOS) to set NVMe single user password (or user + administrator/recovery passwords) to encrypt the disk encryption key. If one's firmware didn't come with such features, one can also use SEDutil to inspect and configure all of this. Latest release of major Linux distributions have SEDutil already packaged.

Once password is set, on startup, pre-boot authentication will request one to enter password - prior to booting any operating systems. It means that full disk is actually encrypted, including the UEFI ESP and all operating systems that are installed in case of dual or multi-boot installations. This also prevents tampering with ESP, UEFI bootloaders and kernels which with traditional software-based encryption often remain unencrypted and accessible. It also means one doesn't have to do special OS level repartitioning, or installation steps to ensure all data is encrypted at rest.

What about FIPS compliance? Well, the good news is that majority of the OPAL compliant hard drives and/or security sub-chips do have FIPS 140-3 certification. Meaning they have been tested by independent laboratories to ensure they do in-fact encrypt data. On the CMVP website one can search for module name terms "OPAL" or "NVMe" or name of hardware vendor to locate FIPS certificates.

Are such drives widely available? Yes. For example, a common Thinkpad X1 gen 11 has OPAL NVMe drives as standard, and they have FIPS certification too. Thus, it is likely in your hardware fleet these are already widely available. Use sedutil to check if MediaEncrypt and LockingSupported features are available.

Well, this is great for laptops and physical servers, but you may ask - what about public or private cloud? Actually, more or less the same is already in-place in both. On CVMP website all major clouds have their disk encryption hardware certified, and all of them always encrypt all Virtual Machines with FIPS certified cryptography without an ability to opt-out. One is however in full control of how the encryption keys are managed: cloud-provider or self-managed (either with a cloud HSM or KMS or bring your own / external). See these relevant encryption options and key management docs for GCP, Azure, AWS. But the key takeaway without doing anything, at rest, VMs in public cloud are always encrypted and satisfy NIST SP 800-53 controls.

What about private cloud? Most Linux based private clouds ultimately use qemu typically with qcow2 virtual disk images. Qemu supports user-space encryption of qcow2 disk, see this manpage. Such encryption encrypts the full virtual machine disk, including the bootloader and ESP. And it is handled entirely outside of the VM on the host - meaning the VM never has access to the disk encryption keys. Qemu implements this encryption entirely in userspace using gnutls, nettle, libgcrypt depending on how it was compiled. This also means one can satisfy FIPS requirements entirely in userspace without a Linux kernel in FIPS mode. Higher level APIs built on top of qemu also support qcow2 disk encryption, as in projects such as libvirt and OpenStack Cinder.

If you carefully read the docs, you may notice that agent support is explicitly sometimes called out as not supported or not mentioned. Quite often agents running inside the OS may not have enough observability to them to assess if there is external encryption. It does mean that monitoring above encryption options require different approaches - for example monitor your cloud configuration using tools such as Wiz and Orca, rather than using agents inside individual VMs. For laptop / endpoint security agents, I do wish they would start gaining capability to report OPAL SED availability and status if it is active or not.

What about using software encryption none-the-less on top of the above solutions? It is commonly referred to double or multiple encryption. There will be an additional performance impact, but it can be worthwhile. It really depends on what you define as data at rest for yourself and which controls you need. If one has a dual-boot laptop, and wants to keep one OS encrypted whilst booted into the other, it can perfectly reasonable to encrypted the two using separate software encryption keys. In addition to the OPAL encryption of the ESP. For more targeted per-file / per-folder encryption, one can look into using gocryptfs which is the best successor to the once popular, but now deprecated eCryptfs (amazing tool, but has fallen behind in development and can lead to data loss).

All of the above mostly talks about cryptographic encryption, which only provides confidentially but not data integrity. To protect integrity, one needs to choose how to maintain that. dm-verity is a good choice for read-only and rigid installations. For read-write workloads, it may be easier to deploy ZFS or Btrfs instead. If one is using filesystems without a built-in integrity support such as XFS or Ext4, one can retrofit integrity layer to them by using dm-integrity (either standalone, or via dm-luks/cryptsetup --integrity option).

If one has a lot of estate and a lot of encryption keys to keep track off a key management solution is likely needed. The most popular solution is likely the one from Thales Group marketed under ChiperTrust Data Security Platform (previously Vormetric), but there are many others including OEM / Vendor / Hardware / Cloud specific or agnostic solutions.

I hope this crash course guide piques your interest to learn and discover modern confidentially and integrity solutions, and to re-affirm or change your existing controls w.r.t. to data protection at rest.

Full disk encryption, including UEFI ESP /boot/efi is now widely achievable by default on both baremetal machines and in VMs including with FIPS certification. To discuss more let's connect on Linkedin.

Jonathan Carter: DebConf25

Sat, 19 Jul 2025 17:12:49 +0000

The last two weeks I attended DebConf and DebCamp in Brest, France.

Usually, I like to do a more detailed write-up of DebConf, but I was already quite burnt out when I got here, so I’ll circle back to a few things that were important to me in later posts.

In the meantime, thanks to everyone who made this DebConf possible, whether you volunteered for one task or were part of the organisation team. Also a special thanks to the wonderful sponsors who made this entire event possible!

See you next year in Argentina!

Jellyfish, taken during daytrip at aquarium.