Hello Siduction Team and Community,
I would love to pitch a technical proposal regarding the evolution of rolling releases: an experimental, immutable, and atomic variant of Siduction powered by bootc (and ostree).
We all love Sid for its bleeding-edge packages, and the Siduction team does a fantastic job of managing unstable transitions. However, combining Sid's freshness with the absolute safety of container-native atomic deployments could create an unbreakable, bulletproof rolling-release desktop.
Core Architecture Ideas
1. OS-as-a-Container Base
The entire core system would be defined via a standard Containerfile hosted and built on Siduction's infrastructure, then distributed as a standard OCI image:
dockerfile
FROM docker.io/library/debian:sid
LABEL containers.bootc=1
RUN apt-get update && apt-get install -y linux-image-amd64 systemd-sysv ostree bootc initramfs-tools [...]
Installation images (.qcow2, .raw, or ISO) can then be generated out of the box using
quay.io/centos-bootc/bootc-image-builder.
2. The Hybrid "RakuOS-style" OverlayFS
The main friction point of immutable systems is that users miss running quick local
apt install commands. We can solve this by implementing a custom, version-bound
OverlayFS on top of
/usr during early boot (via a high-priority systemd unit
Before=local-fs.target).
The boot script would read the current deployment hash and bind local modifications to a specific release directory inside
/var:
Bash
# Concept logic during boot
DEPLOY_ID=$(ostree admin status | grep '*' | awk '{print $2}')
UPPER_DIR="/var/local/overlay-layers/$DEPLOY_ID/upper"
WORK_DIR="/var/local/overlay-layers/$DEPLOY_ID/work"
mkdir -p "$UPPER_DIR" "$WORK_DIR"
mount -t overlay overlay -o lowerdir=/usr,upperdir="$UPPER_DIR",workdir="$WORK_DIR" /usr
Why this benefits the Siduction Ecosystem:
• True Atomic Upgrades: Users update their host via sudo bootc update. If a major Sid transition breaks Xorg, Wayland, or a critical library, the user can instantly rollback to the exact working state of the previous day straight from the GRUB menu.
• Isolated Local Packages: When a new bootc image is deployed, the system automatically provisions a clean overlay for the new base hash. The old local apt packages remain safely isolated in the previous deployment directory. If the user performs a rollback, they find their local packages exactly as they left them.
• Automated CI/CD Testing: Siduction could automate image builds on a daily/weekly schedule. If a known bad transition happens in Sid, the build pipeline can hold the release, ensuring users only pull images that have passed basic boot tests.
Projects like Fedora Silverblue and CentOS Bootc are proving that container-native infrastructure is the future of OS maintenance. A Debian Sid-based atomic distribution would make Siduction a unique pioneer in the Debian landscape.
I would love to hear your thoughts on this! If anyone is interested, I'd be happy to share the full working Proof of Concept (PoC) configs to kickstart a test build.
Best regards, Andrea Marengoni, Italy
The proposal and the scripts were developed by artificial intelligence, in response to a prompt asking how Sid could be made similar to RakuOS.