A decade of Docker containers • Hacker News Board

Re: A decade of Docker containers

#51

Post by skydhash » Sat, Mar 07, 2026, 6:55 PM UTC

vanviegen wrote: post #31

forrestthewoods wrote: post #25

Earlier quoted context omitted.

Windows is an order of magnitude better in this regard.

It used to be, but only in cases where your distro doesn't just package whatever software you require. Nowadays I prefer Flatpak or AppImage over crappy custom Windows installers for those cases. They allow for sandboxing and reliable updating/deinstallation.

These days, I equate anything that ships via docker/flatpak first as built by someone that only care about their own computer, especially if the project is opensource. As soon as a library or a tool update, they usually rush to add a hard condition on it for no reason other than to be on the "bleeding edge".

Re: A decade of Docker containers

#52

Post by miladyincontrol » Sat, Mar 07, 2026, 6:57 PM UTC

bmitch3020 wrote: post #26

I've seen countless attempts to replace "docker build" and Dockerfile. They often want to give tighter control to the build, sometimes tightly binding to a package manager. But the Dockerfile has continued because of its flexibility. Starting from a known filesystem/distribution, copying some files in, and then running arbitrary commands within that filesystem mirrored so nicely what operations has been doing for a l…

The lack of docker registry-like solutions really does seem to be the chokepoint for many alternatives.

Personally I love using mkosi and while it has all the composability and deployment options I'd care for, its clear not everyone wants to build starting only with a blank set of OS templates.

Re: A decade of Docker containers

#53

Post by politelemon » Sat, Mar 07, 2026, 7:06 PM UTC

Somewhere along the line they started prioritising docker desktop over docker. It's a bit jarring to see new features coming to desktop before it comes to Linux, such as the new sandbox features.

Is there any insight into this, I would have thought the opposite where developers on the platform that made docker succeed are given first preview of features.

Re: A decade of Docker containers

#54

Post by Hackbraten » Sat, Mar 07, 2026, 7:12 PM UTC

mihaelm wrote: post #23

the__alchemist wrote: post #3

I'm optimistic we will succeed in efforts to simplify linux application / dependency compatibility instead of relying on abstractions that which work around them.

Maybe if you only look at it through the lens of building an app/service, but containers offer so much more than that. By standardizing their delivery through registries and management through runtimes, a lot of operational headaches just go away when using a container orchestrator. Not to mention better utilization of hardware since containers are more lightweight than VMs.

> Not to mention better utilization of hardware

When compared to a VM, yes. But shipping a separate userspace for each small app is still bloat. You can reuse software packages and runtime environments across apps. From an I/O, storage, and memory utilization point of view, it feels baffling to me that containers are so popular.

Re: A decade of Docker containers

#55

Post by brtkwr » Sat, Mar 07, 2026, 7:15 PM UTC

I realise apple containers haven't quite taken off yet as expected but omission from the article stands out. Nice that it mentions alternative approaches like podman and kata though.

Re: A decade of Docker containers

#56

Post by toast0 » Sat, Mar 07, 2026, 7:17 PM UTC

zbentley wrote: post #33

bmitch3020 wrote: post #26

I've seen countless attempts to replace "docker build" and Dockerfile. They often want to give tighter control to the build, sometimes tightly binding to a package manager. But the Dockerfile has continued because of its flexibility. Starting from a known filesystem/distribution, copying some files in, and then running arbitrary commands within that filesystem mirrored so nicely what operations has been doing for a l…

> the Dockerfile has continued because of its flexibility I wish we had standardized on something other than shell commands, though. Puppet or terraform or something more declarative would have been such a better alternative to “everyone cargo cults ‘RUN apt-get upgrade’ onto the top of their dockerfiles”. Like, the layer/stage/caching behavior is fine. I just wish the actual execution parts had been standardized usi…

Oof, not terraform please. If you use foreach and friends, dependency calculations are broken, because dependency happens before dynamic rules are processed.

I'd get much better results it I used something else to do the foreach and gave terraform only static rules.

Re: A decade of Docker containers

#57

Post by __MatrixMan__ » Sat, Mar 07, 2026, 7:19 PM UTC

onei wrote: post #45

__MatrixMan__ wrote: post #8

Earlier quoted context omitted.

Agreed. I've recently switched from docker compose to process compose and it's super nice not to have to map ports or mount volumes. What I actually needed from docker had to do less with containers and more with images, and nix solves that problem better without getting in the way at runtime.

