使用 Windows 六年后，我后悔了 | 畅言

edpedp · 发表于 2019-4-9 21:46:16

“六年以来，我一直坚持使用 Windows 开发最适合在 Linux 上运行的应用程序，因为我习惯了使用 Windows，而习惯很难打破——以前我并不是十分清楚我为之付出的代价，但数据表明，是时候做出改变了！”! W" ?! E# j. i; f) r1 x+ n/ N

作者 | Sam Saffron
译者 | 弯月
责编 | 郭芮
出品 | CSDN（ID：CSDNnews）
以下为译文：
最近，我的这篇推文颇受欢迎：

我们测试了一下在各种开发机器上运行Discourse的Ruby测试所需的时间，我用亮色标出了我的结果，难以置信这么多年来我坚持使用Windows付出了如此大的代价。
这篇推文引起了很多人的强烈反应。有人说：“Sam，你个呆瓜，这算哪门子的测试基准？”，也有人说：“这个故事说明MacOS运行Ruby的性能很差。”，也有人只是说了一句：“天啊，不会吧。”
我想表明的主要观点是：我为“坚持使用Windows”付出了惨重代价。当然，这中间隐藏的其他一些点也值得讨论。

为什么你坚持在Windows的虚拟机中运行Linux？
以前我并不知道我会随时为使用虚拟机付出代价，我的电脑上从来没有配置过双启动，所以我没有适当的参考。
我非常坚信，许多Ruby / Rust / Go / Elixir / Scala，甚至是一些Node开发人员，他们都使用了WSL，或者在虚拟机上运行Linux，或者在Windows上使用Linux Docker做开发，他们肯定也不清楚其中的代价。
以我的机器为例，WSL会导致日常运行速度下降25%，而使用基于VM的虚拟系统会导致速度降低38%。
我并不是唯一一个遭受这种损失的人，我们团队中的其他人也经历了相同的速度下降，而且外面有很多人也有类似的经历。
在内心深处，我一直天真地希望我所看到的性能下降很小。如果你搜索一下Google，也会得到相同的答案。用不用虚拟机并不重要，只会造成5-10%的性能差异。也许我只是忽略了一些关键的BIOS设置，也许我需要直接挂载卷，而不是在专用的NVMe Samsung 960 pro上使用vmdk，也许我可以通过一些其他的手段来实现1-5%。也许Hyper-V更好，但我不确定。我所知道的是，我并不是唯一一个这样想的人。
我无法使用WSL，因为根据WSL团队的文档，Ruby中的大量小文件和大量stats调用的性能非常差。有多差呢？作为比较的基准，在WSL上运行rails c控制台（不使用bootsnap）至少需要30秒。同样的操作在Linux上（不使用bootsnap）只需要4-5秒。即使采用了一切规避手段，如此糟糕的IO性能也很显眼。实际上，我宁愿使用速度减慢38%的虚拟机，因为至少一切都是始终如一的，不像WSL那样各方面的性能非常不均衡。在开发过程中，快速启动控制台或Web服务器至关重要。短时间内Fuse也不太可能实现，所以也没办法通过挂载块设备的方式来规避这个问题。
所以，我只能坚持使用虚拟机，这样我不需要反复重启电脑，所以我以为代价不会太高。
我喜欢Windows 10的字体渲染，我喜欢HiDPI支持，我喜欢在Windows上使用Lightroom，我还要在Windows上玩Rocksmith。我喜欢它提供的开箱即用的体验，只需要最低限度的定制。我喜欢在启动Skype时不会由于LD_PRELOAD jemalloc而产生段错误。我感觉Windows 10是最好的窗口管理器（对于我的使用而言），远远超过我的Macbook Pro上运行的MacOS。
双启动是个折中方案，有些东西最好在Windows上运行。我认为我以性能的代价换来了使用一个“熟悉”的OS时获得的便利性，这也算物有所值。
我感觉如果我不得不启动Linux，就需要处理各种各样的驱动和稳定性问题，而不是拥有开箱即用的一套工具。
我喜欢安于现状，我这个人生平最不喜欢改变。

