This is a tired cliché. Today, a modern Linux desktop like KDE Plasma just works and more importantly, gets out of your way unlike obnoxious MacOS and Windows. Aside of that you get the most advanced OS in the world where the thing being discussed here is a decade old.
The issue with Linux isn’t the software, it’s the hardware. Apple Silicon Macs are still the nicest laptop hardware by a huge margin. All the Linux-native options are, at best, “okay”.
Agreed, the Linux laptop story is pretty dire compared to Apple hardware. My travel laptop is an M1 with Asahi.
WSL1 was very conceptually appealing, and ended up working very poorly because of the poor matching between Linux syscalls and the Windows kernel. Git suffered terribly as a result. The inverse is also somewhat true - there have been cases where Wine is much slower than native Windows because Linux simply doesn't provide a simple way to achieve the same outcome, and interestingly the Wine developers have had reasonab…
It did work quite well. The problem with the filesystem could have been solved by optimizing the Windows kernel, that would have benefit also programs run outside the WSL by the way (NTFS have performance problems and Microsoft knows, and even provided a kind of solution as far as I know with the developer FS or what they call it). The thing that I don't like of the WSL2 is that is just a VM, but a VM that is very li…
> The problem with the filesystem could have been solved by optimizing the Windows kernel
Over time this would tie the Windows kernel’s requirements so that they matched the Linux kernel’s due to expectations from WSL1 users. This of course is a bad idea for any engineering organization - you will have requirements imposed on you that don’t mesh well with your other non-WSL users and you also have no real sway over Linux governance. This would lead to the Windows kernel either becoming a clone of Linux or serving at least one set of users poorly.
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.
[flagged]
Hmm, that sounds very vague. how DID you solve it? Do you now run Vite dev servers in containers?
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?
> for GUI stuff you’re now having to have some sort of Wayland layer/driver. The target for this isn't GUI stuff.
Generally I’d agree but the comment I replied to mentioned people running Linux applications and in my mind that means GUI.
This is all fine and dandy, but where are the native Darwin Jails Apple? Still scared that people will filling whole rooms of Mac Minis if you allow them to have multiple macOS containers and not only up to two fat VMs per machine?
Darwin namespaces would be much more interesting and we are in dire need of them in the current security landscape. I don’t really understand the hype for Apple’s Containerization, it’s just another container runtime alongside many others. It’s not really any better than OrbStack - in fact it’s worse.
Just to clarify, this requires Mac OS 26 Tahoe for "container" doesn't it? So those of us holding out on Sequoia who can't stand the broken glass UI or what's called and the other undesired features need to stick to Docker desktop.
I turned off what "glass" UI I could with config, and it's not too different than Sequoia, got used to it pretty quick. Obviously the things not supported on an old OS will keep increasing, until eventually it is EOL'd.
OrbStack works really well for me. I wonder how it’s compared to this performance wise
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.
Can you share more details? OrbStack has always supported inotify/fanotify (Linux fs watching APIs) on bind mounts and most people use watchers with no issues. Happy to look into whatever you're running into: danny@orbstack.dev
To clarify a few comments here: this is not only OCI containers: container machines add support for persistence and filesystem mounting, making container machines a great lightweight Linux environment for developers using macOS. More details here: https://developer.apple.com/videos/play/wwdc2026/389
> 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 c…
Sounds like a lot of the same choices/compromises that are in wsl2.
WSL1 was very conceptually appealing, and ended up working very poorly because of the poor matching between Linux syscalls and the Windows kernel. Git suffered terribly as a result. The inverse is also somewhat true - there have been cases where Wine is much slower than native Windows because Linux simply doesn't provide a simple way to achieve the same outcome, and interestingly the Wine developers have had reasonab…
It did work quite well. The problem with the filesystem could have been solved by optimizing the Windows kernel, that would have benefit also programs run outside the WSL by the way (NTFS have performance problems and Microsoft knows, and even provided a kind of solution as far as I know with the developer FS or what they call it). The thing that I don't like of the WSL2 is that is just a VM, but a VM that is very li…
Why would you work on embedded development through a VM? Out of curiosity.
> 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, yo…
>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 aski…
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?