[HN Gopher] Show HN: Container Desktop - Podman Desktop Companion
       ___________________________________________________________________
        
       Show HN: Container Desktop - Podman Desktop Companion
        
       Author : istoica
       Score  : 427 points
       Date   : 2024-09-20 18:08 UTC (1 days ago)
        
 (HTM) web link (container-desktop.com)
 (TXT) w3m dump (container-desktop.com)
        
       | bradleyy wrote:
       | While I'm basically fine with Colima on Mac, this seems like a
       | nice alternative to Docker Desktop.
        
         | veonik wrote:
         | After some initial pains with colima, I tend to agree. Mostly,
         | just needing to specify some VZ args[0] so I could run x86_64
         | docker images on my M-series.
         | 
         | Is there something in these desktop UIs that colima is
         | completely missing?
         | 
         | [0] `colima start --vm-type=vz --vz-rosetta`
        
           | fragmede wrote:
           | "some initial pains" = Colima VM running out of resources
           | running kind, so I had to raise the CPU and RAM, and then
           | raise the fd's in the VM itself to get it to work. but now it
           | works!
        
           | cjauvin wrote:
           | Could this be the answer I needed to run an SQL Server image
           | that refused to run on my M3 MBP? I was about to, sadly, try
           | Docker Desktop, because of that.
        
             | veonik wrote:
             | That is exactly why I needed it, too! :D
             | 
             | Be sure to increase RAM over the default 2GB as well, that
             | SQL Server container is hungry and will crash without
             | enough resources dedicated to it.
        
       | dmonitor wrote:
       | what does this offer that podman desktop does not?
       | 
       | https://podman-desktop.io/
        
         | gnulinux wrote:
         | Last I checked podman's support of docker-compose.yml was very
         | limited to say the least. Has it changed?
        
           | scheme271 wrote:
           | What parts did you find lacking? I haven't had any issues
           | using podman-compose to launch stuff using unmodified docker-
           | compose.yml files.
        
           | mfenniak wrote:
           | 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 socket service as a
           | specific user account which end up running all the pods.
        
             | 3np wrote:
             | 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.
        
           | EdwardDiego wrote:
           | Yeah, I'm using it and it's nearly everything I need.
        
         | candiddevmike wrote:
         | What does podman desktop offer that WSL does not (at least for
         | those of us on Windows)?
        
           | eterm wrote:
           | Ease of use, even used as a GUI for WSL, that doesn't mean it
           | doesn't add value.
        
       | moondowner wrote:
       | I'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.com/containerd/nerdctl
        
         | manojlds wrote:
         | Yup +1 for Rancher Desktop. Works as smooth as Docker Desktop
         | on MacOS.
        
         | SystemOut wrote:
         | We just completed the switch to Rancher where I work. 1200ish
         | engineers, mostly on Macs. So far it's worked out pretty
         | well..fewer hiccups than I expected.
        
           | justinclift wrote:
           | Does it use the same "containers are really just running in a
           | Linux VM" approach as Docker Desktop on macOS?
        
             | 1oooqooq wrote:
             | unless you run osx on a Linux kernel, it will always be so.
             | 
             | not a personal attack on you, but it blows my mind how
             | clueless the current generation of developers become after
             | the docker phase.
        
               | brianpan wrote:
               | I don't understand this comment on any level.
               | 
               | Containers will only ever be on a linux kernel or VM?
               | Never natively on ANY other OS? Only Linux containers
               | exist?
               | 
               | Developers were more clueful about containers before
               | Docker made them wildly popular?
        
               | ahoka wrote:
               | "Only Linux containers exist?"
               | 
               | In practice, yes.
        
               | maccard wrote:
               | Windows containers absolutely exist in practice.
        
               | justinclift wrote:
               | > unless you run osx on a Linux kernel, it will always be
               | so
               | 
               | Linux is not the only OS that has container like things.
               | FreeBSD had jails years earlier, Solaris had something
               | else which I don't remember any more, and for all I know
               | macOS may have their own native equivalent as well.
               | 
               | Bear in mind that Apple introduced an official hypervisor
               | framework a few releases ago, so they could be doing
               | something similar for containers. It wouldn't be a bad
               | idea. :)
        
               | fragmede wrote:
               | personal attack or not, you could have just left that
               | last bit off and had a good comment.
               | 
               | There's always been a mythos of a _true_ developer. Here
               | 's a rant from 1983 about how real programmers don't use
               | Pascal.
               | https://www.pbm.com/~lindahl/real.programmers.html
               | 
               | Kids these days...
        
         | aaqureshi wrote:
         | Been using Rancher Desktop for 2 years, can definitely
         | recommend this as an alternative to Docker Desktop.
        
         | pjmlp wrote:
         | Currently it is the best alternative I have used, in what
         | concerns the same experience as Docker Desktop on Windows.
        
         | PufPufPuf wrote:
         | 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.
        
         | cortesoft wrote:
         | I really like the whole Rancher ecosystem. Setting up a cluster
         | with rancher is such a pleasant experience.
        
       | hnlmorg wrote:
       | If you're on macOS, then Orbstack is a nice alternative to Docker
       | Desktop
       | 
       | (I'm not affiliated with Orbstack)
        
         | cweagans wrote:
         | Another enthusiastic +1 for OrbStack. It's fantastic.
        
           | throwanem wrote:
           | GPU support would be a real benefit, but for anything not
           | needing that, Orbstack's become my strong preference.
        
             | cweagans wrote:
             | Is there anything you can actually _do_ with the Apple GPUs
             | outside of macOS? I know the Asahi Linux person was working
             | on a driver for it, but is it in a useful state?
        
               | rahen wrote:
               | Yes. In fact it's accelerated and supports OpenGL 4.6
               | while macOS tops at OpenGL 4.1, and really mostly only
               | supports Metal nowadays. With Asahi you can use OpenGL
               | and Vulkan.
               | 
               | https://arstechnica.com/gadgets/2024/02/asahi-linux-
               | projects...
        
               | cweagans wrote:
               | Oh neat! Thanks for the tip!
        
         | alexandre_m wrote:
         | It's nice, but only for personal use.
         | 
         | Be aware that you need a license if you use it at work.
        
           | hnlmorg wrote:
           | As is true with a lot of developer tooling. Including Docker
           | Desktop itself.
        
         | corytheboyd wrote:
         | I would love to use it but I loathe subscriptions, especially
         | for something I'd need work to pay for. I would happily pay a
         | one-time $50-100 and get a perpetual license so I don't have to
         | deal with the headache...
        
           | shepherdjerred wrote:
           | IMO if Docker is important to you then Orbstack is worth it.
           | 
           | The debug shell feature alone makes it better than any
           | alternative, and hopefully that subscription money is put
           | towards more unique features.
           | 
           | https://docs.orbstack.dev/features/debug
        
             | 1oooqooq wrote:
             | if i understood that page, debug shell is... "exec" with a
             | nicer .bashprofile and injected text editor binary???
        
               | huimang wrote:
               | It's an alternative to
               | https://docs.docker.com/reference/cli/docker/debug/,
               | which is also a paid feature.
               | 
               | Debugging slim or distroless images is quite the pain, so
               | a tool like this is worth it if you're frequently working
               | on such images.
        
               | tanduv wrote:
               | It's installing additional packages which may not have
               | been included in your base image.
               | 
               | > Debug Shell works by injecting a debugging environment
               | using: > NixOS for a large package collection, and
               | flexibility with filesystem paths
               | 
               | https://orbstack.dev/blog/debug-shell?utm_source=relnotes
        
         | swyx wrote:
         | colima is also good https://www.swyx.io/running-docker-without-
         | docker-desktop
         | 
         | also no affiliation and have not tried orbstack
        
           | comprev wrote:
           | Colima has been great to support x86 images on Apple Silicon
           | like OracleDB 19, instead of building arm64 images.
           | 
           | The flexibility of container runtimes and host architecture
           | (via QEMU) has proven useful.
        
             | lanstin wrote:
             | Yeah, I use this to support extremely old C++ project on
             | x86_64 docker images and it's tolerable if not speedy.
        
           | istoica wrote:
           | Colima offers the best experience for docker alternative.
           | LIMA offers the equivalent of WSL, where both docker and
           | podman are supported. I like LIMA a lot as I deal with both,
           | but COLIMA rocks for simplicity. I think COLIMA + Container
           | Desktop are perfect replacement on mac for traditional Docker
           | Desktop users.
        
         | bdcravens wrote:
         | Switched to it, and paid for the license. I agree with others
         | about not wanting to get subcriptioned to death, but I feel
         | like it's worth $8/month.
         | 
         | I've also used Colima, and if Orbstack wasn't an option, I'd be
         | happy to keep using it.
        
         | renewiltord wrote:
         | Orbstack is wicked good. I love it. I compile to 4 platforms
         | with it (Ubuntu/Mac x x86_64/arm) and it's the fastest
         | emu/docker thing.
        
           | rahen wrote:
           | Of course Orbstack is fast, it uses LXD, not actual VMs. In
           | fact, Orbstack on Mac is what made me switch to LXD (Incus)
           | on Linux to replace Docker and virt-manager.
        
             | cstrahan wrote:
             | Wrong, Orbstack _does_ use VMs.
             | 
             | https://docs.orbstack.dev/architecture
             | 
             | > OrbStack uses a lightweight Linux virtual machine with a
             | shared kernel to minimize overhead and save resources,
             | similar to WSL 2 (Windows Subsystem for Linux).
        
               | rahen wrote:
               | No. It uses a VM to virtualize a Linux kernel running LXD
               | containers. Those are not virtual machines.
               | 
               | https://github.com/orbstack/orbstack/issues/461#issuecomm
               | ent...
        
               | cstrahan wrote:
               | The VM you just referred to _is_ a virtual machine,
               | that's what VM stands for.
               | 
               | I think you forgot how this thread got started:
               | 
               | > If you're on macOS, then Orbstack is a nice alternative
               | to Docker Desktop
               | 
               | We're talking about running OCI ("Docker compatible")
               | images. The page you just linked to makes it apparent
               | that you are talking about something orthogonal:
               | OrbStack's "machines" feature
               | (https://docs.orbstack.dev/machines/).
               | 
               | The original topic is that OrbStack's support for Docker
               | containers is fast (implied: faster than Docker for
               | Desktop), which cannot be explained by the lack of a VM,
               | as both use a Linux VM to run one or more Docker
               | containers.
        
       | samz wrote:
       | Rancher desktop is fine. I did migration within 30 minutes.
        
       | koito17 wrote:
       | Looks 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 spends at most 2
       | seconds to start up. The UI is minimal, but it offers just enough
       | to inspect containers, pods, services, logs, etc. It also is very
       | lightweight on memory usage and battery. I personally cannot
       | return to either Docker or Rancher Desktop after having tried
       | OrbStack.
       | 
       | OrbStack also allows using Kubernetes service domains directly on
       | the host. So no need to use kubectl port-forward, and
       | applications running on the host can use identical configuration
       | to what's inside the Kubernetes cluster.
       | 
       | The battery savings, dynamic memory usage, fast startup time, and
       | QOL of OrbStack is pretty much my standard for a Docker Desktop
       | alternative. I am not sure if container-desktop satisfies all of
       | these requirements. (Rancher Desktop certainly doesn't)
        
         | linkdd wrote:
         | You should check out https://kind.sigs.k8s.io/ and
         | https://k0sproject.io
        
           | leonheld wrote:
           | I love kind! Used it a lot when I was writing my thesis on
           | Kubernetes schedulers.
        
             | arjvik wrote:
             | Curious to see your thesis!
        
             | yard2010 wrote:
             | Literally or figuratively?
        
           | hu3 wrote:
           | I'm torn between https://k0sproject.io and https://k3s.io to
           | use in CI and production.
           | 
           | Any suggestions or personal experience?
        
             | PufPufPuf wrote:
             | 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.
        
             | linkdd wrote:
             | k0s is especially easy to deploy thanks to k0sctl, whether
             | it's single node clusters, or multi node clusters. I
             | haven't looked back ever since I started using it.
        
           | adhamsalama wrote:
           | What about minikube?
        
             | linkdd wrote:
             | Minikube is more for dev environments than prod. So k0s
             | over it anytime. For dev envs, I adopted KinD, I can even
             | run it in CI for tests.
        
         | JosephRedfern wrote:
         | +1 for OrbStack, it's one of the few software subscriptions I
         | pay for, and is worth every penny. Leagues head of Docker
         | Desktop.
        
         | nicwolff wrote:
         | I demoed Orbstack to my whole department of 100+ engineers, now
         | we've canceled our Docker Desktop account and switched everyone
         | over. Zero complaints.
        
       | forrestthewoods wrote:
       | Personally 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.
        
         | diego_sandoval wrote:
         | 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.
        
           | candiddevmike wrote:
           | 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.
        
             | forrestthewoods wrote:
             | > 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!
        
           | forrestthewoods wrote:
           | > 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.
        
         | borski wrote:
         | 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)
        
           | forrestthewoods wrote:
           | You can have convenience and reliability with fewer
           | tradeoffs!
        
         | gnulinux wrote:
         | 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 Docker. So, any
         | isolation guarantee I get is guarantee I'll take. You claim
         | today that your software is isolated, but I don't know if 3
         | years down the road I'll upgrade my freaking text editor and
         | 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. Thanks but no thanks.
        
           | forrestthewoods wrote:
           | > 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.
        
             | mook wrote:
             | It's often literally not possible to ship everything. You
             | wouldn't want to spin up a second X11 (or Wayland) server,
             | for example, because you can't have two of them talk to the
             | same video card device at the same time usefully.
        
               | forrestthewoods wrote:
               | The number of things that can't be shipped is extremely
               | small. And I don't think that Docker is a silver bullet
               | for Wayland vs X11 issues? Although I'm not sure about
               | the fine details as I don't have a ton of experience
               | there. Shouldn't you be using an abstraction that can
               | automatically support which ever is available?
               | 
               | I tend to ship code that needs to run on Linux + macOS +
               | Windows + Android. So Docker is a total non-option. And
               | it's totally fine! Very easy in fact.
        
               | mook wrote:
               | It's the same thing everywhere -- there are some
               | dependencies you can't ship. On Linux, you can't ship the
               | window server (because you need to share it with all of
               | the other apps also running). On mac, you can't ship Core
               | Foundation. On Windows, kernel32.dll etc. I assume
               | Android is similar -- I haven't tried figuring out what a
               | purely static app on Android would be, since I think the
               | bootstrap is Dalvik...
               | 
               | It's literally impossible to _not_ depend on the system
               | path.
        
               | forrestthewoods wrote:
               | Let me rephrase. If a dependency can be bundled then it
               | should be bundled.
               | 
               | The "Linux Way" is to depend on a bunch of random garbage
               | pooped by lord knows bullshit script into one of several
               | global search paths. This is bad, stupid, and wrong.
               | Programs should include as many of their dependencies as
               | is possible.
               | 
               | The number of dependencies that a program can not deploy
               | and must assume are provided by the system are extremely
               | minimal and special case. It's a short and static list.
               | 
               | In general no script or program should add libraries into
               | the global search paths. On Windows user programs do not
               | add random crap to System32. On Linux the existence of
               | /usr/lib is an abomination that should not exist.
               | 
               | Is that better? I'm fairly certain you understand what
               | I'm trying to say.
        
               | skydhash wrote:
               | I know that the Linux way is not perfect, but I don't
               | know how companies can't do better than the distro
               | maintainers. Most repositories packages are driven by
               | some kind of build scripts. I don't expect it would be
               | that hard of a job to create one for your software for
               | the most popular ones. Anyone using obscure distros are
               | familiar enough with Linux to do container or chroot
               | environments. I like the fact that my environment is a
               | complete one, not siloes where the developer is more than
               | happy to let the software lingers. At least macOS force
               | developers to upgrade, Microsoft's backward
               | compatibility's promise is keeping so much crust around
               | in the system.
        
         | dpkirchner wrote:
         | That's basically what a docker image does in a more formalized,
         | isolated, and repeatable fashion.
        
           | mtndew4brkfst wrote:
           | In most scenarios it is definitely good-enough but even in
           | just my own personal experiences over a decade I need to
           | asterisk all three of your listed benefits.
        
           | forrestthewoods wrote:
           | True. But Docker comes with a lot of complexity. And it comes
           | with a meaningful performance hit on macOS and Windows. And
           | it doesn't work at all on Android/iOS.
           | 
           | It's so sad that running software on Linux is so wildly
           | complicated and unreliable than things like Docker had to be
           | invented. :(
        
             | madiele wrote:
             | For most uses wsl2 on windows is pretty close to a bare
             | metal instalation
             | 
             | https://www.phoronix.com/review/windows11-wsl2-zen4
             | 
             | wsl2 runs under the windows hypervisor as a vm, but so does
             | windows since windows 11. So there should not be much
             | performance issues from running stuff in windows vs wsl2.
             | The major bottleneck is if you need to move files from and
             | to the windows vm to the Linux vm
        
               | forrestthewoods wrote:
               | My interest in running Linux binaries on Windows is zero.
               | I run native windows binaries. Why would I want to run
               | via WSL2 when I can do it natively?
               | 
               | Why people constantly insist on adding unnecessary layers
               | of abstraction is beyond me.
        
               | madiele wrote:
               | Nobody is forcing you to use anything I just wanted to
               | underline that the performance hit you mentioned is not
               | really there, as we are in a public forum there is value
               | to keep things factual.
               | 
               | As for why to do it, if you develop on server apps Linux
               | is the standard (as an example redis does not have a
               | windows native version), and I say this as a developer of
               | Windows based microsevices on the cloud, my company is
               | actively looking to migrate to Linux due to lack of
               | tooling in the windows space (and also licence cost of
               | windows server), like it or not that is the way it goes.
               | If you don't need it great for you, but for other of us
               | those layers are life saver
        
         | hu3 wrote:
         | On some projects and teams, more than usually expected, this is
         | more than fine.
        
       | achristmascarl wrote:
       | I've really enjoyed using Orbstack: https://orbstack.dev/
       | 
       | it also has support for Linux VMs and kubernetes (although i
       | haven't tried that yet)
        
       | Apreche wrote:
       | Does it support VSCode Devcontainers? That's the only reason I
       | haven't been able to switch to an alternative.
        
         | gbraad wrote:
         | Is this supported by DD?
        
       | saghul wrote:
       | I'm currently using colima, and none of the other alternatives
       | that I have found support forwarding UDP ports, which I use a
       | lot, so that's a bummer!
       | 
       | Thankfully, lima has landed a new port forwarder with UDP
       | support! [0]. I'm hoping to be able to use it soon once it makes
       | into a release.
       | 
       | [0]: https://github.com/lima-
       | vm/lima/commit/13e9cbcabc6a0a05ec389...
        
       | ekzy wrote:
       | Honest question, what's wrong with docker desktop? Looking at all
       | the alternatives suggested it's not clear to me why any other
       | tools are better? I'm not using k8s locally, just docker compose.
       | To connect to our remote k8s cluster, I use IntelliJ k8s
       | extension (I just need to do some basic dev tasks, I'm not
       | administrating the cluster)
        
         | alx__ wrote:
         | For me, it was consuming so much memory. Switching to OrbStack
         | helped fix that
        
           | bboygravity wrote:
           | FreeBSD jails? :p
        
         | maxyurk wrote:
         | it's not free
        
         | Andoryuuta wrote:
         | One big difference is the licensing. Docker Engine itself is
         | apache licensed (and hence free to use at a company of any
         | scale), but Docker Desktop requires a paid plan if your company
         | has more than 250 employees or more than $10 million in annual
         | revenue [0].
         | 
         | [0]: https://docs.docker.com/engine/#licensing
        
           | fragmede wrote:
           | Which like, seems entirely fair, but when there are suitable
           | enough replacements that cost $0, why pay for it? Sure there
           | are big picture reasons, but companies often don't think that
           | long-term.
        
             | otteromkram wrote:
             | Priority tech support when everything blows up is usually
             | the number one reason.
        
               | dewey wrote:
               | I have a hard time thinking of cases where you need
               | support or priority support for developer tooling like
               | Docker. It's not like Docker Desktop is running in
               | production.
        
               | chuckadams wrote:
               | "The update failed on 200 desktops."
               | 
               | "Performance is crap when running BlahBlah Management
               | Suite."
               | 
               | And so on. You don't necessarily call support when one
               | dev has an issue, you call when they all do.
        
         | Delk wrote:
         | Docker Desktop requires a paid licence for companies with over
         | 250 employees. While that's totally fair, it can add red tape
         | if you want to use it in a project.
         | 
         | I'm not completely sure about licensing for Container Desktop
         | but the footer suggests MIT license.
        
       | istoica wrote:
       | Kubernetes is planned - my devops wants me to add it badly!
       | 
       | Author note - Most of you guys here are power users, for whom UI
       | is a visual poem that you need or not. This is not a commercial
       | project, it is not following any business goals. But this does
       | not mean concessions to quality, it does try to offer minimal
       | resource usage everywhere, easy experience, good UI/UX.
       | 
       | It explains all it does behind the scenes if you enable the
       | developer console. It can help one learn so at a certain moment
       | one understands and automates with scripts and specs.
       | 
       | But everyone these days is either seen as too smart or too dumb,
       | I don't consider users like this. I know everyone started
       | somewhere and a gradual learning experience is the best.
       | 
       | I broke so many radios and toys when I was a kid and I learned so
       | much, by looking at what was is inside.
       | 
       | It is a project done by one dude, after work and when it rains
       | outside (In Belgium it rains a lot).
        
         | beepbooptheory wrote:
         | > But everyone these days is either seen as too smart or too
         | dumb
         | 
         | Vert succinct and poetic way to describe so much these days in
         | this space.
        
         | ljm wrote:
         | I never finished it, but I had a lot of fun documenting a
         | basic-ass K8S (well, K3S) setup that costs about 20EUR/mo on
         | Hetzner.
         | 
         | You don't really learn about sysadmin through it, or even about
         | docker that much, but you get an idea of how you might easily
         | run a few different things on a server while only needing to
         | know YAML, and not some custom DSL like chef or puppet.
        
           | thwarted wrote:
           | > _only needing to know YAML, and not some custom DSL like
           | chef or puppet._
           | 
           | YAML may be a known syntax, but the use of it still requires
           | domain specific knowledge, and is still a domain specific
           | language expressing those domain specific concepts, as to
           | what the expected keys and values are allowed to be and how
           | they are interpreted.
        
             | ljm wrote:
             | YAML isn't the DSL, it's just the language used to express
             | declarative config because the tooling is ubiquitous and
             | it's rare that anyone uses it as anything more than a nicer
             | version of JSON.
             | 
             | For Kubernetes, it's CRDs that are written in YAML and they
             | conform to a specification.
        
           | ericbarrett wrote:
           | I did something similar between jobs--built a k8s "cluster"
           | on my home Linux box using kops+qemu. It didn't make me an
           | experienced admin, but it was really enlightening and fun!
           | Projects like these are a great way to learn.
        
           | gavindean90 wrote:
           | Ansible?
        
         | knowitnone wrote:
         | Sorry for being pandentic but you don't learn much by looking
         | at the inside of a radio because it's mostly electronic
         | components except for the knobs, antenna, dial. Without
         | understanding how the the electronics work, you're just looking
         | at parts. Mechanical parts like a bicycle, much easier to
         | reason. Not knowing your background, can you build a radio if
         | giving a box of parts? I certainly can't.
        
           | diggan wrote:
           | Maybe he's talking about a crystal radio? Those are
           | relatively trivial to put together.
        
           | salmo wrote:
           | I don't think you're being pedantic. You're just making a
           | weird assumption that the radio itself is the only resource.
           | I learned a ton from this as a kid. And I learned from Radio
           | Shack. You stare at it, you go research, you try to fix it,
           | you fail. Talk to someone who knows stuff. Repeat until it
           | works or you work on a new one.
           | 
           | It's really no different than how I taught myself to fix a
           | chain or replace a spoke. Or know to use WD-40 to clean, but
           | then apply an oil to keep stuff lubricated and protected.
           | 
           | With the internet, it's a lot easier. I can look up spec
           | sheets just googling component markings and see the sample
           | circuits.
           | 
           | I've stared at the Linux kernel a ton. I messed with some
           | stuff. I couldn't write a kernel myself, but I program better
           | from doing it and I can troubleshoot things easier knowing
           | the components and topology.
           | 
           | Off the top of my head, I can fumble around and make a crappy
           | amplifier from parts in my closet, or write a crappy FAT-like
           | file system. I'd probably struggle a bit with a nice new
           | bike. I think gear shifters and stuff are a lot fancier than
           | an old 10 speed.
        
         | AlienRobot wrote:
         | Well said. I agree completely.
        
         | sverhagen wrote:
         | I don't live my life entirely on the command line either, but
         | GUIs for Docker are just an interesting niche to me, for which
         | I just don't understand what the ven diagram is between people
         | that want Docker containers running locally, know that that's
         | what they want, and know how it all works, but then don't want
         | to do the small handful of commands at the prompt needed to get
         | it running...
        
           | brailsafe wrote:
           | I don't necessarily _want_ docker containers running locally
           | as some hobbyist, they might be just part of the process, and
           | if the gui helps me move through that process efficiently
           | without having to add more commands to my memory, I 'm happy
           | about that. CLIs are great, but when nearly everything has
           | one, those small amount of commands become quite a lot in
           | aggregate.
        
             | bubaumba wrote:
             | there are ways to minimize memorization, most important:
             | 
             | 1. keep log, docs, records of whatever you are doing. most
             | commands are repetitive.
             | 
             | 2. copilot or chatgpt, they help a lot with command lines
             | and simple utilities
             | 
             | 3. amazon Q sucks in comparison.
             | 
             | 4. it used to be google, but now LLMs do it better. less
             | scrolling and ads/spam.
        
               | ihateolives wrote:
               | Yes, either all that above or just GUI for rare
               | occasions.
        
               | bubaumba wrote:
               | yes, when it's possible. but guis may not exist or may be
               | not better than console, like in case of ffmpeg. the
               | best, of course, is smart assistant who can take verbal
               | commands. either human or llm.
               | 
               | but my post was about doing complex tasks in general. try
               | to offload. another advise for developers is to write
               | comments, even in your small hobby projects. this way you
               | don't have to memorize it all. this was learned hard way.
               | i usually also have a separate documentation with plans,
               | ideas, algorithms, useful info. remind: this is for hobby
               | projects.
               | 
               | and important thing: touch typing is must have. this
               | makes it all much easier
        
               | phantomathkg wrote:
               | Life is full of many things to do and so not everyone
               | have the luxury to priorities logging ones life for
               | everything they do. 2 or GUI are very feasible option for
               | busy people.
        
               | herval wrote:
               | you don't have to "prioritize logging" to have logs,
               | calling this a "luxury" is quite bizarre. You can simply
               | use tools that do bash history search, or one of the many
               | copy-paste memorizer tools, and you'll save many hours
               | out of those "many things to do" simply by typing ctrl+s.
               | Some people are busy simply because they want to.
        
           | scosman wrote:
           | I would have assumed the same, but Docker makes ~100m ARR on
           | docker desktop so it's def not niche.
           | 
           | https://sacra.com/research/docker-plg-pivot/
        
             | DavyJone wrote:
             | Docker Desktop includes the easy to run Docker Engine /
             | Docker Machine. I think is fair to assume that most of the
             | revenue is not from users that want a GUI but from users
             | that want a stable Docker Engine experience.
        
               | ilbeeper wrote:
               | Anecdotal, but my experience, as someone who gives DevOps
               | professional services for many organizations, is that
               | windows users that need containers know that they are
               | called Docker and just download that. Must of them
               | absolutely need GUI. Most of them doesn't know that
               | Docker Desktop requires license, and I convert them to
               | Rancher Desktop.
        
               | robertlagrant wrote:
               | Nothing wrong with paying for good software.
        
               | chii wrote:
               | just because it costs money, doesn't mean it's good
               | software.
        
               | robertlagrant wrote:
               | That seems like a non sequitur.
        
             | maccard wrote:
             | How do I install and run docker containers on windows
             | without docker desktop? I've made attempts in the past but
             | never actually succeeded, and just enddd up using docker
             | desktop.
        
               | fithisux wrote:
               | Step 1. Uninstall docker Desktop completely (and images
               | and builds and storage and containers) and reboot. Step
               | 2. Install Rancher Desktop.
               | 
               | If you also need docker emulation with podman too
               | 
               | Step 3. Install Podman Step 4. Install Podman Desktop.
               | 
               | Now a. Either work with Rancher Desktop (open it) and
               | Docker is available also in cmd line (docker, docker
               | ccompose , etc) b. Or Start Podman Desktop to configure
               | Podman (or just use comandline to configure)
               | 
               | Now in cmd you not only have docker and friends but also
               | podman and friends
               | 
               | Bonus, you have Kubernetes tools too and you are FOSS.
               | 
               | Happy composing :-)
               | 
               | PS: I think you cannot start both. I have both installed
               | and never looked back. Windows 10 x64 PRO
        
           | quest88 wrote:
           | relatedly, I prefer using the github app instead of using the
           | CLI.
        
           | tomjen3 wrote:
           | I use non Linux systems for which docker desktop was the best
           | way to have docker running without having to do much work.
        
           | vasco wrote:
           | Frontenders that need to run backends in my experience are
           | such a cohort.
        
           | alexchamberlain wrote:
           | I use Docker Desktop on both my macbooks, despite shunning
           | IDEs in favour of a decent text editor and the command line.
           | I use it for 2 reasons: to manage the Linux VM, and to
           | twiddle the occasional setting. For running the containers
           | themselves, or running `system prune` when everything gets
           | cluttered up, I use the CLI.
        
             | maccard wrote:
             | Orbstack is absolutely worth the money on MacOS, fwiw
        
           | osigurdson wrote:
           | I agree on the docker / podman, but for Kubernetes, Lens is
           | is really useful. It isn't a substitute for knowing the
           | command line but can be much quicker.
        
           | ahoka wrote:
           | Your false assumption is that most of its users know what is
           | Docker and how it works.
        
           | lofaszvanitt wrote:
           | The problem is, I forget the commands all the time, because I
           | use them on rare occasions. It gets the how this shit worked
           | moment off your shoulder.
        
           | maccard wrote:
           | GUIs excel at exploring. Exploring is a very very large part
           | of what I do when running containers locally.
        
         | mihaitodor wrote:
         | I don't get why people need Kubernetes integrations. Kind works
         | just fine. You run it from the terminal and it starts a
         | "cluster" as one or more containers. You can define port
         | bindings and volume mounts via the yaml config. Job done.
         | 
         | Also, nice work on Container Desktop!
        
           | dboreham wrote:
           | Poorly documented is one possibility. Also if you find an
           | issue with anything that's not "testing k8s" the devs will
           | tell you you're not supposed to use it for that.
        
         | osigurdson wrote:
         | >> Kubernetes is planned - my devops wants me to add it badly!
         | 
         | Do you mean the Podman "Kubernetes like" functionality (e.g.
         | podman play kube..) or Kubernetes itself?
        
         | tacone wrote:
         | > It explains all it does behind the scenes if you enable the
         | developer console. It can help one learn so at a certain moment
         | one understands and automates with scripts and specs.
         | 
         | An excellent way to learn indeed! Good luck with your project.
        
       | 2OEH8eoCRo0 wrote:
       | Why does Docker feel like it was designed by people with no Unix
       | background?
        
         | bityard wrote:
         | I don't know if your comment was intended to imply that Docker
         | was against the Unix philosophy in some way (a debatable point,
         | but not really one I share), or if you mean that the tools
         | don't follow a lot of common Unix convension.
         | 
         | When Docker was only a few years old, I did keep running into
         | lots of small things which implied that the people developing
         | docker in fact did NOT have a Unix (or even Linux) background.
         | Things like source code files having the wrong type of newlines
         | (or a mix of types), and forgetting to add a newline to the
         | last line in a file. (A correct Unix text file has a newline at
         | the end of _every_ line, even the last one.) There were of
         | course more giveaways than this, I just remember the newline
         | stuff irritating me the most.
        
           | jve wrote:
           | Why is newline at the end relevant?
           | 
           | I remember not having a newline breaks some tools... but why?
           | It can't be because of unix philosophy!?
        
             | mook wrote:
             | Some old tools had bugs where they'd read a line (up to the
             | new line) and then process it, so if the last line didn't
             | end with a new line they'd never do the processing. So a
             | manual workaround for bugs became the convention.
        
               | paulv wrote:
               | Back in ~2002 this was the case with cron. Found out the
               | hard way when all the backup tapes we desperately needed
               | were completely empty.
        
             | SSLy wrote:
             | so that you can cat(1) multiple files at once, and their
             | bookends don't get glued.
        
       | ape4 wrote:
       | Is it ok to run the Windows version on a normal desktop (not in a
       | VM). Does it uninstall cleanly. Thx
        
       | leoqa wrote:
       | Orthogonal rant: Podman allows host mounts during image build,
       | whereas docker does not. Ran into a big headache where a monorepo
       | using podman leveraged this to create container images from
       | source and the equivalent docker implementation had to copy the
       | monorepo into the docker build context every time.
       | 
       | We needed to use Docker for M1 support (probably should've tried
       | Colima, etc).
        
         | jmholla wrote:
         | I may be wrong, but I think BuildKit gives Docker that
         | functionality.
        
         | nine_k wrote:
         | I'd bind-mount the tree into the context. (I assume Docker
         | won't follow simple symlinks.)
        
         | taspeotis wrote:
         | https://docs.docker.com/reference/dockerfile/#run---mount
        
       | ademup wrote:
       | Is Ubuntu 24.04 supported? (Docker Desktop doesn't support 24.04
       | currently)
        
       | wg0 wrote:
       | colima + docker CLI goes a long way.
       | 
       | $ colima start
       | 
       | $ docker context use colima
       | 
       | And that's it.
       | 
       | And Kubernestes? No thank you, life is already hard as is.
        
         | dewey wrote:
         | Every time I tried Colima it stopped working after a few days.
         | Not just for me either. Back to Docker Desktop which never gave
         | me a single issue in many years.
        
       | delduca wrote:
       | +1 for OrbStack.
        
       | delduca wrote:
       | Is another crap electron app?
        
       | jpace121 wrote:
       | I would also encourage people to look at Podman desktop which has
       | pretty good support from Red Hat.
       | 
       | https://podman-desktop.io/
        
         | 1oooqooq wrote:
         | support from red hat is not a good thing :nervouslaughteremoji
        
       | dzonga wrote:
       | how is this different from the usual podman client ?
        
       | jlos wrote:
       | My team switched our medium sized org over to Rancher Desktop
       | with no major issues after about 10 months. We don't need
       | kubernetes though.
        
       | hi-v-rocknroll wrote:
       | It's not fully baked. _Sigh_
       | 
       | - Buggy as heck with bad error messages.
       | 
       | - Bad UX with inadequate help.
       | 
       | - Requires extra tweaking and installing more stuff to get going,
       | which defeats its entire purpose.
       | 
       | - Confusing.
       | 
       | - Can't browse or choose tags of images.
       | 
       | It's not a viable alternative yet, but maybe it will improve
       | sometime in the future.
        
         | knowitnone wrote:
         | not affiliated with the project but thanks for the feedback!
         | Now they have some more items in their TODO list which will
         | make their product better.
        
       | rednafi wrote:
       | Orbstack
        
       | nerdponx wrote:
       | Nice!
       | 
       | Unfortunately I got this error upon opening the Mac app:
       | Uncaught Exception:       TypeError: Cannot read properties of
       | null (reading 'setImage')       at NativeTheme.<anonymous>
       | (file:///Applications/Container%20Desktop.app/
       | Contents/Resources/app.asar/build/main-5.2.3.mjs:22:537771)
       | at NativeTheme.emit (node:events:519:28)
       | 
       | Nothing seems to be wrong, but that was surprising.
       | 
       | Also, it's not obvious from the site that Container Desktop does
       | _bundle_ Podman along wit it, unlike Docker Desktop. The analogy
       | with the latter and the subtitle  "Podman Desktop Companion" on
       | the site made me think it might include a bundled Podman
       | installation.
       | 
       | That said I do like the idea, and I'm definitely looking forward
       | to trying it. For context, I'm not a Kubernetes user, mostly just
       | Compose and plain `docker run` for ad-hoc things.
        
       | TechSquidTV wrote:
       | I saw this, I think posted here the other day, looked
       | interesting. https://github.com/ajayd-san/gomanagedocker
       | 
       | A TUI alternative.
        
       | v3ss0n wrote:
       | For none gui, lazydocker is perfect
        
       | snapplebobapple wrote:
       | Tangentially unrelated side queation: how do you make nfs mounts
       | work in podman without running it as root and making running
       | podman over docker kind of pointless or what do you use to share
       | a base fileayatem from somewhere else on the network to a docker
       | container that isnt nfs or samba?
        
         | lozf wrote:
         | Maybe these blog posts12 from Red Hat will help. I haven't
         | tried yet, just found these earlier.
         | 
         | 1: https://www.redhat.com/sysadmin/rootless-podman-nfs
         | 
         | 2: https://www.redhat.com/sysadmin/nfs-rootless-podman
        
           | snapplebobapple wrote:
           | I dont think thats quite it. I have nfs mounts defined in my
           | compose files. I.e in the container /media is an volume
           | docker creates from an nfs mount defined in the docker
           | compose. That dodnt work withpout podman having root last i
           | checked a few years ago
        
       ___________________________________________________________________
       (page generated 2024-09-21 23:01 UTC)