A few months back, if I had asked anyone how to test Linux-specific applications or just play around with Linux tools, the recommendations were always the same: dual-boot your system and install Linux alongside Windows, switch to Linux (probably Arch) completely, or run Linux in VirtualBox. I took this advice seriously when I started my sophomore year at university, and stuck with it until last semester.
My Linux Journey: The Complete Switch
From my second semester through my fifth semester, I completely switched to Linux and everything was working fine. I was learning the Linux environment, getting comfortable with the command line, and enjoying the development experience. But then I enrolled in an Information Security course that threw a wrench in my setup.
The course had several assignments that were specifically designed for Windows: reverse engineering and patching Windows applications, testing and exploiting Event Tracer for Microsoft Windows, and other Windows-specific security work. Due to space constraints on my system's SSD, I found myself switching back to Windows 11. It felt like taking a step backward, but I didn't have much choice at the time.
The Transition Back and an Unexpected Discovery
During my transition back to Windows, I made a mistake that would later become somewhat problematic. I downloaded Windows from a bootable USB borrowed from a friend, who had downloaded the ISO from a third-party website rather than the official Microsoft source. Everything seemed to work smoothly at first, but problems were lurking beneath the surface.
At the same time, I was taking an Operating Systems course where all the labs and projects were designed specifically for Linux machines. This is when I first installed Ubuntu on WSL. Even though I had to reinstall my GCC compiler and various other applications on WSL, the installation size compared to dual-booting or VirtualBox was significantly smaller. WSL won by a great margin in terms of disk space, and surprisingly, all my Linux requirements were met even without installing additional tools and packages.
When Things Started Breaking
Remember that third-party Windows ISO I mentioned? After some time, PowerShell stopped working entirely. I'm not sure if it was an issue with the Windows installation itself, a bug in the ISO, or if I had messed something up while doing my Information Security assignments. Regardless of the cause, it became a real problem.
The Command Prompt (CMD) just wasn't enough for my needs. There were constantly documentations and tutorials that either required Linux to work properly, or if they were available for Windows, they needed PowerShell commands to execute. Yes, I know you can sometimes modify PowerShell commands to work in Command Prompt, but that's not the point I'm trying to make here. The point is that WSL worked perfectly in this scenario, seamlessly filling the gap left by my broken PowerShell.
The VirtualBox Disappointment
Fast forward to this semester: I'm taking a Robotics and Control course at university, and we were required to install ROS2 and several other applications related to robotics 3D software and simulations. By this point, I had changed my laptop and the disk space constraint was no longer an issue, so I decided to keep Windows as my main OS and install Ubuntu in VirtualBox.
This turned out to be a frustrating experience. Even after allocating more than the required resources to the virtual machine, the experience wasn't smooth at all. Gazebo, a software we were specifically instructed to use for robotics simulation, simply refused to load properly. I spent around 4 hours debugging, following various guides, and yes, even blaming AI assistants for not helping me solve the issue. Nothing worked.
WSL to the Rescue
After that ordeal, I decided to completely remove VirtualBox and install all the required applications and dependencies on my Windows WSL instead. To my surprise, not only did everything work, but it worked better than I had anticipated.
The GUI applications launched smoothly, WSL perfectly synced with my graphics drivers and system resources, and the overall speed was significantly better compared to VirtualBox Ubuntu. It felt like native performance. After going through various articles and documentation online, I configured the resource allocation for WSL through the .wslconfig file, and now it genuinely feels like I'm running a complete Linux operating system inside Windows.
The Best of Both Worlds
Since the disk size required for WSL distributions is relatively small, I now have both a Debian-based and an Arch-based WSL system installed, and both are working perfectly. I understand that Windows as an overall operating system is slower than Linux and can't compete in terms of raw speed or development tools, but at the same time, many software applications used at my university—like Visual Studio and various Windows-specific tools—require Windows.
When I had switched to Linux earlier, I always had to find workarounds to make certain programs work. Some software was easily installable and well-supported on Windows but had limited or poor support on Linux. WSL completely fulfills my need for Linux development without forcing me to switch operating systems or worry about compatibility issues.
My Current Setup and Workflow
Today, my development workflow is smoother than it's ever been:
- Windows as my primary OS for university software, Visual Studio, and Windows-specific tools
- Ubuntu WSL for general Linux development, ROS2, robotics simulations, and course assignments
- Debian WSL for testing packages and experimenting with different configurations
- Arch WSL for bleeding-edge tools and the latest software versions
The ability to run wsl from any Windows terminal and instantly drop into a full Linux environment has been transformative. I can access my Windows files from Linux through /mnt/c/, run GUI applications with WSLg (Windows Subsystem for Linux GUI), and even run Docker containers natively.
Performance Considerations
One thing worth mentioning: I did take time to properly configure WSL for optimal performance. By default, WSL2 can be resource-hungry, but creating a .wslconfig file in your Windows user directory allows you to set memory limits, processor counts, and swap space. This configuration has made all the difference in my experience.
For anyone considering a similar setup, here's what worked for me:
- Limiting WSL memory to about 50-60% of total system RAM
- Enabling GPU passthrough for applications like Gazebo that need graphics acceleration
- Using WSL2 instead of WSL1 for better compatibility and performance
- Keeping my Linux distributions updated but minimal (only installing what I actually need)
Final Thoughts
WSL has become an indispensable tool in my development toolkit. It's not perfect—there are still some edge cases where native Linux performs better, and some low-level system operations aren't fully supported—but for the vast majority of my university work and personal projects, it's been exactly what I needed.
For students or developers who find themselves needing both Windows and Linux, I can't recommend WSL enough. It eliminates the storage overhead of dual-booting, the performance penalty of virtual machines, and the commitment of switching operating systems entirely.
That was my experience, and I'd love to hear your thoughts. Have you tried WSL? What's your preferred way of working across Windows and Linux? Feel free to share your experiences and advice in the comments below.
Top comments (0)