> filesystem mounting

How is this different to bind mounts

I just wish bind mounts would be more performant/native. I get that this is probably impossible, and probably also sucks on Linux, haven't tried.

But like having containers that need file watchers like vite dev server, or frankenphp in watch mode will overload OrbStack real quick since It seems to fallback to polling instead of listening to fs events.

So I'm stuck running vite dev servers and the like on the host.

I really like OrbStack and am also not sure why I'd use Container Machines over it, at the moment...

I'd like to see a comparison to https://tart.run/ as well.

AFAICT it's pretty similar.

Not a full docker env, I aimed this as doing builds though you can run dockerd as an option, https://github.com/cpuguy83/crucible uses the containerization framework to run either build kitd or dockerd and wire it up to docker/buildx cli (or whatever client tooling you want to use).

The Containerization framework is a library that sits as a layer on top of the virtualization framework. So each container is its own VM.

Machine is tooling above the containerization framework to run multiple things in a container in a vm.

> ... highly integrated Linux environment that works seamlessly on your Mac. ...

Which kernel is running, and is it hosted in hypervisor.framework, as is done with UTM (when not using the qemu mode)?

Ah, the Darwin/BSD Subsystem for Linux.

Why try to circumvent W^X page protection? Some sort of self-modifying program without extra pointer indirections?

(OrbStack dev here.) Instead of Virtualization.framework, we have a custom Rust virtualization stack with custom devices and protocols for things like filesystem sharing. It's a highly optimized vertically integrated stack specifically for running our Linux machines and containers.

Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else supports this, including Containerization.

I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.

https://github.com/apple/container/blob/main/docs/technical-... read documentation mr. rare breed

I like orbstack in theory, but I find it hard to justify a $96/yr license fee for something that has so many open source, free alternatives. As it is, I’d rather use podman or colima

The katas container kernel by default.

Exactly what I thought. The Mac equivalent to WSL. Which is a great thing for Mac devs. Lots of stuff expects Linux these days, not POSIX. Mach isn’t Linux.

Bad legacy apps like Xilinx ISE

Thanks for the info kdrag0n! Big fan of OrbStack; good call out on dynamic memory.

If the guest image has /sbin/init, we use that.

We'd recommend using a base image for the guest that includes systemd. ie: https://github.com/apple/container/blob/main/docs/container-...

just adding a 'hell yeah: orbstack is so good' to the thread. i mainly avoid containers where i can, but when containers need to happen, orbstack is 'just enough' for me. lovely and well considered ui, stable, performant. don't need much else. thank you for your work and care!

> Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else supports this, including Containerization.

Wow, missed this when reviewing OrbStack. I assumed that you just used Containerization and therefore would have the same limitation.

just dropping in to say orbstack super owns and i use it every day. huge respect to rethinking this experience, for a minute there i thought docker was just going to be the only path. i dont think ive looked back for docker since. orbstack just feels right, and damn its so fast and good with resources, and the UI is just insanely straight forward. props!

The alternatives are all broken in some ways is the answer, including the official paid docker enterprise.

Personally I’d rather the company provisioned me MacBook hardware with Linux. Unless Fable or some other ai ports asahi properly to modern hardware I expect to retire before this is possible, orbstack is the next best thing, available today.

Like, this doesn’t answer when to use this vs Docker. Any reference there?

It's free for personal use, and for a company 96/year is absolutely nothing, I'd hope.

Note that orbstack supports audio and usb pass through, which is super nice

Linux VMs on doesn't have to be expensive!

Others here mention it and I’m a new convert to Colima.

The pain of working around Docker Desktop is bad.

That sure would be nice. I seem to rm -rf ~/.colima every few days.

Orbstack plays well with Pycharms BTW.

Not quite, it’s still a VM. And while it supports virtio balloon for growing RAM, it doesn’t yet support releasing that RAM back to the host. And there isn’t a convenient way to shrink the sparse disk images as they grow yet, either.

