Why does Docker feel like it was designed by people with no Unix background?
Show HN: Container Desktop – Podman Desktop Companion
51–60 of 207 posts
Re: Show HN: Container Desktop – Podman Desktop Companion
#52Earlier quoted context omitted.
Last I checked podman's support of docker-compose.yml was very limited to say the least. Has it changed?
There are two approaches to using compose w/ podman: Replace docker-compose with podman-compose -- somewhat limited capabilities, but works in a lot of cases. Use docker-compose against podman w/ podman's system service, which provides a docker compatible API endpoint ( https://docs.podman.io/en/v5.2.1/markdown/podman-system-serv... ). This basically has full docker-compose capabilities, but, you do need run the sock…
I found the most stable to be a third option: 'podman compose' with docker-compose-v2 cli "backend" connecting to the actual podman socket. This will be done if you run 'podman compose' with 'docker-compose' in PATH, and DOCKER_HOST set to your podman socke, since 'podman compose' will just shim through to whichever command it finds available.
Both podman-compose (the Python project) and docker-compose-v1 have significant gaps in the compose spec.
Re: Show HN: Container Desktop – Podman Desktop Companion
#53I've been using Rancher Desktop as an alternative to Docker Desktop, https://rancherdesktop.io/ on macOS and Windows, it's pretty solid. It has some kinks to work out but I got it working with IDEs too (e.g. the Intellij IDEA Docker Compose integration to work with it). What I also like is that existing scripts and etc that use the docker-compose cli work with Rancher Desktop too, as it uses nerdctl https://github.co…
Rancher Desktop is great, because kubernetes just works. Not only that, you can "docker build" an image, and then immediately spin it up as a kubernetes pod, without spending ten minutes googling the correct commands to correctly "load" the image.
Re: Show HN: Container Desktop – Podman Desktop Companion
#54Looks cool, but how is the Kubernetes support? One of the major reasons we use Docker Desktop at work is to host a local Kubernetes cluster with services deployed there. We also support Rancher Desktop since it uses k3s, and k3s is arguably a nicer Kubernetes distribution than the one set up by Docker Desktop. With that said, I have recently tried OrbStack, and it is able to start up near instantly, while Kubernetes…
You should check out https://kind.sigs.k8s.io/ and https://k0sproject.io
What about minikube?
Re: Show HN: Container Desktop – Podman Desktop Companion
#55Personally I just build all my software so it includes its dependencies and then you don't need docker or any complex image manager. Don't rely on a bunch of crap being installed in the system path! Much much simpler this way imho.
I'm sorry but this doesn't work. Over the last 10 years so I was fucked over by countless "software that includes all its dependencies" that stopped working when I upgraded some other totally irrelevant software because "well duh it obviously uses system libC" or whatever. Examples: critical .AppImage binaries stopping working after random system upgrades. Nothing runs on my computer is ever fully isolated, not even…
> your program will stop working because that one library from 1987 has to be exactly version A.X but my text editor upgraded it to A.Y.
Perhaps you misunderstand. This issue is fully solved by including dependencies and not relying on anything in the system path. Programs should not touch the system path. If a program requires library A.Y then it should include and use A.Y. But it should not touch the system path and thus should not impact any other program. Nor will it be impacted by other programs wanting A.Z.
Re: Show HN: Container Desktop – Podman Desktop Companion
#56Earlier quoted context omitted.
You should check out https://kind.sigs.k8s.io/ and https://k0sproject.io
I'm torn between https://k0sproject.io and https://k3s.io to use in CI and production. Any suggestions or personal experience?
I'm a fan of k3s. Mostly because Rancher Desktop, but there are more useful features, like a full k3s distribution within a single docker container. It includes some nice QoL features, like pre-loading images from a mounted folder. Great for CI.
Re: Show HN: Container Desktop – Podman Desktop Companion
#57Is it ok to run the Windows version on a normal desktop (not in a VM). Does it uninstall cleanly. Thx
Re: Show HN: Container Desktop – Podman Desktop Companion
#58Personally I just build all my software so it includes its dependencies and then you don't need docker or any complex image manager. Don't rely on a bunch of crap being installed in the system path! Much much simpler this way imho.
I think that's the right way to do it from the software distributor's side, but most software distributors don't do it like you. So, from a consumer's point of view, if you want to use their software, then docker is the lesser evil compared to all the others. Notably, it's much better than binaries with dynamic libraries that don't come included in the bundle itself.
> better than binaries with dynamic libraries that don't come included in the bundle itself.
Binaries should always include the dynamic libraries they require. Docker is one way to include them. But you can also just include them the vanilla way. Works great! Very easy and reliable.
Re: Show HN: Container Desktop – Podman Desktop Companion
#59Personally I just build all my software so it includes its dependencies and then you don't need docker or any complex image manager. Don't rely on a bunch of crap being installed in the system path! Much much simpler this way imho.
Personally, I just ship every user a small Chromebook that runs my software so I can guarantee the environment is the same every time. (I get your point, but docker has made distribution way easier in a lot of ways, and you accept sole tradeoffs for that convenience)
You can have convenience and reliability with fewer tradeoffs!
Re: Show HN: Container Desktop – Podman Desktop Companion
#60Earlier quoted context omitted.
I think that's the right way to do it from the software distributor's side, but most software distributors don't do it like you. So, from a consumer's point of view, if you want to use their software, then docker is the lesser evil compared to all the others. Notably, it's much better than binaries with dynamic libraries that don't come included in the bundle itself.
As a user, I'd rather use a container then figure out how to run a binary. The onboarding process is typically so much easier, and most enterprise folks already have container infrastructure in place. For big customers, getting a Kubernetes namespace can have significantly less friction than a VM these days.
> then figure out how to run a binary
It should never be more complicated than "run the binary". Running programs shouldn't require infrastructure or VMs or Docker images. Deploying a program should be, and can be, as simple as sharing a zip file, extracting, and running.
It's not that hard!