Podman Desktop Companion GUI – Parity on All Major Operating Systems
iongion.github.io
iongion.github.io
- First binary for Windows, all due to amazing work of podman team
- https://github.com/containers/podman/releases/tag/v4.0.3
- First test flatpak image
- Binaries for ARM
- On Linux, easily switching between native podman and podman machine based setups
- Easily identify where settings are stored
- Debug panel and log level control to know everything that is happening
- Optimization of settings screen
- Toggle for automatically starting the podman service
One remark:
> Application looks the same everywhere, no mental mapping!
That depends on your perspective. If you are on one OS and this non-natve-looking app comes along, you have to mentally map it for your OS so it's none-nativeness requires mapping to the OS-nativeness.
If you, on the other hand, only work "in" this application and just take it with you regardless of the OS, then you would indeed not need to mentally map the application itself. But I doubt this application is used that way in isolation.
More importantly, however, working on : OSes frequently is rare. The developer of the app does it. I, as the user, dominantly use a single OS and want apps to be standard for that OS…
If it is, or if there were a command translation layer to transform docker cli stanzas to the podman equivalent, I'd love to dump and forget about docker forever.
Please keep pushing Team Podman! Self-respecting nerds everywhere are rooting for (and counting on) you!
Once generated and enabled, your pods/containers act as systemd services that can be started, stopped etc.
[0]: https://docs.podman.io/en/latest/markdown/podman-generate-sy...
I reboot my machine after kernel updates and everything comes up flawlessly.
Looks like the service is called podman-restart.service on my system.
You can run podman-system-service and get a socket/port that you can point the official Docker CLI or any Docker library at and it will just work (tm).
Some tools try to detect whether podman exists on the system or not and change their behaviour accordingly. I couldn’t get docker-compose to work properly either even though I had a socket exposed.
I would much prefer if the podman binary/cli also supported the compose command.
Then there are slight differences such as the registry that is used by default when resolving. Docker defaults to docker.io where podman asks. The same when an image is available in multiple registries.
Am not familiar with Rancher Desktop, but briefly looking at their website it has a Docker CLI dependency which surely would land it in the Docker licensing controversy space, no ?
Docker cli is still fair game.
It works well enough for single docker images, but I've never gotten it to work well with a complicated docker-compose set-up (I haven't tried in a couple months though, so go check the docs before you write it off).
My complaint with it is that I’d prefer if there was a 100% feature-parity CLI interface so it could run in the background, and that it should be open source.
To have a low-level developer tool that’s required to be in my menubar and administered through a closed-source GUI is IMHO an insane departure from web software development norms. I use lazydocker for now but it should be an official utility that replaces the GUI app.
> To have a low-level developer tool that’s required to be in my menubar and administered through a closed-source GUI is IMHO an insane departure from web software development norms.
Yeah, this is why I mentioned the mac/windows shop part. Desktop is only required on mac/windows. On linux, it's just the cli, which works just fine (it's also free).
Docker desktop works pretty well, and I'm not saying they don't deserve the money, but I'm not going to spend my own money to do enterprise work, so I have to investigate alternatives (minikube and podman worked the best, in my experience).
Podman has an almost identical CLI to Docker, and can have a daemon that is fully Docker compatible (thus, all Docker integrations work against it including docker-compose). It is literally a drop-in replacement but it doesn't require your company to buy licenses. So yes, you should if you can.
IBM/RHEL seem to be the effective the stewards of Podman, and are using their monopoly-like position in enterprise OS segments to take control of the virtualization layer through it. This is similar but worse to old MS/Windows doing tricks for IE vs others. Supporting Podman is supporting explicitly anti-competitive IBM/RHEL OSS behavior for enterprise, utility, & gov environments.
Everything Red Hat produces is open source (except the branded offerings, which are derived from the OSS upstreams). They charge for support. If you don't want support, use the OSS upstreams. What lock-in are you explicitly pointing to? Because I have no idea what you mean by taking "control of the virtualization layer".
Also, I should note that Nutanix and VMWare are a thing but again I am unclear at what unethical behavior you are actually pointing to at Red Hat. I am only responding to a shaky interpretation of what I think you are pointing to.
Yeah sure OSS in theory and IBM is a free entity. But for the same freedom, I am free to call from for divesting from any use of IBM/RHEL products and consultants in enterprise and gov contracts as no longer a trusted and ethical partner due to their anti-competitive self-dealing at the clear expense of the community & customer. RHEL lost neutrality & HA credibility as an infra layer and IBM as a partner through this. Nothing personal, just business and trying to protect our users, same as the RHEL org's actions helping themselves.
Can you clarify what you mean by swapping their race horse? What is the horse being swapped?
Where this gets problematic for a commonly "single-sourced" infrastructure technology in regulated envs is IBM/RHEL also prevented docker from making it into the RHEL 8 repos. Podman was obviously technically deficient as a critical infra replacement due to immaturity like many unimplemented compatibility APIs, yet it was marketed as compatible and instead of offering both until the community could prove it out etc, RHEL8 didn't include docker. NBD for people doing redhat at home or whatever easy environments, but if you're doing something like bringing AI to important societal problems at big world-reaching orgs, having to go outside the main repos can be a major drain on time, staff, budget, and even an existential risk. This is the kind of BigCo malfeasance we're supposed to be moving away from by promoting Linux, OSS, and containers.
RHEL8 felt like a repeat of IE vs Firefox but now for RHEL (main sponsor of Podman) vs Docker, and much worse. It's one thing if docker was never there or containers were removed, but this was replacing with a binary-incompatible tool under their effective control and marketing to security-critical customers (and on hackernews) as a safe and ready replacement. So we also burnt time diagnosising people were trying to use broken podman tech because that's all RHEL gave them and tricked them into thinking was appropriate.
- Both docker and podman support rootless containers.
- Rootless podman setup is easier to achieve from experience and it integrates well enough with systemd.
- Docker requires a daemon to run at all times whereas podman doesn't.
- A lot of interesting things are going on with podman ("native" gitlab-runner executor in the works, wsl2 support, among other things)
wsl2 mode is super impressive -- none of the overhead of docker on os x
Are there any good docs/blogs that go into detail on how they’ve managed to avoid that overhead? Would be awesome to learn about
In contrast, yes, wsl2 has 5% CPU hits (hyperv, ...),but a sane FS mapping, so the total overhead is imperceptible for a windows dev box.
I was pleasantly surprised to see wsl2 Just Work. Our only issue preventing wsl2 from being the official team rec over native Linux has been wsl2's lack of opencl, and that's just specific to our use of GPUs. As someone whose preferred dev box has been osx for ~20 years, even when at MS, I was biased against Windows for most dev... but no longer.
VSCodes “Create Remote Dev Container from Repository” functionality has made it even easier. My dev containers have no overlap with the host filesystem so macOS and Windows are equally performant for my use cases :)
Almost all our dev is generic, so that means Windows for Office/web/... and full Linux for dev (except no real OpenCL).
Nvidia punts to IBM RHEL8 docs for GPU podman, which is unusual and risky to see. We officially recommend against it for HA environments due to this kind of lack and overall low relative confidence. I think k8s envs may be moving to something here, so maybe in a year or two? I'd be curious of folks doing stock rhel8 podman with tensorflow/torch on nvidia, which should be as vanilla as you can get for enterprise ai. We generally see more interesting GPU envs here (ex: DGX with advanced networking hw/sw), but we don't have confidence for the simple case, which is the starting point..
I've found this troubleshooting page quite helpful: https://github.com/containers/podman/blob/main/troubleshooti...
This changed in the last year, previously docker was free to use personally or at non enterprise scale work/office.
This can be found at the very bottom of that page:
> Docker Desktop can be used for free as part of a Docker Personal subscription for: small companies (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.
podman run -ti --rm --security-opt seccomp=unconfined --security-opt label=disable --cap-add SYS_ADMIN --env STORAGE_DRIVER=vfs quay.io/podman/stable sh -c 'podman run -ti --rm --security-opt seccomp=unconfined --security-opt label=disable --cap-add SYS_ADMIN --env STORAGE_DRIVER=vfs quay.io/podman/stable sh -c "podman run --rm hello-world"'Ton's of people do, it's the default container CLI for OpenShift.
I have a Windows PC where I would like to use the podman context over SSH on a Linux machine.
That's the only thing that has kept me from switching.
Ideally with VSCode Remote.
Or just replace MacOS with Linux.
I don't think I'd call Linux, Mac and Windows "All Major Operating Systems".
Also, while istoica says there's ARM support, I see no links for downloads for anything but 64 bit x86, and there's nowhere to go for more information, unless we're expected to ask all questions on Twitter.
Perhaps "Parity on popular 64 bit x86 operating systems" would be more accurate?
If you saw a game marketed as runnable on "all major operating systems", would you think it's deceptive, or at very least a poor choice of wording, if the game really only ran on Windows 7, 8, 10 and 11?
In the open source world, on a site called "Hacker News", "all major operating systems" would usually be thought to mean more than just Mac, Windows and Linux, particularly when it's chosen as a headline.
Also, claims by the author about ARM support are nice, but I don't see any ARM anything, anywhere, so not only is it not "all major operating systems", but it's "just the three most popular OSes, and only then on 64 bit x86".
In my eyes this pretty much covers it: they even have both DEB and RPM distro support, as well as AppImage and Flatpak packaging formats (they could also consider snaps, but those might not be strictly necessary, considering that there are .deb packages available).
What else would you like to add to the list of major operating systems?
Genuinely curious, i might expand it to include some of the BSD varieties, like FreeBSD and OpenBSD, but they never really embraced OCI images much, Docker not being a first class citizen, nor Podman, given that they already have the historical jails mechanism which is what you should use on those OSes in most cases.
One might also consider Android/iOS a "major" operating system, but those are almost never the targets for software like this, or things related to servers. Actually that's a shame, considering that an old phone with a custom Android ROM and root might make for a really cost-effective alternative to a Raspberry Pi, but alas, we're not quite there yet as an industry.
Any other suggestions? Agreed about ARM support, but that's an architecture question, rather than an OS one.