6 ms·

Only WSL2; WSL1 was an actual subsystem.

by gsnedders 3mo ago

selcuka 3mo ago
So this is Darwin/BSD Subsystem for Linux 2.
- rvz 3mo ago
  Yes.
LoganDark 3mo ago
WSL1 was so cool, WSL2 made it boring and isolated.
- TylerE 3mo 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 3mo ago
    ... Now it's just called git bash
    - michaelsbradley 3mo ago
      Just install and use MSYS2, git bash is derived from it anyway, and a regular MSYS2 installation offers a lot more.
  - noduerme 3mo 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 3mo 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 3mo 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 3mo 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.
        noduerme 3mo ago
        Yeah, I recall directory paths being the biggest PITA with running scripts in cygwin. But I mean, that was a very minor set of things to fix compared to what would've had to be written in anything else available at the time. Doing retail office deployments of custom code on employee computers is a weird niche, and you find whatever works and hope you can maintain it somehow. Cygwin was awesome though, saved me a ton of time and the client a lot of money for the moment. (The client later stipulated to all future franchisees that they had to buy only Macs, lol)
      - bschwindHN 3mo ago
        We should be using the baguette emoji for path separators for cross-platform compatibility. https://old.reddit.com/r/ProgrammerHumor/comments/96ufiz/proposal_for_a_new_directory_separator/ https://old.reddit.com/r/ProgrammerHumor/comments/96ufiz/pro...
  - qalmakka 3mo ago
    Does any older folk here remembers when NT was the Cool New Thing (TM) and it had by design support to multiple subsystems plopped over the NT API, and Win32 was just one of them alongside POSIX (Interix) and OS/2? There was even a _very short_ time span when Interix was actually usable (it was extremely short though)
    - pjmlp 3mo ago
      Yes, the only reason I cared for Linux in first place was that the POSIX support wasn't that good. I am convinced that if POSIX subsystem was UNIX serious, GNU/Linux would never taken off on PC, and the whole would be divided between SGI, HP-UX, Solaris, Aix and Windows NT.
      - hnlmorg 3mo ago
        There were already better free options than Linux when Linux first started gaining traction. The reason Linux grew in the 90s was because it was part of the hacker culture. Not because better options didn’t exist. Kids liked the fact that Linux was a free-for-all, anything-goes, platform. It wasn’t stuffy like Unix and it wasn’t proprietary like Windows. Then those kids grew up and became decision makers themselves. And we started to see Linux replace FreeBSD and commercial Unixes.
        pjmlp 3mo ago
        Which ones? BSD was tied in a lawsuit that left doubts on its future. Minix was a toy OS for university teachings. Coherent was commercial. Nothing else was there on the PC market.
        hnlmorg 3mo ago
        386BSD and its derivatives (eg FreeBSD) weren’t really attacked by SCO like other UNIXes were. In fact SCO filed more lawsuits against Linux than they did (for example) FreeBSD. FreeBSD was also used heavily in the late 90s in ISPs and similar domains.
  - kergonath 3mo ago
    > Back in my day you to to download a couple GB worth of cygwin You still can, and it still works exactly the same way.
    - procflora 3mo ago
      It's true, but to be honest the MinGW-built stuff that ships with git for Windows has been enough since WSL took off.
  - iririririr 3mo ago
    what do you mean? that's still the only way to work as a human in windows. wsl1 almost replaced it, but obviously they scrapped it. if you must use windows, it's because you will compile for windows. so you install MSYS, which is a linux distro-ish compiled native for windows. and do your work. wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a server.
    - TylerE 3mo ago
      shrug. I haven't owned a Windows machine in years at this point. It's one of those things like PHP that I just decided my life was better off without.
    - metaltyphoon 3mo ago
      > wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a server. Many enterprises allow windows only so your way into Linux is via WSL2
      - oso2k 3mo ago
        There is also git-bash which usually doesn’t need to have administrator to be installed. https://git-scm.com/install/windows https://git-scm.com/install/windows
- kevinminehart 3mo ago
  It was soooo slow though. Practically unusable for anything i/o heavy.
  - dented42 3mo ago
    Those issues could have been fixed…
- mjg59 3mo 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 3mo 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 3mo 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 3mo 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 3mo 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 3mo 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 3mo ago
    What has that to do with a version number and not keeping up with the times?
    - embedding-shape 3mo 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.

