I’m an extremely heavy user of WSL2 (and previously WSL), and have years of daily driving Linux and Windows on native installations as desktops, so please take this comment coming from that vantage point:
I think that running a full-blown desktop environment in WSL2 misses the point. The main benefit of using WSL2 over a virtual machine or a native installation of Linux, IMVHO, is that you prefer or mostly need to work in Windows, but you have some Linux use-cases you’d like to integrate into your flow. If you don’t want the integration, you can get a more genuine experience just running a full-screen VM. If you are mostly in Linux, you’ll get higher performance with a native installation. WSL2 really shines when you want to run a couple of apps, but mostly live in Windows.
To me, running a full desktop environment via WSL2 gets into a weird area where you’re paying WSL2 costs, but reaping very few benefits. Windows, ideally, already is the desktop manager; if you can use an X server that integrates with it (I prefer to use X410 for its turnkey HiDPI support and transparent clipboard integration, but I’ve also had good experiences with others in the past), you can have a truly Linux-and-Windows-living-together experience. If you instead run a full-blown desktop environment, it feels…maybe not quite as bad as in a full-on VM, but pretty close to, say, early Mac OS X running Classic: the splits between the two environments are painfully obvious, and I end up wanting to have an editor for Linux and an editor for Windows, and an email client for Linux and for Windows, etc., which puts me back into “why didn’t I just use a full-blown VM” land.
This is very much in the mind of the beholder, and if you like and want to run a Linux desktop via WSL2, then do it in good health. But if you’re just getting into WSL2 (and you should!), I’d encourage you not to start there. Try using WSL2 just for the genuine Linux stuff first, and only turn to the DE if you’re both unhappy with that experience, and can’t install Linux natively.
The two big things from WSL (maybe in WSL2?) that I find useful are wslpath, to convert paths between the two, so I can hand a file from my Linux home directory to a *NIX program and the ability to run .exes directly from bash. There are also some fun things in the WSL image activator that let you chain together shell scripts in the shbang line. I have a shell script saved as wps that looks like this:
I can then put #!/path/to/wps at the start of .ps1 files that I want to run with the Windows version of PowerShell and run them directly from WSL’s bash. This is very useful for things like starting and stopping Azure VMs. I’ve recently switched to using the Windows Terminal from Konsole in WSL + X11, but I still use vcXsrv so I can run things like gitg (locally or via X forwarding).
I like the suggested use-case from @david_chisnail, but for the most part I agree with you @gecko. My personal laptop was a Windows machine with WSL, then dual-booted Linux/Windows, and now it’s just Linux. This was an experiment to see if I could have a mostly-Linux work laptop, even though I needed Windows for Rhino3D CAD software.
I wanted to see if I could, for all intents and purposes, have a visually Linux laptop running on Windows. This tutorial is the steps that I took, and I really enjoyed the results. One thing that’s not included in the tutorial (but I found extremely useful) was calling Windows .exe files inside .desktop files from within WSL. You could then use rofi, or the dmenu, to call Windows applications from within a WSL2 desktop GUI (but obviously they sill ran outside of VcXsrv).
This whole setup is really unsustainable, mainly because of the fact that you don’t have a persistent session with VcXsrv, so anything that isn’t recoverable in a Tmux session gets trashed if your computer goes to sleep (disconnecting from VcXsrv). It’s a total monstrosity, but it’s nice to have the gnome-terminal and tiling, I think.
Excited for Microsoft to integrate a wayland compositor to actually do this stuff by default!
I like that this post uses just awk to extract the address for the DISPLAY variable. I’ve gotten frustrated with tutorials that use some combo of ‘cat’, ‘grep’, and then ‘awk’.
But the argument to awk is the file to consume, grep is something you can do with awk line filtering, and even the external :0.0 can be integrated with the awk print statement, so you can also just do
I’m an extremely heavy user of WSL2 (and previously WSL), and have years of daily driving Linux and Windows on native installations as desktops, so please take this comment coming from that vantage point:
I think that running a full-blown desktop environment in WSL2 misses the point. The main benefit of using WSL2 over a virtual machine or a native installation of Linux, IMVHO, is that you prefer or mostly need to work in Windows, but you have some Linux use-cases you’d like to integrate into your flow. If you don’t want the integration, you can get a more genuine experience just running a full-screen VM. If you are mostly in Linux, you’ll get higher performance with a native installation. WSL2 really shines when you want to run a couple of apps, but mostly live in Windows.
To me, running a full desktop environment via WSL2 gets into a weird area where you’re paying WSL2 costs, but reaping very few benefits. Windows, ideally, already is the desktop manager; if you can use an X server that integrates with it (I prefer to use X410 for its turnkey HiDPI support and transparent clipboard integration, but I’ve also had good experiences with others in the past), you can have a truly Linux-and-Windows-living-together experience. If you instead run a full-blown desktop environment, it feels…maybe not quite as bad as in a full-on VM, but pretty close to, say, early Mac OS X running Classic: the splits between the two environments are painfully obvious, and I end up wanting to have an editor for Linux and an editor for Windows, and an email client for Linux and for Windows, etc., which puts me back into “why didn’t I just use a full-blown VM” land.
This is very much in the mind of the beholder, and if you like and want to run a Linux desktop via WSL2, then do it in good health. But if you’re just getting into WSL2 (and you should!), I’d encourage you not to start there. Try using WSL2 just for the genuine Linux stuff first, and only turn to the DE if you’re both unhappy with that experience, and can’t install Linux natively.
The two big things from WSL (maybe in WSL2?) that I find useful are
wslpath, to convert paths between the two, so I can hand a file from my Linux home directory to a *NIX program and the ability to run.exes directly from bash. There are also some fun things in the WSL image activator that let you chain together shell scripts in the shbang line. I have a shell script saved aswpsthat looks like this:I can then put
#!/path/to/wpsat the start of .ps1 files that I want to run with the Windows version of PowerShell and run them directly from WSL’s bash. This is very useful for things like starting and stopping Azure VMs. I’ve recently switched to using the Windows Terminal from Konsole in WSL + X11, but I still use vcXsrv so I can run things like gitg (locally or via X forwarding).I like the suggested use-case from @david_chisnail, but for the most part I agree with you @gecko. My personal laptop was a Windows machine with WSL, then dual-booted Linux/Windows, and now it’s just Linux. This was an experiment to see if I could have a mostly-Linux work laptop, even though I needed Windows for Rhino3D CAD software.
I wanted to see if I could, for all intents and purposes, have a visually Linux laptop running on Windows. This tutorial is the steps that I took, and I really enjoyed the results. One thing that’s not included in the tutorial (but I found extremely useful) was calling Windows
.exefiles inside.desktopfiles from within WSL. You could then use rofi, or the dmenu, to call Windows applications from within a WSL2 desktop GUI (but obviously they sill ran outside of VcXsrv).This whole setup is really unsustainable, mainly because of the fact that you don’t have a persistent session with VcXsrv, so anything that isn’t recoverable in a Tmux session gets trashed if your computer goes to sleep (disconnecting from VcXsrv). It’s a total monstrosity, but it’s nice to have the gnome-terminal and tiling, I think.
Excited for Microsoft to integrate a wayland compositor to actually do this stuff by default!
I like that this post uses just awk to extract the address for the DISPLAY variable. I’ve gotten frustrated with tutorials that use some combo of ‘cat’, ‘grep’, and then ‘awk’.
Heh, that’s fair. I saw that in one single post aeons ago; my suspicion is everyone since is just copying it without thinking about it.
For fellow crustaceans: the line that’s usually suggested is
But the argument to
awkis the file to consume,grepis something you can do withawkline filtering, and even the external:0.0can be integrated with theawkprint statement, so you can also just doYea, you caught me, I just copied it from someone else, but I also appreciate the simplicity of just using
awk:)