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