Question
Which operating-system distribution and release should this project run on?
Decision
Use Debian 13 stable as the Base release.
This replaces Debian testing. The deciding criterion is Debian’s dedicated stable security workflow: stable receives coordinated, minimally disruptive security fixes, while testing receives fixes through migration from unstable and can be delayed by transitions.
Options considered
Debian stable
Chosen as the base system. It provides a supported fixed release, a predictable package set, and dedicated security maintenance.
Debian stable with official backports
Chosen for selected packages that stable does not provide at a suitable version. Backports are rebuilt from Debian testing to run on stable; they are opt-in per package and do not turn the host into testing.
The current use case is the Hyprland desktop stack. It must be installed as a coherent backports set and tested on local hardware.
Debian testing
Rejected as the base system. It offers newer packages, but it is a rolling integration branch rather than Debian’s primary secure-server target. Security fixes can be delayed by the unstable-to-testing migration and dependency transitions.
Ubuntu
Viable, particularly where Canonical’s desktop integration or managed tooling is a better fit. It is not required for this system: Debian provides the required package model and desktop path, and changing distributions would not eliminate vendor-release, restart, or third-party-application update delays.
RHEL
A strong alternative for organizations that want paid production support, centralized fleet management, long-lived support streams, and selective kernel live patching. Its official production support and management channel is subscription-based. No-cost developer access exists but is not equivalent to paid production support.
RHEL is a separate platform decision, not automatically a faster or safer replacement for Base. It would require reworking this Debian-focused desktop stack and does not remove the upstream, activation, or reboot parts of the patch pipeline.
Community rebuilds of RHEL
Rocky Linux and AlmaLinux can be useful free RHEL-compatible systems, but they normally need Red Hat to publish a fix before they rebuild it. That can add a downstream delay compared with RHEL itself. Community-maintained does not inherently mean slow: Debian and Fedora both operate direct security/update processes.
Security delivery in an AI-accelerated environment
A zero-day has no public trusted fix, so no update channel can patch it immediately. The defensive options before a fix exists are reducing exposure and privilege, disabling an affected feature where possible, and detecting suspicious behavior.
Once a fix exists, the path is:
- Upstream fixes the vulnerable software.
- The distribution or vendor adapts, tests, signs, and publishes a package for its supported platform.
- The host downloads and installs that package.
- The affected service, application, kernel, firmware, or host is restarted when required.
The longest delay is often step 2: an upstream fix is not useful to this system until Debian or the relevant vendor publishes an applicable update. Faster polling only reduces the final discovery delay after publication; it cannot create a patch, complete QA, or activate a newly installed kernel without a reboot.
How Base receives fixes
- Debian stable, security, and official backports are the normal update channels.
- Node.js and NVIDIA are explicit upstream vendor channels for software Debian does not provide at the required version.
- Base checks these configured sources automatically and installs the available packages. A restart or reboot may still be required for protection to become active.
- Each extra source is a separate trust and update path; use only the minimum needed.
Vendor speed
There is no single fastest vendor across all software.
- A vendor directly responsible for a tightly integrated platform can often deploy its own fixes quickly: ChromeOS is the clearest example for its own devices and software.
- Windows, Ubuntu, and RHEL provide stronger centralized fleet tooling and limited live/hot patching for supported products, but they still require vendor publication and periodic reboot baselines.
- Debian stable favors focused, compatible security fixes. It is the better choice than Debian testing for this project because testing can lag on migrations, not because Debian is guaranteed to be faster than every vendor for every package.
- For applications outside the base OS, the relevant vendor is the application publisher. A browser, driver, language runtime, container image, or proprietary application may have its own faster or slower patch path.
AI-assisted remediation
No mature general-purpose desktop or server distribution currently uses autonomous agents to safely turn upstream fixes into production packages without the normal review, signing, compatibility, and activation steps.
Fedora Hummingbird is an agent-first, container-native system for AI builders with an agent-enhanced software pipeline. It is not yet a proven replacement for a general-purpose security-focused desktop or server.
Akrites
Akrites is a Linux Foundation coordination project created for the AI-accelerated vulnerability landscape. Its shared Security Incident Response Team receives confidential reports, validates and deduplicates them, coordinates maintainers and participating engineers, and supports upstream fixes before synchronized disclosure.
Akrites patches upstream open-source projects, not Debian packages. It is not an operating system, package repository, or update agent for Base. Debian is not publicly listed as a participant, and Canonical is not publicly listed among the founding participants. Debian and other distributions still decide whether and how to adapt an upstream fix, build packages, and publish updates.
Red Hat is a founding Akrites participant. Its stated role is upstream: it contributes to finding and fixing vulnerabilities at the source, strengthening the supply chain before Red Hat packages a fix for RHEL. This is a positive RHEL consideration, but not a guarantee that every RHEL fix ships first or that Base must change distributions.
Akrites can shorten upstream remediation for selected critical projects. Base would still receive any resulting fix through Debian or its explicitly configured vendor sources.
No platform removes the zero-day problem. The goal is to minimize the time from a trusted applicable fix to active protection without replacing one delay with unreviewed or untrusted updates.
Hardware and package constraints
- The GTX 1070/Pascal setup can use NVIDIA’s Debian 12 repository and DKMS; Ubuntu-specific driver packages are not required.
- Node.js 24 remains the chosen LTS runtime through its upstream repository.
- The existing Hyprland testing snapshot and pins must not be mixed into stable.
- The stable-backports Hyprland stack is a candidate migration target, but local testing is required before declaring the desktop migration complete.
Migration acceptance criteria
- Debian testing sources, snapshots, and version pins are removed.
- Debian 13 stable, security, and official backports sources are configured.
- Hyprland from official backports is tested for login, graphics acceleration, displays, input, XWayland, audio, Bluetooth, screen sharing, recording, suspend/resume, and the cursor plugin.
- The NVIDIA driver path is verified on the stable system.
Supersedes
Supersedes #3, which researched only the Ubuntu-versus-Debian NVIDIA question. Its conclusion is retained here: Debian is viable for this hardware, and Ubuntu is not required for the NVIDIA driver path.
Out of scope
Firewall rules, SSH policy, backups, monitoring, and incident recovery are separate implementation concerns.
Question
Which operating-system distribution and release should this project run on?
Decision
Use Debian 13 stable as the Base release.
This replaces Debian testing. The deciding criterion is Debian’s dedicated stable security workflow: stable receives coordinated, minimally disruptive security fixes, while testing receives fixes through migration from unstable and can be delayed by transitions.
Options considered
Debian stable
Chosen as the base system. It provides a supported fixed release, a predictable package set, and dedicated security maintenance.
Debian stable with official backports
Chosen for selected packages that stable does not provide at a suitable version. Backports are rebuilt from Debian testing to run on stable; they are opt-in per package and do not turn the host into testing.
The current use case is the Hyprland desktop stack. It must be installed as a coherent backports set and tested on local hardware.
Debian testing
Rejected as the base system. It offers newer packages, but it is a rolling integration branch rather than Debian’s primary secure-server target. Security fixes can be delayed by the unstable-to-testing migration and dependency transitions.
Ubuntu
Viable, particularly where Canonical’s desktop integration or managed tooling is a better fit. It is not required for this system: Debian provides the required package model and desktop path, and changing distributions would not eliminate vendor-release, restart, or third-party-application update delays.
RHEL
A strong alternative for organizations that want paid production support, centralized fleet management, long-lived support streams, and selective kernel live patching. Its official production support and management channel is subscription-based. No-cost developer access exists but is not equivalent to paid production support.
RHEL is a separate platform decision, not automatically a faster or safer replacement for Base. It would require reworking this Debian-focused desktop stack and does not remove the upstream, activation, or reboot parts of the patch pipeline.
Community rebuilds of RHEL
Rocky Linux and AlmaLinux can be useful free RHEL-compatible systems, but they normally need Red Hat to publish a fix before they rebuild it. That can add a downstream delay compared with RHEL itself. Community-maintained does not inherently mean slow: Debian and Fedora both operate direct security/update processes.
Security delivery in an AI-accelerated environment
A zero-day has no public trusted fix, so no update channel can patch it immediately. The defensive options before a fix exists are reducing exposure and privilege, disabling an affected feature where possible, and detecting suspicious behavior.
Once a fix exists, the path is:
The longest delay is often step 2: an upstream fix is not useful to this system until Debian or the relevant vendor publishes an applicable update. Faster polling only reduces the final discovery delay after publication; it cannot create a patch, complete QA, or activate a newly installed kernel without a reboot.
How Base receives fixes
Vendor speed
There is no single fastest vendor across all software.
AI-assisted remediation
No mature general-purpose desktop or server distribution currently uses autonomous agents to safely turn upstream fixes into production packages without the normal review, signing, compatibility, and activation steps.
Fedora Hummingbird is an agent-first, container-native system for AI builders with an agent-enhanced software pipeline. It is not yet a proven replacement for a general-purpose security-focused desktop or server.
Akrites
Akrites is a Linux Foundation coordination project created for the AI-accelerated vulnerability landscape. Its shared Security Incident Response Team receives confidential reports, validates and deduplicates them, coordinates maintainers and participating engineers, and supports upstream fixes before synchronized disclosure.
Akrites patches upstream open-source projects, not Debian packages. It is not an operating system, package repository, or update agent for Base. Debian is not publicly listed as a participant, and Canonical is not publicly listed among the founding participants. Debian and other distributions still decide whether and how to adapt an upstream fix, build packages, and publish updates.
Red Hat is a founding Akrites participant. Its stated role is upstream: it contributes to finding and fixing vulnerabilities at the source, strengthening the supply chain before Red Hat packages a fix for RHEL. This is a positive RHEL consideration, but not a guarantee that every RHEL fix ships first or that Base must change distributions.
Akrites can shorten upstream remediation for selected critical projects. Base would still receive any resulting fix through Debian or its explicitly configured vendor sources.
No platform removes the zero-day problem. The goal is to minimize the time from a trusted applicable fix to active protection without replacing one delay with unreviewed or untrusted updates.
Hardware and package constraints
Migration acceptance criteria
Supersedes
Supersedes #3, which researched only the Ubuntu-versus-Debian NVIDIA question. Its conclusion is retained here: Debian is viable for this hardware, and Ubuntu is not required for the NVIDIA driver path.
Out of scope
Firewall rules, SSH policy, backups, monitoring, and incident recovery are separate implementation concerns.