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

jasl · 发布于 2016年03月31日 · 最后由 jasl 回复于 2016年04月09日 · 3849 次阅读
1107

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

共收到 43 条回复
3873

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

96

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

96

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

4002

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

4002

看了下这个视频,未来 Windows 下开发 Ruby 应用的体验可能不亚于 Linux 了, https://channel9.msdn.com/Events/Build/2016/P488

1342

从10.5开始用了快8年 macbook 的表示这下终于可以把工作机换成 win 的机器了,考虑是不是来个戴尔的移动工作站试试

还是那个观点,ruby 对 windows 系统是友好的,而写 gem 的人并没考虑他们的代码在 windows 下是否可用

96

在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/

4002

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

96

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

4002

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

1

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

De6df3

好事!

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

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

De6df3

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

1605

一直都是用Vagrant

15

坐等 visual studio 可以开发 ruby 像 rubymine

96

windows本身就是痛苦

De6df3

还演示了 Sinatra 应用

1107

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

A908ae

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

96

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

2852

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

244

#11楼 @rei 太有同感了

96

#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环境是很痛苦的,目前微软官方的方案只是解决了部分问题。

4002

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

96

#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如果两个分支差异比较大,随随便便等个几分钟甚至更长时间。

总之用得很搓火。

9096

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

Eda824

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

12834

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

12834

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

9800

这个项目能否反哺wine?

1342

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

1107

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

1342

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

5508

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

1107

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

96

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

1107

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

96

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

96

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

1342

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

96

今天装上了, 我主要搞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命令用的不当)

1107

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

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