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.
> 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.
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.
Yup. Ubuntu promises the best of both worlds, and in my experience the end result is noticeably worse than Debian. You notice when things are deliberate and tested versus cobbled together and made to work.
Consider checking out Linux Mint Debian Edition (LMDE). Best of two worlds - stable foundation of Debian, easy-to-use interface of Mint. I have been using it for about 2 years now, very happy with it.
> designed to ignore the rest of my system as much as it can and live in its own little world.
Exactly what a small, locked-down system needs. A single-purpose server box. An advanced appliance, like a "smart TV", or media box, or an advanced home automation hub.
I don't see why this calls for a new system. If anything these environments are a stronger case for a quality ecosystem where a whole community cares about keeping it coherent and up-to-date.
A minimal Debian installation for single-purpose server isn't a new idea, or I often reach for Alpine and trim it down to a dozen or so packages. These are both quality ecosystems with track records and reputations. I can get a minimal attack surface and still count on timely updates, security patches, good integration (when it turns out that I needed a dual-purpose server box and not a single-purpose box), etc. These systems scale up and down.
What I'm reluctant to trust in a deploy-and-forget system is a fly-by-night package from someone who picked a packaging system because it looked easy and didn't make them think about an actual lifecycle. A few months or years down the road I expect most of those will be unmaintained. One of the most valuable parts of an ecosystem like Debian is that they make everybody think about all those issues and actually do the work.
[OP] xlmnxp | 12 hours ago
nine_k | 11 hours ago
Common chunks of data are shared / deduplicated across installed packages, again like Docker or Nix.
The runtime is under LGPL2.
stephenlf | 11 hours ago
Holy Claude
novafunc | 10 hours ago
- 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.
RandomGerm4n | 9 hours ago
Groxx | 5 hours ago
quasigod | 4 hours ago
Groxx | 4 hours ago
ChocolateGod | 10 hours ago
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.
_russross | 10 hours ago
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.
juujian | 9 hours ago
noir_lord | 5 hours ago
Debian rock stable, changes slowly and carefully.
Fedora rock stable, changes rapidly and constantly.
Ubuntu is just painful.
Note: this is on the desktop, I just use Debian on the server as the host OS - some habits are hard to break.
dv35z | 3 hours ago
https://linuxmint.com/download_lmde.php
noir_lord | 3 hours ago
Fedora KDE is hard to beat on the features that matter to noir_lord scale though, it’s always good to have choices.
nine_k | 8 hours ago
Exactly what a small, locked-down system needs. A single-purpose server box. An advanced appliance, like a "smart TV", or media box, or an advanced home automation hub.
_russross | 3 hours ago
A minimal Debian installation for single-purpose server isn't a new idea, or I often reach for Alpine and trim it down to a dozen or so packages. These are both quality ecosystems with track records and reputations. I can get a minimal attack surface and still count on timely updates, security patches, good integration (when it turns out that I needed a dual-purpose server box and not a single-purpose box), etc. These systems scale up and down.
What I'm reluctant to trust in a deploy-and-forget system is a fly-by-night package from someone who picked a packaging system because it looked easy and didn't make them think about an actual lifecycle. A few months or years down the road I expect most of those will be unmaintained. One of the most valuable parts of an ecosystem like Debian is that they make everybody think about all those issues and actually do the work.
purgedreality | 9 hours ago
Gander5739 | 6 hours ago
localhoster | 9 hours ago
With comments like this, I'm not even gonna bother opening the link