31–40 of 92 posts
The most evil pattern is when application developers force users to install Docker to use their applications.
As a tangent… do you mean „developers of open source software available for free download”?
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
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.
The most evil pattern is when application developers force users to install Docker to use their applications.
Why? You can treat Dockerfile as documentation for the most part
This is particularly common with CLI tools written in some languages. I was looking at Antora the other day (not intending to single this project out, it's just the one that came to mind). I found two ways to run it:
1. By installing Node: https://docs.antora.org/antora/latest/install-and-run-quicks...
2. By running it in a Docker container: https://docs.antora.org/antora/latest/antora-container/.
The amount of complexity here is shocking. This is a tool that could just as well be a single binary, with the only dynamic linkage being to libc and maybe OpenSSL.
This also means that if something goes wrong, black-box debugging tools like system call tracers are much harder to use. I rely on system call tracers all the time, and it really sucks when they stop working.
subversion intended to be a better version of CVS
which it certainly delivered, but no-one really stopped to think if that was such a good thing in the first place
The most evil pattern is when application developers force users to install Docker to use their applications.
Hell, even if you're paying customer, if a product has only Docker as installation method and seller is not interested for providing .deb's and .rpm's, go find another solution.
That failed. Miserably.
Developers always assumed things like "well naturally, if you're playing in the XYZ space, you've already got meson installed. What, do you expect me to teach you basic arithmetic in this README too?" Developers across the board, across programming subcultures, showed themselves unable to get past this sort of thing.
So now we have Docker. You may not like it, but this is what peak install guide looks like. An unambiguous file that describes the exact shell steps required to get the piece of software running, starting from a base distro. The developer can't omit any steps or the container won't work on their machine.
It sucks that this Hegelian situation calls for such a draconian solution, but that's where we're at. Developers as a whole can't be trusted to handle this on their own. If you don't have a better solution to this problem, I'm not sure there's much point in complaining.
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
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.
Earlier quoted context omitted.
Why? You can treat Dockerfile as documentation for the most part
Because despite most devs opinion on the matter, we don't live in a Linux only world.