What is involved in a WSL "distribution"?

Some other answers here have focused on the "normal" meaning of a "Linux distribution", which is certainly useful to understand as background for your question. But you are asking about it specifically in the context of WSL.

what difference does it make which distribution you choose?

Let me answer that part of your question first, before we get into the "differences" regarding distributions on WSL. The main differences in Linux distributions are going to be (focusing primarily on the WSL/developer needs here):

• Versions of applications available in the default repositories. There are (to over-summarize) typically two types of distributions that you will find:

  • "Stable" distributions, which tend to update very infrequently (other than security updates) but focus on making sure (to the best of their ability) that all packages work together well and don't break the system. Ubuntu, Debian, and Red Hat are good examples of these.

    Ubuntu, for example, has one release every 6 months. But only every two years (in April of even numbered years) is it updated with a long-term support (LTS) version (e.g. 22.04 LTS), which is supported for 5 years.

  • "Rolling-release" distributions, which focus on getting new releases of software into their repositories as soon as they are considered stable and tested. Arch and Kali are common examples of these.

  openSUSE, as another example, has distribution releases for each model, and both are available as Microsoft Store installs for WSL. If you search the Store for openSUSE, you'll find both "Leap" releases (stable) and "Tumbleweed" (rolling).

  Whether you choose a Stable or Rolling release is really up to you. I keep both around, personally. There's no reason at all on WSL to limit yourself to just one distribution (other than disk space). I've used Tumbleweed as my rolling release for a while, with the latest LTS of Ubuntu as my stable. However, I've been impressed with Artix as a rolling release (based on Arch) and am probably going to be trying it as my daily-rolling-driver for a while.

  Also note that, as a developer (from the fact that you posted this first on Stack Overflow, as well as your profile there), it may not matter quite as much for you based on the languages and tools you use. You appear to do a lot of Node-based/React/web/framework development from your SO tags. Under WSL (or any Linux distribution), you're unlikely to use the pre-packaged, repository version of Node.js anyway. You're going to install via nvm or n. Then, of course, you'll install packages/modules via npm, yarn (or other).

  And even for languages which are critical to the system and shouldn't be changed (e.g. it's a bad idea to change the Python version in a Linux distribution), you can use Docker or other virtualization/container technologies to use different language versions on WSL, regardless of the distribution. (More reading on that topic - See my recent answer regarding Docker Python on the Ask Ubuntu question How do I install a different Python version using apt-get?).

  So, as a developer, if you don't have any non-developer reasons to go with a rolling release, a stable-style distribution might make your life easier in the long run.

• Availability of documentation and support is another good reason to choose a distribution. It's on this basis that I simply have to recommend Ubuntu to most new WSL users (and it is, as you mention, now the default WSL distribution). Most blogs, videos, or other instructional documentation that you find are going to focus on how to do things in Ubuntu. This may be shifting somewhat to Arch, but for now I think the advantage in this camp still goes to Ubuntu.

  That's not to say that you can blindly follow any Ubuntu (or any distribution) documentation and have it work on WSL. There are a number of differences in WSL that mean you often need to tweak the instructions somewhat. Some of those differences are covered below, but I try to maintain a more complete list in this Ask Ubuntu answer.

  On the flip side, note that Kali is an advanced distribution, even when not in WSL. See the excellent meta post here, If you need to ask, then Kali Linux is not the right distribution for you.

So what is the relevance of distribution in this [the WSL] context

In WSL, the word "Distribution" is actually a bit overloaded, with several meanings, as well as some important differences from the "normal" definition of Linux distribution:

• First, a WSL distribution, at its core, is simply a packaged root filesystem. It can include something as simple as a single statically linked executable (like BusyBox) or a complex ecosystem of packages, scripts, and package management (like Ubuntu or Arch).

  That package can be a:

  • tar or tar.gz
  • A Hyper-V virtual disk image (vhd or vhdx) in the latest WSL Preview releases.

  But really, as long as you can package your files in one of those two forms, you can, at least wsl --import the package into a WSL distribution. There are some convenient (and presumably tested) distributions available to install from the Microsoft Store into WSL, but they ultimately package an install.tar.gz which then gets installed into WSL.

  WSL's packaging has the added advantage that it is really easy to convert any software for which there is a Docker image to a WSL "distribution". Just docker pull ..., docker run ..., and docker export ... to create a tarball. Want a Red Hat image that isn't in the Microsoft Store, just grab the appropriate Docker image. BusyBox? Same. Etc.

  To be a "bootable" distribution, however, you do need a minimum of:

  • An /etc/passwd with one or more users.
  • The shell defined for the primary user, which becomes the default entry point.
  • If the user is not root, then you either need a /etc/wsl.conf defining the default user (see here) or a registry entry.

