Subject: Proposal: A Cloud-Native, Immutable Variant of Siduction using bootc

[and1973]

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

Code Select Expand

bootc (and

Code Select Expand

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

Code Select Expand

Containerfile hosted and built on Siduction's infrastructure, then distributed as a standard OCI image:

dockerfile

Code Select Expand

FROM docker.io/library/debian:sid
LABEL containers.bootc=1
RUN apt-get update && apt-get install -y
 Installation images (.qcow2, .raw, or ISO) can then be generated out of the box using
quay.io/centos-bootc/bootc-image-builder[font=Google Sans, Roboto, sans-serif].[/font]
[font=Google Sans, Roboto, sans-serif][b]2. The Hybrid "RakuOS-style" OverlayFS[/b]
The main friction point of immutable systems is that users miss running quick local [/font]
apt install[font=Google Sans, Roboto, sans-serif] commands. We can solve this by implementing a custom, version-bound [/font]
OverlayFS[font=Google Sans, Roboto, sans-serif] on top of [/font]
/usr[font=Google Sans, Roboto, sans-serif] during early boot (via a high-priority systemd unit [/font]
Before=local-fs.target[font=Google Sans, Roboto, sans-serif]).[/font]
[font=Google Sans, Roboto, sans-serif]The boot script would read the current deployment hash and bind local modifications to a specific release directory inside [/font]
/var[font=Google Sans, Roboto, sans-serif]:[/font]

[size=2][font=Google Sans, Roboto, sans-serif][size=4]bash[/size][/font][/size]
# 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[size=2][font=Google Sans, Roboto, sans-serif]
Usa il codice con cautela.
[/font][/size]

[size=4][font=Google Sans, Roboto, sans-serif]Why this benefits the Siduction Ecosystem:[/font][/size]
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.[font=Google Sans, Roboto, sans-serif]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.[/font]
[font=Google Sans, Roboto, sans-serif]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.[/font]
Best regards, Andrea Marengoni, Italy
The proposal was developed by artificial intelligence, in response to a query about how Sid could be made similar to RakuOS.