微软打算在为 WSL 提供一个真正的 Linux 内核

[qcts33]

https://devblogs.microsoft.com/commandline/shipping-a-linux-kernel-with-windows/

不知道是不是为了提供 Docker 的支持才这么干的，而且 Linux 内核是不是需要用 Hyper-V 的虚拟化啊？

感觉从原来的转译 API 变成基于虚拟机的结构在某种意义上说反而是倒退了……

另外，这个话题应该属于哪个节点啊……

[deorth]

感觉这个不好实现啊，也不知道实现出来是什么样的效果。看评论似乎是只虚拟化用户空间？那需要内核提供的功能(比如挂载 ext4)还是没法实现？

[rayhy]

不说别的，对 https://github.com/microsoft/Terminal 很期待！

[k9982874]

@rayhy #2 同等 ms terminal，现在的 cmd 太烂了

[Track13]

感觉是 Hyper-v。我选择 vm

[ly50247]

为什么说是倒退呢？从性能上讲 API 转译并不比虚拟机实现更高（做性能测试的话，很多情况 WSL 要比虚拟机要差，只有一部分会强些），功能上也存在缺陷。重点还是和 Windows 环境整合上，比如访问 Windows 分区中的文件、互相调用程序等等，只要这些功能都高效地实现了，是否用虚拟机实现是没有什么区别的。而且实现了这个的话，原来用其他虚拟机运行 Linux 的用户，也不再需要继续使用其他虚拟机了，这样基本上也就不存在多个虚拟机不能共存等可能的问题了。

[cdwyd]

只要是网络，文件还是能够方便的共享访问的话，怎么实现无所没

[redsonic]

巨硬的 VM 支持硬件虚拟化，不会比 api 转译慢。

[0attocs]

@ly50247 wsl 好像是 io 性能低吧？甚至关闭 windows defender 等杀软后 wsl 性能会大幅提升………

[qcts33]

@ly50247 确实从用户角度来说肯定不是倒退。我说倒退是从实现的角度来说，总觉得原来的转译的技术实现有一种让人眼前一亮的感觉，这回使用虚拟机的实现就感觉没有那么惊艳了……而且原来花那么大力气写得转译层就这么浪费掉了

不过仔细想想，如果能把 Linux 内核与 window 用户界面的互操作做得比较无缝的话估计也不是什么简单的事情，不知道什么时候能进入 release

[qcts33]

@redsonic 说到巨硬的硬件虚拟化，hyper-v 不是 win10 专业版才能开启的吗？ win10 家庭版不会用不了新 wsl 吧

[ly50247]

@0attocs 不关闭是干脆没法用的，关闭后和原生（包括虚拟机中的） Linux 相比性能依然比较差。

[ly50247]

@qcts33 如果真的在用户体验不下降的前提下用虚拟机实现了，那只能说之前的技术选型出现严重失误了，比如低估了 linux 内核完整功能的实现难度，高估了转译的性能，那样及时止损也是一个比较理性的选择。但至少有些组件（比如文件系统互访问相关的）可以继续沿用。以后发布了先看下什么情况吧。

[qcts33]

@deorth 应该是虚拟化内核空间吧？不过内核里面文件系统这一块的东西要怎么处理确实是个大问题。我觉得挂载 ext4 这种能力还是比较悬的，搞不好相关驱动会被去除，然后还是靠转译的方式实现对 ntfs 的互操作，否则不好跟 Windows 本身的用户界面做整合。

[qcts33]

@ly50247 从测试来看在计算为主的应用中转译的性能其实是相当不错的，估计主要是低估了完整模拟 Linux 内核的难度。不过感觉文件系统互访问这个最大的性能瓶颈是怎么也绕不过去了……

[ly50247]

@qcts33 我之前想是不是可以把 WSL 的文件系统放到一个单独的文件里，像虚拟机镜像，那就不需要和 NTFS 的各种东西打交道了。但影响编译速度的还有一个很重要的进程启动开销，不用虚拟机的话估计很难优化了。

[springmarker]

官方也说了是靠虚拟化实现的，本质上跟 Hyper-V+Linux 一样，不过这个是更加高度集成化、更加轻量。GPU 加速也指日可待了。

[0attocs]

@ly50247

你始终无差别说 wsl 性能差，有什么依据吗？