I know this is off topic, but I do thank you for your Android work, the idea and elegance of fastboot.js and that SafetyNet workaround trick was truly really cool.

Super happy orbstack customer. Just curious on your statement:

> I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.

The linked md document says:

> Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed.

Was that not the case when you used container machines?

Apple says that `systemctl` is supported... hmm am I missing something?

"Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed."

I’ve been using podman on Mac. It’s been a nice fit as the container build files are identical to what I use on my fedora server. I have noticed my 2 virtual core 4 gb Linode vps runs apps faster in the same container as when run on my MacBook Air M2 16 gb. I expected some performance overhead but didn’t think it would be noticeable as it is. Overall happy with podman. How might OrbStack differ?

We love OrbStack too! Thank you for it,

I wanted to make its VM/machine our default secure agent sandbox, but I couldn’t figure out how to isolate this VM from the host properly. This thread prompted me to find the issue though, and I saw this was recently implemented! https://github.com/orbstack/orbstack/issues/169

My first thought as well, docker desktop overhead is pretty bad, would be awesome to see this land natively in DD. By my estimate this could happen, seeing as Docker has historically tried to improve performance but quickly had to accept platform limitations… would only be natural to settle DD over to containers

It mostly removes the big shared background VM and replaces it with smaller, more isolated Apple-native VMs.

I did an experiment migrating my Podman workload to Apple's container @ https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f...

TL;DR reduces ram/storage usage; minimizes it's existence

Ahh those were good times, glad you came across it :)

Mac Subsystem for Linux 2

That's my bad, I used the example alpine commands and the official alpine doesn't have init. It's supported if you build an image with systemd installed

Yep! Still refining it but isolated machines now have fine-grained settings for filesystem mounts, network isolation, SSH agent forwarding, and CPU/memory/disk limits

Having used both, it feels like OrbStack "just works" more than Podman. The main example of this is Supabase.

Isn't the Windows subsystem for Linux (the reference there) also a VM?

Good catch, I tried the example alpine commands and there was no init system. Makes sense if it's based on OCI images

Nice, thanks for this. My plan is to swap over to Apple's containers for local dev, and keep using podman quadlets in production.

> Nowadays, you can't even have multiple routing tables on the latter, the firewall code was probably last updated in Snow Leopard

Apple uses OpenBSD's Packet Filter [1]; I doubt multiple routing tables are a problem. Back in the Snow Leopard days, it was FreeBSD's IPFW, which is also no slouch.

Whatever a firewall can do, PF can do it.

You can also get a nice GUI for PF [2].

[1]: https://www.openbsd.org/faq/pf/index.html

[2]: https://www.murusfirewall.com/murus/

> OpenDarwin was a thing at one point, with mailing lists and other infrastructure hosted by Apple.

"Exploring Darwin and PureDarwin: The Open-Source Foundation of Apple's Operating Systems" - https://machaddr.substack.com/p/exploring-darwin-and-puredar...

Very unlikely to lose support for Rosetta for Linux. Maybe just Rosetta 2 for mac apps.

They already support this scenario with XCode Cloud, it is only a market for those that don't want to pay Apple for it.

We're working on block device passthrough for the builtin SD reader.

OrbStack is great also

How does that work, realistically?

> Memory defaults to half of host memory

That's the most expensive part of the whole transaction, b/c AFAIK, RAM is then dedicated to the VM. It can be swapped out, I suppose, but that's not great.

Yeah. But in exchange it’s a lot of work to keep up with. For GUI stuff you’re now having to have some sort of Wayland layer/driver.

Running VMs is really really easy and low maintenance demand on Apple. And it’s guaranteed compatibility.

Wasn’t compatibility what really sunk WSL1?

Except game development, hence Proton.

For server side, which I believe is the context here, Linux and open source are king.

Even Microsoft gave up on Windows and just runs Linux most things except niche cases. Heck, even SQL Server which is expensive piece of machinery got ported to Linux and that's the default target now in their docs.

