3 ms·

This is definitely true, but only as long as docker (or $container_runtime) remains lightweight enough that you can still use those independent parts on their o

This is definitely true, but only as long as docker (or $container_runtime) remains lightweight enough that you can still use those independent parts on their own, compatibly with docker. The risk is that docker grows in complexity such that it creates new dependencies between these independent parts and therefore handicaps their power when used individually. As an example, it's easy to create network namespaces and add routing rules, interfaces, packet forwarding logic, etc all by using `ip netns exec`. But there is no easy way to launch a docker container into an existing netns. You need to use docker's own network tooling or build your own network driver, which may be more complex than what you need. This strikes me as a code smell in docker.

josteink 10y ago
> This is definitely true, but only as long as docker (or $container_runtime) remains lightweight enough that you can still use those independent parts on their own, compatibly with docker. As someone who has exclusively used LXC containers (which Docker is/was initially built on), none of this applies to me. Your issue is with Docker, the implementation, not containers as a concept. Sometimes I feel HN needs to get its head out of Dockers butt and see that there's a world out here too. How many people here even know there are other container types at all? I'm often inclined to think none. No really. Just once try real, raw containers without all that docker wrapping bloat. How everything works and is tied together is just clear as day and obvious at once. It's all simple and super refreshing.
- vosper 10y ago
  The comment you replied to is clearly talking about Docker, and not containers in general. So I don't think the snark was warranted.
- deleted 10y ago
  [deleted]