WSL Extreme Usages. Using GUIs, USB connections, and… | by TonyM | Aug, 2022

Using GUIs, USB connections, and Kubernetes

Photo by Gabriel Heinzer on Unsplash

As you may know from my previous posts, I tend to use a lot of development environments and play with quite a few different technologies. I write code on Linux, Windows, and Mac in various languages, mostly C/C++ with SYCL, Golang, Python, JavaScript, and Java. I also use technologies like Kubernetes and dabble with AI technologies like TensorFlow, PyTorch, and Intel Distribution of OpenVINO.

I’m always interested in simplifying cross-platform development because the one thing any of us never have enough of is time. In this post, I will outline some of my quick experiences with the Windows Subsystem for Linux (WSL). The short of it is it mostly works great, sometimes we can use workarounds to make it work reasonably well, and sometimes we may need to boot into Linux.

Before we go too far, I would recommend if you are using WSL on Windows that you get the latest version from the Microsoft Store, as it did fix some issues for me related to CMake usage and some other weird behavior. Just search WSL and install the Windows Subsystem for Linux Preview below.

I found it odd it wasn’t at the top, but if you scroll down a bit, you’ll find it. Quick tip, I had to recreate my WSL environment for the changes to work for me.

Assuming you haven’t set up a WSL environment after this, you can follow any WSL setup tutorial (some links to those below). For reference, the systems I’m using for this post:

  • HP Envy 16 laptop with Intel Alder Lake Core i7-12700H, 32GB DDR4, Intel Arc a370m GPU, Windows 11 Pro
  • Alienware R13 with Intel Alder Lake Core i9–12900KF, 64GB DD5, NVIDIA GeForce 3080Ti GPU, Windows 11 Pro

The Basics

If you are just writing command line code, scripts, or using something like a Jupyter notebook it works great. My C++, Python, and Golang codes compile and run just like they would be on Linux. Conda, Tensorflow, and PyTorch all install and work.

If you want to use some simple tools, here are some links that might help you get started:

Setting up WSL, VSCode, and Intel oneAPI Base Toolkit

Setting up Docker

Setting up a Jupyter Notebook

GPGPU programming on an Intel Arc GPU

Kubernetes (for small systems)

I’ve used K3s and MicroK8s in the past, but I was not confident this would work right out of the box. I was extremely pleased that installing K3s on a WSL using 20.04 Ubuntu was as simple as it is on Linux.

  1. make sure systemd is configured in WSL
  2. Install K3s from and runningsudo k3s server
  3. Install kubectl usingsudo apt get kubectl
  4. make sure the kubeconfig/etc/rancher/k3s/k3s.yamlis usable by kubectl
Working K3s in less than 10 minutes

This is a small subset of what developers need, and I won’t be able to cover everything that works well, but for most things, WSL is overwhelmingly easy to use.


WSL2 is a huge step forward over the original WSL since it added support for GUIs. For some things I tested, it just worked out of the box. For example, creating a simple OpenGL window and rendering a simple scene works great. The only issue I ran into was that the highest OpenGL version supported by the WSL DirectX layer is 3.3.

WSL supported OpenGL version

My second test was to see if our Intel tools with a GUI would work. When I tried to run the Intel VTune Profiler GUI, I ran into this issue:

tonym@HPEnvy:~$ vtune-gui
vtune-gui: error while loading shared libraries: cannot open shared object file: No such file or directory

After installing some libraries, I realized the reason for the issue was that the application was expecting GTK+ to be installed on the system. The following commands allowed me to run the Intel VTune Profiler GUI within WSL:

> sudo apt install libnss3-dev
> sudo apt install libatk1.0–0
> sudo apt install libatk-bridge2.0–0
> sudo apt-get install libgtk-3-dev
Intel VTune Profiler GUI running!

The great thing about doing this via WSL is now I can use the GUI to target my Linux application on my WSL file system and run my workload.

To be fair, this last issue is not a limitation of WSL. Unfortunately, it is a very common problem you may run into where Linux GUI developers assume certain platform libraries exist for their applications.

When I went to do some testing using a USB device, the simple workflow of hooking up my device to the machine didn’t work initially. Of course, this makes a lot of sense as this requires mapping the connection through the virtual machine layer.

Fortunately, there is a way to enable a USB-connected device using the USB/IP open source project. Microsoft has documented the requirements and how to set up this library for WSL, which allowed me to interface with devices. Nice to have easy solutions to common problems!

If you require a corporate VPN for work, it can be very tricky to connect your WSL instance to the internet while using the VPN. There are a few workarounds, but the official, unofficial workaround can be found here.

K3s with GPU support

Fortunately for me, there is only one thing I tried that did not work, and it is possible I just don’t know how to set it up correctly. The culprit is running Kubernetes with GPU support. I did find some resources that suggested you might be able to make it run, but I was not able to get it working.

WSL and Docker (or other container runtimes) work great out of the box. The only use case I have for this is really niche; if you want to run a GPU-enabled container workflow but want to do it via K3s instead of another container runtime. This probably does not make sense unless you are doing some Kubernetes development or trying to leverage some Kubernetes deployment.

As far as I understand, WSL uses its DirectX Linux driver to interface with the underlying GPUs, and that might be able to be exposed to Kubernetes. I didn’t find an easy way to do it. Unfortunately, my use case was even narrower; I was messing with implementing a particular Kubernetes device plugin.

At the end of the day, I ended up just firing up Linux on the systems when I needed to do this.

WSL works great for about 95% of what I do, and although I have Linux installed on all my systems, I very rarely have to boot into native Linux. This saves me a significant amount of time when doing cross-platform development, which is great so I don’t have to waste half my day staring at my BIOS boot screen.

It also has some extra benefits like letting me run some of my cross-platform enabled tools, like Python, on the OS I’d prefer. It seems like a minor thing, but I like typingls instead of dir for some reason. All-in-all, I consider WSL a huge win for my productivity, and I’m guessing if you’re reading this, you probably agree (or you want to get to a point where you agree 😊).

Want to Connect?If you want to see what random tech news I’m reading, you can visit me on Twitter.

Leave a Comment