As most of you know, in the Microsoft Store, there are three versions of Ubuntu. This means that on Windows I can emulate Ubuntu and have the Ubuntu command line directly on Windows.

The question is very easy: what can’t I do from the Ubuntu command line emulated in Windows that I can do on a proper Linux-based Ubuntu? Is it useful to download this Ubuntu application, install it, and work just with it instead of the real OS? Is it possible to install all the development libraries? Can I write (or not) device drivers? In other words: what are the limits?

What features of Ubuntu Linux-based are missing from Ubuntu-on-Windows?

New answers are welcome: I know that every software is always changing by improving characteristics and features!

  • If you've booted into Windows, perhaps for gaming, it's nice to have Ubuntu 16.04 installed there when you are on micro-breaks, reading Ubuntu Q&A's here and want to quickly check some commands out without rebooting. If you want the limitations of Ubuntu on Windows your best bet is to go to Microsoft's website and read all the new feature requests or bugs users have posted: docs.microsoft.com/en-us/windows/wsl/faq Jul 2, 2018 at 15:21
  • 1
    WSL is still quite a lot slower in terms of I/O (disk operations), even compared to Linux virtual machines running on Windows. Though, this seems to be an area worked on by Microsoft.
    – liori
    Jul 2, 2018 at 22:23
  • @jpaugh, exactly, thanks! I have also just updated the question again :)
    – Leos313
    Jul 3, 2018 at 10:40

6 Answers 6


The Ubuntu that runs under Windows 10 Subsystem for Linux is not a full distro. In fact, it's not Linux at all -- it has no Linux kernel. So you can't test or try kernel extensions, including drivers, because you're not running Linux.

If you want to do stuff like that, either install Ubuntu in a VM -- Win10 includes Hyper-V, but personally, I prefer VirtualBox, which is free -- or dual-boot your machine with Ubuntu running on the bare metal. You will almost certainly find the latter faster than running Windows -- I do on all my machines. Partly this is because you need antivirus protection when running Windows, which saps performance, especially disk performance. And because you need it, Win10 includes built-in antivirus.

With Linux, you do not need any, so there is less performance impact.

  • 21
    Why do you think that you do not need antivirus on Linux?
    – user351871
    Jul 2, 2018 at 15:38
  • 7
    @SeligkeitIstInGott It's not an emulator. It's a compatibility layer, just like for Wine on Linux. Jul 2, 2018 at 17:19
  • 6
    "With Linux, you do not need any [antivirus], so there is less performance impact." -- Linux is not immune to viruses/malware/etc. Antivirus SW is useful in Linux both to protect yourself and to prevent bad stuff from spreading to other environments (e.g. Windows). I know it is not normally used, but that doesn't mean the threat doesn't exist.
    – Daniel
    Jul 2, 2018 at 23:35
  • 5
    I have issue with this. 1. Antivirus is not "required" to run windows. The windows operating system will run without an antivirus. It also comes with an antivirus, which leads to point 2: picking random software to point at as "slowing down the OS" seems arbitrary - what if I argued that ubuntu was slower because I needed a bunch of extra software to get apps working that only work in Windows? (like a VM so I could play AAA games?). 3. You have provided no evidence to support this claim.
    – Caleb Jay
    Jul 2, 2018 at 23:40
  • 6
    @Hack-R There is no deception. They have been quite clear from the beginning that this is not the actual Linux kernel. It started off as "running Linux tools, especially Bash" to "running Linux environments/distributions/applications". If any of that is deceptive, so is WINE.
    – Bob
    Jul 3, 2018 at 1:48

There are many useful pieces of information on each of the above answers. I am here summarizing the main concepts of each of them.

Update April 2020: Pro and cons in using WSL are here explained. There is clear why having a real Linux kernel is an advantage!! Additionally, here there is a guide to install WSL 2 onto your Windows 10. If you have installed the WSL 1 and you want to pass to WSL 2, here you can find the instruction for doing it.

Update August 2019: The new WSL 2 was released (read here for more information). It seems that you can work with a real Linux kernel and with a Linux file system. Honestly, I haven't tried the new version so far (it is on my TODO list).

Update May 2019: as pointed out in one of the most recent answers, WSL is evolving by using the real Linux Kernel and giving many more options. I have been through this document and, if confirmed, it will be a big step forward. Here you can find a nice article about the topic "real Linux kernel on W10"

Answer July 2018 Summarizing: "Ubuntu on windows is the complete Ubuntu userland on top of a Windows kernel in Linux-Compatibility mode", as point out in one of the comments.

What I can't do:

  • Officially, no graphics interface supported so far. This means also that graphics applications cannot be executed. Additionally, the standard GUIs of the classic Ubuntu Linux-based are not supported for this reason of course.
  • The kernel of Linux developed by Linus is NOT part of the Windows Subsystem for Linux (WSL). This means that you cannot develop drivers and try it directly.
  • Not every command line works.

