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

What this isn't

It's not a desktop environment. Don't expect Ubuntu's GUI. This is Bash and command-line tools only. Graphical Linux apps 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.

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 edited config files with Windows Notepad, and they disappeared from the Linux side. The file system translation layer doesn't handle concurrent access from both sides.

This breaks a key workflow. You can't edit code in Visual Studio Code (Windows) and run it in Bash (Linux) reliably when the files live in the Linux file system.

Accessing Windows drives

Windows drives mount under /mnt:

• C: becomes /mnt/c
• D: becomes /mnt/d

This works well:

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

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 Bash for command-line work while editing code in Windows editors. Put projects on C: (Windows), access via /mnt/c (Linux), edit in Windows, run commands in Bash.

File watching broke completely. Tools like Webpack and Gulp watch for file changes. When I edited files in Windows, the Linux side didn't detect changes. 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. There are no tabs, so multiple terminals means separate windows managed with Alt+Tab.

This gets messy fast with 10 terminal windows open. tmux helps, but it's not as ergonomic as native terminal tabs.

Can you install zsh and other shells?

Yes:

sudo apt install zsh

It worked but occasionally glitched, with prompts rendering incorrectly and some plugins refusing to load. The environment was not stable enough to trust.

The data loss scare

Files disappeared when I edited from Windows. 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. That warning is justified.

Performance

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

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 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 run fine.

Learning Linux: For developers learning Linux commands, this beats 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: Build systems and test runners that watch for changes don't work on /mnt paths.

The verdict in 2016

Bash on Ubuntu on Windows was an impressive technical achievement, but not ready for serious work. File system issues and performance problems made it unreliable for daily 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. 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 was viable. If you're reading this in 2025, use WSL2—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 they were serious about modernizing their developer tools.