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.

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/

> 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

Consider the case of a team of people collaborating on a software stack - the prototypical use case includes Docker Compose at the simplest and a full K8s stack at the extreme. There is quite often a minimum of 3 containers here; frontend, API/Backend and a database server. If you start to add observability tools, async/batch/event execution, caching, automated integration testing, etc, the number of "layers" in the stack grows quickly. In addition, each component may have unique per-environment or even per-user customizations.

Often one ore two people will manage the stack itself and provide instructions on how to get the whole thing working for others using a specific defined selection of easy to use tools that essentially offer minimal prerequisite knowledge to use

"Install X, run Y, get to work."

It saves a lot of time for the intern on the UI team who just wants to add a component to one page and test it locally and not also have to learn how to deploy the entire stack from scratch.

Frontenders that need to run backends in my experience are such a cohort.

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.

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.

I use non Linux systems for which docker desktop was the best way to have docker running without having to do much work.

GUIs excel at exploring. Exploring is a very very large part of what I do when running containers locally.

Your false assumption is that most of its users know what is Docker and how it works.

relatedly, I prefer using the github app instead of using the CLI.

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.

[dead]

Incus looks promising, see here https://linuxcontainers.org/incus

As for systemd, podman is amazing https://docs.redhat.com/en/documentation/red_hat_enterprise_...

> 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.

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.

Ansible?

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.

Like everything in tech, it's all about tradeoffs and understanding how you want to scale your business. Of the three startups I've been at, 2 of them adopted k8s early on and 1 of which didn't. Of the two that adopted k8s, one I would say k8s was our key differentiator in terms of our GTM motion and how our platform powered the business. $MM customer needs a setup running as close to their current infra's region for just about any reason, yeah sure we can spin that up in a week. This was often the key bit that allowed us to take customers from our key competitors before the competitor even knew we were in play. The 2nd one..... giant waste of money that gave me a decent pay check.

The third startup that opted _not_ to adopt k8s is stuck at $100M in revenue and can't land customers fast enough to offset churn. This is entirely because the COO has held the mentality "k8s bad, amirite?" and stuck with a patchwork of ansible scripts to manage configuring VM farms that ran our stack. Years of tech debt piled up and every new $MM customer coming in that needs to run in a specific region for $reasons, takes 6 months to setup and cost so much that we'd lose money on the deal. I genuinely believe this startup would be closer to $500M in revenue in the years since I've left had they invested in migrating from containers running in VM's to k8s. But instead they had to lay off 30% of their staff and get another round of funding, and are stagnating.

Your basically-absolutist stance is about as unenlightened as the one that you’re arguing against.

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.

Maybe he's talking about a crystal radio? Those are relatively trivial to put together.

I'm torn between https://k0sproject.io and https://k3s.io to use in CI and production.

Any suggestions or personal experience?

I love kind! Used it a lot when I was writing my thesis on Kubernetes schedulers.

What about minikube?

Does it use the same "containers are really just running in a Linux VM" approach as Docker Desktop on macOS?

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

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.

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.

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.

As is true with a lot of developer tooling. Including Docker Desktop itself.

GPU support would be a real benefit, but for anything not needing that, Orbstack's become my strong preference.

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.

What parts did you find lacking? I haven't had any issues using podman-compose to launch stuff using unmodified docker-compose.yml files.

Yeah, I'm using it and it's nearly everything I need.

Ease of use, even used as a GUI for WSL, that doesn't mean it doesn't add value.

"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!

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.

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.

FreeBSD jails? :p

I understand that packaging cross platform apps is hard. Just note that I was talking about the MacOS package, not Flatpak.

Yes. It is the most supported option.

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

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!?

You can have convenience and reliability with fewer tradeoffs!

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. :(

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.

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.

> 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.

> 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.