I've been a Linux user since 1995 and run Windows + WSL2 on my desktop machines. It's not too deep and pretty similar to why so many folks were drawn to Macs; a no brains just works GUI with the ability to launch a terminal and do real work on a UNIX-like system.
I can use a single machine to do everything I need, without rebooting and without making sacrifices.
I can watch Netflix and play games, without needing to write a f'n shell script to fix the screen tearing present in the nvidia driver - or realizing a particular game has quirks or doesn't work in Proton, so I just have to throw up my arms and say "Well, I guess we just don't play that game".
I can pop open a terminal anytime and have access to a real Linux system, as opposed to the faux "uncanny valley linux" solutions like Cygwin and Git Bash that seem to work until they don't. And unlike a traditional VM there's no management involved; I open the terminal when I need it and close it when i'm done, just like a normal application.
If you want to remove a lot of unnecessary pain in your life, completely abandon the idea of mounting a host FS within a guest VM. Doubly so if they're different OS's/FS's and triply so if this a development VM.
Not quite. WSL2 dynamically uses resources as needed (`vmmem`), whereas a traditional VM requires allocating a fixed amount of RAM and CPU from the host machine.
I did. But I also have Windows machines, in which I use WSL2. Granted, I don't use GUI applications on them (or see much need to).
It's actually quite nice to have a "real" linux instance available on virtually any Windows machine. I believe Microsoft is targeting the "developer who uses a Mac" market share with WSL2 and I expect more and more to jump ship, as the experience is significantly better.
WSL2 uses it's own init system - only one kernel (plus a tiny initrd) is virtualized by hyper-v; each subsequent linux instance (distribution) is containerized. There's additional facilities that handle resource allocation dynamically vs the user specifying a static amount during VM creation.
These (and more) result in the end-user interacting with WSL2 the same way they would any normal application. To think of it as simply a VM isn't quite correct.
You said earlier that "If the inconvenience of arguments troubles you, write a wrapper". That's precisely what a script like this is. A wrapper. I can run one simple, static command, similar to just about any build tool e.g. `cd project && make`.
It's unnecessary complexity for the user. As opposed to simply having the build instructions as `Run bin/build` you're suggesting "Run bin/build <project root>". But there's zero reason for requiring the user to supply the project root when we already know it.
Yes, it is silly. You've just added extra complexity to a project for little to no benefit. If you decide to move the script you take the same steps as if you moved anything else i.e update the references.
In many cases one might not want a full stand-alone program with arguments, usage and such. Rather a "script" i.e. something that can be simply executed to run a series of tasks. For example it's quite silly for a build script to require the path of the project it resides in.
I knew a guy in high school (1997) who was talking about this thing called Linux. It was a super complex operating system and didn't even have a graphical interface. Our thinking was if we managed to install it we'd be geniuses or something. After a few days we got it installed on his PC, but i'd yet to install it myself.
Unfortuantly the only computer I had (not counting the family PC) was a laptop with 4MB of RAM (effectively less than 4). The installation required booting one floppy disk containing the kernel, then swapping and loading another disk containing the installer. And course the machine ran out of memory during this process. I spent days learning how to compile a custom kernel that excluded the things I didn't need, until it was small enough to fit in memory and succesfully install it.
WSL2 has been a major game changer for me. Being able to isolate my work entirely inside the linux VM (with VSCode Remote) has eliminated 90% of my frustrations with developing on Windows.
I can use a single machine to do everything I need, without rebooting and without making sacrifices.
I can watch Netflix and play games, without needing to write a f'n shell script to fix the screen tearing present in the nvidia driver - or realizing a particular game has quirks or doesn't work in Proton, so I just have to throw up my arms and say "Well, I guess we just don't play that game".
I can pop open a terminal anytime and have access to a real Linux system, as opposed to the faux "uncanny valley linux" solutions like Cygwin and Git Bash that seem to work until they don't. And unlike a traditional VM there's no management involved; I open the terminal when I need it and close it when i'm done, just like a normal application.