6 ms·

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 difficul

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

SlightlyLeftPad 2y ago
Fair but there are some specific mechanisms that are particularly poorly documented and designed, like exposing gpus and cifs/nfs mounts as a couple examples.
EdwardDiego 2y ago
I really hate "skill issue" as a response
- gjvc 2y ago
  agree, not everyone has / had a mentor
xyproto 2y ago
Not writing all software in machine code is also a skill issue. The question is not if it's a skill issue or not, but if the complexity of the solution matches the complexity of the problem domain. And also: if there are easier and clearer ways to reach the same goals.
- p_ing 2y ago
  Bingo. Which is why that k8s fad was inappropriate for almost everyone out there. Your app could have run under cron every hour once an hour on an i586 but you had to spin k8s because it was "cool".
- 9dev 2y ago
  Dockerfiles provide a small set of operations to create a reproducible software artefact. I have been doing this for a while, I’ve seen POM files, Groovy Pipelines, endless shell scripts, Makefiles, and lots more. From all those, Dockerfiles do not seem like an absurdly complex solution to the problem to me.
homebrewer 2y ago
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 <<END set -eu foo bar baz END 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/92015b7f4301d7eb8057a39663ab44eabfb65986/examples/lighttpd.sh 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.
gjvc 2y ago
relevant https://news.ycombinator.com/item?id=34383754 https://news.ycombinator.com/item?id=34383754
manosyja 2y ago
> skill issue liw is Lars Wirzenius, so I assume we can rule that out.
Hizonner 2y ago
Trivial things should not require skill.

SlightlyLeftPad 2y ago

Fair but there are some specific mechanisms that are particularly poorly documented and designed, like exposing gpus and cifs/nfs mounts as a couple examples.

EdwardDiego 2y ago

I really hate "skill issue" as a response

gjvc 2y ago
agree, not everyone has / had a mentor

xyproto 2y ago

Not writing all software in machine code is also a skill issue. The question is not if it's a skill issue or not, but if the complexity of the solution matches the complexity of the problem domain. And also: if there are easier and clearer ways to reach the same goals.

p_ing 2y ago
Bingo. Which is why that k8s fad was inappropriate for almost everyone out there. Your app could have run under cron every hour once an hour on an i586 but you had to spin k8s because it was "cool".
9dev 2y ago
Dockerfiles provide a small set of operations to create a reproducible software artefact. I have been doing this for a while, I’ve seen POM files, Groovy Pipelines, endless shell scripts, Makefiles, and lots more. From all those, Dockerfiles do not seem like an absurdly complex solution to the problem to me.

homebrewer 2y ago

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 <<END set -eu foo bar baz END 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/92015b7f4301d7eb8057a39663ab44eabfb65986/examples/lighttpd.sh 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.

gjvc 2y ago

relevant https://news.ycombinator.com/item?id=34383754 https://news.ycombinator.com/item?id=34383754

manosyja 2y ago

> skill issue liw is Lars Wirzenius, so I assume we can rule that out.

Hizonner 2y ago

Trivial things should not require skill.