Nix on Windows: does it run yet? That’s the question I wondered about while testing the latest NixOS release, version 17.09. To that end, I had the idea of running the Nix installation process from inside the Windows Subsystem for Linux (WSL) see if it worked. And it worked! Success!

Testing the NixOS 17.09 release under Windows Subsystem for Linux. Works like a charm. pic.twitter.com/19qvXjDpDv

— zimbatm (@zimbatm) September 24, 2017

So what does this mean?

You might remember that the Windows NT kernel used to have a POSIX layer. Unfortunately, The POSIX layer always had compatibility issues with BSD and Linux software, because typical applications seldom fit completely and entirely within the confines of an age old API. Nevertheless, the NT kernel was designed from the start to support different subsystems, not just Win32, and the POSIX layer of old was a step in the right direction. The WSL is a revival of that idea but with a specific focus on the Linux ABI. It means that it is now possible to run Linux software natively on Windows. Think of it as reverse Wine. Linux software can execute Windows software and vice versa.

It’s not perfect yet. I/O and symlink resolution seem to be slow and not all Linux syscalls have been implemented yet. This is more about the promised land that Microsoft is showing. WSL is not available on the server edition yet, but it looks like they are going to deliver on it.

At Tweag.io we often use Nix to declaratively specify reproducible build environments for our projects and those of our clients. Nix is a good fit for project that mix different languages. It works really well at providing reproducible builds and compose the various parts of the project with external dependencies. Unfortunately it is also not supported on Windows so we have to decide upfront whether to use it based in part on whether Windows is going to become a target platform or not. Thanks to WSL it looks like we will have an escape hatch, at least for non graphical applications.

Another potential use-case that I see is for Haskell development. Today, a lot of good software is being developed directly on top of Linux and macOS. For some of these projects Windows is not a prime target environment anymore. The Glasgow Haskell Compiler (GHC) is actually quite well behaved on Windows when compiling pure Haskell code. But as soon as C library dependencies are involved, the story gets a lot more complicated. In that case, deploying via WSL might just be easier than aiming for a native Windows port.

How to install

Enable and install WSL following these instructions: https://msdn.microsoft.com/en-us/commandline/wsl/install_guide.

Make sure to have the latest version of Windows 10 installed. I had this version at the time of install:

• Windows Edition: Windows 10 Pro
• Windows Version: 1703
• Windows OS Build: 15063.540
• System Type: 64-bit operating system

Start the “Bash On Ubuntu On Windows” program and type curl https://nixos.org/nix/install | sh.

Known issues

WSL is an experimental subsystem still. At this point in time, there are still important issues to know about. Here are the workarounds I came up with:

• curl is hanging. Hit Ctrl+C and retry.
• Nix installation crash. Older versions of WSL didn’t support all the syscalls needed by Nix. Update Windows and try again.
• nix-shell is broken. Fails with synchronous I/O disk error https://github.com/NixOS/nix/issues/1203. Here’s a workaround: edit /etc/nix/nix.conf and add use-sqlite-wal=false
• It’s slow. Yes, especially I/O and symlinks seem to be quite slow. The only solution here is to wait for Microsoft to optimise their syscalls.
• Nix environment is not started in new logins. Workaround: Run source ~/.profile

Conclusion

For now, it’s just a technology preview that opens new possibilities. Hopefully in the future, when the performance of I/O operations improves, it will also be enjoyable to develop Linux programs under WSL directly. Meanwhile, Microsoft has put out useful resources to go further with WSL:

• the WSL FAQ,
• the Github project.