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.
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.
Can you expand on this a bit? What is an example of something you'd like another player to do that RH isn't doing?
podman compose is effectively 90% finished too. It's just annoying seeing some roughness around the edges.
I'm not convinced it would be all that hard to make it better than docker compose, either.
I'm still using it, because the last time I had time to mess with it, docker-compose still required a lot of fiddling to work with podman. From the other replies to your comment, I guess it must have gotten better, so I'll guess I'll try docker-compose again soon.
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.
I love Podman but sadly not enough to run my own servers :(
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.
I tried switching to nerdctl and containerd but the problem is that I have existing workflows that make use of docker_init files and nerdctl breaks those.
That isn't docker, Kubernetes is designed to work that way. To be infinitely horizontally scalable, and automatically handle pods (and servers) going down, caring about which instance you are talking to is generally a bad thing.
In the kubernetes case (I am using k3d on my Mac) pods aren't directly routable but with metallb, load balancer IP addresses can be connected to directly and there's no worry about port conflicts as there might be with k3d's default servicelb implementation (this is my bootstrap script https://github.com/andrewmackrodt/k3d-boot).
If you need to connect to specific pods directly and it doesn't make sense to change your pod config, kubectl port-forward may suffice?
x64$ podman system service -t 0 &
x64$ systemctl enable --now --user podman.socket
m1$ podman system connection add fedora --identity ~/.ssh/id_rsa --port 22 ssh://craig@s1.local/run/user/1000/podman/podman.sock
m1$ podman system connection default fedora
m1$ podman system connection list --all
m1$ podman system connection default <chosen system from above command>
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
[0] https://www.phoronix.com/news/CentOS-8-Ending-For-Stream
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)
It's exciting and important to have an open source alternative in this space.
It still has lots of documentation issues/missing. Lots of little bugs and very little updates on stability.
Used wsl2 and ubuntu. Eventually gave up because it was just leading from one rabbit hole to the next.
Either use venv/vagrant/docker. Or just use native development workflow.
Podman is not worth the pain unless its for a mid size business or bigger.
Only to find out yesterday I had to downgrade the extension due to differences between docker and podman.