5 ms·

For a long time macos was close enough to *nix that it was far better than Windows for developers that need a Linux-like terminal. WSL might be seen as Microsof

by jarym 3y ago

For a long time macos was close enough to *nix that it was far better than Windows for developers that need a Linux-like terminal. WSL might be seen as Microsoft's attempt to catchup and in many respects they leap frogged macos for this set of users. I don't see Apple putting in the same level of effort to create the WSL experience on mac but who knows. Hyperkit could be quite a nice base to build on. The only issue I've run into is that there are more gotchas with podman & docker when running the ARM macs but that's only because so many images are still x86-only. Edit: Darwin has BSD roots and FreeBSD offers Linux binary compatibility.. 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).

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.
Vecr 3y ago
Technically MacOS is UNIX but at this point what people actually want is Linux-compat and possibly FreeBSD/OpenBSD stuff, as you said. MacOS is *nix.
chungy 3y ago
Darwin's FreeBSD roots are not very large (basically some of the userland terminal programs). It was never based on the FreeBSD kernel and that's where FreeBSD's Linux compatibility really resides.
- comex 3y ago
  That’s not true: xnu has significant parts originally copied from the FreeBSD kernel, alongside the Mach parts and the IOKit parts. However, considering not just the changes made in the process but also the ~20 years of independent evolution since then, I wouldn’t count on anything from the modern FreeBSD kernel being easy to port. Probably easier to start from scratch.
epolanski 3y ago
One key difference between Apple and Microsoft on this regard is that Microsoft needed such a tool internally: after all given the importance of Azure in Microsoft's ecosystem Microsoft developers need machines able to handle Linux workloads. I know for a fact that Microsoft sees it as a defeat internally that their own developers would rather have a macbook over the company-issued Surfaces or similar windows laptops. So easing the pain of working on *nix machines is a top priority for enterprise Microsoft users. That's not really a huge issue for Apple, they are neither in the business of selling linux virtual machines nor their ecosystem offers such a huge gap to native linux after all.

by jarym 3y ago

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.

Vecr 3y ago

Technically MacOS is UNIX but at this point what people actually want is Linux-compat and possibly FreeBSD/OpenBSD stuff, as you said. MacOS is *nix.

chungy 3y ago

Darwin's FreeBSD roots are not very large (basically some of the userland terminal programs). It was never based on the FreeBSD kernel and that's where FreeBSD's Linux compatibility really resides.

comex 3y ago
That’s not true: xnu has significant parts originally copied from the FreeBSD kernel, alongside the Mach parts and the IOKit parts. However, considering not just the changes made in the process but also the ~20 years of independent evolution since then, I wouldn’t count on anything from the modern FreeBSD kernel being easy to port. Probably easier to start from scratch.

epolanski 3y ago

One key difference between Apple and Microsoft on this regard is that Microsoft needed such a tool internally: after all given the importance of Azure in Microsoft's ecosystem Microsoft developers need machines able to handle Linux workloads. I know for a fact that Microsoft sees it as a defeat internally that their own developers would rather have a macbook over the company-issued Surfaces or similar windows laptops. So easing the pain of working on *nix machines is a top priority for enterprise Microsoft users. That's not really a huge issue for Apple, they are neither in the business of selling linux virtual machines nor their ecosystem offers such a huge gap to native linux after all.