All Systems Go! 2025

I'll use these 20 minutes to explain why and why contributing to systemd is a great experience. We'll avoid beating dead horses by not discussing git forges and email, but instead focus on the development experience, from building systemd distribution packages from git main, running integration tests against those distribution packages, debugging failures, writing new tests, and installing the distribution packages on real hardware to debug issues.

Let's have an open discussion with systemd developers who are at ASG and users in the audience. We will open with the developers saying what they plan to work on in the near future, and then allow questions / comments from the audience.

More than six months have passed since Daan tried to shame gently peer pressure Lennart to actually use the stuff he builds, via a FOSDEM talk:

https://fosdem.org/2025/schedule/event/fosdem-2025-4057-particleos-can-we-make-lennart-poettering-run-an-image-based-distribution-/

Did he succeed? Is dogfooding standard practice now in the systemd development process? Or do things like randomly breaking logging in GNOME (cough) still happen from time to time? Join us for this talk to find out, and to apply yet more peer pressure.

We will also spend some time talking about more boring and mundane topics, such as giving an overview of the current status of ParticleOS, and how we build it as a ready-to-consume and secure-by-default signed and self-enrolling appliance on the SUSE Open Build Service.

https://github.com/systemd/particleos
https://build.opensuse.org/package/show/system:systemd/particleos-fedora
https://build.opensuse.org/package/show/system:systemd/particleos-debian

At Meta, we've been looking to revamp our internal container runtime (Twine). Instead of maintaining all the low level container runtime code ourselves, we'd much prefer having more of this managed by systemd. This talk will go over what we did to make systemd transient units a suitable environment for running system containers (pid namespace support, cgroup namespace support, namespace delegation, ...), and why we went this route instead of reusing systemd-nspawn.