1. 据我所知，wsl 不是像 wine 那样的转译，而是实现了一个 linux kernel。
2. 因此，WSL 的主要问题是 IO 性能差（关闭 windows defender 可大幅改善，WSL2 宣传就是 IO 提升），非 IO 性能和 native 几乎一样[1]。
3. 不关闭当然是可以用的，我日常用 wsl 下的 emacs 写 LaTeX 和 Coq，用 X11 绘制在 windows 里。
4. wsl 是 windows mobile 的遗产，目标是日常使用环境。wsl2 的目标是生产环境。

[1] https://www.phoronix.com/scan.php?page=article&item=windows-1804-wsl

[reus]

@ly50247 实现一个读写宿主机文件系统的内核模块不就行了，哪有那么复杂。现在的虚拟机都有现成的共享文件夹方案了。

[0attocs]

@qcts33
官方说家庭版也可以用 wsl2，因为 lcow 是跑在 type-1 hypervisor 上的，和 windows side by side，不需要专业版的 type-2 hypervisor license 和 GUI。

[reus]

@0attocs wine 和 wsl 一样，都是实现了 windows 或者 linux 的系统调用，以使现有 binary 可以执行，原理是一样的

[ly50247]

@reus 能访问不难，高性能就不容易了。现有虚拟机的共享文件夹性能是比较差的。这个事情主要还是在虚拟机本身做，而不是在内核模块做。按理说以现在 WSL 的基础实现一下并不是很难吧，所以这一点还是比较看好的。

[ly50247]

@0attocs 我并没有无差别地说 WSL 性能差，但很多性能测试上确实多数项目都是有差距的，比如你发的那个。里边确实有一些占优的，但优势都很小，而其余的基本都差很多。当然可以说主要是 io 性能差导致的，但不能说 io 提升上去后就没有差距了。比如 Windows 下进程启动开销比 Linux 下大基本是常识，自己写个脚本启动一千个 /bin/true 测下时间就知道了，这个和 io 没太大关系了。而编译时要启动大量进程（比如编译 c，一个文件就要启动好几个进程用来预处理、编译、链接等等）。

[0attocs]

"为什么说是倒退呢？从性能上讲 API 转译并不比虚拟机实现更高（做性能测试的话，很多情况 WSL 要比虚拟机要差，只有一部分会强些），功能上也存在缺陷。"

这是你的原话。误导在于：wsl 不是 api 转译，而是几乎 native，不存在因此产生的性能下降。IO 几乎是性能下降的唯一原因。



“我并没有无差别地说 WSL 性能差，但很多性能测试上确实多数项目都是有差距的，比如你发的那个。里边确实有一些占优的，但优势都很小，而其余的基本都差很多。当然可以说主要是 io 性能差导致的，但不能说 io 提升上去后就没有差距了。比如 Windows 下进程启动开销比 Linux 下大基本是常识，自己写个脚本启动一千个 /bin/true 测下时间就知道了，这个和 io 没太大关系了。而编译时要启动大量进程（比如编译 c，一个文件就要启动好几个进程用来预处理、编译、链接等等）。”

请不要臆测了。仔细阅读下文：
https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/

[ly50247]

@0attocs WSL 的实现是将 Linux 的 API 转义成 Windows 内核中的现有实现。其余的我想已经说得足够明白了。

[0attocs]

@ly50247 嗯，你对 wsl 的系列离谱理解和无依据的断言已经错得足够明白了。

[xiaoyanbot]

去年建的群，来，继续讨论讨论哈：

qq 群 257277694

[reus]

@ly50247 程序要做 io，当然要通过内核模块。读写文件，就需要先通过实现了该文件系统的内核模块，ext4 / ntfs / btrfs 等等，这些文件系统内核模块又依赖块设备内核模块，例如硬盘、lvm、远程块设备等等。这都是一层层从软件到硬件的。我不知道你说的“这个事情主要还是在虚拟机本身做，而不是在内核模块做”是什么意思。虚拟机虚拟出来的是硬件，要想利用上，必然需要相应的内核模块。

既然 wsl2 打算用虚拟机跑一个 linux 内核而不是兼容层，那实现一个文件系统内核模块，来做和宿主系统的文件系统的互操作，是最自然不过的。

[0attocs]

@reus
不一样。wsl 首先是在 nt kernel 里实现了 picoprocess 等等 linux kernel 的东西，而不是如 @ly50247 所说的使用“现有实现”。然后在 nt kernel 上实现了和 win32 api 平级的 linux api。

[reus]

