4 ms·

> I wonder if it could be brought to macos (would be a huge undertaking though since there are SO many differences between Linux and modern macs). That sounds

by dgl 3y ago

> I wonder if it could be brought to macos (would be a huge undertaking though since there are SO many differences between Linux and modern macs). That sounds like trying to recreate what Microsoft did with WSL1*, which is an emulation layer for Linux on Windows. They realised that was a mistake (things like cgroups and container support are complex and slightly different implementations led to subtle bugs). Now WSL2 is a whole Linux kernel running in virtualisation. The "clever" bits are now the glue (file sharing, even if that has performance limitations) and some things like WSLg, which sadly they still keep as their own fork and haven't upstreamed yet. *: As touched on in other threads, despite the version number of 1.3.10, most of the features they are talking about, such as actually using a real Linux kernel are for "WSL2".

yjftsjthsd-h 3y ago
> which is an emulation layer for Linux on Windows. They realised that was a mistake (things like cgroups and container support are complex and slightly different implementations led to subtle bugs). In the meantime, FreeBSD, NetBSD, and illumos have all had Linux ABI compat since long before WSL1 and are doing fine - not perfect compatibility, but quite good. If I were guessing, I would guess that papering over the difference between members of the unix family is easier than between unix OSs and NT.
- FooBarWidget 3y ago
  Microsoft's lesson suggests that actual user needs have evolved passed the point where FreeBSD-style emulation compatibility is good enough. Users are no longer content with "good enough" Linux compatibility, they want perfect Linux compatibility.
  - deleted 3y ago
    [deleted]
  - baq 3y ago
    Last time I tried WSL1 it couldn’t run Postgres, which was immediate disqualification for my backend work, if you could live with the slow git. WSL2 runs Postgres, docker and basically anything, and git is as fast as native if you stick to WSL2 file system. The quote is misrepresenting issues with wsl1.
  - yjftsjthsd-h 3y ago
    Two thoughts: * As I sort of mentioned, I suspect that the others may actually do a better job of compatibility than WSL1 because they're on unix-likes already so there's less fundamental differences to try and make compatible. For example, fork() is already cheap, and unix-likes already have filesystem performance like Linux. * A binary compatibility layer is less important to begin with since you're already on a unix-like. For example, sibling comment says postgres didn't work; FreeBSD already has postgres as a fully supported native package, so you're unlikely to care how it runs under the Linux compat layer.
