Can you write an article explaining the implementation principle?

[snail2sky]

I am very interested in your project. Unfortunately, I don’t know the zig language very well. I searched a lot about dockerc-related matters on the Internet, but there is no content related to the current dockerc project. Your approach will greatly solve the problems in the Linux world. Various program operation problems are very promising and far-sighted.
If this project succeeds and spreads, all package managers will be eclipsed, whether rpm/yum/dnf or dpkg/apt
These tools will become extinct with the emergence of dockerc. Please don’t give up. I firmly believe that this project will achieve great success.

[zaleGZL]

From Copilot:

The dockerc repository converts Docker images into standalone portable binaries, allowing users to run applications without the need for Docker. Here's a general overview of its implementation principles:

Overview and Purpose:

The main goal of dockerc is to compile Docker images into executable binaries that can be run directly on a system without Docker.
This eliminates the need for commands like docker run, pip install, or npm i.
Usage:

Users can specify images from Docker Hub or local Docker daemon storage and compile them into binaries using the dockerc command.
It supports specifying target instruction set architectures and passing environment variables and volumes similar to Docker.
Features:

Compiles Docker images into portable binaries.
Supports rootless containers, x86_64, and arm64 architectures.
Future support for MacOS and Windows through QEMU.
Allows specifying environment variables and volumes.
Implementation Details:

The implementation leverages Zig and C for core functionalities.
Uses Skopeo for loading Docker images.
Compiles with Zig, ensuring optimized and safe release builds.
Key Code Structures:

The main Zig file (main.zig) handles reading environment variables, managing user and group ID mappings, and running containers using the libcrun library.
It also includes functions for parsing and updating ID mappings, handling file systems, and managing container processes.
You can view the detailed README here and the main implementation code here.

[snail2sky]

OK thank you very much
I actually learned about these contents on chatgpt.
I'm just a little confused about the detailed process. After I used dockerc to compile haproxy and iperf, I found that both binary programs could not run normally.
The operation method of dockerc may be similar to appimage. It uses fuse to create a file system in user space, and then uses other tools, libraries and other environments.
These are all things that the binary program compiled by dockerc has to do. This binary must prepare the running environment before actually calling the actual program.
But in fact, many programs rely on a lot of things, such as simple runtime libraries, which can be placed in the appropriate location according to the operating specifications, but I think
The complexity is actually the configuration files and data files. Because the application has its own file system, we need to interact with it when we run the program.
For example, plug-in configuration files, plug-in data directories, etc. In this case, how to effectively organize and transfer program parameters becomes extremely important.
This is my doubt~~

[SerJaimeLannister]

Interested as well. Would love to see a blog post actually explaining what it does