瞎扯淡 以后真的可以在 Win 下无痛苦的开发 Rails 或者其他依赖 Posix 环境的工程了

jasl · 2016年03月31日 · 最后由 jasl 回复于 2016年04月09日 · 8052 次阅读

这次 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

然而我刚准备买 mac book...因为还想做 iOS…

我一直盼望 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 这类的东西在不同子系统件顺畅的传递?

#1 楼 @cqcn1991 Visual Studio 现在也能开发 iOS 了:)

#3 楼 @neutralevil Visual Studio 开发 iOS 时,仍然依赖 OS X 和 Xcode 啊

看了下这个视频,未来 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/

#7 楼 @neutralevil 这也完全正常啊,完全没有什么不方便的

#8 楼 @libuchao 看使用场景了,如果你的任务可以只用 Linux 子系统内的工具完成所有事情,当然没什么不方便。但在 Windows 上开发,很多人的应用场景是要用到 Windows 原生程序,甚至以这些程序为主,但又需要某些 Unix 命令行工具提供的便利。

#9 楼 @neutralevil 你看下 5 楼的里面的演示视频,里面演示了 Unix 命令和 Windows 原生程序的无缝切换 https://channel9.msdn.com/Events/Build/2016/P488

用了大半个月 Mac 还是觉得 Linux 好用。

好事!

如果哪天 Windows 再出 Retina Display 模糊字体也解决,说不一定我会考虑再用用 Windows

另外,这个对 Ruby 来说是大好的发展机会呀!

这个 Ubuntu 改不会是一个隐藏的内置虚拟系统吧

一直都是用 Vagrant

坐等 visual studio 可以开发 ruby 像 rubymine

windows 本身就是痛苦

还演示了 Sinatra 应用

#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 的要强的(因为运行在内核态),还有一些额外的内科技加持(内核态的负载均衡,多进程共享句柄等等)

不太喜欢微软的桌面,希望 win 下可以集成类似 gnome 这样风格的 UI

https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-ubuntu-on-windows/ 本来想来发帖的~被抢先了.... 感觉微软最近一年大招频频啊,不过按照微软最近虎头蛇尾的操性.... 不得不说厨子真是个好领导,能在苹果创新能力越来越差的情况下还能创造销售记录... 下一台电脑要买 surface 系列了

第一阶段:卧槽,微软这个牛逼,微人希,测试版出来我就去下一个 第二阶段:咦,怎么有点问题,跟 XX 怎么不一样,是不是用微软自己内部的方法实现的,还是说测试版有点小 bug,先切回之前的平台用一下吧。 第三阶段:也不知道微软那个项目搞得怎么样了,上次发布会都好几年了,什么?已经不更新/Pass 了?好可惜啊,正式版都没出几个月。 第四阶段:微软将在 XXXX 年发布一项新的技术,这项技术会彻底改变人类的生活,卧槽,微软牛逼。

#11 楼 @rei 太有同感了

#10 楼 @libuchao 可能我们的关注点不一样。看了视频,所谓的“无缝切换”,是建立在 Linux、Windows 可以访问同一个文件系统上的。这个功能应该是显而易见的,不然和虚拟机比,可用性上也没太多优势。另外就是,我注意到,演示时在 cmd 直接输入bash运行。但不确定这个 bash 是 Linux 原生的(也就意味着 Windows 程序可以直接调用 Linux 工具),还是做了特别处理。

但我的疑问还是没有解决,至少从视频看不出来。举个实际的用况,假设一个 OS X 用户,使用 Textmate 做编辑器,那么他可以:

  1. mate path/to/file编辑指定文件
  2. $EDITOR设为mate,这样当命令行工具需要编辑文本时,可以调用 Textmate
  3. Textmate 的很多功能是调用 sh、ruby 等脚本实现的
  4. 它还可以直接调用其它命令行工具。例如在编辑器内通过 git 插件访问代码库;如果你写了一段 C++ 程序并运行,它可以自动调用 gcc 来编译,然后运行 gcc 构建出来的程序。

