Are there any limitations in working in Ubuntu in Windows Subsystem for Linux on Windows 10?

Question

Are all of Ubuntu's capabilities including support for GUI applications available in the latest version of Windows Subsystem for Linux installation of Ubuntu or are there any limitations in working in Ubuntu in Windows Subsystem for Linux on Windows 10?

Answer 1

The limitations Ubuntu in Windows Subsystem for Linux on Windows 10 are less and less over time and changing from being limitations due to missing functionality in WSL to limitations due to Ubuntu's learning curve.

---

Windows Subsystem for Linux (WSL) allows you to run Linux software on a Windows 10/11 PC. With WSL enabled, Windows can run a distribution of Linux at the same time. Microsoft allows you to enable WSL on all major versions of Windows 11, meaning you don't need to upgrade from Windows 11 Home to Pro to use it. Windows 11 uses WSL 2.0, an upgraded version of WSL designed to run a full Linux kernel in a Hyper-V environment. ^source

---

Integration between Windows and Linux

The Windows Subsystem for Linux (WSL) is continuously improving integration between Windows and Linux. You can:

• Run Windows tools (i.e. notepad.exe) from a Linux command line (i.e. Ubuntu).
• Run Linux tools (i.e. grep) from a Windows command line (i.e. PowerShell).
• Share environment variables between Linux and Windows. (Build 17063+)

Run Linux binaries from the Windows Command Prompt (CMD) or PowerShell using wsl <command> (or wsl.exe <command> ). Binaries invoked in this way:

• Use the same working directory as the current CMD or PowerShell prompt.
• Run as the WSL default user.
• Have the same Windows administrative rights as the calling process and terminal.

The Linux command following wsl (or wsl.exe) is handled like any command run in WSL. Things such as sudo, piping, and file redirection work. ^source

Mount ext4 filesystems

Starting with Windows Insiders preview build 20211, WSL 2 will be offering a new feature: wsl --mount. This new parameter allows a physical disk to be attached and mounted inside WSL 2, which enables you to access filesystems such as ext4 that aren't natively supported by Windows from Windows File Manager and PowerShell.

GPU Compute, WSL Install and WSL Update arrive in latest Insider build for WSL 2

GPU support for WSL arrived in the Dev Channel preview of Windows 10 build 20150 under Microsoft's reorganized testing structure, which lets it test Windows 10 builds that aren't tied to a specific future feature release. Microsoft announced upcoming GPU support for WSL a few weeks ago at Build 2020, along with support for running Linux GUI apps. The move on GPU access for WSL is intended to bring the performance of applications running in WSL2 up to par with those running on Windows. GPU compute support is the feature most requested by WSL users, according to Microsoft. The 20150 update includes support for Nvidia's CUDA parallel computing platform and GPUs, as well as GPUs from AMD and Intel. It also supports DirectML (Direct Machine Learning), Microsoft's Windows 10 API for hardware-accelerated machine learning. ^Slashdot

---

What's coming to WSL

Install WSL with a single command

One common complaint about WSL is that it's not easy to find and enable. Microsoft is working on some improvements to the wsl.exe command-line tool to help you install WSL. Soon you will be able to simply install WSL by entering: wsl.exe --install in your command-line.

This command will be added to every Windows machine so that all you need to do is open a Terminal window elevated with administrator privileges and run wsl.exe --install. From there the WSL optional components will be enabled, and your specified distro will be downloaded and installed for you automatically upon restart.

You can expect to see initial releases of this feature in the next few months in the Windows Insiders Fast Ring.

WSL 2 will be the new default when installing for the first time

We're also introducing the change to make WSL 2 the new default distribution type when installing WSL for the first time. WSL 2 brings significant improvements and we found that the majority of our users on Insider branches are using WSL 2 distros. When developing wsl.exe --install it made sense for it to default to what people are using: WSL 2, and we've included this as well for any new installations of WSL when enabling the 'Windows Subsystem for Linux' optional component. You'll see these changes in the Insiders Fast ring in the next few months alongside the wsl.exe --install improvement.

WSL will support GPU Compute workflows

Adding CUDA and/or GPU Compute support to WSL has been our #1 most requested feature since our first release! Over the last 3+ years, the WSL, Virtualization, DirectX, Windows Driver teams, and our silicon partners have been working hard on a complex engineering feat to deliver this capability.

This is why we're thrilled to announce that we will start previewing GPU compute support for WSL in Windows 10 Insider builds within the next few months.

Initially, the GPU compute capability will support two scenarios:

• NVIDIA CUDA
  • Supports existing Linux tools & workflows used by professionals
