In the ability to legally and without hassle install it on random PCs.
The kernel is open source
The actual userland is proprietary in both cases. Opening Apple Terminal on macOS and using homebrew is as “open” as running Windows Terminal with WSL: Basically the things in the terminal are FOSS, the graphical surroundings of both systems aren’t.
Having used both, I don’t find WSL comparable to macOS’s native unix shell. Aside from the bloat of it, integration with the rest of the OS is troublesome on Windows, and WSL apps are second-class citizens. On macOS, there is no “rest of the OS” because the unix shell is fundamental. It’s not running in a virtual environment like WSL; it is the native environment.
the WSL 2 architecture uses virtualized networking components, which means that WSL 2 will behave similarly to a virtual machine – WSL 2 distributions will have a different IP address than the host machine (Windows OS).
As of right now WSL 2 does not include serial support, or USB device support
If you have no open file handles to Windows processes, the WSL VM will automatically be shut down. This means if you are using it as a web server, SSH into it to run your server and then exit, the VM could shut down because it is detecting that users are finished using it and will clean up its resources.
WSL is a great addition to Windows, but it’s still kind of a band-aid.
Having used both, I don’t find WSL comparable to macOS’s native unix shell.
I use Windows with openSUSE WSL, macOS with homebrew and “real” Linux.
Aside from the bloat of it
Which bloat? It’s just a regular terminal.
WSL 2 will behave similarly to a virtual machine
That’s not so much different from a sanboxed environment on native Linux where a Flatpak application can request file system access but not touch processes outside its sandbox. If anything, I prefer that I have all my regular openSUSE thingies (zypper, my own Build Service repository,…) available unmodified on Windows, whereas the macOS terminal (and I know that’s subjective) just feels off.
It’s a virtual environment that requires installation of an entire Linux system. The disk and memory usage is not comparable to a native Unix OS.
Everything uses some sort of “virtual environment” these days. It’s not bloat, it’s the norm. homebrew does not use native macOS libraries except the very low level stuff. It handles its own dependencies. “Regular” macOS applications usually bundle their dependencies inside the .app folder bundle. On Linux, Flatpak installs its own dependencies. Heck, for whatever reason the Bazzite maintainers decided that installing Steam within a Arch Linux distrobox container is somehow preferable to the alternatives and Steam on Linux in turn uses “virtual environments” because the various Steam Linux Runtimes are specialized Ubuntu and Debian environments and every version of Proton is its own “virtual environment” of Windows.
I’ve bought a notebook almost exactly 10 years ago for €629 that had a 1TB hard drive and that I’ve upgraded to 16 or 24GB RAM for relatively little money (IIRC around €100). Sure, if you look at the insane prices that Apple asks for even a pathetic 8GB RAM / 256 GB SSD entry level MacBook, you surely want to avoid “bloat” but for many people in the regular x86 PC world a few “virtual environments” here and there don’t make a difference and aren’t considered bloat at all. If anything, for WSL users being able to run most unmodified Linux binaries is a benefit over relying on crappy ports of GTK to macOS and such because those ports of Linux software to macOS integrates so well…
I disagree with the characterization of Homebrew as a “virtual environment”. It installs binaries and libraries in its own directory and by default adds those directories to your PATH. This makes them first-class entities on macOS. Unlike with WSL, there is no secondary kernel and no hypervisor. Everything runs natively within the macOS environment. There’s no bridge, no virtualizer, not even sandboxing with Homebrew or MacPorts. Homebrew and MacPorts do not install “Linux” software; they install Mac software.
As a real-world example, I can install newer versions of standard tools like openssl and kerberos5 via MacPorts or Homebrew, and native Mac apps that rely on those pick them up seamlessly. I don’t think that is realistic with WSL, if even possible.
I haven’t re-evaluated a lot of development stuff since the release of WSL2, so perhaps things are smoother now, but in WSL1 I found there to be a big disconnect between e.g. a Windows-native installation of Spyder and a WSL-based Python environment. If there is a way to set that up, rather than installing Spyder within WSL and wrestling with X11 to run it as a second-class GUI, I’d love to hear it.
In the ability to legally and without hassle install it on random PCs.
The actual userland is proprietary in both cases. Opening Apple Terminal on macOS and using homebrew is as “open” as running Windows Terminal with WSL: Basically the things in the terminal are FOSS, the graphical surroundings of both systems aren’t.
Having used both, I don’t find WSL comparable to macOS’s native unix shell. Aside from the bloat of it, integration with the rest of the OS is troublesome on Windows, and WSL apps are second-class citizens. On macOS, there is no “rest of the OS” because the unix shell is fundamental. It’s not running in a virtual environment like WSL; it is the native environment.
Microsoft details some of the little gotchas of WSL in their FAQ: https://learn.microsoft.com/en-us/windows/wsl/faq . A few notable ones:
WSL is a great addition to Windows, but it’s still kind of a band-aid.
I use Windows with openSUSE WSL, macOS with homebrew and “real” Linux.
Which bloat? It’s just a regular terminal.
That’s not so much different from a sanboxed environment on native Linux where a Flatpak application can request file system access but not touch processes outside its sandbox. If anything, I prefer that I have all my regular openSUSE thingies (zypper, my own Build Service repository,…) available unmodified on Windows, whereas the macOS terminal (and I know that’s subjective) just feels off.
It’s a virtual environment that requires installation of an entire Linux system. The disk and memory usage is not comparable to a native Unix OS.
Everything uses some sort of “virtual environment” these days. It’s not bloat, it’s the norm. homebrew does not use native macOS libraries except the very low level stuff. It handles its own dependencies. “Regular” macOS applications usually bundle their dependencies inside the .app folder bundle. On Linux, Flatpak installs its own dependencies. Heck, for whatever reason the Bazzite maintainers decided that installing Steam within a Arch Linux distrobox container is somehow preferable to the alternatives and Steam on Linux in turn uses “virtual environments” because the various Steam Linux Runtimes are specialized Ubuntu and Debian environments and every version of Proton is its own “virtual environment” of Windows.
I’ve bought a notebook almost exactly 10 years ago for €629 that had a 1TB hard drive and that I’ve upgraded to 16 or 24GB RAM for relatively little money (IIRC around €100). Sure, if you look at the insane prices that Apple asks for even a pathetic 8GB RAM / 256 GB SSD entry level MacBook, you surely want to avoid “bloat” but for many people in the regular x86 PC world a few “virtual environments” here and there don’t make a difference and aren’t considered bloat at all. If anything, for WSL users being able to run most unmodified Linux binaries is a benefit over relying on crappy ports of GTK to macOS and such because those ports of Linux software to macOS integrates so well…
I appreciate your well-reasoned arguments.
I disagree with the characterization of Homebrew as a “virtual environment”. It installs binaries and libraries in its own directory and by default adds those directories to your PATH. This makes them first-class entities on macOS. Unlike with WSL, there is no secondary kernel and no hypervisor. Everything runs natively within the macOS environment. There’s no bridge, no virtualizer, not even sandboxing with Homebrew or MacPorts. Homebrew and MacPorts do not install “Linux” software; they install Mac software.
As a real-world example, I can install newer versions of standard tools like openssl and kerberos5 via MacPorts or Homebrew, and native Mac apps that rely on those pick them up seamlessly. I don’t think that is realistic with WSL, if even possible.
I haven’t re-evaluated a lot of development stuff since the release of WSL2, so perhaps things are smoother now, but in WSL1 I found there to be a big disconnect between e.g. a Windows-native installation of Spyder and a WSL-based Python environment. If there is a way to set that up, rather than installing Spyder within WSL and wrestling with X11 to run it as a second-class GUI, I’d love to hear it.