What I can do:

  • Use the command line and the basic Bash shell. It is possible to write and execute scripts.
  • Develop applications (compile or cross-compile and execute them) but with no graphics so far.
  • Use "apt-get" to install/remove new/old packets.

Additional information:

  • other distributions are officially supported (like, for example, Debian and Kali)
  • these applications are free, downloadable from the Windows Store and here you can find the instruction to install and use it.

  • In this other question of the blog, some suggestion on how to use a GUI for WSL (unofficial, third party)


One of the things you cannot easily do under the Windows Subsystem for Linux (WSL) is run Linux GUI applications.

To do so you have to install an unsupported X11 server such as VcXsrv or Xming.

Enabling WSL is relatively trivial. It seems to be pretty good as a Linux command-line userland.

  • I wouldn't call VcXsrv unsupported. They've released about 10 updates since I've been using it (October 2017). Jul 2, 2018 at 17:19
  • 1
    @WinEunuuchs2Unix: I meant unsupported by Miscrosoft, in the sense in which they support WSL by implementing the kernel API, distributing the Ubuntu userland, providing tools to install/enable WSl and so on. Jul 2, 2018 at 19:04

From How-To Geek:

[It] doesn’t yet support background server software, and it won’t officially work with graphical Linux desktop applications. Not every command-line application works, either, as the feature isn’t perfect.

Update from allquixotic's comment:

As of Windows 10 v1803 background tasks are supported.

  • 6
    As of Windows 10 v1803 background tasks are supported. Jul 3, 2018 at 1:46
  • 1
    It might be helpful to point out "background tasks" = crontab and other daemons. Here is a practical example of loading crontab when Windows boots up. Then using rsync every 2 days to backup Windows database: blog.snowme34.com/post/… May 7, 2019 at 11:24

As of May 2019, WSL 2 is under development.

Dramatic file system performance increases, and full system call compatibility, meaning you can run more Linux apps in WSL 2 such as Docker.


WSL 2 uses an entirely new architecture that uses a real Linux kernel.


Initial builds of WSL 2 will be available through the Windows insider program by the end of June 2019.

(emphasis mine)


When this question was first written, neither WSL2 nor WSLg had been released, so the answer today is certainly different than it was a few years ago. Some of that info has been updated in answers here, but I feel there's a lot missing in other answers here around actual "limitations".

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 managed 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. Its 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 PID 1 inside the Ubuntu WSL instance/namespace/container, unless you enable Systemd support, in which case Systemd becomes PID 1.

  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:

    Out of the box, WSL still does not have Systemd enabled, but it is available, and now works on both Windows 10 and Windows 11. Many docs, blog posts, etc. that you come across for various tasks (e.g. installing Docker) will assume that Systemd is enabled, so you'll need to either make sure that it is or learn how to adapt without it.

    There were quite a few other Systemd-related limitations in this section, but they have been removed based on recent WSL improvements.

  • 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: Older versions of WSL lacked the ability to access physical drives, but recent WSL releases now do include the ability to mount physical drives, as long as they aren't in use by Windows.

    However, USB mass storage devices are not directly supported unless you use a special kernel.

    • Graphics: This used to be more of a limitation, but WSL 1.0.0 added support for GUI applications with WSLg (for both Windows 10 and 11). This support is through Wayland/XWayland/Weston running with an RDP backend. Of course, there still isn't any direct access from X to the physical hardware, so there are some things that don't work just like their "pure" Ubuntu equivalent.

    One of the most common is in running desktop environments. You'll find several question and answers here on Ask Ubuntu around this topic.

    • GPU: Under recent Windows 10 versions, some GPU Compute tasks are available using a passthrough library and the Windows GPU drivers.

      Under Windows 11, some additional GPU Compute tasks have been added.

    • 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, though, 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.

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

  • Pen-testing: Some penetration testing tasks simply won't work under with WSL1 (because of the limited syscall translations) nor WSL2 (because hardware is virtualized). Two areas stand out here:

    • Direct access to the wifi interface is not available (only a virtual ethernet device), so WLAN password cracking techniques will not work. As a workaround, it should be possible to install a secondary USB WiFi dongle, pass it through via USB/IP as discussed above, and use it inside WSL2. Note that you will need to build your own kernel with the appropriate drivers for the network dongle.

    • Because WSL2 is on a separate layer 2 network than your Windows host (and the rest of your network), it won't be possible to do any layer 2 scanning. The above USB/IP workaround should work for this as well.

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

  • +1, nothing more to say
    – Leos313
    Sep 5, 2022 at 14:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .