for-mac VS podman

looks to be this: https://github.com/docker/for-mac/issues/7527#issuecomment-2...

I just finished porting my projects canonical build process to Docker a few days ago, and had a rude awakening today when MacOS declared Docker malware and deleted its executable. After an hour of trying to figure out why my build was broken, of course.

The workaround is just reinstallation, looks like they had a certificate issue:

https://github.com/docker/for-mac/issues/7520

The error was reported in issue #7520 of the official Docker for Mac repository. In the thread of this issue, a user named cdcaires shared a set of commands that resolved the problem.

For more details, check out the ongoing discussion on GitHub or Docker Community Forum here.

I use containers on Mac and Windows for development (and we deploy on linux). Docker for Mac is _unusably_ slow in my experience. The VM that it runs is a giant resource hog and a battery hog, and doesn't support ipv6 [0] Docker Desktop itself is (another) resource hog, wildly buggy, and painfully slow. It's the epitome of "shitty electron app".

On windows, docker desktop has all of the same issues as it does on mac. Docker's concept of volumes and file permissions on windows are nonsense. Windows updates and Docker Desktop regularly decide to disagree, [1] It's networking support interferes with other applications (like OpenVPN and the Xbox Game Center) [2].

[0] https://github.com/docker/for-mac/issues/1432

[1] https://github.com/docker/for-win/issues/599

[2] https://github.com/docker/for-win/issues/1976

Podman: A lightweight container runtime that eliminates the need for a desktop app. It’s free, open-source, and compatible with many Docker workflows.

Container Engines: Docker, Podman

A Quadlet is a way to create a service (with systemd) from a container. It uses Podman, a container engine. As it is OCI complient, the Docker images are compatibles with Podman.

And there's no REPL for the editor--so I can't actually find out details, let alone fix anything.

I had thought emacs DX was bad--but I've revised my opinion now: compared to vscode DX, emacs DX is great. You live with VSCode if you want to.

And note, vscode was made after emacs was made. There's no excuse for this.

I think this now was about all the time that I want to waste on this thing, again.

How is this a problem in 2025? shakes head

>VS Code managed to by-pass the qualitiy and amount of extensions/plugins in a fraction of time Emacs took decades.

Yeah? Seems to me these vscode extensions are written in crayon. Bad quality like that would never make it into emacs mainline. And it's not even strictly about that! I wonder who would write a developer tool that the developer can't easily debug its own extensions in. That flies about as well as a lead balloon.

For comparison, there's emacs bufferenv that does dev containerization like this and it works just fine. Configuration: 1 line--the names of the containerfiles one wants it to pick up. Also, if I wanted to debug what it did (which is rare) I could just evaluate any expression whatsoever in emacs. ("Alt-ESC : «expression»" anywhere)

PS. manually running "podman-compose up" in an example project as a regular user works just fine--starts up the project and everything needed. So what are they overcomplicating here? Pipes too hard?

PPS. I've read some blog article to make socket activation work for rootless podman[1] but it's not really talking about vscode. Instead, it talks how one would set up "linger" so that the container stays there when I'm logged out. So that's not for dev containers (why would I possibly want that there? I'm not ensuring Heisenbugs myself :P).

[1] https://github.com/containers/podman/blob/main/docs/tutorial...

Podman kube has support for k8s Jobs now: https://github.com/containers/podman/pull/23722

k8s docs > concepts > workloads > controllers > job:

There is a third option: enable the Docker socket and use Docker Compose as usual.

https://github.com/containers/podman/blob/main/docs/tutorial...

To install Podman on Windows, start by downloading the Windows installer from the official GitHub release page. Make sure to grab version 4.1 or later for all the features in this guide.

In the intensity of working as a DevOps engineer with the container, I have found Podman to be a game-changer in teams that take the security aspect seriously-that means avoiding root privileges. It's daemonless compared with Docker, which is a big architectural change. Daemonless approach just magically changes how teams do container security in production environments.

Podman implements a daemonless container architecture that eliminates the need for a central runtime service. This approach fundamentally differs from Docker's client-server model.

Docker is a company that maintains the Docker software and also offers a cloud service to run Docker containers in the cloud. They run DockerHub, which is a platform to store share and run Docker images. The actual standard for Docker containers is called OCI (Open Container Initiative). Because Docker is based on OCI there are many other tools that can interact with Docker containers, like Podman or Lima. If you want to go really deep, I really recommend reading the OCI specification! It's long but super interesting.