-
I have a Makefile for a Rust project which binds the local repository to a Docker volume, builds it in the container using muslrust, and then does a chown to change the target directory back from root ownership to my own user.
All I had to do was 's/docker/podman/g' and remove the chown hack and it works fine: https://github.com/sevagh/pq/commit/6acf6d05a094ac2959567a9a...
It understands Dockerfiles and can pull images from Dockerhub.
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
Under the covers, both podman AND docker use runc. Redhat is writing a new version named "crun" which is lower overhead and faster:
https://github.com/containers/crun
-
Not entirely true.
I was researching this few hours ago and according to https://github.com/containers/podman/issues/6114#issuecommen... it just works when you add another network.
Docker registry having no IPv6 is another fun story tho.
-
Well, "daemonless" is kind of marketing - there is still this daemon-per-container 'conmon' thing https://github.com/containers/conmon and I don't get why it is needed because 1) who actually needs to re-attach anyway? 2) container's streams are already properly handled by whatever supervisor (e.g. systemd). You can't disable conmon and I'm not sure if its usage is not hardcoded throughout the codebase.
I would very much like to use Podman as a finally proper container launcher in production (non-FAANG scale - at which you maybe start to need k8s), but having an unnecessary daemon moving part in thousands lines of C makes me frown so far.
-
railcar
Discontinued RailCar: Rust implementation of the Open Containers Initiative oci-runtime (by drahnr)
-
I you'd like to know what it is like to use Podman, I've found those Asciinema snippets by Matthew Heon (Podman contributor) quite helpful: https://asciinema.org/~mheon
-
One very interesting piece of tech coming from it, is toolbox (https://github.com/containers/toolbox). Basically throwaway (or keeparound) rootless containers with their own root directory but shared HOME. Install hundreds of dev-dependencies to build this one piece of software? Yeah, not gonna install those packages permanently. Spin up a toolbox, build it, install it in my home/.local.
You have root in the container without having root in the host system. That takes care of a lot of issues as well.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Remember that runc contains quite a few lines of C:
https://github.com/opencontainers/runc/blob/4d4d19ce528ac40c...
https://github.com/opencontainers/runc/blob/4d4d19ce528ac40c...
-
> Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0]
This was addressed in 2017/2018 [0], it's no longer a poor choice.
[0]: https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef...
-
Moby
The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems
Alexander Larsson did the lions share of the work on device mapper, and here are 29 PRs to show it:
https://github.com/moby/moby/pulls?page=2&q=is%3Apr+is%3Aclo...
In fact, Solomon's own words from https://github.com/moby/moby/pull/2609 "Integrate lvm/devicemapper implementation by @alexlarsson into a driver", so unless you're more knowledgeable about the history than Solomon, I'm going to have to discount your take on this entire thing.
Regardless, I think things are at a much better place now.
-
It is absolutely not correct that Larsson did the lion’s share. What he did was implement a Go wrapper for libdevmapper, which exposes a very low-level API. It is the Docker team that implemented devmapper-based container storage, as well as the whole storage plugin system which was now required to support more than one storage method. The original devmapper lib is utterly undocumented and Larsson’s wrapper did not fix that. So getting that feature to work was an all-consuming task and it is the Docker team that did the bulk of it.
You can see all this from the early history of the devmapper directory: https://github.com/alexlarsson/docker/commits/a14496ce891f1f...
-
Docker is properly attributed to, see https://github.com/containers/storage/blob/a4cc7aa79e050c976...
I think OP wanted to say that Podman hates Docker what is not I feel when I'm interacting with the community there. People who use Podman do it because of it's additional features that Docker does not have, like starting an Container from a rootfs or mounting the currect directory in a container using "." as path. It's a lot of small things that make Podman better.
