6 ms·

Not quite, it’s still a VM. And while it supports virtio balloon for growing RAM, it doesn’t yet support releasing that RAM back to the host. And there isn’t a

Not quite, it’s still a VM. And while it supports virtio balloon for growing RAM, it doesn’t yet support releasing that RAM back to the host. And there isn’t a convenient way to shrink the sparse disk images as they grow yet, either.

AlexB138 4mo ago
Isn't the Windows subsystem for Linux (the reference there) also a VM?
- gsnedders 4mo ago
  Only WSL2; WSL1 was an actual subsystem.
  - selcuka 4mo ago
    So this is Darwin/BSD Subsystem for Linux 2.
    - rvz 4mo ago
      Yes.
  - LoganDark 4mo ago
    WSL1 was so cool, WSL2 made it boring and isolated.
    - TylerE 4mo ago
      Back in my day you to to download a couple GB worth of cygwin, and that wasn't an actual environment, basically just a GNU toolchain compiled for windows. But it got you like....grep and bash and stuff that ran natively on windows which was kinda cool.
      - _blk 4mo ago
        ... Now it's just called git bash
        michaelsbradley 4mo ago
        Just install and use MSYS2, git bash is derived from it anyway, and a regular MSYS2 installation offers a lot more.
      - noduerme 4mo ago
        Cygwin was fun. I'd done zero development on Windows, but about 10 years ago I had to figure out how to deploy some nightly shell scripts across a bunch of local computers in a few dozen offices, where about 80% were MacOS and the rest were Windows. I don't remember exactly how I rigged it, but basically cygwin allowed me to keep the scripts as they were and trigger them in place, with a few small modifications. I never want to deal with that again ;) [edit] fwiw, Termux on Android is similarly a fun pseudo-environment. It's a nice and helpful toy.
        TylerE 4mo ago
        The biggest issue I remember is directory seperators... windows of course using \ which bash would then interpret as an escape. Cygwin mostly papered over that from what I can recall, but it could lead to some weirdness, like sometimes you'd get C:\\path\\es\\like\\this
        rpeden 4mo ago
        You could also use forward slashes, like C:/path/subpath, which has worked since Windows 1.0/DOS 2.0. That's handy when you're entering paths in a Cygwin/MSYS Bash shell, but might not help much if you're trying to parse or otherwise work with existing patgh variables composed with backslashes.
        TylerE 4mo ago
        Yes, you could if you were entering them manually, but some apps that generated file names would screw it up. I think they were using some sort of stdlib function to get the path seperator. Forward slash paths working in native windows apps also wasn't quite a given, either. Keep in mind this was a loooong time ago... like windows xp era maybe, even.
    - kevinminehart 4mo ago
      It was soooo slow though. Practically unusable for anything i/o heavy.
      - dented42 4mo ago
        Those issues could have been fixed…
    - mjg59 4mo ago
      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 reasonable (if tediously slow) success in making it possible to express the same semantics to Linux and have it handle things fast. It would be fascinating to know whether WSL1 developers didn't have enough traction to get Windows internals altered to match, or whether it's just way harder to do the same under Windows.
      - LoganDark 4mo ago
        Wine achieves better performance these days due to things like... adding a module to the Linux kernel that implements NT-like synchronization primitives. So, Linux subsystem for NT synchronization basically. (a.k.a. NTSync) Maybe this works out better because Linux is more flexible, while Windows/NT is more "set in its ways" and therefore more difficult to implement Linux on top of... Maybe?
      - barrkel 4mo ago
        It's my understanding that a big part of WSL1 performance loss comes from the relatively thick layered filesystem architecture on Windows. Since git and nodejs are both common in modern development and are expected to work efficiently with huge numbers of files, this was a real bottleneck and it couldn't easily be tackled without threatening backward compatibility.
      - alerighi 4mo ago
        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 limited. For example working in the embedded development field I often need to use serial ports or USB devices, a thing that the WSL2 is not capable of doing (unless passing trough USB/IP that has its compatibility issues especially for stuff like debuggers needing precise timing), and that the WSL1 was at least for the serial ports able to do. This is a limitation that doesn't allow me to use the WSL. Same thing with all kind of other software that wants to access peripherals of the machine natively (e.g. a GPU for example, or another PCI card, something that to be fair is not even doable as far as I know with hypervisors on Windows but completely doable with hypervisors running on a Linux OS where trough the IO MMU you can share any PCI device of the host to the VM). WSL1 was a great idea, bad thing that Microsoft abandoned it for something that is just good for web application development.
  - pjmlp 4mo ago
    WSL 1 is long gone for all practical purposes, yet it still dominates conversations. Also everyone on FOSS gets it wrong, WSL wasn't a subsystem like classical Windows NT ones. It was based on Drawbridge research using picoprocesses, a new approach for library OSes. https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-process-overview https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro...
    - embedding-shape 4mo ago
      > Also everyone on FOSS gets it wrong, WSL wasn't a subsystem like classical Windows NT ones. Everyone in FOSS? How about Microsoft got it wrong, since they actually named it The Windows Subsystem for Linux (WSL)? It wasn't the FOSS community who chose the name for them.
      - pjmlp 4mo ago
        What has that to do with a version number and not keeping up with the times?
        embedding-shape 4mo ago
        What version number? WSL1 vs WSL2? I'm not sure if you see the quoted part. My comment is about the part that starts with "> " that you wrote earlier.
