Software engineers have a never-ending debate about which operating system is the best for their work. Windows, MacOS, and Linux all have their dedicated user base, with each system offering different features and benefits. However, when developers work in teams with different OS preferences, it can create problems with compatibility issues. In this article, we'll discuss how Microsoft's WSL2 has addressed these issues and how it has become a preferred option over virtual machines for developers.
OS Stereotypes
If you've ever worked in software engineering, you know that operating system preferences can be a hot topic. It's like a turf war between developers, each one waving the flag of their favorite OS. Here’s my take on the three types of people in the workspace:
- The Linux guy/girl, always the senior software engineer, who swears by the flexibility and customization of the operating system. They know that Linux is known for its robust security features, making it a hacker's worst nightmare.
- The Apple enthusiast, who praises the MacBook as if it were their child. They love the Unix-based macOS and its slick interface, even if it is closed-source.
- The non-technical people, who just use Windows because it's what they know. They get excited about all the corporate software like Teams, Outlook, and Office that are readily available.
Compatibility Issues
But what happens when these three worlds collide? That's when the real trouble begins. The Linux guy/girl can't get the microphone to work on the Microsoft Teams app they installed on their Linux distro. The Apple enthusiast tries to use a Linux command on their MacBook and ends up getting a "not found" error message. These compatibility issues can quickly turn a productive day into a frustrating one.
Virtual Machines
A common solution is for developers to use virtual machines on their Windows computers, through software like VirtualBox. Virtual machines were clunky and time-consuming to set up. You had to allocate certain resources like RAM and disk storage for each virtual machine. If you wanted to use two different Linux distributions, that would mean you’d have to assign RAM and disk storage twice, once for each distribution. Starting the virtual machine wasn’t a easy neither, as it came with the overhead of a hypervisor.
WSL1
In 2016, Microsoft introduced WSL1, a response to the growing number of developers using Linux as their primary development environment. WSL1 was a significant step forward for developers who wanted to use Linux binaries on a Windows machine without the need for a virtual machine. It worked by translating Linux system calls into Windows system calls, which made it possible to run Linux binaries on Windows without needing to modify them.
However, WSL1 had some limitations that made it unsuitable for certain types of development tasks. One of the biggest drawbacks of WSL1 was its lack of support for background services and daemons. This meant that developers couldn't run certain types of Linux applications that required these services to be running in the background. For example, if you wanted to run a web server or a database server, you couldn't do so with WSL1.
Another limitation of WSL1 was that it relied on the Windows NT kernel to function. While this was an improvement over the need for a virtual machine, it still meant that WSL1 couldn't offer the same level of compatibility with Linux applications as a true Linux kernel.
Despite these limitations, WSL1 was still a significant improvement over previous options for running Linux on Windows, such as virtual machines. It allowed developers to use Linux binaries on a Windows machine with fewer resources and better performance than a virtual machine would provide. However, there was still room for improvement, which is where WSL2 comes in.
WSL2
WSL2 addressed many of these limitations by using a real Linux kernel instead of a translation layer. This allowed for full system call compatibility, which in turn made it possible for WSL2 to run Docker containers natively. By using a real Linux kernel, WSL2 eliminated the need for a translation layer to map Linux system calls to Windows system calls. This not only improved performance but also ensured better compatibility with Linux applications.
One of the key advantages of WSL2 is that it allows developers to work in a Linux environment while using Windows as their primary operating system. This is particularly useful for those who prefer Windows for their day-to-day work but need to use Linux-specific tools and software for their development tasks.
Installing WSL2
To use WSL2, you need to install a Linux distribution from the Microsoft Store, such as Ubuntu, Debian, or Fedora. If you don’t want to use the Microsoft Store, you can also install WSL2 using PowerShell:
wsl --install
Note that this command will only work if you don’t already have WSL installed. if you run wsl --install and see the WSL help text, try running wsl --list --online to see a list of available distros and run wsl --install -d <DistroName> to install a distro.
Conclusion
For me personally, WSL2 has proven to be a preferred option over virtual machines. It allows for better performance and compatibility with Linux applications, eliminates the overhead of a hypervisor, and requires fewer resources.
While building Ballistic, I’m using WSL2 on a daily basis, as all my development work is done in an Ubuntu distribution on my Windows machine. With the addition of a real Linux kernel, WSL2 is a game-changer for developers who use Windows as their primary development environment.
Top comments (0)