wget -F -i html 文件

在这里加不加 -o- 没什么区别。

ctrl + t 可以开标签页，然后菜单也有了，可以再折腾下，目前看一个严重 bug 就是输入法窗口不跟随。

@springmarker 谢谢，下载试了下，和演示的不一样，没有右上角的菜单，不知道怎么配置和开标签页，输入法窗口不跟随。但界面看起来还可以，半透明效果，滚动条处理得比较好。

可以装个 vs 编译试试。

技术上估计没问题，但得试用下才知道会不会有让人不舒服的小毛病。不过即使官方的不好用，第三方的也会比现在繁荣很多吧。

@TonyHoAspire 编译是没问题的，和编译什么没关系，就是速度慢些。

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

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

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

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

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

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

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

@guiqiqi 不是道德上好不好的问题，而是事情的发展不会像你想象的那样，你要吃亏的。

假如你平时半夜上网，突然从某一天开始半夜就上不了网了，你会不去查原因就直接改睡觉吗？你会不会想为什么半夜上不了网了白天又正常了？你会不会想问题出在哪里，是谁干的？你会感谢那个试图让你作息更合理的人，还是不善罢甘休？

很多问题不是技术能解决的。不过早点吃这个亏代价确实会小点。

可以用 python-ffmpeg，或者直接调用 ffmpeg。