jayd16 4mo ago
Mac Subsystem for Linux 2
BodyCulture 4mo ago
This is not a problem at all as most Apple computers come with plenty of RAM and lots of disk space! We are so lucky that Apple engineers always think so differently into the future!
alerighi 4mo ago
And a limited VM, for example I look at the documentation and it's not possible to share USB devices with the VM, making it perfectly useless for doing embedded development where you have to connect to the boards with USB. I will continue to use UTM for that reason...
- mrpippy 4mo ago
  Virtualization.framework just gained USB passthrough support in macOS 27. It might be a niche feature for containers to add, but other VM software will likely add support soon.
hedora 4mo ago
So, heavier than running docker in qemu?
burnte 4mo ago
WSL is a VM too, but that's still what this is. WSL for MacOS. It's great!
musicale 4mo ago
macOS is basically already a POSIX subsystem for macOS, which is already a UNIX™. But (some) people still criticize it because it's not Linux or FreeBSD (though it is closer to the latter than the former).

AlexB138 4mo ago

Isn't the Windows subsystem for Linux (the reference there) also a VM?

gsnedders 4mo ago
Only WSL2; WSL1 was an actual subsystem.
- selcuka 4mo ago
  So this is Darwin/BSD Subsystem for Linux 2.
  - rvz 4mo ago
    Yes.
