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.
I've been a Debian user since the late 90s, and their packaging system is the main reason. Not the tools and package format, but the culture and strict rules that govern inclusion in the system.
Every time I see a new package system that promises to free creators of the burden of integration and compatibility with the rest of my installed software, it's a hard "no" from me--and there have been a lot of these over the years. The promise is always how easy and carefree it is for packagers, but the things that make Debian harder are the things that make it valuable. Careful integration with the rest of the system with matching dependency versions. Modular, carefully partitioned packages for complex systems that would otherwise be all-or-nothing. Ongoing maintenance and updates. Responsiveness to security updates. Following common rules for configuration, directory placement, init/systemd integration, etc.
cpak looks like yet another system designed to ignore the rest of my system as much as it can and live in its own little world. In other words, designing around the needs and goals of software packagers over the needs of users and long-term system maintenance. Solving the easy problems instead of the hard ones.
> 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.
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.
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.
The runtime is under LGPL2.
I've been a Debian user since the late 90s, and their packaging system is the main reason. Not the tools and package format, but the culture and strict rules that govern inclusion in the system.
Every time I see a new package system that promises to free creators of the burden of integration and compatibility with the rest of my installed software, it's a hard "no" from me--and there have been a lot of these over the years. The promise is always how easy and carefree it is for packagers, but the things that make Debian harder are the things that make it valuable. Careful integration with the rest of the system with matching dependency versions. Modular, carefully partitioned packages for complex systems that would otherwise be all-or-nothing. Ongoing maintenance and updates. Responsiveness to security updates. Following common rules for configuration, directory placement, init/systemd integration, etc.
cpak looks like yet another system designed to ignore the rest of my system as much as it can and live in its own little world. In other words, designing around the needs and goals of software packagers over the needs of users and long-term system maintenance. Solving the easy problems instead of the hard ones.
> 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.
Holy Claude
He has a bunch of projects. Most notable being:
- 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.
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.
cpak is the OCI application package format for Linux desktops, servers and devices.