以上的用法,应该不算很罕见和特殊吧?我们把他挪到 Windows 上,至少需要实现:

  1. 从 Linux 环境调用 Windows 程序,这点视频里没有演示,他用 vscode 的时候,都是用 File Explorer 打开的
  2. Windows 程序可以调用 Linux 程序,从能够在 cmd 运行 bash 看,似乎是可以的,即使不能自由的调用所有的工具,至少把对 Linux 命令的调用封装到 bash 脚本里间接调用,应该是可行的,虽然这样比较麻烦。
  3. 不同子系统信息的交换,例如最基本的是文件路径:一个 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 环境是很痛苦的,目前微软官方的方案只是解决了部分问题。

#23 楼 @neutralevil 从视频上看,你说的这四点目前应该还没实现。是否有必要去追求这种 100 % 无缝,看用户是否愿意妥协了

#24 楼 @libuchao 现在看来,目前的解决方案从使用效果上,相当于更好用的虚拟机。不过由于文件系统的无缝共享,也有望解决部分问题了,如 git for Windows 的效率问题。

git 本来是以快著称的,但我在工作项目上运行time git status的结果(另,我是用 PCI-E 协议的固态硬盘):

real    0m6.824s
user    0m2.437s
sys     0m12.078s

这在 OS X 或 Linux 基本是秒开的。

git difftoolgit mergetool每个文件弹出来目测要等好几秒(好吧,如果用原生 git,估计我不能设置某个 Windows 程序做 merge tool 了)。

git checkout如果两个分支差异比较大,随随便便等个几分钟甚至更长时间。

总之用得很搓火。

不知道 Linux 病毒数量会不会激增

结合之前微软将 SQL Server 移植到 Linux 平台的新闻,我认为微软终于认清了 server 端操作系统之战已经结束的事实,再加上 Mobile 端 Windows Phone 操作系统的失败,微软终于开始将精力放到 Desktop 桌面端了,恭喜一下!

#6 楼 @ywjno 为什么想换回 win?

#11 楼 @rei 不会觉得 linux 无线网络太慢太不稳定了吗?还是只有我一个人有这个问题。

这个项目能否反哺 wine?

#28 楼 @hemengzhi88 因为我在 steam 上买了 119 个游戏,其中只有 79 个游戏能在 mac 下玩,我要玩 辐射 4 跟 全境封锁

#31 楼 @ywjno 而且打游戏还不能用配置太烂的机器...一万多的台机只能打游戏有点浪费...

#33 楼 @jasl 换机器总要找个借口不是,=。=,况且 1w 多还买不了相同配置的 mac 的台机。。

#18 楼 @jasl 看了下视频介绍,有来自 ubuntu 的工程师,专职在微软写 user space

#35 楼 @jun1st 恩 我引用的两篇文章都是来自 Ubuntu 那边,知乎上叛逆者还有几个人貌似也参与一部分开发 然而现在最大的问题是 Win 上没有太好用的 Terminal 啊。。。。Linux 也没有跟 OSX 的 iTerm 匹敌的终端模拟器,elementaryOS 的那个只能说相对好用

#36 楼 @jasl Windows 终端可以用 ConEmu,虽然不如 ITerm2,但已经比较好用了。

#37 楼 @neutralevil 用过,ConEmu 的界面太复杂了。。。。另外我记得复制粘贴终端里的文本也不是那么方便,还有几个替代品我记得,都各自有一点欠缺

#38 楼 @jasl 界面复杂几乎是 Window 程序的通病,没办法,好在调教好了能用。复制粘贴很方便,跟 iTerm 差不多。

就算这子系统完美无缺,就 win 那 hidpi 的效果和其上的各种 bug, 有什么值得程序员特别是开源栈的程序员迁移上去的?何况 ms 向来弄东西朝三暮四,说停就停,商业目的极为纯粹,谁把自己绑上去谁傻。

google 弄的东西也朝三暮四说停就停~~

今天装上了,我主要搞 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 的软件质量下降了不少。。。),这方面可以说苹果是没有任何积累的

需要 登录 后方可回复, 如果你还没有账号请 注册新账号