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).
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...
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 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 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 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.
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.
I never finished it, but I had a lot of fun documenting a basic-ass K8S (well, K3S) setup that costs about 20€/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.
> 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.
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.
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.
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.
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.
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)
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.
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
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.
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.
> 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. :)
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…
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.
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.
> 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).
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?
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.
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).
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.
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.
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)
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].
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.
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.
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?
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.
"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!
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.
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.
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.
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.
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.
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. :(
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
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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).
>> 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?
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...
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.
Your false assumption is that most of its users know what is Docker and how it works.
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/
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 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.
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.
Yes, either all that above or just GUI for rare occasions.
Frontenders that need to run backends in my experience are such a cohort.
relatedly, I prefer using the github app instead of using the CLI.
I use non Linux systems for which docker desktop was the best way to have docker running without having to do much work.
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!
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.
> 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.
I never finished it, but I had a lot of fun documenting a basic-ass K8S (well, K3S) setup that costs about 20€/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.
> 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.
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.
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?
Well said. I agree completely.
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.
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.
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)
+1 for OrbStack, it’s one of the few software subscriptions I pay for, and is worth every penny. Leagues head of Docker Desktop.
I demoed Orbstack to my whole department of 100+ engineers, now we've canceled our Docker Desktop account and switched everyone over. Zero complaints.
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.
I love kind! Used it a lot when I was writing my thesis on Kubernetes schedulers.
Literally or figuratively?
Curious to see your thesis!
What about minikube?
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
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.
Been using Rancher Desktop for 2 years, can definitely recommend this as an alternative to Docker Desktop.
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.
Does it use the same "containers are really just running in a Linux VM" approach as Docker Desktop on macOS?
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.
> 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. :)
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?
“Only Linux containers exist?“
In practice, yes.
Yup +1 for Rancher Desktop. Works as smooth as Docker Desktop on MacOS.
I really like the whole Rancher ecosystem. Setting up a cluster with rancher is such a pleasant experience.
Currently it is the best alternative I have used, in what concerns the same experience as Docker Desktop on Windows.
If you’re on macOS, then Orbstack is a nice alternative to Docker Desktop
(I’m not affiliated with Orbstack)
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…
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
if i understood that page, debug shell is... "exec" with a nicer .bashprofile and injected text editor binary???
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
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.
colima is also good https://www.swyx.io/running-docker-without-docker-desktop
also no affiliation and have not tried orbstack
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.
Yeah, I use this to support extremely old C++ project on x86_64 docker images and it's tolerable if not speedy.
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.
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.
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).
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.
It's nice, but only for personal use.
Be aware that you need a license if you use it at work.
As is true with a lot of developer tooling. Including Docker Desktop itself.
Another enthusiastic +1 for OrbStack. It's fantastic.
GPU support would be a real benefit, but for anything not needing that, Orbstack's become my strong preference.
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?
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...
Oh neat! Thanks for the tip!
I would also encourage people to look at Podman desktop which has pretty good support from Red Hat.
https://podman-desktop.io/
support from red hat is not a good thing :nervouslaughteremoji
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...
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)
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).
https://docs.docker.com/reference/dockerfile/#run---mount
I may be wrong, but I think BuildKit gives Docker that functionality.
I'd bind-mount the tree into the context. (I assume Docker won't follow simple symlinks.)
what does this offer that podman desktop does not?
https://podman-desktop.io/
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 socket service as a specific user account which end up running all the pods.
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.
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.
What does podman desktop offer that WSL does not (at least for those of us on Windows)?
Ease of use, even used as a GUI for WSL, that doesn't mean it doesn't add value.
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)
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
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.
Priority tech support when everything blows up is usually the number one reason.
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.
For me, it was consuming so much memory. Switching to OrbStack helped fix that
FreeBSD jails? :p
it's not free
While I'm basically fine with Colima on Mac, this seems like a nice alternative to Docker Desktop.
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`
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.
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.
"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!
Nice!
Unfortunately I got this error upon opening the Mac app:
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.
Rancher desktop is fine. I did migration within 30 minutes.
For none gui, lazydocker is perfect
Does it support VSCode Devcontainers? That's the only reason I haven't been able to switch to an alternative.
Is this supported by DD?
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.
I saw this, I think posted here the other day, looked interesting. https://github.com/ajayd-san/gomanagedocker
A TUI alternative.
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.
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.
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.
Is it ok to run the Windows version on a normal desktop (not in a VM). Does it uninstall cleanly. Thx
Is Ubuntu 24.04 supported? (Docker Desktop doesn't support 24.04 currently)
+1 for OrbStack.
Why does Docker feel like it was designed by people with no Unix background?
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.
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!?
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.
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.
so that you can cat(1) multiple files at once, and their bookends don't get glued.
how is this different from the usual podman client ?
Orbstack
Is another crap electron app?
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.
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!
That's basically what a docker image does in a more formalized, isolated, and repeatable fashion.
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.
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. :(
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
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.
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!
> 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.
On some projects and teams, more than usually expected, this is more than fine.
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.
> 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.
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.
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.
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.
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.