Quick unrelated thing before I get into this: my brother's Galaxy Note 7 finally got the "please turn this off forever" treatment this week. Samsung killed the whole line on October 11th, after months of it catching fire in people's pockets, and he'd been carrying his around like a tiny bomb ever since the recall in September. Watching him hand it back to the Verizon store on Saturday was oddly satisfying. Anyway. Not what this post is about.
What this post is actually about is Bash on Windows, or the "Windows Subsystem for Linux (Beta)" if you want the official mouthful, which shipped quietly with the Anniversary Update back in August. I poked at it for about five minutes when it came out, said "huh, neat," and closed the window. This past week I actually tried living in it instead of dual-booting into the Ubuntu partition I keep around for terminal work, mostly ssh, git, and some node stuff I do for a client.
Getting it turned on
It's not exactly a checkbox away, though it's close:
- Settings > Update & Security > For developers, and flip on Developer Mode.
- Control Panel > Programs > Turn Windows features on or off, and tick "Windows Subsystem for Linux (Beta)."
- Reboot, because of course.
- Open cmd.exe, type
bash, hit enter. It pulls down an Ubuntu image and walks you through setting up a user right there in the console window. Took about four minutes on my connection at home.
That last step still feels weird to me every time. Typing bash into a Windows command prompt to summon a whole other operating system's userland is a neat trick, but it doesn't feel like a real option in the Start menu yet, it feels like a cheat code you type in. I get that it's labeled beta for a reason.
What actually works, and what doesn't
Once it's up, apt behaves like apt. apt-get update && apt-get install tmux git openssh-client vim went through without complaint, and I've had tmux sessions running for four days straight without anything falling over. ssh works exactly like you'd expect. git works. I pushed a commit from inside it this morning without thinking about it, which is honestly the whole point.
The thing that trips people up, and tripped me up on day two, is the filesystem split. Your Linux files live in some buried folder under %localappdata%\lxss, and Microsoft's own docs tell you, in bold, not to go poking at those files from Explorer or any Windows program. Something about case sensitivity and permission bits not translating cleanly. I ignored that warning exactly once, dragged a file into the folder from Explorer to "fix" a permissions issue, and spent twenty minutes untangling why bash could suddenly no longer see it. Lesson learned, I dont touch it from the Windows side anymore.
The other snag: I tried pointing an existing node project at a folder over on the Windows C: drive (mounted at /mnt/c/) instead of copying it into the Linux home directory, and npm install choked on a symlink it tried to create. Cloned the same repo fresh into ~/projects instead and it installed fine. So the rule of thumb seems to be: keep your actual work inside the Linux side, and only reach across to /mnt/c when you have to. Which, fine, but it means I can't just work out of my normal Documents folder the way I was hoping.
Disk IO across that C: mount is also noticeably slower than native. Nothing that matters for editing text files, but I ran a build that touches a lot of small files and it dragged in a way it never did in real Ubuntu on the same hardware.
Where that leaves me
I haven't gone back to rebooting into the Ubuntu partition yet, and it's been a full week, which says something. The GUI-app gap doesn't bother me since everything I need is a terminal thing anyway, and not rebooting to check my email and then reboot again to ssh into a server is a genuinely nice change to my day. But I'm keeping the dual boot around for now. If the IO thing on /mnt/c starts actually costing me time instead of just being a mild annoyance, I know exactly where the eject button is.