• DirectML
  • Initially targeting beginners and students, leveraging DirectX 12 capable GPUs from several vendors
  • The team will be releasing a preview package of TensorFlow with a DirectML back-end enabling hardware agnostic acceleration of AI & ML workloads across the breadth of Windows hardware – DirectML will also support native Windows too, including TensorFlow on Windows.

Once this preview is released, you will simply need to ensure that you have the latest Windows Insider Fast build, WSL 2 installed, install the correct driver for your GPU from the hardware vendor, and then you'll be ready to start developing, training and testing your machine learning and AI models inside of WSL.

This change will be released to the Windows Insiders Fast ring in the next few months. For all the details of what this change means and how it was made possible, please read the DirectX Developer blog post.

Adding Linux GUI app support to WSL is on our roadmap

Microsoft is making the promised support for Linux graphical user interface (GUI) apps on Windows 10 available to customers as of the next Windows 10 release, officials said on May 25.

One of our other most prolific requests is to support not just command-line apps, but Linux GUI apps as well. For example, some users want to run their preferred Linux GUI text editor or IDE in a Linux environment and work on their code stored locally within their distro's filesystem, or simply develop Linux GUI apps on their Windows machine.

Our goal is for you to be able to run Linux GUI apps on your desktop seamlessly alongside your Windows apps. This will enable you to use Linux apps to edit, build, and run your code, visualize data plots in Python, or even use applications that are optimized for a Linux environment.

At BUILD we demonstrated an early version of this work, running a few GUI sample apps directly from WSL such as Eye of Gnome, gedit and the mpv media player. These apps connected to a wayland server running inside of WSL, which communicated with a RDP client on the Windows host. You can see a screenshot of this in action below where we're running the GNOME file manager in WSL and Outlook side by side.

These changes are on the WSL's team roadmap and you can expect to hear more about this work by the end of 2020, at which time this answer will be updated.

_{Source: The Windows Subsystem for Linux BUILD 2020 Summary}

Answer 2

_{Note: It's come to my attention that this question is really a duplicate of the much earlier (and active) What can't I do with the Ubuntu application for Microsoft Windows?. While I'll leave this answer here in it's current form, please refer to my answer on that other question for any updates.}

---

I'm a fairly big WSL fan, but I'll be the first to acknowledge that there are quite a few limitations when it comes to WSL. Fortunately, most of these have workarounds, but they do catch most new users off guard.

To start with, let me just lay out some "differences" between Ubuntu on WSL and a traditional Ubuntu installation on a VM or physical machine. I'll reference some of these in the "limitations" section below:

1. WSL1 runs as a "syscall translation layer" that attempts to translate Linux kernel API's into those of the Windows kernel.

