I'm excited to see this finally happen—acknowledgement that Docker Desktop has been an essential part of the process of onboarding devs (who often use the command line, but sparingly) into containerized development with a gentle on-ramp.
The big question is whether Podman Desktop will be (a) stable and not a memory-hog, (b) make container workflows on Mac/Windows as simple (conceptually at least) as on Linux, and (c) be a sustainable effort for the community that's still extremely Red Hat-centric.
To that last point, I still see very little adoption outside of the Red Hat ecosystem. It seems like `docker-ce` is still installed on most servers, `docker-compose` for lightweight app orchestration, and when people use Kubernetes, few people know or care what underlying container management daemon is running.
I can write docker-compose file, run it on my laptop.
Can't do that without spending 2 days of pre study with K8s. And to have it ready on a basic laptop is not fun. At all
I work on an operations team of about 2.5 people who handle everything for a small SaaS company and we're slowly containerizing. New systems are built and deployed in Docker and the legacy stuff is slowly getting there. We're using Swarm which I'm thinking is probably more like the middle ground.
I've tried to make podman work so many times but one of my biggest issues is the lack of great documentation and support from third parties (that's okay!). I just have a hard time finding good examples well explained to gain anything out of it.
I do think my issues are coming from not fully understanding rootless/rootful stuff combined with SELinux doing its thing as well.
I like docker compose to deploy stuff.
I do use podman+distrobox (Steam Deck & Fedora Kinoite)
It looks like I can finally see my distrobox containers with podman desktop. The first time I installed it months ago I could see them.
Anyone have any experience running Windows and WSL2 with Podman Desktop? I'm running W11, with fedora in WSL2. What I've been doing with Docker Desktop is running Docker Desktop on Windows startup, and that gives me access to the docker machine in both powershell and inside my wsl2 environment (for the latter, docker-desktop installs a binary inside fedora-wsl2 at `/usr/local/bin/docker` that communicates to the host)
So far, I uninstalled Docker-Desktop and installed Podman-Desktop, and now I can run `podman` from powershell but not from fedora. I'm about to try `sudo dnf install podman` and hope it connects to the podman-machine? I dunno, it's not exactly clear
> now I can run `podman` from powershell but not from fedora. I'm about to try `sudo dnf install podman` and hope it connects to the podman-machine? I dunno, it's not exactly clear
One thing you could do is just symlink or wrap the Windows podman.exe as `podman` on your WSL guests, and rely on WSL interop at the CLI instead of sharing a socket. This is probably what Docker Desktop does, based on your description (I thought it (used to?) share(s) a socket from the dedicated WSL guest it creates to your other WSL guests).
Alternatively, if you install Podman Desktop via Scoop and have WSL interop enabled for your guests (so that your Windows binaries appear on your Linux guests' PATHs), I think you'll get the same `podman` as your Windows PowerShell sessions access onto your WSL guests for free.
1. In the past, created a managed WSL vm to run containers.
2. At some point, it included the option to use a WSL distro instead, but you had to tell it explicitly.
3. Nowadays it detects whether a default WSL distro is present and uses it to run containers automatically. Otherwise it creates a managed WSL distro just to run containers.
As far as I understand, Podman Desktop still is at (1). You can't tell it to use your own WSL distro.
> I'm about to try `sudo dnf install podman` and hope it connects to the podman-machine? I dunno, it's not exactly clear
I think podman-machine is meant to be executed on the host, but worth a try anyway
Docker Desktop provides some compelling options for lowering the barrier of entry for selfhosting. Today you can take a Windows laptop and run just about any Linux service, with pretty fast networking and host disk access. No CLI experience required. The only major missing piece is inbound networking from the internet. Tunneling[0] is my preferred solution to that problem. Or if you don't want to expose your services to the internet there's already a Tailscale extension[1].
It's exciting and important to have an open source alternative in this space.
What value is added by swapping Docker out for an alternative on ECS? It's (at least as I understand it) basically an implementation detail, and well beneath the "covered by AWS support, don't touch" surface
You're right in a way, I really don't care what AWS does under the hood. The bigger issue is that I don't want any avoidable discrepancies between what I'm testing with on local and what I'm deploying. Obviously it's never 1:1 because my local isn't an AWS cloud infrastructure, but up til now the container engine isn't a variable.
Bear in mind that there are alternatives: JavaFX and Compose for Desktop are the ones I know best. They can be used from high level and popular languages. JavaFX is particularly good for desktop apps and can be compiled down to purely native code that starts as fast as an app written in C++ (likewise for Compose but the experiments with that are newer).
There are some downsides: fewer people know them than with HTML. There are a few tweaks like window styles on macOS it could use to be more modern. On the other hand, it's easy to learn and you benefit from a proper reactively bindable widget library, like table and tree views if you need those. For developer tools such widgets can be useful.
CfD uses Material Design of course, but you can customize it.
Having written desktop apps of varying complexity in all these frameworks, I can't say Electron is clearly superior. It is in some cases (e.g. if I was wanting to write a video conferencing app then it makes sense to re-use Google's investment into Hangouts/Meet for that), but it's also worse in some cases. For instance the multi-process model constantly gets in the way, but you can't disable it as otherwise XSS turns into RCE.
Does the podman VM have Rosetta 2 acceleration or does it still use the slow qemu runtime on M series Macbooks? This is the main reason I switched to OrbStack which is a very promising alternative to all of this. Free for now but looks like they intend on making it a paid app in the future. The speed difference is significant.
Qemu is the hypervisor in this situation. Which doesn't necessarily preclude having Rosetta acceleration of AMD64 binaries within the ARM64 Linux guest itself.
That said, as far as I know, the only official way to use Rosetta inside a Linux guest is using Virtualization.Framework, which allows mounting a Rosetta binfmt handler via Virtiofs. So it's also going to use Qemu inside the VM to handle running amd64 images, not Rosetta.
Readit News
The big question is whether Podman Desktop will be (a) stable and not a memory-hog, (b) make container workflows on Mac/Windows as simple (conceptually at least) as on Linux, and (c) be a sustainable effort for the community that's still extremely Red Hat-centric.
To that last point, I still see very little adoption outside of the Red Hat ecosystem. It seems like `docker-ce` is still installed on most servers, `docker-compose` for lightweight app orchestration, and when people use Kubernetes, few people know or care what underlying container management daemon is running.
But K8s is maybe not the tool for that either.
1. Use Docker Compose and have no container strategy
2. Have a container team and an orchestration platform.
Not many organizations operate in the middle ground, seems difficult to do well with little overhead.
That's why I don't bother with it on servers, I always use docker-ce with compose.
I do think my issues are coming from not fully understanding rootless/rootful stuff combined with SELinux doing its thing as well.
I like docker compose to deploy stuff.
I do use podman+distrobox (Steam Deck & Fedora Kinoite)
It looks like I can finally see my distrobox containers with podman desktop. The first time I installed it months ago I could see them.
Podman Desktop: Same functionality as Docker Desktop but open source - https://news.ycombinator.com/item?id=35296165 - March 2023 (36 comments)
Podman Desktop: A Free OSS Alternative to Docker Desktop - https://news.ycombinator.com/item?id=33536978 - Nov 2022 (191 comments)
Podman Desktop Companion GUI – Parity on All Major Operating Systems - https://news.ycombinator.com/item?id=31055475 - April 2022 (113 comments)
So far, I uninstalled Docker-Desktop and installed Podman-Desktop, and now I can run `podman` from powershell but not from fedora. I'm about to try `sudo dnf install podman` and hope it connects to the podman-machine? I dunno, it's not exactly clear
One thing you could do is just symlink or wrap the Windows podman.exe as `podman` on your WSL guests, and rely on WSL interop at the CLI instead of sharing a socket. This is probably what Docker Desktop does, based on your description (I thought it (used to?) share(s) a socket from the dedicated WSL guest it creates to your other WSL guests).
Alternatively, if you install Podman Desktop via Scoop and have WSL interop enabled for your guests (so that your Windows binaries appear on your Linux guests' PATHs), I think you'll get the same `podman` as your Windows PowerShell sessions access onto your WSL guests for free.
1. In the past, created a managed WSL vm to run containers.
2. At some point, it included the option to use a WSL distro instead, but you had to tell it explicitly.
3. Nowadays it detects whether a default WSL distro is present and uses it to run containers automatically. Otherwise it creates a managed WSL distro just to run containers.
As far as I understand, Podman Desktop still is at (1). You can't tell it to use your own WSL distro.
> I'm about to try `sudo dnf install podman` and hope it connects to the podman-machine? I dunno, it's not exactly clear
I think podman-machine is meant to be executed on the host, but worth a try anyway
It's exciting and important to have an open source alternative in this space.
[0]: https://github.com/anderspitman/awesome-tunneling
[1]: https://tailscale.com/blog/docker/
https://github.com/aws/containers-roadmap/issues/626
I love Podman but sadly not enough to run my own servers :(
Nothing else even comes close, unfortunately.
Maybe someday.
Bear in mind that there are alternatives: JavaFX and Compose for Desktop are the ones I know best. They can be used from high level and popular languages. JavaFX is particularly good for desktop apps and can be compiled down to purely native code that starts as fast as an app written in C++ (likewise for Compose but the experiments with that are newer).
There are some downsides: fewer people know them than with HTML. There are a few tweaks like window styles on macOS it could use to be more modern. On the other hand, it's easy to learn and you benefit from a proper reactively bindable widget library, like table and tree views if you need those. For developer tools such widgets can be useful.
There's a modern theme for JavaFX here:
https://github.com/mkpaz/atlantafx
CfD uses Material Design of course, but you can customize it.
Having written desktop apps of varying complexity in all these frameworks, I can't say Electron is clearly superior. It is in some cases (e.g. if I was wanting to write a video conferencing app then it makes sense to re-use Google's investment into Hangouts/Meet for that), but it's also worse in some cases. For instance the multi-process model constantly gets in the way, but you can't disable it as otherwise XSS turns into RCE.
The days of multi-stack-skill devs are gone.
It's likely easier if you assume the same starting skill level since dotnet build system is way simpler to deal with.
"lightweight and efficient" is definitely not what comes to mind when talking about Electron.
Depends on how much one actually bothers to look around.
That said, as far as I know, the only official way to use Rosetta inside a Linux guest is using Virtualization.Framework, which allows mounting a Rosetta binfmt handler via Virtiofs. So it's also going to use Qemu inside the VM to handle running amd64 images, not Rosetta.