Immutable Edition

The system presents itself as a fixed image; your experiments happen in layers around it.

Model

Layer Behavior

Root (/)

Read-only at runtime; updated atomically as units, not package-by-package drift

/home & writable paths

Yours entirely — normal files, flatpaks, dotfiles

Applications beyond base

Flatpak first, containers second, layering last resort

Why people choose it

  • Machines shared with family/colleagues stop accumulating mystery breakage

  • Kiosks/digital signage stay deterministic

  • Rollback = boot previous deployment entry, not snapshot surgery

Working within the model

# typical software flow:
flatpak install flathub org.mozilla.firefox
# development: containers/toolbx-style environments rather than host installs

Host-level package additions are possible but deliberately frictionful — if everything needs layering, standard edition fits better.

Relationship to snapshots

Timeshift-style rollback complements atomicity here; recovery tooling targets user data + bootloader layers consistent with the image approach (edition-specific notes ship in its README/docs bundle).

Honest tradeoffs

Gain Cost

Predictability, easy rollback

Less spontaneous tinkering surface

Great Flatpak/container fit

Deep-system customization awkward

Fewer partial-state failures

Larger update downloads (image-sized)

Build source lives alongside standard edition in the org repos (acreetionos-immutable) — contributors welcome.