With that said, one can't deny Apple's success on the b2c side of things so it feels wrong to call their strategy a failure.

And what is the revenue stream tied to that ci/cd pipeline they aren’t capturing today? Apple would sell less hardware in order to…?

There aren’t any app developers avoiding the Apple ecosystem because there aren’t Darwin containers. They don’t sell server hardware and by all accounts have no intention of ever reentering that space. So they’d spend a bunch of developer cycles to reduce their own revenue stream with no apparent upside beyond “goodwill” which they’ve never been overly concerned about.

Just tested it on on an OCI image with systemd and it works well. I can see the appeal of OrbStack regarding memory reallocation and will stick with it in the time being :)

Yes, that article states that as well under limitations: "Deprecation status: While functional, Apple discourages its direct use in favor of App Sandbox for developers."

the reason i use this (and just a container with -v $HOME:$HOME before) is to get an environment with all the command line tools i'm familiar with from debian, instead of using something like homebrew. in general, i mostly trust these with access to my home directory. a bonus is that i can throw it away and rebuild it easily if i need to.

i'd still use less permissive containers for things i don't feel comfortable installing on the host, e.g. npm.

Apple does have an OCI variant of this: https://github.com/apple/container

Doesn’t seem to have Compose support though, but it’s probably not impossible to build upon.

And of course, it also uses VMs, though unlike Docker, it’s one (micro-?) VM per container: https://github.com/apple/container/blob/main/docs/technical-...

Considering that this project was published less than 24 hours ago I’m guessing you assume it’s a different project.

Only WSL2; WSL1 was an actual subsystem.

Containers only got so popular as a tool for developers to make developing/deploying easier. If you want to use them as a security layer that is a completely different goal and has many highly dangerous pitfalls [1]. Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system. I'd imagine this could happen to most people who installed docker. So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already. In that case not exposing $HOME is just a small thing on your config to-do list.

[1] https://cheatsheetseries.owasp.org/cheatsheets/Docker_Securi...

No, the point of using such a thing is to be able to run Linux workloads. For example, I recently used Containerization to generate trace logs from the tup test suite so that I could bring it up to relative parity on macOS. If it had complete isolation, I would have difficulty getting the modified source code into the container and difficulty getting the trace logs back out of the container. Sure, you can paper over this with bind mounts or whatever the fuck but that's annoying

No, the whole point of machines is their external interfaces? A Linux VM with no interfaces is just a closed box wasting power doing math.

And I think I would caution Apple to consider the lessons of WSL; having shared access to the filesystem is just the bare minimum. Next is networking (and god is this a rabbit hole with WSL), people will want to access their USB devices, X forwarding, GPU passthrough..

Postman Desktop too

Isn't that just expected for modern macOS devices? They have been on arm64 for 6 years now.

it differs by lacking all the cool options that makes vmware and virtualbox good products, but apple users will praise it as a benefit

"bind mounts? I'm better without it"

Isn't multiphase is Ubuntu only?

Correct me if I'm wrong, but by the same logic, you could also say this whole containerization framework is of no use either.

If they're investing resources into it regardless, they might at least try making something that Docker for macOS and co. haven't solved the same exact way already. Something that, due to their almost unhealthy obsession with "system integrity", only they can realistically make. Like native containers.

WSL1 was so cool, WSL2 made it boring and isolated.

So this is Darwin/BSD Subsystem for Linux 2.

You mean Podman Desktop?

Supporting the containerization framework lets them sell more laptops to Linux devs that may have otherwise bought a Dell or hp or insert brand to run Linux natively on or windows with WSL.

It was soooo slow though. Practically unusable for anything i/o heavy.

Containers are REALLY REALLY popular. This is a a great value add for developers on Mac who need to deal with Linux containers.

Which is a ton of ‘em.

Yes.

Yes, thank you iOS autocorrect.

