Using Docker Desktop to compile Envoy using the standard Docker build process took somewhere in the ball park of 3 to 4 hours depending on my luck. OrbStack, on the other hand, brought it down to a bit under an hour, much closer to inline with a fresh compilation natively. Needless to say, the kinds of performance benefits I was seeing with OrbStack were game changers, and absolutely justify the cost.

Even if Docker Desktop improves to match the performance, OrbStack brings basically the whole WSL2 + Docker experience to macOS, while Docker just brings the usual Docker experience. If you get the value of WSL2 on Windows, you'll probably understand the value of OrbStack on macOS.

Sure, macOS is a UNIX environment, so a lot of the same software as Linux does run natively. However, a lot of Linux technologies don't really map to Darwin, so if you're working on Linux stuff on your macOS machine, there are plenty of use cases for virtual machines (case in point, Docker itself) not to mention simply being able to test software and build processes on Linux. The tight integration that OrbStack gives you is far better than just using Parallels or VMware. I have licenses for both at varying versions, but they're largely collecting dust on macOS, as now I basically only ever use traditional virtual machine products on macOS for the purpose of running Windows VMs.

I'm sure some people don't have any use for this: their Docker performance is fine, they don't need Linux for anything else, etc. However, for me, it's one of those things that makes macOS much more usable for development work.

I have also moved towards using devcontainers for my projects whenever I can, so that I can spin up my environment on whatever machine I have, or connect to a remote one if the machine doesn't allow it.

And I've also found WSL2 less smooth than just working on Mac natively w/o containers. Containers are a necessary evil for testing certain types of things locally, but even the free tools for working with them on Mac seem fine, though Orbstack's gui is very nice.

