CTRL-OS April Update (5-Year LTS Downstream of NixOS)

With the last CTRL-OS update already being 3 months old, we thought it was time to give you an update on what we’ve been working on around long-term support for NixOS. If you’ve heard about CTRL-OS for the first time, check out our documentation or website.

CTRL-OS 26.05 (based on NixOS 26.05)

As you may know, CTRL-OS is the commercially supported downstream distribution of NixOS. Our main milestone this year is the release of CTRL-OS 26.05. CTRL-OS 26.05 will launch shortly after NixOS 26.05. People who need longer-term support than the standard NixOS release cycle can just use CTRL-OS 26.05 and will have a seamless experience when community support ends.

In the same manner as for our 24.05 release, the public version of CTRL-OS will support the release-small package set. This keeps the maintenance scope manageable and allows us to provide high-quality support with a small team. Commercial support extends this coverage based on customer needs.

We want to do LTS in a way that everyone wins, including the community. Our plan is to pass NixOS 26.05 through our distribution pipeline as CTRL-OS 26.05 (with minor additions, if necessary) as long as the upstream release-26.05 branch is community supported. We will address any issues that affect our customers (missing package/security updates, etc.) directly upstream. We will also coordinate with the Nixpkgs security team around security updates.

Once community support ends, we will continue to develop the 26.05 release in our repository, just as we are doing for 24.05.

We are aware that parts of the Nix community are cautious about commercial involvement. We’re eager to hear your feedback on our release plans!

security.ctrl-os.com

We’ve also just added a web frontend to our internal security issue tracking. This is brand new and will mature and grow from its current minimalist incarnation over the coming weeks and months.

Our security tracker is not meant to replace the Nixpkgs Security Tracker but serves different purposes and audiences. While the Nixpkgs Security Tracker is meant to coordinate work around security issues upstream, our security tracker is chiefly meant for CTRL-OS customers and their special needs around vulnerability monitoring.

We are currently exploring how to collaborate with the Nixpkgs Security Tracker. It’s early days here. We understand that CTRL-OS security is only good if NixOS security is good. As such, we will contribute to the state of SBOM and vulnerability matching via the Software Provenance Team. For interaction on the higher levels, we are still brainstorming. Ideas are welcome!

Nvidia Jetson Orin Nano Support

Our set of CTRL-OS Modules has grown another module for Nvidia Jetson Orin Nano support. This module helps you navigate the madness of Nvidia’s out-of-tree modules and makes running NixOS (or CTRL-OS :grinning_face:) on this powerful platform straightforward. We didn’t get around to writing nice documentation yet, but the module options linked above should be fairly self-explanatory. My colleagues run AI workloads with this module. I use this module to power my AArch64 remote builder.

What’s Next?

There is still enough to be done to keep us busy until the CTRL-OS 26.05 release, especially around the security tracker. I’ll definitely post another update then. After the release, we will focus on deployment topics (for example via FIDO Device Onboarding (FDO)) and Cyber Resilience Act compliance. See you then!

19 Likes

This is awesome!

We are aware that parts of the Nix community are cautious about commercial involvement. We’re eager to hear your feedback on our release plans!

Speaking for myself: I do think open-source does better when companies support it, provided they are good citizens. Your plans seem perfectly in this logic, which I really appreciate so thanks!

Will you accept communautary contributions to your 26.05 channel to other packages than the release-small package set?

2 Likes

Hi @autra! Regarding community contributions: We’ll keep the Github repo open to contributions and handle contributions as we encounter them! Right now our QA tooling runs internally and while we do have a wish to move this more onto public git forges, unfortunately it’s not there yet. That means the contribution flow will be a bit clunky in the beginning. We might also have to decline certain updates if they introduce too much risk of breakage.

What were you thinking about contributing?