The issue is that pausing that way isn't really fixable mostly because of systemd priniciples. One would have to interact with it AFAIK which makes it way more complex, and still there are the usability issues. (I wrote the blogpost)
I am usually an early adopter but I keep coming back to Docker since Podman is still very rough around the edges, especially in terms of "non-direct" usage (aka other tools)
As someone who's been bitten by this, I'm not sure if it's an issue with podman itself as much as the tools which expect docker. It could be argued that podman is not a docker drop-in replacement, but I expect more and more tools to pick it up.
Besides the advertising, it's very close to being a drop-in replacement but their pace isn't closing that gap quick enough (or maybe they don't want to, or it isn't possible, idk I'm just a user) so you get a false sense of confidence doing the simple stuff before you run into a parity problem.
Is this a matter of developers constantly relearning the lesson of the folly of only supporting the current top thing, or is it a lot harder to support more than one?
I don't know how "hard" it is, but in my particular case I wanted to use this from intellij. It actually works, but the issue is that the docker emulation socket isn't where the ide expects it, and I haven't found a way to tell it where to look for.
The devil is in the details. For example, docker has a DNS service at 127.0.0.11 it injects into /etc/resolv.conf, while podman injects domain names of your network into /etc/hosts. Nginx requires a real DNS service for its `resolver` configuration.
I think that Docker can have a viable business plan but they had terrible execution.
At my previous position, I wanted to use DockerHub more heavily but the entire experience was like a bootstrap project someone did as a university assignment. Many advanced features for organizations were lacking (SSO/SAML) that we would have happily paid for.
mirrord is a tool for backend engineers that enables them to work on a remote environment without needing to deploy there or actually run there.
It makes the iteration time (code -> test -> [review] -> deploy) faster since you don't replace the remote service also, which means many devs can work the same time.
Most odds is when x64 binary will stop shipping, arm64e won't be in preview mode anymore and we will be able to just do the re-signing part. (Which is supported)