2. Ubuntu running in WSL2 acts more like a container. It is running under a real Linux kernel in a virtual machine (that you can't access). Ubuntu is running inside a namespace in that VM. It is not, itself, directly running in a VM.

3. WSL has its own init system. It's main job (other than some "normal" Linux init tasks) is to set up the interoperability between Linux and Windows. For instance, it:

   • makes the Windows network available to Ubuntu
   • adds the Windows path to the environment
   • mounts Windows drives into Ubuntu

4. That init runs as PID1 inside the Ubuntu WSL instance/namespace/container.

5. Starting WSL is not like booting a virtual or physical machine. Many of the tasks that Ubuntu would normally (typically through Systemd) do during boot are either not needed for WSL or are actually harmful to its normal operation.

6. There is no concept of a "login" when starting WSL. WSL detects the default user and automatically starts the shell defined for that user in /etc/passwd. No password is requested or needed.

Limitations of WSL

With that in mind, here are some limitations that I can think of:

• init/Systemd: Ubuntu running in WSL does not use Systemd. Systemd requires that it be running as PID1, but WSL's init runs as PID1. Many docs, blog posts, etc. that you come across for various tasks (e.g. installing Docker) will assume that Systemd is available. There are several workarounds that I mention in this answer.

  Further, software packages that are deeply ingrained with and rely on Systemd just won't function unless you resort to the namespace hack mentioned in that answer. Gnome is one of the more common examples.

  As another personal example, I was trying to run cockpit (for a web-interface to libvirtd) in a non-Systemd distribution a few days ago, and I just could not find any way to work around its reliance on Systemd.

  This is certainly one of the top areas of confusion for new users coming to Ubuntu on WSL.

• Running Systemd on WSL2: Related to the previous items, if you do attempt to use Systemd, the default Systemd boot process on Ubuntu (and pretty much any distribution) makes some assumptions that aren't valid on WSL. For instance:

  • Systemd will erase files in /tmp, but at that point in the startup, WSL has already created a symlink there for the well-known X11 socket under Windows 11.

  • Systemd will set up some binfmt_misc handlers, overwriting the WSL handler that allows you to run Windows binaries under WSL.

  • Systemd will redefine the user environment, overwriting the Windows path that was appended to it.

  If you are planning on running Systemd (even with a "helper" script), I strongly encourage you to keep in mind that it could interfere with other Ubuntu operations under WSL and plan to troubleshoot if and when it happens.

• Access to physical hardware: On WSL, you will have limited access to hardware:

  • Serial ports: WSL1 has access to serial ports at some level, but only as far as the syscall implementations go. That said, it's possible to run some software on WSL1 that utilizes the serial ports that is not possible on WSL2.

  • Physical drives: Under Windows 10, you can only mount drives via a network protocol or physical drives that are connected to Windows and formatted NTFS. Raw drives and those using other filesystems cannot be mounted.

    WSL2 under Windows 11 does have the ability to mount additional drive types.

  • Graphics: Under Windows 10, there is no direct access from Ubuntu on WSl to any graphical application or interface. If you want to run a graphical Linux app in Ubuntu on WSL, you must install a third-party X server in Windows and run the X client/application in WSL with the appropriate DISPLAY settings. See this answer and this answer for more details.

    Again, under Windows 11, WSL2 now has the ability to run graphical apps out-of-the-box.

  • GPU: Similarly, under Windows 10, there is no access to the physical GPU, so GPU-compute tasks are not possible.

    Windows 11 also improves on this, providing a number of GPU-compute tasks that can passthrough to the physical GPU using the Windows driver.

  • USB: USB devices are not directly accessible. However, under WSL2 (both in Windows 10 and 11), they can be shared from Windows using USB/IP and then attached in Ubuntu.

    Note that the stock WSL2 kernel does not include most device drivers for USB devices. For instance, even the basic media capture (i.e. camera) drivers are not included. However, you can build your own kernel for WSL2 and include the necessary drivers. However, note that currently, I (and others) have not succeeded in capturing video from a USB camera in WSL. See this question on Stack Overflow for the progress-to-date.

• Ubuntu boot device: The primary boot virtual disk/partition for Ubuntu in WSL must be formatted ext4. Although the WSL2 kernel supports additional filesystems such as btrfs, they can only be used for secondary partitions.

• Tasks that rely on authentication/login: Due to (6) above, certain tasks that rely on authentication will behave differently on WSL. For instance, normally you would edit /etc/security/limits.conf to raise the limits (e.g. number of open files, priority/nice, etc.) for a user. However, this is a file that is handled by PAM (the "pluggable authentication module") during user login. Without an authenticated login, this file is never processed. See workaround in this answer if you come across this.

• Startup services:

  • Windows 10: Without Systemd (or another init) to rely on, there's no easy way to define what services should run by default in a WSL instance. For instance, the cron daemon won't be running (the source of this question). The workaround is to check and see if a service is running in your shell startup (e.g. ~/.bashrc) and start it if not. See this answer for more details.

  • Windows 11: Now at least includes the ability to run tasks at startup. Also see the same answer for details. However, I might recommend that you start a process supervisor as your main tasks using this method, then use the process supervisor to start and manage other needed tasks. I mention how to do this in this Stack Overflow answer using supervisord, but any process supervisor (that doesn't require that it be PID1, of course) will work.

• Networking: While this might belong under the "hardware" section, it probably deserves its own callout here. WSL2's network currently runs under a virtual switch inside Hyper-V, and that switch is NAT'd from the rest of the network. This means that you cannot easily access network services in WSL2 from other devices (computers, phones, etc.) on the local network without additional effort.

  The easiest workaround is to use WSL1 for this when possible. There are multiple other workarounds as well.

• VPNs: Likewise, when connecting to certain VPN's which disable local traffic, WSL2 will lose networking, since it is "local" (but not localhost) network traffic.

• Performance: In general, performance under WSL2 is pretty good. However, there are a few caveats:

  • WSL1: WSL1 has slightly reduced performance on its "pseudo-ext4/overlay" filesystem. However, WSL2 achieves near-native performance on ext4 filesystems.

  • WSL2: WSL2 takes a huge performance hit when accessing files on Windows drives, especially multiple, small files. Checking out the WSL2 kernel on an NTFS drive takes over 10 minutes (but ~30 seconds otherwise). It is highly recommended that you keep project files on the ext4 filesystem or use WSL1 when accessing Windows drives.

  I keep a WSL1 instance around primarily for the purpose of working with Windows drives when needed.

I'm sure I'll remember some more (or perhaps someone will point them out in the comments), and I'll add them in if needed.

Again, with the workarounds mentioned, most of these are not serious blockers for most WSL users. However, they are the source of many questions that I've answered across the Stack Exchange sites.