Only WSL2; WSL1 was an actual subsystem.

selcuka 3mo ago

So this is Darwin/BSD Subsystem for Linux 2.

rvz 3mo ago
Yes.

LoganDark 3mo ago

WSL1 was so cool, WSL2 made it boring and isolated.

TylerE 3mo 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 3mo ago
  ... Now it's just called git bash
  - michaelsbradley 3mo ago
    Just install and use MSYS2, git bash is derived from it anyway, and a regular MSYS2 installation offers a lot more.
- noduerme 3mo 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 3mo 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 3mo 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 3mo 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.
        noduerme 3mo ago
        Yeah, I recall directory paths being the biggest PITA with running scripts in cygwin. But I mean, that was a very minor set of things to fix compared to what would've had to be written in anything else available at the time. Doing retail office deployments of custom code on employee computers is a weird niche, and you find whatever works and hope you can maintain it somehow. Cygwin was awesome though, saved me a ton of time and the client a lot of money for the moment. (The client later stipulated to all future franchisees that they had to buy only Macs, lol)
    - bschwindHN 3mo ago
      We should be using the baguette emoji for path separators for cross-platform compatibility. https://old.reddit.com/r/ProgrammerHumor/comments/96ufiz/proposal_for_a_new_directory_separator/ https://old.reddit.com/r/ProgrammerHumor/comments/96ufiz/pro...
- qalmakka 3mo ago
  Does any older folk here remembers when NT was the Cool New Thing (TM) and it had by design support to multiple subsystems plopped over the NT API, and Win32 was just one of them alongside POSIX (Interix) and OS/2? There was even a _very short_ time span when Interix was actually usable (it was extremely short though)
  - pjmlp 3mo ago
    Yes, the only reason I cared for Linux in first place was that the POSIX support wasn't that good. I am convinced that if POSIX subsystem was UNIX serious, GNU/Linux would never taken off on PC, and the whole would be divided between SGI, HP-UX, Solaris, Aix and Windows NT.
    - hnlmorg 3mo ago
      There were already better free options than Linux when Linux first started gaining traction. The reason Linux grew in the 90s was because it was part of the hacker culture. Not because better options didn’t exist. Kids liked the fact that Linux was a free-for-all, anything-goes, platform. It wasn’t stuffy like Unix and it wasn’t proprietary like Windows. Then those kids grew up and became decision makers themselves. And we started to see Linux replace FreeBSD and commercial Unixes.
      - pjmlp 3mo ago
        Which ones? BSD was tied in a lawsuit that left doubts on its future. Minix was a toy OS for university teachings. Coherent was commercial. Nothing else was there on the PC market.
        hnlmorg 3mo ago
        386BSD and its derivatives (eg FreeBSD) weren’t really attacked by SCO like other UNIXes were. In fact SCO filed more lawsuits against Linux than they did (for example) FreeBSD. FreeBSD was also used heavily in the late 90s in ISPs and similar domains.
- kergonath 3mo ago
  > Back in my day you to to download a couple GB worth of cygwin You still can, and it still works exactly the same way.
  - procflora 3mo ago
    It's true, but to be honest the MinGW-built stuff that ships with git for Windows has been enough since WSL took off.
- iririririr 3mo ago
  what do you mean? that's still the only way to work as a human in windows. wsl1 almost replaced it, but obviously they scrapped it. if you must use windows, it's because you will compile for windows. so you install MSYS, which is a linux distro-ish compiled native for windows. and do your work. wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a server.
  - TylerE 3mo ago
    shrug. I haven't owned a Windows machine in years at this point. It's one of those things like PHP that I just decided my life was better off without.
  - metaltyphoon 3mo ago
    > wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a server. Many enterprises allow windows only so your way into Linux is via WSL2
    - oso2k 3mo ago
      There is also git-bash which usually doesn’t need to have administrator to be installed. https://git-scm.com/install/windows https://git-scm.com/install/windows
kevinminehart 3mo ago
It was soooo slow though. Practically unusable for anything i/o heavy.
- dented42 3mo ago
  Those issues could have been fixed…
mjg59 3mo 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 3mo 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 3mo 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 3mo 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 3mo 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 3mo 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 3mo ago
  What has that to do with a version number and not keeping up with the times?
  - embedding-shape 3mo 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.