瞎扯淡 以后真的可以在 Win 下无痛苦的开发 Rails 或者其他依赖 Posix 环境的工程了
这次 MS Build 大会上有一个亮点是 MS 宣布和 Canonical 合作使得 Ubuntu 的 binary 可以在 win 上执行，应该是基于之前 Android 子系统的成果，内核上实现了 Linux 子系统，可以原生的执行 linux 的 ELF，而无需像 cygwin 那样重新编译。
HN 上的讨论：https://news.ycombinator.com/item?id=11390545 另外有两篇来自 ubuntu 的人写的解释文章 http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html http://www.hanselman.com/blog/DevelopersCanRunBashShellAndUsermodeUbuntuLinuxBinariesOnWindows10.aspx
根据文中提到的 The sysbench utility is showing nearly equivalent cpu, memory, and io performance. 来看，这个实时转换几乎没有什么损耗
由于是完整的打包了 Ubuntu 的 user space，甚至包括了 apt-get，终于可以在 Win 下像在 OSX 上原生的进行目标为 Linux 平台的项目的开发啦（这本身也是 OSX 重要的竞争力），这样的做法也可以比 OSX 提供一个更加贴近 Linux 的环境
这也是初学者接触 Ruby 有巨大利好，不需要再被前辈们苦口婆心软的硬的的劝用 linux，也不需要花大笔钱买 MAC...
不过 win 下还是没有一个能和 iTerm2 匹敌的 Terminal
我一直盼望 Windows 能像 OS X 一样加上一个原生的 POSIX 兼容层。所以现在微软走出这一步，还是很兴奋的。 但对以宣传的这种方式实现 Linux 兼容，听起来能直接运行 LInux 程序很厉害，但可用性怎么样还得看实际的使用效果，能用和 好用是两回事。希望这个宣传是真的：The sysbench utility is showing nearly equivalent cpu, memory, and io performance.
以 cygwin 为例，这样的工具用户体验是比较差的，我个人是没有把它投入实用的欲望，主要有两个问题：
一个是效率（也许这次微软能解决），举个栗子，Windows git 用在大型项目上速度感人，用过的人应该有所体会。这里面可能有两个原因：NTFS 处理大量小文件似乎效率不高；Linux 程序大量依赖 fork 调用子进程完成任务，本来 fork 是很轻量级的，但 cygwin 用 Windows API 模拟的 fork 代价极高。
二是和其它子系统的配合。这一点在 OS X 上都有所体现，例如通过 bash 配置的$PATH，其他应用继承不到（除非是在终端启动），需要另想办法。但人家总归是在整个系统层级实现的 Posix，少少的配置之后，日常使用不会出问题。但以类似 wine 的方式实现 Linux 兼容层，和其他 Windows 程序的配合不知道能怎样解决。比如怎样让 c:\path\to\file、/c/path/to/file、/path/to/file 这类的东西在不同子系统件顺畅的传递？
看了下这个视频，未来 Windows 下开发 Ruby 应用的体验可能不亚于 Linux 了， https://channel9.msdn.com/Events/Build/2016/P488
从 10.5 开始用了快 8 年 macbook 的表示这下终于可以把工作机换成 win 的机器了，考虑是不是来个戴尔的移动工作站试试
还是那个观点，ruby 对 windows 系统是友好的，而写 gem 的人并没考虑他们的代码在 windows 下是否可用
在 Windows Blog 上看到这么一条： Third, note that Bash and Linux tools cannot interact with Windows applications and tools, and vice-versa. So you won’t be able to run Notepad from Bash, or run Ruby in Bash from PowerShell.
https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-ubuntu-on-windows/
#9 楼 @neutralevil 你看下 5 楼的里面的演示视频，里面演示了 Unix 命令和 Windows 原生程序的无缝切换 https://channel9.msdn.com/Events/Build/2016/P488
好事！
如果哪天 Windows 再出 Retina Display 模糊字体也解决，说不一定我会考虑再用用 Windows
另外，这个对 Ruby 来说是大好的发展机会呀！
#13 楼 @huacnlee 首先 nt 是混合内核（目前应该已经完成微内核化了），即使是 win32 也仅仅是一个内核靠外的模块而已，win10 前内核是内置有 Posix 子系统，MS 单独提供了一套叫 SUV 的东西，提供了完整的 Unix 工具链，不过那玩意 2006 年之后就没在维护了，老旧也有 bug 所以没啥人用，posix 子系统也就没几个人知道了...
按文章的说法来看，MS 是重新实现了 Linux 的全部内核 spec（不道是否全部类似 chmod 和 win 体系的差别还挺大的）并且避免了法律问题，另外打包了 Ubuntu 的 user space（内核外的全部东西）
话说，不知道 epoll 这些 io 模型如何处理，如果对应到 win 这边是 io 完成端口，那搞不好性能比原生还要高一些。。。还有互操作上，例如 win 的 winhttp 的设计应该要比 linux 的要强的（因为运行在内核态），还有一些额外的内科技加持（内核态的负载均衡，多进程共享句柄等等）
https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-ubuntu-on-windows/ 本来想来发帖的~被抢先了.... 感觉微软最近一年大招频频啊，不过按照微软最近虎头蛇尾的操性.... 不得不说厨子真是个好领导，能在苹果创新能力越来越差的情况下还能创造销售记录... 下一台电脑要买 surface 系列了
第一阶段：卧槽，微软这个牛逼，微人希，测试版出来我就去下一个 第二阶段：咦，怎么有点问题，跟 XX 怎么不一样，是不是用微软自己内部的方法实现的，还是说测试版有点小 bug，先切回之前的平台用一下吧。 第三阶段：也不知道微软那个项目搞得怎么样了，上次发布会都好几年了，什么？已经不更新/Pass 了？好可惜啊，正式版都没出几个月。 第四阶段：微软将在 XXXX 年发布一项新的技术，这项技术会彻底改变人类的生活，卧槽，微软牛逼。
#10 楼 @libuchao 可能我们的关注点不一样。看了视频，所谓的“无缝切换”，是建立在 Linux、Windows 可以访问同一个文件系统上的。这个功能应该是显而易见的，不然和虚拟机比，可用性上也没太多优势。另外就是，我注意到，演示时在 cmd 直接输入bash运行。但不确定这个 bash 是 Linux 原生的（也就意味着 Windows 程序可以直接调用 Linux 工具），还是做了特别处理。
但我的疑问还是没有解决，至少从视频看不出来。举个实际的用况，假设一个 OS X 用户，使用 Textmate 做编辑器，那么他可以：
-
mate path/to/file编辑指定文件 - 把
$EDITOR设为mate，这样当命令行工具需要编辑文本时，可以调用 Textmate - Textmate 的很多功能是调用 sh、ruby 等脚本实现的
- 它还可以直接调用其它命令行工具。例如在编辑器内通过 git 插件访问代码库；如果你写了一段 C++ 程序并运行，它可以自动调用 gcc 来编译，然后运行 gcc 构建出来的程序。
以上的用法，应该不算很罕见和特殊吧？我们把他挪到 Windows 上，至少需要实现：
- 从 Linux 环境调用 Windows 程序，这点视频里没有演示，他用 vscode 的时候，都是用 File Explorer 打开的
- Windows 程序可以调用 Linux 程序，从能够在 cmd 运行 bash 看，似乎是可以的，即使不能自由的调用所有的工具，至少把对 Linux 命令的调用封装到 bash 脚本里间接调用，应该是可行的，虽然这样比较麻烦。
- 不同子系统信息的交换，例如最基本的是文件路径：一个 Windows 程序传给 Linux 程序的肯定是
C:/path/to/file，甚至是C:\path\to\file，Linux 程序怎么理解？而 Linux 程序给 Windows 的则是/mnt/c/path/to/file或/home/username/path/to/file。 还有ln -s（或者通过其他脚本创建 symlink），在 Unix 是个很常用的操作，而在 Windows 上坑爹的是个特权操作。于是 cygwin 是自己实现的 symlink，出了 cygwin 环境就不认了。而 MinGW 默认配置是关掉 symlink，ln -s实际在做拷贝，即使配置成使用系统原生的 symlink，因为权限问题，也不方便。
总之现在 Windows 上使用 Unix 环境是很痛苦的，目前微软官方的方案只是解决了部分问题。
#24 楼 @libuchao 现在看来，目前的解决方案从使用效果上，相当于更好用的虚拟机。不过由于文件系统的无缝共享，也有望解决部分问题了，如 git for Windows 的效率问题。
git 本来是以快著称的，但我在工作项目上运行time git status的结果（另，我是用 PCI-E 协议的固态硬盘）：
real 0m6.824s
user 0m2.437s
sys 0m12.078s
这在 OS X 或 Linux 基本是秒开的。
git difftool、git mergetool每个文件弹出来目测要等好几秒（好吧，如果用原生 git，估计我不能设置某个 Windows 程序做 merge tool 了）。
git checkout如果两个分支差异比较大，随随便便等个几分钟甚至更长时间。
总之用得很搓火。
结合之前微软将 SQL Server 移植到 Linux 平台的新闻，我认为微软终于认清了 server 端操作系统之战已经结束的事实，再加上 Mobile 端 Windows Phone 操作系统的失败，微软终于开始将精力放到 Desktop 桌面端了，恭喜一下！
#28 楼 @hemengzhi88 因为我在 steam 上买了 119 个游戏，其中只有 79 个游戏能在 mac 下玩，我要玩 辐射 4 跟 全境封锁
#37 楼 @neutralevil 用过，ConEmu 的界面太复杂了。。。。另外我记得复制粘贴终端里的文本也不是那么方便，还有几个替代品我记得，都各自有一点欠缺
就算这子系统完美无缺，就 win 那 hidpi 的效果和其上的各种 bug, 有什么值得程序员特别是开源栈的程序员迁移上去的？何况 ms 向来弄东西朝三暮四，说停就停，商业目的极为纯粹，谁把自己绑上去谁傻。
今天装上了，我主要搞 python 和 go，试了主要的几个 python 项目，基本都能跑起来。go 不行
现在很多问题，但这些问题个人感觉修复起来问题不大，因为错误提示都很明显，不是那种死机，段错误之类的，相信如果 ms 诚信要搞的话，在夏天应该都能解决。
体验是很有意思的，比方说 postgresql /memcached 现在直接跑不起来，但在 bash 中可以直接访问 windows 版本的 postgresql, memcached, 像 postgresql 同样是 localhost 5432, memcached 之类的配置都不用改。
在 bash 中把项目跑起来，在 windows 中打开浏览器，输入地址如 localhost:8000, 就能访问 bash 中启动的服务
用 sublime text 之类的，可以直接打开 users/xxx/appdata/local/lxss 访问 unbutn 中文件夹进行编辑，甚至在 windows 下能识别 ubuntu 下的符号链接（目录显示还有问题，也可能是我 ln 命令用的不当）
#40 楼 @chenjau HiDPI 严格来说不是 MS 的问题，首先 HiDPI 均发生在遗留程序上（老的 MFC、WinForm 等实现的应用程序，而非新的 GUI 开发模型），对于遗留程序 OS X 也只是简单的拉伸像素，并无高明之处，在 OS X 下有问题的程序也有不少（我也刚好从第一代 rMBP 入坑 OS X），Win 的软件基数比 Mac 多起来不是一个数量级的，所以问题就尤为明显。
到现在来看，Win 过去优良兼容性现在看来也是成为了负担，和一个很资深的 Win 开发朋友聊了聊，得知其实很早 MFC 的设计就已经能够兼容 HiDPI 了（虽然当时没这个概念），但是当初没有这样的需求，所以普遍没有遵循推荐写法来实现，导致现在在 HiDPI 下的问题。至于 MS 为何不实现类似 OS X 的像素拉伸机制，（朋友给出的）一个可能的推测是，MFC 本身就提供了一些相对单位的支持，有些人遵循了，也有人不遵循，导致很难提供一个简单的机制能够兼顾两者，而苹果由于在提出视网膜前没提供过类似的机制，所以不需要考虑这些情况。
OS X 有一个很重要的后发优势（2000 年以后才发布，引入了诸如用于 GUI 渲染的 Composer 等先进特性，Win 自 Vista 开始在保持兼容的情况下，逐步过渡），然而，论工程能力和对开发人员的友善度，苹果相比微软谷歌还是差距很大，至于 Bug 就有公开统计的 0day 安全漏洞而言，OS X 是 Win 的 4 倍之多，何况 WIn 早已建立稳定的 Hotfix 和补丁星期二机制（当然得吐槽一下纳德拉上台后 MS 的软件质量下降了不少。。。），这方面可以说苹果是没有任何积累的