@0attocs 读写 ntfs 也重新实现了？网络栈也重新实现了？
wsl 1 是一个兼容层，可以让 ELF binary 跑在 windows 环境下，picoprocess 是这个兼容层的一部分。进程用了 picoprocess 不代表所有其他东西都不使用现有实现。像网络栈，你不用 nt 现有的，wsl 自己重新实现一个？
wine 也是一样的兼容层，让 PE binary 可以跑在 windows 环境下。它们的原理都是提供 ELF / PE 可以使用的系统调用，所以原理是一样的。
我不知道你说的“转译”是什么意思，wine 并没有将 PE 转成 ELF，wsl 也没有将 ELF 转成 PE，都是实现了一个兼容的环境去让它们运行。

[reus]

@0attocs s/让 PE binary 可以跑在 windows 环境下 /让 PE binary 可以跑在 linux 环境下

wsl 1 的网络，参考 https://blogs.msdn.microsoft.com/wsl/2016/11/08/225/ ，TCP/IP 栈及往下，都是共用一个实现，这难道不算使用现有实现？

wsl 2 就可以不使用 nt 内核的 TCP/IP 栈而是使用 linux 内核的 TCP/IP 栈，只需要共用链路层或者网卡驱动等。

[redsonic]

@qcts33 19 楼答案。

@springmarker hyperv 目前无法家用，gpu 很差，有时候客户机的声卡莫名其妙崩溃，merge 数据的时候机器休眠会造成未 merge 的数据丢失，除了 cpu 效率高以外，不比其他家的产品好哪里去。不觉得 WSL2 会吸引跑虚拟机的普通 linux 用户。

既然巨硬造了自己的终端是不是下面要造个 X11 或 wayland 服务器。

[qcts33]

@reus 转译这个说法是我先开始用的，我所说的转译跟你说的兼容层应该是一个意思。因为按照我的理解，这个兼容层的提供 ELF/PE 调用的方式就是把相应的调用转换或者说转译成底层系统实际支持的调用，从而实现相应的功能。类似于软件工程里所说的适配器模式。

[huiyifyj]

@rayhy #2
最近好像有消息了。
https://devblogs.microsoft.com/commandline/introducing-windows-terminal/
他们说可以在 windows 商店下载，可能我解锁的姿势不对，没找着，可能要换区，但我不愿捣腾了。

[qcts33]

@huiyifyj 说了是 This summer in 2019，估计还得一两个月吧

[huiyifyj]

@qcts33 #34
我看 YouTube 里官方宣传视频下面有评论说商店有下，是不是也不清楚。

[mmdsun]

只要速度提起来，兼容 vm 我就很满意了

[happy123]

关于 WSL CPU 性能，我有个实际例子：

我在一台 E5-2620 的机器上跑 pbkdf2，基本上没有 IO 操作，分别在原生 Linux，Windows，WSL 里面测试了 pypy3.5.3, python3.6 下的性能，令我震惊的是，WSL 里面竟然跑赢了原生 Linux 20%!

这不是人品问题，而且是一个单一的加密算法，我在三台机器上测试过，得到的结果都是一样的，所以现在我的一些高计算量的东东，我做到 Python 的 c 扩展里面，用 WSL+pypy 来跑。

至少对我来说，WSL 带来的性能提升好处是实实在在的，很科幻。

[happy123]

基于以上认识，作为 Pypy 党，我得说 WSL 真香。

WSL2 啥样呢？期盼。

[jon]

所以用了 wsl2 就不能用 vagrant ？

[hljjhb]

@happy123 这么科幻的么 Windows 原生跑差距有多大呢

[smdbh]

感觉配套的东西太多，难搞。还是继续虚拟机吧。

[lizhuoli]

我一直认为原来的 WSL 技术选型有问题，像是为了复用代码或者说拯救已经死了的 Android on Windows，选择了一条实现 Linux System Call 这条路，毕竟 Linux 历史兼容代码太多，Cleanroom 再怎么写就是个无尽的坑，早就应该用硬件虚拟化或者双内核搞这种事情

[sean250031]

自己比 ms 厉害系列

[daya]

@0attocs 为什么说 WSL 是 Windows Mobile 的遗产呢

[qcts33]

@sean250031 额，我哪里有说自己厉害……我只是觉得基于虚拟机的结构不那么“酷”而已，有一点中二的想法😂😂😂

[RenJianHeNian]

@smdbh 虚拟机上装 ubuntu 再装 idea、git、sourceTree、beyondCompare、maven、docker 等等一整套完整打的开发环境，然后在虚拟机上开发，香吗