- LoganDark 4mo ago
  WSL1 was so cool, WSL2 made it boring and isolated.
  - TylerE 4mo ago
    Back in my day you to to download a couple GB worth of cygwin, and that wasn't an actual environment, basically just a GNU toolchain compiled for windows. But it got you like....grep and bash and stuff that ran natively on windows which was kinda cool.
    - _blk 4mo ago
      ... Now it's just called git bash
      - michaelsbradley 4mo ago
        Just install and use MSYS2, git bash is derived from it anyway, and a regular MSYS2 installation offers a lot more.
    - noduerme 4mo ago
      Cygwin was fun. I'd done zero development on Windows, but about 10 years ago I had to figure out how to deploy some nightly shell scripts across a bunch of local computers in a few dozen offices, where about 80% were MacOS and the rest were Windows. I don't remember exactly how I rigged it, but basically cygwin allowed me to keep the scripts as they were and trigger them in place, with a few small modifications. I never want to deal with that again ;) [edit] fwiw, Termux on Android is similarly a fun pseudo-environment. It's a nice and helpful toy.
      - TylerE 4mo ago
        The biggest issue I remember is directory seperators... windows of course using \ which bash would then interpret as an escape. Cygwin mostly papered over that from what I can recall, but it could lead to some weirdness, like sometimes you'd get C:\\path\\es\\like\\this
        rpeden 4mo ago
        You could also use forward slashes, like C:/path/subpath, which has worked since Windows 1.0/DOS 2.0. That's handy when you're entering paths in a Cygwin/MSYS Bash shell, but might not help much if you're trying to parse or otherwise work with existing patgh variables composed with backslashes.
        TylerE 4mo ago
        Yes, you could if you were entering them manually, but some apps that generated file names would screw it up. I think they were using some sort of stdlib function to get the path seperator. Forward slash paths working in native windows apps also wasn't quite a given, either. Keep in mind this was a loooong time ago... like windows xp era maybe, even.
  - kevinminehart 4mo ago
    It was soooo slow though. Practically unusable for anything i/o heavy.
    - dented42 4mo ago
      Those issues could have been fixed…
  - mjg59 4mo ago
    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 reasonable (if tediously slow) success in making it possible to express the same semantics to Linux and have it handle things fast. It would be fascinating to know whether WSL1 developers didn't have enough traction to get Windows internals altered to match, or whether it's just way harder to do the same under Windows.
    - LoganDark 4mo ago
      Wine achieves better performance these days due to things like... adding a module to the Linux kernel that implements NT-like synchronization primitives. So, Linux subsystem for NT synchronization basically. (a.k.a. NTSync) Maybe this works out better because Linux is more flexible, while Windows/NT is more "set in its ways" and therefore more difficult to implement Linux on top of... Maybe?
    - barrkel 4mo ago
      It's my understanding that a big part of WSL1 performance loss comes from the relatively thick layered filesystem architecture on Windows. Since git and nodejs are both common in modern development and are expected to work efficiently with huge numbers of files, this was a real bottleneck and it couldn't easily be tackled without threatening backward compatibility.
    - alerighi 4mo ago
      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 limited. For example working in the embedded development field I often need to use serial ports or USB devices, a thing that the WSL2 is not capable of doing (unless passing trough USB/IP that has its compatibility issues especially for stuff like debuggers needing precise timing), and that the WSL1 was at least for the serial ports able to do. This is a limitation that doesn't allow me to use the WSL. Same thing with all kind of other software that wants to access peripherals of the machine natively (e.g. a GPU for example, or another PCI card, something that to be fair is not even doable as far as I know with hypervisors on Windows but completely doable with hypervisors running on a Linux OS where trough the IO MMU you can share any PCI device of the host to the VM). WSL1 was a great idea, bad thing that Microsoft abandoned it for something that is just good for web application development.
- pjmlp 4mo ago
  WSL 1 is long gone for all practical purposes, yet it still dominates conversations. Also everyone on FOSS gets it wrong, WSL wasn't a subsystem like classical Windows NT ones. It was based on Drawbridge research using picoprocesses, a new approach for library OSes. https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-process-overview https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro...
  - embedding-shape 4mo ago
    > Also everyone on FOSS gets it wrong, WSL wasn't a subsystem like classical Windows NT ones. Everyone in FOSS? How about Microsoft got it wrong, since they actually named it The Windows Subsystem for Linux (WSL)? It wasn't the FOSS community who chose the name for them.
    - pjmlp 4mo ago
      What has that to do with a version number and not keeping up with the times?
      - embedding-shape 4mo ago
        What version number? WSL1 vs WSL2? I'm not sure if you see the quoted part. My comment is about the part that starts with "> " that you wrote earlier.

jayd16 4mo ago

Mac Subsystem for Linux 2

BodyCulture 4mo ago

This is not a problem at all as most Apple computers come with plenty of RAM and lots of disk space! We are so lucky that Apple engineers always think so differently into the future!

alerighi 4mo ago

And a limited VM, for example I look at the documentation and it's not possible to share USB devices with the VM, making it perfectly useless for doing embedded development where you have to connect to the boards with USB. I will continue to use UTM for that reason...

mrpippy 4mo ago
Virtualization.framework just gained USB passthrough support in macOS 27. It might be a niche feature for containers to add, but other VM software will likely add support soon.

hedora 4mo ago

So, heavier than running docker in qemu?

burnte 4mo ago

WSL is a VM too, but that's still what this is. WSL for MacOS. It's great!

musicale 4mo ago

macOS is basically already a POSIX subsystem for macOS, which is already a UNIX™. But (some) people still criticize it because it's not Linux or FreeBSD (though it is closer to the latter than the former).