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 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.