2019年是Linux桌面系统年吗？
这个笑话的起因是：每年都会有一群人开玩笑说今年会是Linux桌面系统年，年年如此。刚开始时总有人说：“最近Linux的发展形势大好，今年是不是可以作为Linux桌面系统年了？”然后就会有一堆欢乐的嘲讽，还有哈哈……别再犯傻了……今年不会是Linux桌面系统年等等。
久而久之，这种笑话就传播开了……
一般来讲，这些笑话都没有恶意，而且不久就会平息。但是，这个笑话有个巨大的副作用，甚至会对开发人员产生重大影响——不使用Linux作为桌面系统的开发人员会对Linux产生恐惧心理，即便他们的产品在Linux（而不是MacOS或Windows）上运行，他们也会惧怕Linux。
而我个人也曾被驱动、字体渲染、HiDPI支持、多显示器支持等东西吓怕了，所以从来没有尝试过Linux。
实际上，我的害怕并不是没有道理，运行Linux很麻烦。在努力了4~8小时之后，我还是想放弃，因为Linux上的Firefox仍然有一个严重的问题——默认情况下不支持硬件加速，所以翻页非常卡。这个简单的问题就足以让我放弃Linux。如果网页无法平滑滚动，那我就不会使用Linux。幸运的是，这个问题只需要在about:config中修改一个值即可。
NVIDIA在Linux上的情况也不妙。Linux桌面系统的未来是Wayland。而我想要尝试的窗口管理器sway只有在使用开源社区提供的nouveau驱动时才能正常工作。就连让NVIDIA正常工作都需要启用硬件组合还要修改X11配置。
我不认为Linux今年能够席卷全球。它没有那么重要。但如果你渴望最佳的性价比，想要在开发Discourse或任何Ruby on Rails应用时获得最佳的性能，那么就不要使用虚拟机，在笔记本上安装Linux桌面系统才是你的最佳选择。
此外，还有一个重要的问题：我在切换到Linux时选择了一条比较困难的途径——我距离从源码安装Linux只有两步之遥。

与我有类似经历的同事从Windows/Mac切换到Linux，并坚持使用Ubuntu和Linux Mint，他们说切换的过程非常顺畅。

你尝试过在Windows上运行Ruby吗？
几天前这个问题引发了许多讨论。

这个人想说明，如果Ruby能够在原生Windows上顺畅地运行，那么就可以大幅增加Ruby的接受程度，并且可以防止人们转向其他框架。因为安装一个全新的OS是很高的门槛，只是说“安装Linux”并不能解决问题。
而现实是，在Windows上运行MRI Ruby有两个重大的根本性问题：

Windows上的NTFS文件系统性能十分不适合目前的Ruby设计。我们喜欢Ruby的一大堆小文件，我们喜欢大量的stats调用。6 R) M1 r3 l& x: a" i* }( |
将各种依赖包移植到原生Windows（并维护它们）需要巨大的工作量，因为Discourse的许多依赖根本不支持Windows。gem完全无法安装。根本性的问题是，你必须要付出额外的工作在gem中编写C语言扩展，才能在Windows上运行。而在绝大多数情况下，在MacOS或者Linux上运行根本不需要任何额外的工作。( r9 q3 U( a( r9 _6 a4 J

第二个问题很容易解决，但考虑到WSL提供的兼容性远远超过了Windows本身，如果文件系统问题能有合理的解决方案（这个问题至关重要，而且Windows下这个问题必然存在），那么可能就不需要大费周折了。Discourse在WSL上运行得很好（只要你不跑unicorn），但在Windows原生的Ruby下完全不能运行。苹果的代价与Windows WSL的代价类似（除了文件系统性能问题之外）。
我认为，只要WSL能再优化一些，就足以媲美目前的Mac了。

苹果的性能代价
从上述性能测试图中不难看出，苹果的性能代价也很严重。
仔细观察一下UserBenchmark: Intel Core i7-8559U vs i7-8750H。我们以为8559U的单核性能远超8750H，但是，这台装了Linux的8750H笔记本只用了9分13秒，远胜Macbook Pro的15分16秒。从中可以看出MacOS的性能很差。而且并不仅仅是我一个人有这种看法：

似乎人们坚持认为原生的MacOS体验正是在Mac上开发Ruby on Rails时需要付出的代价。
我知道DHH非常喜欢iMac Pro并极其推荐。

没错，它的硬件非常优秀，屏幕非常漂亮，机器本身也非常好。窗口管理器也很不错，也没有驱动问题。但很不幸的是，在MacOS上进行Ruby on Rails开发依然需要付出不可忽视的代价。
我认为Ruby社区应该调查一下这个问题，记录该问题的各个方面，看看能不能有所改进，让Darwin的性能接近Linux的性能。这个问题是源自文件系统？操作系统？Ruby使用的llvm编译器？还是MacOS的安全特性？是否跟Spectre+Meltdown有关（这个问题在Linux上已经打过补丁了）？目前来看原因依然不明朗。
因此，如果你在Mac上双启动安装Windows，然后安装WSL，通过Mac+Windows+WSL的方式在运行 Discourse测试套件时获得更好的性能，我完全不会感到意外。而且我敢打赌你肯定会这么做。
所以，如果遇到有人说：“还有一个办法，安装黑苹果就好了”。你可以告诉他们，这样做不仅在每一次MacOS系统更新时你都需要冒险，而且也同样要付出与Windows类似的代价。

并行测试怎么样？
Rails 6马上就要发布了，这是Rails首次拥有官方支持的并行测试。我在Linux系统上运行Discourse的测试时，整个过程用了8分钟，期间CPU的使用率不足10%，IO也没有达到饱和。
所以，当我得知在Windows机器的虚拟机中，即使性能下降了38%，并行运行也能在两分钟内跑完测试时，我感到十分震惊。
所以，前面大费周折，却放着这么明显的问题视而不见，这不是很奇怪吗？
我完全同意，Rails的并行测试非常出色，相信很多开发人员都会非常高兴。
此外，对测试套件进行性能评测，同时干掉速度过慢的测试用例也十分重要。
我们将在开发环境中采用并行测试。
但这不是重点。我面临的问题在于，一直以来我的机器的运行速度都被钳制，所以就算测试的运行速度非常快，放到我的机器上依然无法发挥到极致。

今后的选择
目前，我对家里的Arch Linux很满意。现在不仅程序运行速度加快了，而且由于我使用的窗口管理器远胜mac或Windows，我的工作效率也有所提高。当然代价还是有的，以前使用Windows时不需要考虑的很多问题，如今都需要解决，但是回报也十分丰厚。
长期以来我一直在使用i3wm，但从来没能下决心在两个窗口管理器中做出抉择。如今i3是我唯一的选择，我从中也获得了丰厚的回报。我的计划是每隔几个月就尝试不同的平铺式窗口管理器，直到找到最适合我的那个。
6年以来，我一直在坚持使用Windows开发最适合在Linux上运行的应用程序，因为我习惯了使用Windows，习惯很难打破。以前我并不是十分清楚我为之付出的代价，而且我觉得许多开发人员也跟我一样。
我只有一条建议，那就是……不要害怕尝试。Linux的桌面系统越做越好了，在硬盘上划一个分区出来做成双启动也十分容易。如果你和我一样在两个世界之间举棋不定，特别是如果你使用的是台式机而不是笔记本，那么还是建议你尝试一下。
欢迎留言分享你的评测结果和经验。希望看到更多在同一台机器上比较MacOS和Linux的评测结果，以及Windows+WSL/虚拟机和Linux的评测结果。
原文：https://samsaffron.com/archive/2019/03/31/why-i-stuck-with-windows-for-6-years-while-developing-discourse
本文为CSDN翻译，转载请注明来源出处。
【End】

热文 推荐

戳他↓↓↓

System.out.println("点个在看吧！");
console.log("点个在看吧！");
print("点个在看吧！");
printf("点个在看吧！\n");
cout

账号		自动登录	找回密码
密码			立即注册

使用 Windows 六年后，我后悔了 | 畅言

本帖子中包含更多资源

浏览过的版块