I think at this point native linux ports are somewhat a thing of the past. The problem was that the ports were usually contracted out to a 3rd party and rarely updated or cared for that much. There was also the issue that they often relied on dynamically linked libraries provided by the distro rather than static linked libraries bundled with the game. So stuff that did work would break on distro updates.

The proton model has the benefit that bugs on linux can be fixed by Valve and the Wine community. While bugs in an official linux port can only be fixed by the game publisher which rarely happened. There also seems to be virtually no downsides to running a Windows game in Proton. These days I don't even bother checking the Wine DB or proton rating because unless the game is deliberately blocking linux via anti cheat, it will just work.

Back in my day you to to download a couple GB worth of cygwin, and that wasn't an actual environment, basically just a GNU toolchain compiled for windows. But it got you like....grep and bash and stuff that ran natively on windows which was kinda cool.

I see. Why this interests me is the similar stuff I have been reading lately. All these supply chain attacks regarding npm, Tanstack etc. Therefore I wanted to create a totally isolated sandbox and while considering options I have seen they all by default mount the $HOME. I needed to explicitly tell colima to not do that.

But yeah, I guess my use case is not the main use of such tools or their purpose in general. Thanks for the link, I‘ll take a look at it.

The whole point of container machines is their isolation.

If we wanted access to all interfaces, we'd just run it locally.

We want the container as a closed box, "wasting power doing math", i.e. processing what we actually passed to it.

> Back in my day you to to download a couple GB worth of cygwin

You still can, and it still works exactly the same way.

This however is for Linux containers on macOS, and for those the deployment target are not usually/necessarily arm.

(Plus, you could always even have amd64 linux containers on macOS AS, with good performance, via Rosetta2).

It used to be. Any image is allowed now.

> Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system.

This was due to implicitly granting the LLM access to the host docker daemon, which has superuser privileges, not due to a "container breakout". That's arguably a very different scenario, but of course both are worth considering.

> So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already.

I'd disagree. Containers, at least without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactual, despite their bad reputation.

Understand. And yeah that‘s annoying. I use containers only for development and to keep my main system secure from supply chain attacks. I have almost no build tooling in my Mac anymore. No npm, no cargo, no uv. Nothing. They all live inside the container which is completely isolated.

I guess my use case is not that important for the main user of these tools.

The irony that without Windows there are no Linux games, eventually Linux folks will learn about OS/2 history in regards to Windows compatibility features.

Linux will stay forever a headless operating system great for embedded, server rooms and containers.

We have all limited time on Earth, and eventually Valve won't be around as it used to be, might even be acquired, sold, whatever, then what in regards to Linux gaming?

Cygwin was fun. I'd done zero development on Windows, but about 10 years ago I had to figure out how to deploy some nightly shell scripts across a bunch of local computers in a few dozen offices, where about 80% were MacOS and the rest were Windows. I don't remember exactly how I rigged it, but basically cygwin allowed me to keep the scripts as they were and trigger them in place, with a few small modifications.

I never want to deal with that again ;)

[edit] fwiw, Termux on Android is similarly a fun pseudo-environment. It's a nice and helpful toy.

Does any older folk here remembers when NT was the Cool New Thing (TM) and it had by design support to multiple subsystems plopped over the NT API, and Win32 was just one of them alongside POSIX (Interix) and OS/2? There was even a _very short_ time span when Interix was actually usable (it was extremely short though)

... Now it's just called git bash

Funny how confidently people can mock while knowing nothing about the specific tech discussed and the different targets. I'd google: VirtualBox vs containers.

Just install and use MSYS2, git bash is derived from it anyway, and a regular MSYS2 installation offers a lot more.

Wine existed before Proton, Valve made it better but the project doesn't rely on Valve. Currently Linux is the best gaming experience. Zero bloat or nagware, everything just works. It's just ironic Wine/Proton ended up being the best platform for gaming on Linux. I don't think anyone expected it to run so well with virtually no performance impact.

Now with the Fex project, it might end up that running Windows games on linux on a modern ARM processor could be the best way to game going forward, especially for mobile platforms like the SteamDeck.

