【IT168 评论】昨天，我在Windows电脑上安装了两个Linux发行版。不是虚拟机，也不是双系统，不需要查找下载页面和解压缩安装程序文件的路径。 相反，我去了Windows Store，搜索了Linux，选了我想要的发行版，然后点击了安装。 一旦下载完毕，我需要做的就是打开终端窗口并添加用户名和密码。曾经的不可思议，现在一切都是可能的。
但是让Windows实现答案并不简单。程序员在MacOS和Linux上，使用命令行工具在云中的Linux服务器上工作。他们已经拥有与Docker，GitHub，Jenkins，Ansible，Chef和TravisCI等服务合作的工具链，应用程序和脚本。那么如何将这些程序员带到Windows上呢?
第一步是以无缝的方式将Unix带到熟悉的Windows桌面。MacOS具有Unix用户的内在优势，因为它基于BSD Unix的微内核实现，通过每个Mac上的终端应用程序访问。
但是，Windows本身是NT内核，也不必要必须构建熟悉的工具的新版本，然后重新编译成Windows可运行的版本，为什么不直接在Windows上运行Linux二进制文件呢?使用Project Astoria，为Windows Phone和Windows 10提供已取消的Android兼容性层，Microsoft可以提供一个新的子操作系统，将Linux系统调用转换为Windows，允许代码运行而无需任何更改。
与Ubuntu合作的初始版本提供了一个运行在Windows熟悉的终端中的Bash shell(由cmd和PowerShell使用)。为Windows内部人员构建的第一个测试，毫不奇怪，还很有限，但随着Windows 10周年更新接近发布，他们进行了快速改进，允许复杂的控制台应用程序运行，支持Ubuntu的apt-get安装程序，以快速访问工具库和服务。通过创作者更新，Microsoft和Canonical能够将WSL移动到Ubuntu最新的16.04长期支持版本。
从技术上讲，WSL仅适用于控制台应用程序，可为开发人员提供外壳支持，并远程访问在内部和公共云中运行的Linux服务器。用户已经安装并运行基于X的GUI应用程序，使用Windows X服务器为WSL带来完整的Linux桌面体验。
早期的WSL构建在运行某些应用程序时遇到问题，因为不支持密钥依赖关系。但是从Windows 10周年纪念更新版本开始，它已经很简单了，现在甚至支持像Docker这样复杂的软件包安装和运行。
今年晚些时候，随着本地Linux容器来到Windows Server，WSL将成为企业系统工具集的关键组件之一。(Windows Server上的WSL将不支持大型Linux工作负载或服务器，但它将为程序员提供托管的Linux容器的直接管理连接，支持现有的管理脚本和工具。)
程序员可以使用WSL默认用户从Windows命令行调用Linux二进制文件，可以从Bash调用Windows二进制文件(并且可以从Visual Studio代码中的终端访问Bash，程序员可测试Unix代码，而不用离开开发工具，不用离开Windows)。
提示：WSL将Windows目录视为挂载文件系统，因此可能需要将链接设置为常用文件或将Windows程序文件目录添加到Bash路径。
程序员应该都很高兴看到Visual Studio code支持WSL的工具。如果微软要将其平台带入到程序员中，其工具就需要将Windows和Linux的最佳方式融合在一起。很容易想象将来发布的完整的Visual Studio托管Linux终端，并呼吁在WSL中运行的服务上的webhooks和其他API。
随着Suse，Fedora加入WSL，程序员可以使用Linux工具、服务和熟悉的工作方式，将脚本和二进制文件从现有工具链转移到Windows PC。WSL甚至可以同时托管几个Linux任务，每个都在一个单独的终端中。
支持许多不同的Linux发行版很有意义。在过去几年中，不同的供应商和团队专注于不同的用例，从同一虚拟套件中构建不同的平台。像Fedora和Ubuntu这样的旧版本是非常通用的操作系统，从开发人员的角度来看，使用它们是有意义的。
程序员不妨尽情想象，如果将来WSL支持更专门的版本，就像容器集中的CoreOS，岂不是很有趣?
