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.
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.
> 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.
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.
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.
> 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.
At least Bottles is really good and not just slop
(edit: removed because I was confusing Bottles and Boxes, no need to leak wrong ideas)
Bottles is a wine/proton runner, not a VM manager. I think you might be mixing it up with Boxes?
Yes! I am indeed, thank you! Bottles has been useful, though I haven't used it in years.
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.
> 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.
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.
The weird thing is that Ubuntu manages to sit in some unholy local minima.
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.
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.
https://linuxmint.com/download_lmde.php
Used Cinnamon (on Fedora) for several years, it’s an excellent DE in the classic (and therefore best) style.
Fedora KDE is hard to beat on the features that matter to noir_lord scale though, it’s always good to have choices.
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.
> holy claude
With comments like this, I'm not even gonna bother opening the link
Isn't there an XKCD about this?
https://xkcd.com/927/
cpak is the OCI application package format for Linux desktops, servers and devices.