• A "normal" Linux distribution also typically provides a default:

  • Init system
  • Kernel with drivers
  • Bootloader (typically GRUB2)
  • X and/or Wayland server

  None of that is needed or utilized in WSL. WSL provides its own kernel. While (in WSL2 at least) you can build your own (from standard kernel sources) and replace it, a single kernel is shared among all distributions that you have installed on your Windows/WSL system. In WSL1, this is a pseudo-kernel that does syscall translations from Linux to Windows. In WSL2, it is a real Linux kernel running in a managed (as in, you can't typically see it, access it, or change it) Hyper-V virtual machine.

  WSL also provides its own init system, which handles the interoperability between WSL/Linux and the Windows layer (such as networking, the ability to execute Windows binaries through binfmt_misc, WSLg boot, and more).

  This can be problematic, since WSL does not run the standard init for most Linux distributions. For instance, even though Ubuntu/Debian/Arch (pretty much everyone other than some niche distros) runs Systemd, WSL does not enable it, even when running one of those "distributions". See my explanations here and here.

  And while Systemd is, of course, the dominant init system, it is more problematic than most other init systems under WSL since both WSL's init and Systemd vie to be PID1. Systemd will flat out refuse to run as anything but PID1 (and WSL2 won't let it, without using namespaces as a workaround). Some other inits / process managers can run as non-PID1, so are more (IMHO) suitable for use under WSL. I've had good success with Artix and Dinit, for instance. And as a plain-vanilla process manager, Supervisord works reasonably well under most any distribution.

• A WSL "Distribution" can also mean the "instance" or "container" that is created from the imported package. Running wsl -l -v will list the installed distributions on your system.

  When you run one of these, at least under WSL2, what is running is essentially a container (isolated namespace) for the package you imported.

• A Linux distribution also often comes with a default Desktop environment (e.g. Gnome, KDE Plasma, Xfce, others) as well as (as you mention) theming. While it's possible to run a desktop environment from your a distro in WSL, it's not a standard process. In Windows 11, WSL can run Linux GUI applications through the use of the WSLg feature, but that's for running individual Linux applications integrated into the Windows desktop.

  Running a Linux desktop environment can be done (either through third-party X server, WSLg full-screen Weston/Xwayland, or XRDP) but (with the exception of XRDP) you'll need to make sure that keybindings for things like Alt+Tab are changed so that they don't get intercepted by Windows built-in functionality.

In a broad term, the difference in distributions is a difference in skin. The different graphic interfaces is just a special case of it. Primarily, there are two major differences between any two distributives:

1. what is included inside the repository and what is not included;
2. what are defaults for the basic tools.

The example for the first could be a version of libraries or applications. Once developer make a new version - the maintainer of the distributive should download it, compile, and publish in the repository. If the maintainer (who is a real person) is expecting a lot of bugs in the new version of the application - he can skip that version. But the maintainer of another distributive will publish it as is and allow regular users to complain about bugs directly to developers.

For the second: in Ubuntu, the sudo is checking the group wheel for the list of users who is allowed to use sudo. In Fedora, that group is named sudo. That difference is built into the tool sudo during its compilation before it is put in repository as one of the basic tools.

And please do not forget, that the terminal is also a UI. Just not graphical. And there too could be differences. For example: in Ubuntu, you are using apt to install new applications from its repository, but in Fedora you are using dnf for the same task. That can be viewed as different UI choices. They have the very same purpose and almost the very same abilities and limitations. Just different set of command line keys and are working with packages of different structure.

With a good understanding of OS structure it is possible to ignore which distributive you installed and mix different approaches from different distros. You can recompile sudo yourself and define its special group as admins for example. Or you can install dnf on Ubuntu (or apt on Fedora) and download applications from both repositories, you would probably have to adjust some settings of the downloaded application afterwards, but it is possible. And of course, you can always download some application/library as a source code, and compile it yourself, and share the compiled version - that would become you own distributive.

That apply to both - normal setup of OS and a WSL one.

The distribution is the collection of software, which not only influences look and feel, but also availability of packages and maintainance thereof. A package you want to use may not be available on some distribution.

If you installed ubuntu via WSL you have to take care of updating the packages like on a VM ( apt update + apt upgrade). Some other distributions may be faster or slower at providing patches (or maintaining packages at all).

I'm not entirely sure if this is "the" answer to your question, but different distros can have different kernel requirements at a given point in time, causing WSL1 compatibility to differ across distros.

As a practical example, Arch Linux suffered from the "kernel too old" problem for a while due to a change in glibc-2.33-4, whereas Ubuntu didn't.
However, this issue also came up on Arch containers on CentOS, so it was not specific to WSL1 per se. But practically speaking it meant you would have more difficulty getting Arch running on WSL1.