Hacker News new | ask | show | jobs
by cogman10 2 days ago
Is there any reason why macOS doesn't try a WSL1 style approach? I get why that didn't fully work out for windows, but it seems like macOS being another *nix would make a lot of what was hard for windows, easy for mac. It seems like it should be possible to run most linux applications natively on macOS with few additional new APIs.

BSD actually has this already.

2 comments

FreeBSD has Linuxlator because there is a lot of binary only software that was never and never will be ported to BSD, so it's necessary for them in order to avoid bleeding users away. Conversely, macOS has basically all software ported natively to it, so when you _need_ a Linux environment 95% of the time it isn't because you need $XYZ that only run Linux, but because you need a proper Linux environment with systemd, cgroups etc. Implementing that stuff on top of XNU would probably be extremely expensive and it would arguably defeat the point of having their own kernel in the first place.
> Implementing that stuff on top of XNU would probably be extremely expensive and it would arguably defeat the point of having their own kernel in the first place.

I'm not sure how it'd defeat the point of having their own kernel.

As for cost, possibly, but it would really be a huge boon to macOS for software devs. It's hard for me to believe that Rosetta isn't similarly costly, but it's been done because running x86 software is still very much a necessity for MacOS.

> I'm not sure how it'd defeat the point of having their own kernel.

Because then you'd need to both maintain your kernel AND your own implementation of the Linux ABI, an ABI you don't have control over and that basically forces you to reimplement half on Linux in the first place.

People already get what they want by having a tiny Linux machine running at native speed. In 2026, virtualisation still isn't free, but it's pretty darn close.

> Because then you'd need to both maintain your kernel AND your own implementation of the Linux ABI, an ABI you don't have control over and that basically forces you to reimplement half on Linux in the first place.

A very large portion of that ABI is already implemented due to both systems being POSIX. But further, a lot of what programs actually interact with is already ported to macOS. For example, you can build and use glibc.

Also, I get the lack of control, but that really isn't a major issue. The linux kernel pretty rarely adds new userspace additions. By and large the majority of work that goes into the kernel is around new drivers and fixing drivers. Even when there's kernel level features, it's very often not a userspace thing but rather things like new schedulers.

There's a reason MS didn't see the same approach as being too terribly crazy with WSL1, and those are very different systems. Heck, there's a reason cygwin continues to exist and work.

> A very large portion of that ABI is already implemented due to both systems being POSIX.

POSIX provides an API, not an ABI, and that API kind of ends at libc. Being compatible with Linux at an ABI level means being able to provide the same syscalls in the same way as Linux does. Not all Linux syscalls map cleanly to POSIX APIs, and in general xnu has lots of different concepts that make it somewhat cumbersome to adapt to what the Linux kernel does. The example of this is Microsoft with WSL1; they gave up not because Windows was too shoddy but rather because people want ALL of the kernel, which is a moving target anyway. it's a waste of time not to simply run it in the first place, virtualization is cheap and you get the real thing, with no quirks

What would be the advantages over a VM infrastructure Apple needs anyway and that has a much simpler, more stable “ABI” compared to the Linux kernel?
Potentially faster application execution along much lower memory requirements. In the case of docker, even a possibility of shared library loading further reducing runtime costs (For example, containers based on the same base image could load glibc into memory only once).

There's also simply the possibility of using linux software directly in macos without doing OS dependent changes to the software.

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?

> Wasn’t compatibility what really sunk WSL1?

Yes, but a big part of the problem with WSL1 was the size of the conceptual gap between POSIX and Windows NT that WSL1 had to bridge. An “MSL1” would likely have fewer problems because the gap between macOS and Linux is smaller, given they are both POSIX

The other thing Apple could potentially do, is add Linux-compatible APIs to macOS. IBM wanted to support Kubernetes on their z/OS mainframe operating system, so they implemented on it a clone of Linux namespace APIs, e.g. unshare. Then we could have macOS nodes in a K8S cluster-which might actually be useful for some people, e.g. if you have a Jenkins CI farm, the Linux nodes can run on K8S, but currently macOS nodes (which you need if you are targeting iOS or macOS) can’t, they have to be bare metal or VMs.

More Linux-macOS source compatibility would also benefit macOS by making it less work to port software to it from Linux

Linux and the BSDs take APIs one from the other all of the time. The issue with having a Linux ABI is that you don't need just the few APIs you're missing, you need to implement the WHOLE Linux API and it has to be _perfect_, otherwise stuff will randomly break. I loved the original WSL, I had to use it for a time period back in the day when I was stuck on a Windows PC, but it can't be denied it was full of random bugs
The original WSL proves that you actually don't need to be perfect or to have the entire ABI to be pretty useful.

It's true that missing ABIs will cause random crashes and problems. However, a lot of apps can run with a minimal set of ABIs.

>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.

Maybe that’s not what they intended.