Live data from Hacker News

Docker 29 has changed its default image store for new installs

docs.docker.com

91–93 of 93 posts

Re: Docker 29 has changed its default image store for new installs

#91

Earlier quoted context omitted.

I suggest you judge based on benchmarks rather than vibes. If you believe the latest M3 does not perform better than machines you’ve used in the 80s, I have no idea how to even start a reasonable discussion about this.

> If you believe the latest M3 does not perform better than machines you’ve used in the 80s That wasn't what I was trying to say, I apologize, I should have been clearer. What I intended to say was that I've been using various, many computers since the 1980's so I have a wide and deep sampling of experiences with them and to that end...the M3 did NOT feel to me like it performed better. Regardless the benchmarks, I k…

Ok that is a much better point and a fair correction.

Re: Docker 29 has changed its default image store for new installs

#92

Earlier quoted context omitted.

I think there is an Issue/PR right now to change this. See: https://github.com/containerd/containerd/issues/13307

Oh, very glad to see this, ML applications that were mentioned in it are exactly why I was thinking this was such a disastrous change. However, the tedium of the reply chain reminds me why I tend to focus most energy on internal projects rather than external open source... Docker may have been built for a specific type of use case that most developers are familiar with (e.g. web apps backed by a DB container) but con…

> ...containerization is useful across so much of computing that are very different....

So much that containerization in general predates Linux, and UNIX, all the way back to System 360.

Also it got introduced into Tru64, HP-UX, BSD and Solaris, before landing into Linux.

Re: Docker 29 has changed its default image store for new installs

#93

I'm a maintainer of the Moby project (which is used to build the Docker Engine), and saw this post got some attention, so let me try to outline some of the changes and motivation. Happy to answer questions if there's any. First of all, some history; the Docker Engine was a monolith daemon that provided many services; this worked well when using Docker as a standalone solution, but when used as runtime for Kubernetes,…

Why store uncompressed layers? Surely decompression is fast enough that there's little gain in storing the decompressed layers?
Post reply on HN