BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//cfp.all-systems-go.io//all-systems-go-2026//TUJZSB
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-all-systems-go-2026-VLKVKW@cfp.all-systems-go.io
DTSTART;TZID=CET:20260930T112500
DTEND;TZID=CET:20260930T115000
DESCRIPTION:The image based Linux vision is clear: immutable system images\
 , declarative composition\, no imperative package installation at runtime.
  But what happens when you need dozens of independently deployable applica
 tion modules on the same device\, each owned by a different team in a larg
 e enterprise\, each on its own release cadence\, while keeping the root fi
 lesystem untouched?\n\nWe built a modular deployment system for production
  Linux devices that takes the image based philosophy to its logical conclu
 sion: every module is a read only ext4 filesystem image\, built determinis
 tically at build time\, deployed to its own A/B partition with zero instal
 lation\, and managed entirely through systemd transient services. No unit 
 files on the rootfs. No package manager on the device. No post deploy scri
 pts. The image is the truth.\n\nOn the packaging side\, we use determinist
 ic ext4 creation with constant timestamps to produce (mostly) reproducible
  images regardless of build environment. This reproducibility directly ena
 bles efficient delta based OTA: because the on device image is read only a
 nd byte identical to what was built\, we can chunk-diff against it and del
 iver only changed blocks critical for constrained networks.\n\nOn the runt
 ime side\, a oneshot service mounts each module and starts it via systemd-
 run as a transient service inheriting automatic restart\, cgroup resource 
 control\, and clean lifecycle semantics without ever writing a .service fi
 le to disk. We deliberately rejected the alternative of modules shipping t
 heir own unit files precisely because it violates the principle that deplo
 yment must not modify the root filesystem. Transient services give us the 
 systemd machinery we need while preserving an immutable rootfs compatible 
 with dm-verity.\n\nModules are fully isolated: separate uid/gid\, sandboxe
 d filesystem access\, dedicated persistent storage\, and communication exc
 lusively through a formal interface (gRPC unix domain sockets in our case)
 . Each module treats every other module as a remote server: no hard startu
 p dependencies\, no shared state\, no assumption that any other module is 
 even present on the same device
DTSTAMP:20260710T220240Z
LOCATION:Galerie
SUMMARY:Image Based Modular Deployment for Large Teams in Embedded Systems 
 - Corin Rypkema\, Mike Sandige\, Gopal Paudel
URL:https://cfp.all-systems-go.io/all-systems-go-2026/talk/VLKVKW/
END:VEVENT
END:VCALENDAR