(Is there a similar GUI for Linux container management? I've just been running shell commands for years now...)

Instead of moving more towards containers I've just been moving towards simpler, easier-to-set-up-on-Linux-or-Mac toolchains. But I don't have Windows as a target anyway, so that removes one huge need for containers.

My preferred UI for managing containers is Lazydocker. It's a terminal UI, so I can run it on servers too.

For the most part I just use the command line on Linux, but when I need to go through a large list of containers, images, or volumes to clean up, lazydocker is much better than the command line.

Yes, I am generally not terribly impressed by colima. Of course, it's great to have as an option, but in practice I ran into issues trying to use it in various places. One issue that I am sure isn't a huge deal to most users is that as far as I could tell, colima did not support IPv6.

I didn't try multipass, but I did try Podman Desktop. It had its niceities but largely was behind even Docker Desktop.

If you really miss WSL2 on macOS, you might genuinely find OrbStack enticing. Then again, it's not free, and obviously, I don't want to give anyone false hope. For "home" use, I just run desktop Linux, using native containers and libvirt for everything. If I had to pay for a decent development experience on my personal machines, I would definitely struggle to justify a subscription charge even if it was good. On the flip side, it's easy to budget OrbStack into the equation for professional use. For your employer it's virtually a no-brainer.

Even the BSDs and Solaris/Illumos have add to add Linux translation layers.

Sad state where POSIX hardly matters for portable UNIX code.

I used Linux workstations for most of my entire career, at nearly every job. Seems like around 2018 something changed and now I'm going to have to fight to get a desktop that I feel vaguely productive under for every single job I get going forward.

As far as not really needing it, it's not like computers themselves are anywhere near the bottom of Maslow's pyramid, but that doesn't make them any less useful

The fact that containers can reliably depend on the ABI contract, thus placing almost any clib they wish they want inside the container is fairly unique.

That extreme stability of that contract is awesome for namespace decoupling. Unfortunately Apple and Microsoft do not have such stable interfaces.

Remember containers are just namespaces.

Given the current state of POSIX applications, I would actually argue that the BSD/Linux hegemony we enjoy is the best possible outcome. The only people that are mad are the people paying for UNIX and expecting to get something better for it. Those people should have learned their lesson in the 90s, I have no empathy for POSIX apologists in 2024.

The only "sad state" is one where everyday people don't have access to free software. Mac users have always paid a time premium and a performance premium for access to normal development features, this ignorance of MacOS is a pattern that persists since the 90s. Of course nobody is bending over backwards to test portability with a proprietary OS.

As long as you use VS Code. Using another editor through the network share isnt great and runs into all sorts of other compatibility issues otherwise. I've also ran into a bunch of networking quirks with WSL2 + Docker that were frustrating to sort out.

WSL2 makes *nix development on Windows great, but I would still much prefer to just be in a native environment.

I admit my greatest confusion about this software is how a product that appears to be a one-man show so quickly became more compelling than the well-funded incumbent (Docker Desktop). This is even more impressive considering that the developer appears to be a college student.

Hats off, this is amazing work.

That being said, it wasn't always been smooth sailing. Under the hood, OrbStack uses an 8TB sparse disk image, which doesn't play nice with most backup software.

https://github.com/orbstack/orbstack/issues/29

It caused me problems with Backblaze, but the Github issues for this show that it also breaks all sorts of backup software, including tarsnap, Druva inSync, Carbon Cloner, iDrive, Carbonite, and even Time Machine itself when formatted with HFS+, apparently.

The official position for a year was "won't fix", because it's an Apple technology, and backup software should support that. While technically correct, realistically, sparse image backup support was not very widespread at the time. (I have no idea about now, since I gave up trying to back up my Orbstack image with my whole disk backup.)

I like Orbstack, but I wish the devs had moved to exclude the disk image from backups immediately, instead of arguing with people about it for a year first.

All that being said, I do still like OrbStack a lot, and I hope to never see a repeat of this problem and how it was handled.

Telling people to exclude the file from backup came too late for many. E.g., Time Machine users with older disks formatted with HFS+ would find their drives crashed/corrupted/wiped, and lost all their backups. Only afterwards would they start googling to see what happened. (Even now, the relevant FAQ still says "Time Machine supports them, so your backups will not be affected" which is not always correct.)

From the time the issue was opened, to the time they said they admitted they were wrong and excluded the Orbstack image from backups by default, was 13 months. Even if other solutions were on the table, the professional thing to do would have been to exclude the images ASAP, so customers weren't at risk of data loss, and then work on alternatives afterwards.

I develop a cloud native system entirely writen in Rust. All my own containers are build without Docker thanks to rules oci in Bazel. However, for integration testing, I'm using internal tools that fire up, say a database container and run the tests all from within Bazel to leverage test caching and parallelization.

For a while, i was struggling to get around Dockers slow startup time on Mac. My CI server uses Firecracker VM's to isolate OCI containers so it's really only a docker on Mac issue.

My main take away:

- I am so close to delete Docker permanently. There is no comparison, not even close. All integration tests run so much faster.

- Especially parallel container starts a noticable faster.

- I've developed custom docker utils for testing and, believe me, the official Docker API is a humongous pile of garbage that I ended up re-implementing everything by wrapping the Docker command line. To nobody's surprise, even the custom docker utils work way faster and more reliable with OrbStack.

- Zero issues. I am still a little bit puzzled that OrbStack basically runs bug-free no matter what I throw at it. Take it as a compliment.

What I would like to see:

- A Ressource monitor or at least some graph that plots CPU and memory usage. In some rare cases the application in the container runs close to the limit probably because a query takes too long, a process got stuck or whatever. Stuff just happenens. Point is, having an eye on ressource usage helps to spot those corner cases early on.

For me, OrbStack is a clear win and a clear keeper. Well done Orb team and I wish you guys all the success in the world.

Is this something you built yourself? I've been looking for a CI tool that uses Firecracker but never found anything, I started building something myself but it never really got finished. Would love to drop that project and use something off the shelf.

It's totally next level. My build is 70 crates, hundreds of unit tests, integration tests, multi platform docker images for two platforms, and everything is done in under 2 minutes, if it's slow(!). If I hit only an incremental change, build is completed within 30 seconds.

The future is now!

In the end I just run a Linux VM and run everything inside. Zero issues by definition.

I'd actually love to use OrbStack Machines cause it feels much nicer than UTM, but, well, I can't run OrbStack's patched Linux kernel :(

With Colima, file mounting and sharing caused reliability and permission issues for me though I've applied some workarounds with success. To avoid this mess, I'd much rather move to a VM though. I used VMWare Fusion and UTM but I still had the struggles with file sharing between host and the guest.

So I took a lot of steps back and I'm currently running a Lima VM with headless Ubuntu and things are great so far. For Vscode we got the remote SSH plugin and then there is the Jetbrains Gateway as well.

I'm sharing my experiences for people in similar shoes to try these out, if that helps!

(I want to run Open Drone Map on Ubuntu desktop. ODM is a collection of image processing software from OpenCV and similar sources loosely bolted together to merge aerial photos from drones into a 3D model. So it has the install from hell unless containerized. ODM had a snap version, but the snap maintainer left the project.)

There's little point in running Docker Desktop on Linux because you don't need either (a) or (b) on Linux (nor the equivalents for Podman or your favorite Kubernetes distribution). You get the overhead and annoyances of running all your containers under a second OS running under your first one for what— an Electron GUI? I guess it's something if you're really worried about container escapes during local development. But it doesn't generally seem worth it to me.

The other thing OrbStack integrates is letting you spin up many 'machines' that have fast startup and efficiently share resources with each other. But OrbStack achieves that by running long-lived system containers on a single guest VM. If you're on Linux, you can just do that directly, just like the Docker containers, using the same tools¹ OrbStack uses under the hood. The CLI for Incus (a descendant if lxd, associated with Linux containers and LXC) is really pretty nice, too.

OrbStack has a lot of polish and performance optimizations that make it really competitive against other tools like it. There's lots of thoughtful touches in it beyond the basic ideas outlined above. But I wouldn't recommend any tool in its class to someone running a Linux desktop/laptop/workstation who wants to use containers in development. Just use the real things directly and learn the normal, universal CLIs.

--

1: https://linuxcontainers.org/incus/

It's very hard to find something with the build quality and affordances of a Mac. Razer makes a good machine but tbh I'd be embarrassed to bring one to a meeting, and I don't like how newer Thinkpads feel and I don't trust Framework to exist in a few years. It's then complicated while seeking reasonably comparable specs--and I'm not a "oh Apple Silicon sounds warmer" sort of person, amd64 is just fine with me, but AMD's high-end IGPs generally keep pace with base-model Macbooks, and start to fall behind pretty significantly when you move up to a Pro or a Max. You can add a discrete GPU, but, me, I like battery life, and mobile dGPUs are a mess of compromises anyway.

Even if you get over that hurdle, I think Windows feels bad when you're using a touchpad. They haven't cracked that one despite how long they've had to work on it. I wouldn't want to work on a Windows laptop without an external trackball; I carry one with my Mac but rarely use it unless I'm going to be working for a pretty long stretch and I want to save my hands.

Windows is still generally my pick for desktops for a lot of reasons (I don't even dual-boot Linux right now!) but this kind of sneering is weird and uncalled-for.

That said I've been tooting the horn that they are not good software development machines for about 2 years now (incidentally matches exactly with when I got a work macbook pro).

All my GUI stuff and text editors are on the windows side and the actual software all runs in docker in the Ubuntu subsystem.

For example, you can create a new process that has as its file system root /home/blah. It will see every process in the system, it can do networking, etc. — but "ls" can only show the files under /home/blah, which appears as /. Inside this process, you can't see any files above this directory.

A Docker container is simply a process which has set all its namespaces in such a way as to isolate it from others.

"Entering" a Docker container is done by setting up your namespace to be the same as that of the container. For example, you can create a new process (a shell, for example) that is a normal process in every way — full access to the root file system and networking and so on — but has the process tree root as the container. The process will see only the processes inside the container.

You can do this on Linux today using the nsenter [1] tool. (This is also a way to create simple namespaced processes without Docker.) This allows a mix of namespaces; you can enter the container's namespaces but also retain the ability to run tools that aren't available inside the container.

In short, I assume the OrbStack debug command does the exact same thing. It's coincidentally the same concept as an ephemeral container on Kubernetes.

[1] https://man7.org/linux/man-pages/man1/nsenter.1.html

> In particular, mount namespaces are what Docker and runc use to give each container its own image and view of the filesystem. But unlike chroot(2), you can copy an existing mount namespace into a new one. Debug Shell uses this to copy a container's namespace, creating a new view where we can inject things without them showing up in the original mount namespace or filesystem.

What's amazing is it fixes an (almost) show stopper bug when using libuv (or software that uses it like CMake) with Rosetta 2 [1], with the bug present on all Docker/VMs I've tried except OrbStack. It just seems to get everything right.

[1]: https://github.com/libuv/libuv/issues/4279

[1] https://testcontainers.com/

orbstack pro business license: 10€ per month

I don't think the hardware cost is prohibitive here. It's the death of a thousand paper cuts of a startup. I agree that orbstack would be a good investment, though.

> Why don't we support Linux? Because we don't support Linux!

runaround. When a company that mandates MDM chooses to buy an MDM software that lacks Linux support, that choice is the choice not to support Linux on developer machines.

What is the reason Orbstack needs a connection to your license server for continued operation?

I was moving and during nearly a month there was no home internet. My server was happily chugging along on wifi though, but one day I connected to it and saw a message that OrbStack couldn’t contact the license server and soon stop functioning.

This put me off a bit and made me consider whether I want to run anything I depend on using this.

It would be more interesting to know the plans for tracking down commercial users abusing the personal license, maybe Oracle VirtualBox Extension Pack reverse IP address lookup style. The ins and outs of software license enforcement doesn't play well on HN, though I'm guessing there are few complaints about OrbStack requiring a subscription because they offer a free personal use license and the entry level commercial use license is so cheap vs. the value provided.

It's actually exciting to see a dev tool where the developers have a sustainable business model, but this usually means there will be plenty of offers to cash out.

Is OrbStack rootless? Where is the security boundary for the containers? (Are they sandboxed completely from the host?)

How does the virtualisation work? (I’d assume Virtualization.framework, so I can run it without Rosetta if all containers will share host architecture?)

Does it support Docker-in-Docker and Docker-out-of-Docker? (M1 and M2 Mac’s don’t have hardware for nested virtualisation so I assume this also prevents DiD with OrbStack?)

Thanks in advance, eager to try it out.

Admin privileges aren't required on the macOS side. You can optionally allow a privileged helper for some small niceties, but the VM process never runs as root.

The virtualization stack is custom, which allows for a lot of performance and stability improvements. It's not Virtualization.framework or QEMU.

Containers don't require virtualization, so Docker-in-Docker works. Not sure what you mean by Docker-out-of-Docker, but you can run Docker in OrbStack Linux machines, and you can use the managed engine from macOS.

Well, as someone who still lives in stone age (I guess?) I always run headless Linux VM on Windows/macOS and have all my projects/files inside VM so I unfortunately don't use your Docker/Kubernetes features, and fast file sharing is a nice to have.

But, you and your team seems to really care about client virtualization on macOS, more so than Apple. So while being a niche, I sincerely hope you may consider this sometimes later.

I think I used “brew install docker docker-compose colima” and then “colima start”.

Is “brew install orbstack” a drop in replacement for colima or does it install other things that might conflict?

It can optionally install OrbStack's bundled `docker` and `docker compose` binaries, but you can also keep using the Homebrew ones.

For instance: Low power/CPU usage is advertised as non-existent in colima. This is simply not true. Based on my perception I can't tell whether colima VM is running or not. Unlike docker desktop, especially with kubernetes on. Does not drain my battery, does not bog my CPU down unless I intentionally spin up something resource hungry.

ease of use/performance: not everyone needs GUI. colima is fine UX/devex wise with fast startup times. What does "fast network" even mean?

Linux machines/distros: not a fair comparison. colima stands for "containers on Lima" where lima is "linux machines" on macos. I.e. if you want arbitrary vms, use lima directly. colima is specifically built to spin up docker/containerd/k3s vms.

containers/kubernetes networking: this is opinionated and depends on a specific use case. In general I prefer the idea when my local kubernetes setup looks like the end production setup in the sense that I cannot mess up much with networking, access clusterip services directly from localhost because clusterip services are supposed to be accessible from inside the cluster itself, not from outside. loadbalancer IP is accessible through NodePorts anyways.

containers file access: there are plenty of ways you can access files in containers and images. But again, probably there are people who like to browse the guts of a kubernetes node in MacOS Finder. When it comes to files and networking I want to be able to re-use my toolbox used for dealing with remote kubernetes clusters and docker/containerd instances to my local ones. Creating a special case with convenient but non-standard ways to access files as if they were part of my host filesystem may be good for someone, but wrong for someone else because at times when something goes wrong this special case will work as an excuse for "works on my machine".

Please take the above as my personal experience. And I am in the herd of those who tend to keep everything as minimal and bare as possible with as much standartization/ lack of deviations across different environments as possible. Came to colima after years of minikube just because minikube's experience was no longer good with apple silicon. And there must be a very strong reason to switch to something new when what you have already is good enough.

Also, when it comes to GUI, what about Rancher Desktop?

Amazing how far they've got since, in just two years. As others have pointed out, it's already "boring" software in that it just works. And that's no small feat because this kind of tool requires all kinds of low-level hackery to make work, and make work fast. Hats off!

(Happy user here if you couldn't tell.)

So that Linux & Windows people know they can look away. (Looks like a cool tool though!)

Can’t say that for much software to be honest.

What would be the closest alternative on Linux? LXD? I've grown accustomed to the convenience of OrbStack.

In fact, LXD is a bit better. The command line is more powerful, it supports snapshots, the network configuration is more comprehensive, there's a direct access to the host kernel, and the web UI is a nice touch since it can work from a headless VM if needed.

This was one of the few things I was missing on Asahi and Linux in general. Feels good.

You can achieve almost the same thing with Alpine Linux, that's how I run all my containers, one VM per container.

Edit: Further down the comments it says OrbStack is a single Linux VM running LXD containers. Oh well, I was close.

With OrbStack, the ability to set up an Ubuntu or Fedora 'VM' in a few seconds, then install even complex SDN workloads inside is incredible.

Now I want something similar on Linux, especially once I switch to Asahi. I haven't tried LXD yet, but it seems to work similarly to OrbStack with the added benefit of having a full Linux kernel and the ability to modprobe modules and create snapshots, something that isn’t possible with OrbStack. I'll have to give it a try.

LXC containers are like Docker/Podman containers except they usually run an init process, so you're not running just one binary inside the container.

You can make LXC "app containers" which just run one binary Docker/Podman containers.

Ideally use multi-arch images or build your own.