Pretty sure that's because podman-compose literally calls docker-compose under the hood.
e: from the manpage:
"podman compose is a thin wrapper around an external compose provider such as docker-compose or podman-compose. This means that podman compose is executing another tool that implements the compose functionality but sets up the environment in a way to let the compose provider communicate transparently with the local Podman socket. The specified options as well as the command and argument are passed directly to the compose provider."
That's the "podman compose" wrapper command. podman-compose (the implementation referenced in the first sentence of your quote) does not call docker-compose: https://github.com/containers/podman-compose
The author mentions that copy-pasting code by itself is not a bad thing. The problem with the phenomena they describe is that people copy-paste files around because they _don't understand it_, and end up with stuff that works, but is inefficient and hard to debug.
> Another example is jq. I use it occasionally, and ChatGPT handles the syntax pretty well. For me, learning it properly just isn’t worth the time or effort.
This resonates with me, I was in exactly the same position when I needed to do something with `kubectl` JSON output - just ask ChatGPT because I couldn't be bothered to learn the unintuitive syntax.
Interestingly I _can_ blame the tool, because I started using Nushell[1] which has built-in JSON manipulation that provides a MUCH simpler syntax, and I have learnt this properly because it was that easy.
Nushell is awesome. Too bad the incompatibilities are still a bit too much for me to use it as a daily driver.
It’s easy to blame the tool, but sometimes the problem space is inherently complex. With limited time, building the right abstraction is an immensely difficult job. LLMs fixed this issue for me, and I’ve stopped complaining about unintuitive but ubiquitous tools.
I am/was in this scenario. I'm sure there are other resources out there specifically aimed at developers, but a book I'm reading now is "Deep Learning From Scratch" by Seth Weidman. He takes a different approach, by explaining concepts in three distinct methods: a mathematical way, by using diagrams and by showing the code.
I like this approach because it allows me to connect the math to the problem, whereas otherwise you wouldn't have.
I think if you are truly trying to understand deep learning, you will never get to avoid the math because that's really what it is at it's core, a couple of (non-linear) functions chained together (obvious gross oversimplification).
