4 ms·

I really like Podman, and I'm happy to see this new release. This little nugget about non-released features makes me most excited though: > More features, incl

by DCKing 5y ago

I really like Podman, and I'm happy to see this new release. This little nugget about non-released features makes me most excited though: > More features, including support for volume mounts from the host, are planned for Podman v4.1, so stay tuned for more updates. IIUC host volume mounts for podman-machine are the last major missing feature in Podman that would allow something like Podman Desktop Companion [1] to replace Docker Desktop on Windows/Mac for most use cases - if it works well. It'd be great to replace that nagging-for-updates and nagging-for-subscriptions with a completely open source replacement tool. (I'm sympathetic to the Docker team in need of a revenue source, but I'm really happy OCI containers on Mac and Windows can be made accessible without vendor lock-in). [1]: https://iongion.github.io/podman-desktop-companion/ https://iongion.github.io/podman-desktop-companion/

gavinray 5y ago
Whoa, thank you for sharing this. I was looking for a Docker Desktop alternative for Podman and found Cockpit but it's not the same. This looks awesome!
kodah 5y ago
Eh, not the only thing. Podman is definitely well on it's way, but my team builds tooling that builds and orchestrates our development environments. When we switched from docker to podman we immediately noticed how slow our container based build stage had become. Podman lacked some caching layer that docker was automatically orchestrating as well as parallel builds (without build kit, and build kit isn't super simple to integrate). Once we integrated build kit it made our build times very similar, but this was only possible because we had tooling to orchestrate build kit on top of podman.
- throwaway894345 5y ago
  As an aside, I recently tried to dabble with some BuildKit APIs and man that was one of the lowest quality Go codebases I've encountered. Probably the lowest hanging fruit would be documenting APIs. Podman (and IIRC Buildah) by comparison were clean, well documented, reasonable APIs were exposed, etc.
tvaughan 5y ago
https://github.com/containers/podman/issues/13256 https://github.com/containers/podman/issues/13256

by DCKing 5y ago

gavinray 5y ago

Whoa, thank you for sharing this. I was looking for a Docker Desktop alternative for Podman and found Cockpit but it's not the same. This looks awesome!

kodah 5y ago

Eh, not the only thing. Podman is definitely well on it's way, but my team builds tooling that builds and orchestrates our development environments. When we switched from docker to podman we immediately noticed how slow our container based build stage had become. Podman lacked some caching layer that docker was automatically orchestrating as well as parallel builds (without build kit, and build kit isn't super simple to integrate). Once we integrated build kit it made our build times very similar, but this was only possible because we had tooling to orchestrate build kit on top of podman.

throwaway894345 5y ago
As an aside, I recently tried to dabble with some BuildKit APIs and man that was one of the lowest quality Go codebases I've encountered. Probably the lowest hanging fruit would be documenting APIs. Podman (and IIRC Buildah) by comparison were clean, well documented, reasonable APIs were exposed, etc.

tvaughan 5y ago

https://github.com/containers/podman/issues/13256 https://github.com/containers/podman/issues/13256