Hacker News Reader

Comment by m90 | Hacker News Reader

The ICE Wifi is using very exotic IPs for their gateway here, so this is not really Docker's fault.

For reference, this can be worked around by deleting your Docker networks, logging in and recreating the networks, which should pose no problems on a dev machine.

View on HN

What are "exotic" IPs? By using "common" ones, would the probability of a conflict even grow?

I am not aware of any guidance how to use privat IPv4 addresses. In practice 192.168.1.0/24 seems to be the most commonly used one, so you might want to avoid that.

Why would docker even need to be running if no containers are running? It is 100% dockers fault, it is a bad design choice.

That's an irrelevant argument. Why should the grandparent not be able to use a container on the train?

It's not that irrelevant, considering that podman managed to solve both problems - necessity of a daemon and keeping the default network namespace clean. That said, I don't want to take away the credit of Docker being the pioneers in their field (yes it existed before. But it wasn't this popular).

Isn't Podman only able to do this because of user namespaces, which are a very recent addition to Linux? I wonder how Podman will do, if that's the case, now that user namespaces are being turned off by default due to their security implications.

I always thought containerization - including docker - was the result of Linux namespaces (more so than even cgroups). Checking again, Linux namespaces were introduced in 2002. Docker was released more than a decade later - in 2013. I believe that Docker always used namespaces - that's how they achieved process isolation. But they didn't use it to its full potential initially - including network namespaces and pods.

Unprivileged user namespaces are much newer.

Thanks for mentioning that.

Reply on news.ycombinator.com