No words can describe WSL1 better than those from Gavin Belson talking about Nucleus:
Windows Subsystem for Linux: The lost potential
191–200 of 250 posts
Re: Windows Subsystem for Linux: The lost potential
#192> Can you imagine how cool it would be to manipulate Windows services from the WSL session? It is a cool integration trick and might even be useful for some people like the author and their role with Azure. But it isn't remotely interesting for most WSL users who just want a local Linux to run containers in, or Linux tools, or just do server related stuff.
But there's literally no point in having WSL then, as such users can just keep using VirtualBox as they always did.
Re: Windows Subsystem for Linux: The lost potential
#193> Can you imagine how cool it would be to manipulate Windows services from the WSL session? It is a cool integration trick and might even be useful for some people like the author and their role with Azure. But it isn't remotely interesting for most WSL users who just want a local Linux to run containers in, or Linux tools, or just do server related stuff.
But there's literally no point in having WSL then, as such users can just keep using VirtualBox as they always did.
The goals of WSL2 compared to VirtualBox or HyperV are:
* Lower memory use
* Tighter integration with networking. i.e. it looks like it is running on localhost.
* Start/stops on demand, and much faster.
* (easier) file system integration. i.e. you can easily get to your Linux files from inside Windows.
So there actually are some points to WSL2.
For me personally I couldn't get Docker (actually its networking) to work properly via WSL2 so I'm still on a VM. But at least it works. VSCode's remote working feature is fantastic too in this situation.
Re: Windows Subsystem for Linux: The lost potential
#194Hmm it could be nice idea to add WSL2 "module" to allow call "exe" from inside WSL2 env. Is this technically currently possible somehow ?
Re: Windows Subsystem for Linux: The lost potential
#195Earlier quoted context omitted.
so what's the 'Windows way' then? keeping a file open forever and let it lock out other programs from using that file? I'm starting to get an idea why Windows is getting on my nerves so much with file locks....
You can just use FILE_SHARE_WRITE if you don't want to lock out other programs...
If I know one thing about files it's that any fix beginning with "You can just..." is probably wrong.
Re: Windows Subsystem for Linux: The lost potential
#196Earlier quoted context omitted.
You can just use FILE_SHARE_WRITE if you don't want to lock out other programs...
If I know one thing about files it's that any fix beginning with "You can just..." is probably wrong. https://danluu.com/file-consistency/
I didn't recommend you do this, I just said it's there if you really want to.
Re: Windows Subsystem for Linux: The lost potential
#197Contra 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…
What are the trillion other problems? Honest question, some I heard this a lot, but in reality I only ever saw people complain about the speed of the filesystem. So that would just mean 1 (hard) thing to fix.
The network stack integration was less than transparent too. Random places all over the system where e.g. a magical ioctl() just didn't work properly. Who really wants to spend their life reimplementing every last baroque detail of that stuff?
Re: Windows Subsystem for Linux: The lost potential
#198> Can you imagine how cool it would be to manipulate Windows services from the WSL session? It is a cool integration trick and might even be useful for some people like the author and their role with Azure. But it isn't remotely interesting for most WSL users who just want a local Linux to run containers in, or Linux tools, or just do server related stuff.
But there's literally no point in having WSL then, as such users can just keep using VirtualBox as they always did.
That's exactly what I ended up concluding as well when I tried switching to WSL 2 because it added too much friction to the DX, whereas Docker Compose and the Docker VSCode extension kept things simple and scoped.
I didn't even keep WSL 2 as Docker engine because it doesn't forward filechange events from shared folders (which breaks livereload / watch mode), ended up going back to Hyper-V and it does exactly what I need.
Re: Windows Subsystem for Linux: The lost potential
#199Earlier quoted context omitted.
But there's literally no point in having WSL then, as such users can just keep using VirtualBox as they always did.
The goals of WSL2 compared to VirtualBox or HyperV are: * Lower memory use * Tighter integration with networking. i.e. it looks like it is running on localhost. * Start/stops on demand, and much faster. * (easier) file system integration. i.e. you can easily get to your Linux files from inside Windows. So there actually are some points to WSL2. For me personally I couldn't get Docker (actually its networking) to work…
[deleted]
Re: Windows Subsystem for Linux: The lost potential
#200Earlier quoted context omitted.
But there's literally no point in having WSL then, as such users can just keep using VirtualBox as they always did.
That's exactly what I ended up concluding as well when I tried switching to WSL 2 because it added too much friction to the DX, whereas Docker Compose and the Docker VSCode extension kept things simple and scoped. I didn't even keep WSL 2 as Docker engine because it doesn't forward filechange events from shared folders (which breaks livereload / watch mode), ended up going back to Hyper-V and it does exactly what I n…
I tried to use Windows Docker with the WSL2 back-end and the impression I got was that it was for people wanting to run scripts on windows which then run docker things. What I just wanted was scripts running on Linux which then did docker things. The whole mix of two operating systems was just complexity and problem I didn't want.
I just run vanilla docker inside a Linux VM and everything works as expected now.