TeMPOraL 3y ago
> That sounds like trying to recreate what Microsoft did with WSL1, which is an emulation layer for Linux on Windows. They realised that was a mistake (things like cgroups and container support are complex and slightly different implementations led to subtle bugs). Now WSL2 is a whole Linux kernel running in virtualisation.* Wish they didn't just throw in the towel. WSL1 was (is, still using it) something special, WSL2 is only streamlining/first-party-ing the usual workaround of running Ubuntu in a VirtualBox.
- packetlost 3y ago
  Except it didn't work and had awful performance as soon as you did any syscall (this is especially apparent for filesystem access). It's a neat idea, but Linux has over 300 syscalls with varying levels of complexity in their behavior.
  - WorldMaker 3y ago
    It worked fine, a lot of people are still using WSL1 and the Windows Android Subsystem is still closer to WSL1 than WSL2, and in that case in Windows 11 Microsoft is even selling that to ordinary users in the Microsoft Store. The performance was never that bad, depending on your use cases is all. Admittedly a lot of use cases for developers are heavily file I/O bound or deal with dark details and edge cases of syscalls rather than the happy paths (because developers gonna develop), so of course developers felt the performance sting there. (I'm very curious if WSL1 on the soon-to-come Dev Drive has good performance, because it will bypass a lot of the file I/O filter drivers that caused some of the worst WSL1 performance for developers. That seems like an obvious and interesting win, if the case.)
    - TeMPOraL 3y ago
      I wonder how much of the WSL1 I/O performance had to do with the syscalls, and how much with them being visible to Widnows Defender and other anti-malware software, which all like to hook into every single file I/O operation userspace programs do. WSL2 I believe, being a full-fledged VM, gets to hide from those checks. In my experience, WSL1 was fast enough even on large git repos with lots of files (after tweaking some Git settings), but performance crashed once corporate nuked my Defender exclusion lists, making both the repo and the entire WSL1 filesystem suffer from "real-time checks" on every file write.

by dgl 3y ago

yjftsjthsd-h 3y ago

> which is an emulation layer for Linux on Windows. They realised that was a mistake (things like cgroups and container support are complex and slightly different implementations led to subtle bugs). In the meantime, FreeBSD, NetBSD, and illumos have all had Linux ABI compat since long before WSL1 and are doing fine - not perfect compatibility, but quite good. If I were guessing, I would guess that papering over the difference between members of the unix family is easier than between unix OSs and NT.

FooBarWidget 3y ago
Microsoft's lesson suggests that actual user needs have evolved passed the point where FreeBSD-style emulation compatibility is good enough. Users are no longer content with "good enough" Linux compatibility, they want perfect Linux compatibility.
- deleted 3y ago
  [deleted]
- baq 3y ago
  Last time I tried WSL1 it couldn’t run Postgres, which was immediate disqualification for my backend work, if you could live with the slow git. WSL2 runs Postgres, docker and basically anything, and git is as fast as native if you stick to WSL2 file system. The quote is misrepresenting issues with wsl1.
- yjftsjthsd-h 3y ago
  Two thoughts: * As I sort of mentioned, I suspect that the others may actually do a better job of compatibility than WSL1 because they're on unix-likes already so there's less fundamental differences to try and make compatible. For example, fork() is already cheap, and unix-likes already have filesystem performance like Linux. * A binary compatibility layer is less important to begin with since you're already on a unix-like. For example, sibling comment says postgres didn't work; FreeBSD already has postgres as a fully supported native package, so you're unlikely to care how it runs under the Linux compat layer.

TeMPOraL 3y ago

> That sounds like trying to recreate what Microsoft did with WSL1, which is an emulation layer for Linux on Windows. They realised that was a mistake (things like cgroups and container support are complex and slightly different implementations led to subtle bugs). Now WSL2 is a whole Linux kernel running in virtualisation.* Wish they didn't just throw in the towel. WSL1 was (is, still using it) something special, WSL2 is only streamlining/first-party-ing the usual workaround of running Ubuntu in a VirtualBox.

packetlost 3y ago
Except it didn't work and had awful performance as soon as you did any syscall (this is especially apparent for filesystem access). It's a neat idea, but Linux has over 300 syscalls with varying levels of complexity in their behavior.
- WorldMaker 3y ago
  It worked fine, a lot of people are still using WSL1 and the Windows Android Subsystem is still closer to WSL1 than WSL2, and in that case in Windows 11 Microsoft is even selling that to ordinary users in the Microsoft Store. The performance was never that bad, depending on your use cases is all. Admittedly a lot of use cases for developers are heavily file I/O bound or deal with dark details and edge cases of syscalls rather than the happy paths (because developers gonna develop), so of course developers felt the performance sting there. (I'm very curious if WSL1 on the soon-to-come Dev Drive has good performance, because it will bypass a lot of the file I/O filter drivers that caused some of the worst WSL1 performance for developers. That seems like an obvious and interesting win, if the case.)
  - TeMPOraL 3y ago
    I wonder how much of the WSL1 I/O performance had to do with the syscalls, and how much with them being visible to Widnows Defender and other anti-malware software, which all like to hook into every single file I/O operation userspace programs do. WSL2 I believe, being a full-fledged VM, gets to hide from those checks. In my experience, WSL1 was fast enough even on large git repos with lots of files (after tweaking some Git settings), but performance crashed once corporate nuked my Defender exclusion lists, making both the repo and the entire WSL1 filesystem suffer from "real-time checks" on every file write.