BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.devconf.info//devconf-cz-2026//talk//MVEWZ8
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-devconf-cz-2026-MVEWZ8@pretalx.devconf.info
DTSTART;TZID=CET:20260618T140000
DTEND;TZID=CET:20260618T143500
DESCRIPTION:Update one package in your container image and watch your users
  re-download 500MB of unchanged content. Traditional Dockerfile layers are
  instruction-based—a single package update invalidates an entire layer.\
 n\nThis talk introduces **chunkah**\, a tool that post-processes container
  images into content-based layers. Files are grouped by package\, not Dock
 erfile structure. Update one package\, users download only that layer.\n\n
 We'll cover:\n\n- Why instruction-based layers hurt pull performance (with
  numbers)\n- How content-based splitting works under the hood\n- Live demo
 : chunkah in action\, before/after comparison\n- How `podman history` reve
 als package-to-layer mapping\n\nFrom Project Hummingbird\, where we run 70
 + production container images with chunkah\, we'll show real metrics on ba
 ndwidth savings and how to adopt this in your own builds.\n\n**Audience**:
  Container image builders\, CI/CD engineers\, registry operators\, anyone 
 who's wondered why their image pulls are so slow.
DTSTAMP:20260430T125905Z
LOCATION:D0206 (capacity 154)
SUMMARY:Stop Re-Downloading Your Container Images: Content-Based Layers wit
 h Chunkah - Michael Krausch-Hofmann
URL:https://pretalx.devconf.info/devconf-cz-2026/talk/MVEWZ8/
END:VEVENT
END:VCALENDAR