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 don't know how this happens to me but i always have trouble with Bottles. And not just the slightly bad UI, but like today, i have an installer that i can run directly with Steam that i cannot get to run in Bottles. When i last used it a couple years ago i did get what i needed working successfully but i remember it being a struggle.
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.
Still supports a proper taskbar, one per screen with windows from only that screen on that screens taskbar (that's just how I've done it since the 90's but it's a must have because I think in terms of screen relations to where stuff is, it's my mental model) and virtual desktops (Cinnamon and XFCE both do this as do others) and it supports Wayland (which is why I'm not still on Cinnamon which I really liked as it's just coming out of experimental support for Wayland).
You can also disable sorting of windows in the taskbar, disable combining them (eugh, I hate that so much) into a single entry (never understood that design choice on OSX or DE's that do it by default, don't hide my shit when there is space to show both).
It is complex for a UI in that there are lots of things you can tweak (spread around in the settings) but just because you can doesn't mean you have to of course.
I mostly just leave the defaults except for the above and rebinding a bunch of the window management, beyond that I strip it back to a start menu, taskbar and clock on both screens.
Mostly I like it because when I'm using it I never have to think about it, if I have to consider the DE (in that it's not just working the way I'd expect it to) then it's failing as a DE because it is getting in the way.
XFCE, Cinnamon and KDE all clear that bar (others may, they are just the last three I used going back well over a decade), Gnome hasn't since v2, KDE has defaults but it doesn't have "opinions" on how you should use it the same way as some of the others.
Switching to KDE from Cinnamon was a non-event after years of using Cinnamon, it took maybe half an hour to find the all the settings I wanted to make it work how I wanted.
It is extremely stable/polished (at least on Fedora) out the box, I want to use my machine to do things, playing with WM/DE's used to fascinate me and 25 years ago I had the inclination, now I just want boring software and a DE as the main interface to the computer should be boring in actual use.
TLDR: I want the classic WIMP desktop, I don't want to have to configure a bunch of half supported/unstable extensions to do it.
I want that for the core system packages but sometimes you need the latest version of some random utility to use for a one off task, and in those cases these package formats are handy: download an AppImage and make no changes to your system, install a Snap/Flatpak without cluttering the system libraries, run something once in an ephemeral docker container.
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
I don't know how this happens to me but i always have trouble with Bottles. And not just the slightly bad UI, but like today, i have an installer that i can run directly with Steam that i cannot get to run in Bottles. When i last used it a couple years ago i did get what i needed working successfully but i remember it being a struggle.
(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.
Curious what features you like in KDE. I also like kDE, but don't use it as my primary DE - in the past, it has felt complex to me.
Still supports a proper taskbar, one per screen with windows from only that screen on that screens taskbar (that's just how I've done it since the 90's but it's a must have because I think in terms of screen relations to where stuff is, it's my mental model) and virtual desktops (Cinnamon and XFCE both do this as do others) and it supports Wayland (which is why I'm not still on Cinnamon which I really liked as it's just coming out of experimental support for Wayland).
You can also disable sorting of windows in the taskbar, disable combining them (eugh, I hate that so much) into a single entry (never understood that design choice on OSX or DE's that do it by default, don't hide my shit when there is space to show both).
It is complex for a UI in that there are lots of things you can tweak (spread around in the settings) but just because you can doesn't mean you have to of course.
I mostly just leave the defaults except for the above and rebinding a bunch of the window management, beyond that I strip it back to a start menu, taskbar and clock on both screens.
Mostly I like it because when I'm using it I never have to think about it, if I have to consider the DE (in that it's not just working the way I'd expect it to) then it's failing as a DE because it is getting in the way.
XFCE, Cinnamon and KDE all clear that bar (others may, they are just the last three I used going back well over a decade), Gnome hasn't since v2, KDE has defaults but it doesn't have "opinions" on how you should use it the same way as some of the others.
Switching to KDE from Cinnamon was a non-event after years of using Cinnamon, it took maybe half an hour to find the all the settings I wanted to make it work how I wanted.
It is extremely stable/polished (at least on Fedora) out the box, I want to use my machine to do things, playing with WM/DE's used to fascinate me and 25 years ago I had the inclination, now I just want boring software and a DE as the main interface to the computer should be boring in actual use.
TLDR: I want the classic WIMP desktop, I don't want to have to configure a bunch of half supported/unstable extensions to do it.
I want that for the core system packages but sometimes you need the latest version of some random utility to use for a one off task, and in those cases these package formats are handy: download an AppImage and make no changes to your system, install a Snap/Flatpak without cluttering the system libraries, run something once in an ephemeral docker container.
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.