[2025 Update: This was Microsoft's first attempt at Linux compatibility on Windows. What started as "Bash on Ubuntu on Windows" became WSL (Windows Subsystem for Linux), and WSL2 in 2019 fixed most of the issues described here. WSL2 runs a real Linux kernel, has proper file system performance, and integrates much better with Windows. This post captures the rough beta experience from 2016.]

Microsoft announced Linux support for Windows at Build 2016, calling it "Bash on Ubuntu on Windows." The name was awkward, but the promise was huge: native Linux tools on Windows without virtual machines.

I installed it on Windows 10 Anniversary Update to see if it could replace dual-boot setups for web development. Here's what I found.

What this isn't

Before installing, understand the limitations:

It's not a desktop environment. Don't expect Ubuntu's GUI. This is Bash and command-line tools only. If you want graphical Linux apps, you still need a VM.

It doesn't integrate with Windows tools. Git for Windows and Bash on Ubuntu use separate credential stores. Your Windows SSH keys won't work in Bash. Each environment is isolated.

You can't run Linux binaries from Windows directly. Linux executables only work inside the Bash shell. You can't double-click a Linux binary in Windows Explorer and have it run.

The file system mystery

The Linux environment lives at:

C:\Users\<YourUserName>\AppData\Local\lxss

For example, /etc maps to:

C:\Users\KahWee\AppData\Local\lxss\rootfs\etc

Don't edit these files from Windows. I tried editing config files using Windows Notepad, and they disappeared from the Linux side. The file system translation layer doesn't handle concurrent access from both sides.

This is a deal-breaker for some workflows. You can't edit code in Visual Studio Code (Windows) and run it in Bash (Linux) reliably if the files live in the Linux file system.

Accessing Windows drives

Windows drives mount under /mnt:

• C: becomes /mnt/c
• D: becomes /mnt/d
• And so on for all drives

This works well. You can navigate to Windows directories and run Linux commands on Windows files:

cd /mnt/c/Users/KahWee/projects
ls -la

The inverse—editing files from Windows while running Linux tools—works better when files live on the Windows side. But performance is noticeably slower than native Linux file I/O.

File synchronization issues

I wanted to use Bash for command-line work while editing code in Windows editors. The setup should work: put projects on C: (Windows), access them via /mnt/c (Linux), edit in Windows, run commands in Bash.

In practice, file watching broke. Tools like Webpack and Gulp watch for file changes. When I edited files in Windows, the Linux side didn't detect changes reliably. Build tools that rely on inotify (Linux's file change notification) don't work with /mnt paths.

No terminal tabs

The Bash window is a single instance. You can't open tabs. If you need multiple terminals (which I do constantly), you manage separate windows with Alt+Tab.

This gets messy fast. With 10 terminal windows open, finding the right one is tedious. Tools like tmux help, but they're not as ergonomic as native terminal tabs.

Can you install zsh and other shells?

Yes. I installed zsh with:

sudo apt install zsh

It worked, but occasionally glitched. Prompts would render incorrectly, or some plugins wouldn't load. The environment wasn't stable enough to trust.

The data loss scare

The file disappearance when editing from Windows spooked me. I don't know if the file was deleted or just invisible to Bash, but losing work isn't acceptable.

Microsoft warned that the Linux file system is fragile and shouldn't be modified from Windows. The warning is justified—don't ignore it.

Performance

Command-line operations felt slower than native Linux. Tools like npm install or git operations took noticeably longer than running the same commands on a Linux VM or dual-boot setup.

The file system translation layer added overhead. Every I/O operation went through Windows, then translated to Linux system calls, then back.

What worked well

Package management: apt worked perfectly. I installed Node.js, Python, Ruby, and other development tools without issues.

Shell scripts: Running existing Bash scripts mostly worked. If your scripts don't rely on file watching or heavy I/O, they'll probably work fine.

Learning Linux: For developers learning Linux commands and shell scripting, this is better than nothing. You get real Bash without setting up dual-boot or VMs.

What didn't work

File system reliability: Editing from Windows while using Bash is risky.

Performance: Noticeably slower than native Linux.

Integration: No shared credentials, SSH keys, or environment variables between Windows and Linux sides.

File watching: Development tools that watch for changes (build systems, test runners) don't work reliably on /mnt paths.

The verdict in 2016

Bash on Ubuntu on Windows was an impressive technical achievement, but not ready for serious work. The file system issues and performance problems made it unreliable for day-to-day development.

For light scripting or learning Linux commands, it worked. For professional web development, I stuck with dual-boot or VMs.

How this evolved

By 2019, Microsoft released WSL2, which fixed almost everything wrong with the original. WSL2 runs a real Linux kernel in a lightweight VM, giving proper performance and file system reliability. It became a legitimate replacement for dual-boot setups.

The 2016 version was a beta experiment. It proved the concept, but you shouldn't trust it with important work. If you're reading this in 2025, use WSL2 instead—it's what Bash on Ubuntu on Windows should have been from the start.

This was part of Microsoft's broader push to win back developers in 2016. Around the same time, they were also improving Edge's web standards support, showing that Microsoft was serious about modernizing their developer tools.