Assuming I've found the right process-compose [1], it struck me as having much overlap with the features of systemd. Or at least, I would tend to reach for systemd if I wanted something to run arbitrary processes. Is there something additional/better that process-compose does for you? [1]: https://github.com/F1bonacc1/process-compose

That's the one, although I tend to reference it through https://github.com/juspay/services-flake because that way I end up using the community-maintained configs for whatever well-known services I've enabled (I'll use postgres as an example below, but there are many: https://community.flake.parts/services-flake/services)

What process-compose gives me is a single parent with all of that project's processes as children, and a nice TUI/CLI for scrolling through them to see who is happy/unhappy and interrogating their logs, and when I shut it down all of that project's dependencies shut down. Pretty much the same flow as docker-compose.

It's all self-contained so I can run it on MacOS and it'll behave just the same as on Linux (I don't think systemd does this, could be wrong), and without requiring me to solve the docker/podman/rancher/orbstack problem (these are dependencies that are hard to bundle in nix, so while everything else comes for free, they come at the cost of complicating my readme with a bunch of requests that the user set things up beforehand).

As a bonus, since it's a single parent process, if I decide to invoke it through libfaketime, the time inherited by subprocess so it's consistently faked in the database and the services and in observability tools...

My feeling for systemd is that it's more for system-level stuff and less for project-level dependencies. Like, if I have separate projects which need different versions of postgres, systemd commands aren't going to give me a natural way to keep track of which project's postgres I'm talking about. process-compose, however, will show me logs for the correct postgres (or whatever service) in these cases:

    ~/src/projA$ process-compose process logs postgres
    ~/src/projB$ process-compose process logs postgres

This is especially helpful because AI agents tend to be scoped to working directory. So if I have one instance of claude code on each monitor and in each directory, which ever one tries to look at postgres logs will end up looking at the correct postgres's logs without having to even know that there are separate ones running.

Basically, I'm alergic to configuring my system at all. All dependencies besides nix, my text editor, and my shell are project level dependencies. This makes it easy to hop between machines and not really care about how they're set up. Even on production systems, I'd rather just clone the repo `nix run` in that dir (it then launches process compose which makes everything just like it was in my dev environment). I am however not in charge of any production systems, so perhaps I'm a bit out of touch there.

Re: A decade of Docker containers

#58

Post by mmh0000 » Sat, Mar 07, 2026, 7:20 PM UTC

mrbluecoat wrote: post #4

> Docker repurposed SLIRP, a 1990s dial-up tool originally for Palm Pilots, to avoid triggering corporate firewall restrictions by translating container network traffic through host system calls instead of network bridging. Genuinely fascinating and clever solution!

Until recently, Podman used slirp4net[1] for its container networking. About two years ago, they switched over to Pasta[2][3] which works quite a bit differently.

[1] https://github.com/rootless-containers/slirp4netns

[2] https://blog.podman.io/2024/03/podman-5-0-breaking-changes-i...

[3] https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstr...

Re: A decade of Docker containers

#59

Post by forrestthewoods » Sat, Mar 07, 2026, 7:22 PM UTC

robmusial wrote: post #32

forrestthewoods wrote: post #25

Earlier quoted context omitted.

Windows is an order of magnitude better in this regard.

And yet I'm constantly getting asked when we'll support Windows containers at my office.

This is because your team doesn’t know how to ship software without using containers.

If you have adopted a bad tool then people are likely to want the bad tool in more places. This is the opposite of a virtuous cycle and is a horrible form of tech debt.

Re: A decade of Docker containers

#60

Post by toast0 » Sat, Mar 07, 2026, 7:23 PM UTC

mrbluecoat wrote: post #4

> Docker repurposed SLIRP, a 1990s dial-up tool originally for Palm Pilots, to avoid triggering corporate firewall restrictions by translating container network traffic through host system calls instead of network bridging. Genuinely fascinating and clever solution!

I don't think SLIRP was originally for palm pilots, given it was released two years before.

SLIRP was useful when you had a dial up shell, and they wouldn't give you slip or ppp; or it would cost extra. SLIRP is just a userspace program that uses the socket apis, so as long as you could run your own programs and make connections to arbitrary destinations, you could make a dial script to connect your computer up like you had a real ppp account. No incomming connections though (afaik), so you weren't really a peer on the internet, a foreshadowing of ubiquitous NAT/CGNAT perhaps.