In short: structurally like Docker (reuses Dockerfiles), but without a daemon, and, unlike Podman or Nix, very lightweight, only two binaries do everything.
Common chunks of data are shared / deduplicated across installed packages, again like Docker or Nix.
How does this handle runtime updates if the source cpak Containerfile doesn't get rebuilt?
Right now on Flatpak, if I target org.freedesktop.Platform, when that gets security updates to libraries, my application will use them without needing to be rebuilt. I assume for cpak because OCI images are layered based on a fixed content commit, it won't get library updates unless rebuilt.
I do think Dockerfiles are a better mechanism than flatpak-builder specs, the ecosystem is huge.
> Follow a complete course, change real manifests and see what cpak accepts, refuses or changes. Professional paths lead to an exam and a public, verifiable credential.
Common chunks of data are shared / deduplicated across installed packages, again like Docker or Nix.
The runtime is under LGPL2.
Right now on Flatpak, if I target org.freedesktop.Platform, when that gets security updates to libraries, my application will use them without needing to be rebuilt. I assume for cpak because OCI images are layered based on a fixed content commit, it won't get library updates unless rebuilt.
I do think Dockerfiles are a better mechanism than flatpak-builder specs, the ecosystem is huge.
Holy Claude
- Bottles (Wine/Proton runner)
- cpak
- Atoms (container manager)
- VanillaOS (atomic OS with bespoke tooling)
- Sinty OS (another atomic OS with bespoke tooling)
- Sinty DE (desktop environement + apps)
It's fair to say most of them are AI generated nowadays.