Live data from Hacker News

I don't like Docker or Podman

blog.liw.fi

41–50 of 92 posts

Re: I don't like Docker or Podman

#41
post #10

> The command line interface is really badly designed. It’s ugly, hard to learn, difficult to remember, illogical, inconsistent, and just makes no sense to me at all. I wonder if the author could elaborate here.

This stood out to me, too. Git's CLI was very confusing for me to learn, but on Docker the metaphors made sense. An image, like a file system image. A container, something with walls. Exec to execute commands. Rm to delete. Some of the networking stuff took a little to learn (exposing ports to other containers vs outside of docker) but I think that's necessary complexity.

Re: I don't like Docker or Podman

#42
post #10

> The command line interface is really badly designed. It’s ugly, hard to learn, difficult to remember, illogical, inconsistent, and just makes no sense to me at all. I wonder if the author could elaborate here.

I wish they would elaborate a bit more on each single point. I'm quite happy about docker, so I'm especially interested when someone has a negative opinion about it. But here I feel like there's no meat to this article.

That's my impression, too.

While I agree that developers should support and have documentation for hosting without Docker, I think the arguments in the article are very poor.

It's completely fine to dislike a technology - hell if I don't! - but here it seems like they are arguing against Docker just for the sake of it.

Re: I don't like Docker or Podman

#43
post #5

Cool story but at least try to give some argumentation when you say stuff like: >The design of the language in Dockerfile is ad hoc in a bad way. It’s difficult to understand, for me, and easy to make mistakes. Because that reads like a skill issue to me

Dockerfile is one of the worst parts of docker — it's a primitive shell-like DSL that didn't have to exist and that feels like it was designed by a person with a couple of hours of experience in writing shell scripts.

Instead of providing a set of separate tools to be glued together with a proper shell or a full programming language, they designed this nonsense that can't even do 1/10th of what busybox is able to do, and have been in the business of adding the missing pieces (like `COPY --chmod`) for the past 10+ years.

It has taken them about a decade to add HEREDOC support, for example. Most dockerfiles still use

  RUN foo && \
      bar && \
      baz
instead of

  RUN 
I avoid dockerfiles and prefer using buildah for building containers. Since they're all using the same specification, it doesn't matter what runtime is then used to run them: it can be docker, podman, k8s, whatever.

Here's the official example of building a lighttpd container:

https://github.com/containers/buildah/blob/92015b7f4301d7eb8...

You can eschew bash and call these commands however you want — from a python script, or Go, or even assembly.

Re: I don't like Docker or Podman

#44
post #10

> The command line interface is really badly designed. It’s ugly, hard to learn, difficult to remember, illogical, inconsistent, and just makes no sense to me at all. I wonder if the author could elaborate here.

not author but

`cmd containers` does nothing, `cmd images` does `cmd image ls`,

`cmd rm` does `cmd container rm`, `cmd ls` does nothing, its of course `cmd ps`,

`cmd rmi`, no `cmd lsi`,

no easy way to extract the resultant hash from a `cmd build`, can use a tag I suppose

Re: I don't like Docker or Podman

#46
post #37

So here's the thing: Docker is the best way we have to document how to set up a project/application in a way that can be repeated on arbitrary computers. The alternative was "have a README where you list all of the things you need to do/install in order to get this project running". That failed. Miserably. Developers always assumed things like "well naturally, if you're playing in the XYZ space, you've already got me…

Fully Agree.

Dockerfiles were an excellent way of sysadmins getting developers to write down their build steps.

The fact that they're not deterministic was helped by the fact that we can just copy/paste tarballs around (all a docker image is, is just a pile of tarballs in a tarball after all).

Re: I don't like Docker or Podman

#48
post #37

So here's the thing: Docker is the best way we have to document how to set up a project/application in a way that can be repeated on arbitrary computers. The alternative was "have a README where you list all of the things you need to do/install in order to get this project running". That failed. Miserably. Developers always assumed things like "well naturally, if you're playing in the XYZ space, you've already got me…

I think for the development story, we had vagrant in the 2010s which IMO provided a much better experience for developers to set up reproducible dev environments.

Docker excels at bundling up all the dependencies of a piece of software for deployment.

Devcontainers definitely work these days, but I miss vagrant.

Re: I don't like Docker or Podman

#50
I had to use Docker at a job or two, I think around 2018. I hated it.

One class of issue: It made interacting with the file system slower, sometimes by orders of magnitude. Stuff like watching files, or statting a large number files, didn’t have the same performance characteristics. So you have a situation where you (probably) already have too many components that are too complicated or poorly understood to install them all on a developer’s machine, but they work on this exact machine snapshot, but now you have to figure out what process dared to stat a few thousand files.

Docker was also just always… there. In the menu bar. Doing stuff. Running system-wide. Updating itself, constantly. Like it’s Steam or Battle.net (which for some reason downloads updates to Warcraft III, an old game, multiple times a day on my kids’ PC, and sometimes breaks and you can’t play the game; this is the level of enshittification we are at).

The command-line experience… similar to git (that is, poor). There’s an underlying conceptual model that’s sort of half abstracted away by the tools and hard to find a good explanation of.

Developer tools like this have a tax: You spend at least half a day a week Googling for issues with them, forever. Same with NPM. All it takes is five such tools in your stack and every weekday morning is gone. And that’s disregarding the fact that you were probably in the middle of actually trying to get something done.

Post reply on HN