Podman Desktop Companion GUI – Parity on All Major Operating Systems(iongion.github.io)
iongion.github.io
Podman Desktop Companion GUI – Parity on All Major Operating Systems
https://iongion.github.io/podman-desktop-companion/
117 comments
Question: why was the official Podman desktop app [1] elevated over this app? The Companion app which this post links to appears more fully featured.
[1] https://github.com/containers/podman-desktop
[1] https://github.com/containers/podman-desktop
Seems like a pretty nice Docker-desktop-ish GUI to me.
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.
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.
Mapping different behavior between operating systems is much harder than mapping between native and non-native apps.
That’s … debatable.
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…
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…
Is the Podman CLI both command-compatible and flag-compatible with the Docker CLI?
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!
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!
It is! At least 99%, in my experience. The one big difference is that Podman is "daemonless", which is actually a huge advantage in a lot of cases. The one downside is that it won't automatically restart your containers if your host machine reboots.
For that Podman provides a nifty little trick: `podman generate systemd`[0] which allows you to generate systemd unit files for your pods and/or containers.
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...
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...
This is no longer necessary as of Podman 3.3 or so--there's a single Podman systemd unit that will launch all containers that have restart=always.
Interesting! Do you have by any chance a link the documentation about it, because so far all I could find are links to information about `podman generate systemd`.
That's awesome, I didn't know about that.
Looks like the service is called podman-restart.service on my system.
Looks like the service is called podman-restart.service on my system.
Yup. I use this for all my home server services like Plex, Adguard, etc.
I reboot my machine after kernel updates and everything comes up flawlessly.
I reboot my machine after kernel updates and everything comes up flawlessly.
This generator has even better systemd integration: https://github.com/containers/quadlet
I want to mention the "-userns=keep-id" option of podman, which is a reason enough to use podman rather than docker on a Linux laptop.
The "podman.service" systemd unit takes care of restarting containers that were marked so.
correction: podman-restart.service
The biggest drawback for me is that podman cannot build containers.
Huh? I use `podman build` all the time. Sure, it uses `buildah` in the backend, but does that really matter?
On Mac OS at least there is a bunch of hoops you have to jump through for build to work at all. If I recall you needed virtualbox installed (which I don't want). With docker it just works, you install docker you can run docker build, no extra troubleshooting, or hacky workarounds, just so you can use basic functionality.
Even better. It”s API compatible with the docker daemon.
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).
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).
I’ve run into many issues with tools when moving from docker to podman, mostly because they tried to be smart.
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.
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.
Also in the same space is https://rancherdesktop.io/.
> Also in the same space is https://rancherdesktop.io/.
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 ?
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 and Docker engine are open source :) Docker Desktop for Windows/Mac are not. So as long as the dependency is on the open source components, AFAIK they'd be fine.
What controversy? It is a replacement for docker Desktop which turned from free to payware for commercial use.
Docker cli is still fair game.
Docker cli is still fair game.
It's containerd and nerdctl by default. You can configure it to use dockerd and docker.
[deleted]
Anyone know if podman has an equivalent to `docker buildx` yet? Right now I use docker a lot to build arm images to deploy on e.g. Raspberry Pis.
You have to explicitly invoke buildah bud with --arch and --manifest. You can then push the manifest with podman. There is slightly less magic, which is a HUGE advantage if you operate outside of the hairline Docker happy path.
I know this isn’t applicable to every use case but I recently went down the rabbit hole of cross compiling for the Pi using buildx and in my case I was able to use their 64 bit OS which was released to the general public back in Feb of this year. That one takes arm64 images no problem. Obviously no Pi’s before 2016 can use this but it solves a lot of difficulties if you aren’t absolutely requiring a cross compile and an arm64 image is available.
I keep hearing that buildx is a next-gen build tool, but I can't find what exactly it does. What features does it add over the classic `docker build` command?
I am also unsure how buildx works, however I do know that the official docker build-and-push action is not compatible with podman (despite the podman-docker pkg), solely because it uses buildx. As well, compared to buildah builds, building with buildx is much faster--at least with default flags for buildah-build-and-push vs docker-build-and-push. I can say that buildx has an additional cache that must be cleared overtime, which might be related to the build speed difference.
If buildx is build kit then there's a good amount of granular caching involved, as well as the ability to build in parallel.
I use it to build x86 images on my M1 MacBook
There is "podman buildx build …" which sounds like what you are searching for?
Somewhat related, do all registries support pushing multi arch builds? DockerHub works, but I can't get it to work with GitHub registries.
I've managed to push amd64/arm64 images to GitHub a while ago, but I was still using Docker proper at the time, so the registry itself should support this.
So question from novice in containers, podman vs docker why should i consider switching from docker?
A few elements to inform the decision:
- 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)
- 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)
Doesn't Docker already support WSL2? Or is there something different about Podman's WSL2 support which makes it better/different than/from Docker's?
Yep, docker in wsl2 is great, including GPU support
wsl2 mode is super impressive -- none of the overhead of docker on os x
wsl2 mode is super impressive -- none of the overhead of docker on os x
None? How does it manage that, it’s still running in a (Hyper-V) VM?
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
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
For the comparison to os x docker, the biggest slowdown for os x docker is the file system mapping. It basically breaks any reasonable performance chart: look up posts getting into alternatives like mutagen. The slowdown makes using an IO-heavy dev flow like live editing via `npm run watch` relatively unusable: 30X+ slowdowns are normal. There might be high CPU overheads too (I recall we had to tweak seccomp), but when basic IO is so slow, the rest doesn't matter.
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.
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.
Oh right yeah — to be honest because I was so used to file system mapping being so slow (and even on my W10 box it’s not perfect for deep file system trees like node_modules), I stopped using it.
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 :)
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 :)
Yes, wsl2 afaict works like that and a bit improved. Instead of dual booting or a restricted dev env, I click my Linux terminal icon and jump into a full & fast Ubuntu, including UIs when helpful. Sharing with Windows is possible through a shared mount of C:, but I rarely encounter it, basically only for a web downloads folder or working around certs. Same thing for VS Code, have a Windows mode and a wsl2 mode, and it opens the right one for you.
Almost all our dev is generic, so that means Windows for Office/web/... and full Linux for dev (except no real OpenCL).
Almost all our dev is generic, so that means Windows for Office/web/... and full Linux for dev (except no real OpenCL).
Just curiosity, what are you using the GPUs for?
interactive graph ai + graph viz, such as for understanding it/sec/fraud/customer log activity
HyperV is lightweight and from what I understood, windows runs on top of hyperV too when you enable WSL2. You may lose a few % of performance in video games.
any idea if podman will support GPU? I couldn't get it to work.
In theory yes, and we got tiny programs running this way, but could not afford to keep subsidizing megacorp politics.
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..
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..
[deleted]
Docker supports wsl2 but I have constant performance issues with it (memory leak, high CPU usage).
podman indeed has many interesting features, but those features tend to have interesting bugs and limitations as well.
What got me at first are the limitations around rootless containers, which I wasn't accustomed to. Rootfull docker makes many things (networking, volumes etc.) Fairly easy.
I've found this troubleshooting page quite helpful: https://github.com/containers/podman/blob/main/troubleshooti...
I've found this troubleshooting page quite helpful: https://github.com/containers/podman/blob/main/troubleshooti...
Any specific limitations? I want to understand how much of a deal breaker they are.
All software has bugs. All software has limitations.
Where can I find more information about this 'native' gitlab-runner executor?
I'm following this issue:
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27119
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27119
thanks!
Npb. It's also listed on the upcomming release page apparently
https://about.gitlab.com/upcoming-releases/
https://about.gitlab.com/upcoming-releases/
The main use case right now is that your company won't spring for a docker desktop license (and you work in a windows/mac shop).
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).
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).
The macOS Docker Desktop app (I haven’t experienced other versions) is free and works fine. The paid upgrade is only required for certain features that I would imagine many teams don’t need.
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.
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.
Docker Desktop is now only free "for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects." per https://www.docker.com/products/docker-desktop/
It works fine if you're working solo, but companies have to pay for it.
> 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).
> 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).
It's not free if you're in a decently sized company, that's the whole point of the Docker controversy.
If the company is of a certain size, Docker Desktop is no longer free. As in, it's free to install and use, but your company is supposed to pay a license.
It depends on how complex your usecase is, but using pods and just scripting your containers' composition isn't such a hassle in podman.
Docker is under a commercial license and if you use it at a company or work you need to now pay $5 a person a month: https://www.docker.com/pricing/
This changed in the last year, previously docker was free to use personally or at non enterprise scale work/office.
This changed in the last year, previously docker was free to use personally or at non enterprise scale work/office.
Isn't that only docker desktop? AFAIK docker cli and docker daemon are still free.
Yeah, but there's no release of docker daemon for mac or windows. You have to run a linux VM and install and use it there. Docker desktop basically wraps that VM process up into a little gui app. If you're willing to do it yourself then yeah a simple virtualbox VM can run docker without issues or license fees.
I guess it’s time to go back to the old boot2docker xhyve setup I used to have!
or just use Podman.
From what I read, the "Personal" $0 tier still has "small businesses" listed, and the little info tooltip for Docker Desktop also explicitly mentions "small businesses."
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.
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.
I've been using podman for a year now and I didn't even realize it until I looked and saw that I had a symlink for 'docker' -> podman.
It's possible to run podman in podman in podman in …, which is nice if you containerize the build system but don't want to pack everything into one large image nor want to divide it into stages called by some main script on the host.
Some extra args needed, though:
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"'Do you know if you need a license for that docker desktop you’re running?
You shouldn't.
Why not?
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.
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.
podman has had repeat compatibility issues for us, and redhat has made docker installation stupidly hard in rhel8 at the policy level, which matters given the monopoly status of rhel in secure environments. It is hard for me to support the podman community for basically ethical reasons at this point. Normally I like competition and innovation, but not like this.
This doesn't sound like an ethics issue unless you have other issues with Red Hat's behavior.
Strong disagree. See above.
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.
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.
This doesn't make any sense to me. How is stewardship over a method of running and managing containers that was originally born out of another project not collaborating with the commons (docker engine) enforcing a monopoly position?
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.
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.
Maybe you are not familiar with how enterprise , and especially utility and gov systems work? It is often hard to not use RHEL due to compliance policies. IBMers deciding to swap in their race horse -- and simultaneously hobbling the current one -- is effectively making the decision for the US Gov for the next 2 years.
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.
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.
Well I am deeply familiar with how enterprise gov systems work in Denmark but no I am not familiar with the US side.
Can you clarify what you mean by swapping their race horse? What is the horse being swapped?
Can you clarify what you mean by swapping their race horse? What is the horse being swapped?
Docker largely entered Enterprise (regulated & security conscious markets) like utilities, us gov, banks, etc. via rhel 7 / centos 7 . A lot of people doing a lot of compliance work everywhere, from approvals to infra to audits, invested serious time, $, and social capital to make that happen. With RHEL 8, IBM / RHEL bet on podman (or, "not docker"), all the way from marketing to M&A to repositories to where developer hours go. On its own, I think that's great: tech should keep pushing, and good pressure on docker for things like rootless. But, that's not the issue here.
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.
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.
It's difficult to add docker's RPM repo and install it?
In secure airgapped environments, very much so. We blew time setting up new offline install processes & tutorials for the Nvidia docker ecosystem for rhel8, which basically reused centos7, as most of our users took weeks/months when they tried to figure out for themselves. Think utilities, gov, banks, etc: Anything not supported by official RHEL8 repos causes problems both technical and compliance.
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.
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.
Podman doesn’t have a daemon, it has a socket that will replicate the docker API. That comes with some limitations, especially around the lifecycle of containers in ie starting containers on boot, restarting unhealthy containers etc which require you to use systemd. Podman’s integration with systemd is pretty easy now though.
I'm not going to attest for accuracy on the statement, but from my RHCSA training I recall that docker runs as a daemon, while podman runs containers in separate processes; so it should be easier to avoid lockup/blocking.
Looks great! I'm pretty comfortable with the podman command line, but here's another (text-based) management interface that is well done:
https://github.com/containers/podman-tui
https://github.com/containers/podman-tui
Is there WSL2 integration?
Yes. Podman allows you to use WSL2 with the `podman machine` command on Windows.
That’s not it. What I’m looking for is the ability to run Podman Desktop on Windows and access it from WSL2. Docket Desktop supports this.
I’m in charge of my teams dockerfile which literally runs all our crap locally for our developers. I was too lazy to care so just put in our O&M budget docker desktop (our dumb IT doesn’t let us run Linux. Half WSL. Half macOS (bleh)). Now I’m wondering if it’s worth the effort to switch. But it’s also hard to say we run podman on the desktop but docker in prod. Anyone run podman on gcp? Is that a thing?
I was wondering, can you do SSH remote with podman like with Docker.
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.
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.
Would this work for graphical applications? For example, could I make a container and run a linux game under X or Wayland on my Mac?
I think this is more like a docker container management system like Docker for Mac vs a VM
Have a look at Lima, which I assume is what this project uses for its Linux VM. Then you'd need to find an X client for MacOS. That would probably give you the biggest chance of getting GUI working, but you would probably be one of the first to try.
Or just replace MacOS with Linux.
Or just replace MacOS with Linux.
[deleted]
yet another Electron app on my computer! neat!
This has quite the, "oh, we got both kinds. We got country AND western" vibe.
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?
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?
> I don't think I'd call Linux, Mac and Windows "All Major Operating Systems".
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.
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.
What at the major operating systems you feel are missed, and how do their market shares compare to Windows, OSX and Linux?
which major operating systems are missing? I would indeed call Linux, Mac and Windows the "major" operation systems. You've got most use-cases covered. Surely there are exceptions, but these are the popular options.
BeOS, obviously.
I take exception with the choice of wording in "all major operating systems".
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".
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".
How about you start by defining what a "major operating system" is, and then point out which by your definition are not included in Mac, Windows, and Linux.
Probably means all major OS with the contrainst that can also run podman?
- 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