this post was submitted on 01 Dec 2023
1676 points (95.5% liked)

linuxmemes

21180 readers
1281 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
     

    Stolen from Deltachat

    you are viewing a single comment's thread
    view the rest of the comments
    [–] GenderNeutralBro@lemmy.sdf.org 10 points 11 months ago (1 children)

    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:

    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.

    [–] woelkchen@lemmy.world 2 points 11 months ago (1 children)

    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.

    [–] GenderNeutralBro@lemmy.sdf.org 4 points 11 months ago (1 children)

    Which bloat? It’s just a regular terminal

    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.

    [–] woelkchen@lemmy.world 1 points 11 months ago (1 children)

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

    [–] GenderNeutralBro@lemmy.sdf.org 1 points 11 months ago

    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.