Yes, the only reason I cared for Linux in first place was that the POSIX support wasn't that good.

I am convinced that if POSIX subsystem was UNIX serious, GNU/Linux would never taken off on PC, and the whole would be divided between SGI, HP-UX, Solaris, Aix and Windows NT.

The biggest issue I remember is directory seperators... windows of course using \ which bash would then interpret as an escape. Cygwin mostly papered over that from what I can recall, but it could lead to some weirdness, like sometimes you'd get C:\\path\\es\\like\\this

There were already better free options than Linux when Linux first started gaining traction.

The reason Linux grew in the 90s was because it was part of the hacker culture. Not because better options didn’t exist.

Kids liked the fact that Linux was a free-for-all, anything-goes, platform. It wasn’t stuffy like Unix and it wasn’t proprietary like Windows.

Then those kids grew up and became decision makers themselves. And we started to see Linux replace FreeBSD and commercial Unixes.

We should be using the baguette emoji for path separators for cross-platform compatibility.

https://old.reddit.com/r/ProgrammerHumor/comments/96ufiz/pro...

The best gaming experience are Switch, PlayStation, XBox, iOS, Android, the very definition of everything just works, and no kernel drivers to worry about.

You could also use forward slashes, like C:/path/subpath, which has worked since Windows 1.0/DOS 2.0.

That's handy when you're entering paths in a Cygwin/MSYS Bash shell, but might not help much if you're trying to parse or otherwise work with existing patgh variables composed with backslashes.

You just listed concrete hardware (with the exception of Android). That's a category error, of course a fixed hardware with specialized software will have less inconsistencies.

I wouldn't say your use case is not important. That is a completely reasonable way to work. I just wouldn't say mounting home directories is an anti-feature. There just should be a way to turn it off.

Yes, you could if you were entering them manually, but some apps that generated file names would screw it up. I think they were using some sort of stdlib function to get the path seperator. Forward slash paths working in native windows apps also wasn't quite a given, either. Keep in mind this was a loooong time ago... like windows xp era maybe, even.

>without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactua

There's much more to it than that if you check out the link above. Misconfiguring a container is the 2026 version of misconfiguring FTP and MYSQL in the 90s. I.e. most users don't even know how they are asking to get rooted.

It's called a container machine but it's a virtual machine. I quote from https://github.com/apple/container/blob/main/docs/technical-...

> container runs containers differently. Using the open source Containerization package, it runs a lightweight VM for each container that you create. This approach has the following properties:

> * Security: Each container has the isolation properties of a full VM, using a minimal set of core utilities and dynamic libraries to reduce resource utilization and attack surface.

> * Privacy: When sharing host data using container, you mount only necessary data into each VM. With a shared VM, you need to mount all data that you may ever want to use into the VM, so that it can be mounted selectively into containers.

> * Performance: Containers created using container require less memory than full VMs, with boot times that are comparable to containers running in a shared VM.

So: you build it as a container image and MacOS starts a VM to run it.

Edit: quite unusually for a container it runs systemd. They give an example "systemctl start postgresql".

Yeah, I recall directory paths being the biggest PITA with running scripts in cygwin. But I mean, that was a very minor set of things to fix compared to what would've had to be written in anything else available at the time.

Doing retail office deployments of custom code on employee computers is a weird niche, and you find whatever works and hope you can maintain it somehow. Cygwin was awesome though, saved me a ton of time and the client a lot of money for the moment. (The client later stipulated to all future franchisees that they had to buy only Macs, lol)

Well, maybe I should have used relativity unimportant. And yes there should be a way to turn them off. In OrbStack it was not possible to do that until lately.

If you let your container write setuid binaries to your path, give it admin access to your network, let it access the Docker daemon socket etc., sure, you're going to have a bad time. But how is that different from e.g. giving software running in a VM SSH access to your host or a writable bind mount to the host's root directory?