HN

Comments (69)

• Menu

  fabian2k
  > This difference is particularly noticeable with multiple images sharing the same base layers. With legacy storage drivers, shared base layers were stored once locally, and reused images that depended on them. With containerd, each image stores its own compressed version of shared layers, even though the uncompressed layers are still de-duplicated through snapshotters.This seems like a really weird decision. If base images are duplicated for every image you have, that will add up quickly.
• Menu

  Oxodao
  Docker already fills up my dev machines yet they decided for this insane solution:> The containerd image store uses more disk space than the legacy storage drivers for the same images. This is because containerd stores images in both compressed and uncompressed formats, while the legacy drivers stored only the uncompressed layers.Why ?
• Menu

  neitsab
  Docker v29 (released 2025-11) switched to using containerd for its image store for new installs.This means `/var/lib/docker` is no longer "hermetic": images and container snapshots are located in `/var/lib/containerd` now.More info about the switch: https://www.docker.com/blog/docker-engine-version-29/To configure this directory, see https://docs.docker.com/engine/storage/containerd/.
• hommelix
  > Docker Engine includes an experimental feature that can automatically switch to the containerd image store under certain conditions. This feature is experimental. It's provided for those who want to test it, but starting fresh is the recommended approach.How bad did we fall with the ship often, ship early and fix later idea? Make a major change, release it and the migration feature is experimental and not recommended.
• jillesvangurp
  Since people are mentioning alternatives, worth calling out colima if maybe you don't want to jump onto Red Hat's podman or Suse's Rancher. Both are open source but there are some corporate entities behind them with their own agendas that you might want to consider.My reasoning is simply that I don't really want to swap out one overly complicated thing for another. I'm sure Podman is fine and amazing. But I'm just not in the IBM/Red Hat ecosystem and I have some reservations their generally a bit overly complex solutions. There's a reason IBM is involved, just saying. And as I'm not planning to use podman in production I see no reason to have it on my laptop.As for Rancher, that seems to me a bit like moving the problem than solving it as it seems to be a for profit solution around an OSS core with its own complexity and potentially similar risks to Docker Desktop down the road.With colima, it's all open source and easy to install/upgrade via homebrew. Nice simple wrapper around qemu. There's no UI, and I don't really miss having one. Lazydocker works fine as a TUI if you crave a UI and so do other generic docker UIs/IDEs. I mainly use docker and docker compose on the command line and that works fine for me. It has Kubernetes support as well if you need that but that's not something I use or need.
• cyberax
  Just use Podman. Docker's development is driven by managers who want to shove hosted services everywhere.Meanwhile, the basic stuff like caching doesn't work properly.
• Menu

  0xbadcafebee
  It sounds like this breaks all Docker installs that use userns-remap? Are they really shipping a breaking change with no fix? In addition to bloating the disk? In addition to breaking all old systems that relied on mapping /var/lib/docker?I can't believe Docker finally shit the bed. Time to replace Docker with Podman.... sigh
• DeathArrow
  I should start looking into Podman.
• Menu

  newsoftheday
  The article says to regularly run prune, how regularly? Currently I run the following once per day from cron: docker system prune -a -f docker volume prune -a -f
• Menu

  mrichman
  Why not just use podman at this point?
• pjmlp
  In case you missed it, recent Rancher Desktop versions also went through this.
• xiaod
  [flagged]
• BoldBrook418
  [dead]
• QuietLedge375
  [dead]