81–90 of 250 posts
Earlier quoted context omitted.
It's clear that they are not enthusiastic about delivering new features to WSL1. Consider how WSL2 now exclusively features CUDA support, Wayland support, loop mounts, Docker, etc.
Docker support is precisely the sort of feature that would have required significantly more work to support in WSL1 than WSL2.
I want to type ‘code ‘ and have it open in VSCode. Can’t.
Earlier quoted context omitted.
WSL1 hasn't gone away for those who prefer it. But we're talking about an extra gigabyte. It's still cheaper than a full VM.
It's even cheaper to only use what you need with msys2! bash inside mintty gives me all I need, with minimal overhead. Eventually, I'd like to see bash inside Windows Terminal made easily available - complete that with busybox, and you cover 90% of the Linux usecases without having to download anything (a bit like how starting Terminal.app offers most of what you need on MacOS) Add an option to install packages using…
Earlier quoted context omitted.
why would you need that if you have the command line functionality already? Windows has shipped with sftp for a while now. about the only think missing is a stand alone ssh client on the windows side but for that there is putty.
I like my GUIs when they're more efficient. All major Linux file managers and the Mac OS one support sftp mounts graphically.
Earlier quoted context omitted.
More or less. Though I'd rephrase your description of WSL1 as "Linux for the NT kernel". In that sense "Win32" (the API used by Windows programs) could also be described as "Win32 for the NT kernel". They are both subsystems that translate their APIs into NT kernel calls. Windows NT used to have a number of these subsystems but all except Win32 were deprecated and eventually removed.
I see, that makes sense! This is a really interesting design and seeing it this way gives me more respect for the Windows operating system generally. Is this subsystem concept something that has a parallel on the *nix/BSD side of the fence? Or is it unique to the NT architecture?
I don't know if the native solaris syscall interface is itself a zone, while Win32 is a subsystem on Windows.
I spent several months using WSL2 but because the implementation attempts to hide virtualization behind a curtain, it was unclear where the magic successfully blended the guest with the host and where it didn't. I ended up having a lot of trouble with networking, and leaned heavily on my understanding of virtualization to debug those issues:
- Connections to Windows VPNs wouldn't work well inside the WSL guest
- Running browser automation tools like Playwright wouldn't allow you access to the browser in Windows
- The WSL2 guest can't connect to services (tcp, ports, whatever) running on the Windows host
- Trying to do something like `ssh -D 1337` from inside the WSL guest is confusing
- If you run `ssh -L 8080:localhost:8080 remote.com` using powershell, the WSL guest does not have access to port `8080`.
While incredible in that it has dynamic VM memory allocation and such, it still felt like running Linux in VirtualBox, SSHing into it and having a lot of automation to handle port forwarding - a workflow I have used in the past and isn't very revolutionary.
WSL1, while a simpler implementation that is more feature constrained, I felt that it matched my behavioural expectations (an API mapping that isn't feature complete) making it more useful. I continue to daily drive it.
Windows Terminal also made Windows competitive with other OSes that have quality terminal emulators, such as `iTerm2` or `gnome-terminal` (`hyper` is too memory heavy, though `cmder` is not too bad).
It's my understanding that MS wants to focus on Hyper-V to make VMs more like containers, but for my simple use-case/world view, I would rather the "reverse Wine" world of WSL1 to the "enhanced VM" world of Hyper V.
I will continue to use WSL1 daily and hope MS chooses to focus on this style of integration over the WSL2 style. I'd love to see features like blending `/etc/hosts`, supporting `tmpfs` and containerization (without virtualization).
If MS deprecates WSL1, I will probably move back to MacOS or Linux.
I want fish as my shell. Easy peasy. I want to type ‘code ‘ and have it open in VSCode. Can’t.
I remember NT was to have an OS/2 subsystem, probably because it started out as OS/2 3.0, with a New Technology (NT) kernel. I know there was a POSIX system, but I never saw or interacted with it and, legend says, it was only used to check a box in government contracts.
The original POSIX subsystem was not very useful -- a minimal set of system calls, plus a Microsoft re-branded MKS Toolkit to provide shells and utilities. Microsoft ended up buying Interix, who offered a much more pleasant UNIX-on-Windows setup. That was supported for many years as "SFU" and later "SUA" SUA was still a pretty weird UNIX though. PE-COFF binaries, and a linker that wasn't 100% GNU compatible, and a lo…
Contra opinion: the VM option reduced the service interface between Windows and Linux to a single kernel implementation and a few drivers, rather than every possible userspace program ever written. It's an amazing and obvious trade off. My inner architecture astronaut appreciates all the ideas in this post, but I've been trying to kill that guy for over a decade now. The bottom line is WSLv1 design SUCKED precisely b…
I agree with the sentiment but, some scenarios have become orders of magnitude more complicated on WSL2 like connecting to a daemon on Windows or vice versa. I understand clear cut security boundaries and separate network interfaces, but it's extremely hard to get them running smoothly now. Everything was on localhost on WSL1. Memory usage has also gone bonkers with the VM approach, causing unnecessary overhead for c…
This is about my only issue with WSL2, but it's a big one. Perhaps worse than this being a problem is that Microsoft don't seem to be providing any solutions - there are various GitHub issues about it, with non-Microsoft ransoms being the ones providing workarounds (but these depend on your environment - I haven't found any way to get this working myself!).
WSL1 was very ambitious. AFAIK, the main reason for shelving it's approach was filesystem performance. While it was indeed slower than native/VM, I personally never found it troublesome outside of artificial benchmarking. For the vast majority of use cases, WSL1 worked well, with Docker being the only real thing missing, IMO.