Please keep in mind I’m asking with genuine interest as I am a happy OrbStack user otherwise, (for private use).
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.
As you appear to be aware per the prefix to your question, this is the nature of all subscription software... what alternative would you choose if you were the author? Requiring the personal use edition to phone home once a month probably increases the potential sale price of the business by at least one order of magnitude.
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.
What’s the security model for OrbStack and its containers?
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?)
It's a shared VM and kernel, so the security boundary between containers is only as strong as typical Linux containers, and we don't really use the VM as a strong security boundary right now. The security model is similar to running Docker containers on a native Linux machine for development.
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.
currently using orbstack with a devcontainer project, and in that devcontainer i'm bringing up some other nested containers via `testcontainers` via golang, so it's completely possible and is running sweetly
One reason I'm still using docker desktop in my (small) company is that our production systems are using docker compose and the networking with domains does not translate 1:1 between orbstack locally and docker compose + nginx in production. Is there an easy way to solve this?
OrbStack domains can be nice but you don't have to use them. It's fully compatible with Compose, so you can just run the same commands with no changes to your setup. Did that not work for you?
I have been using colima as a lightweight alternative to docker desktop and the likes of it for almost two years. Looking at the comparison provided on the orbstack website (https://docs.orbstack.dev/compare/colima) it seems to be not very accurate or at least requires some explanations/clarifications.
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?
weikju|1 year ago
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.
password4321|1 year ago
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.
highwaylights|1 year ago
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.
kdrag0n|1 year ago
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.
bakhtiari_rev|1 year ago
rfoo|1 year ago
Basically I want a true UTM replacement, the one I can run my own kernel.
kdrag0n|1 year ago
nkmnz|1 year ago
kdrag0n|1 year ago
styfle|1 year ago
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?
kdrag0n|1 year ago
It can optionally install OrbStack's bundled `docker` and `docker compose` binaries, but you can also keep using the Homebrew ones.
txdv|1 year ago
kdrag0n|1 year ago
nrvn|1 year ago
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?
saagarjha|1 year ago