何苦用 win。。。
win+虚拟机+linux 是正解

去状态化+分布式负载均衡

两种策略：

以前玩的盗版，觉得不错，等 steam 上打折还债。
想玩的游戏，先加入愿望单，时常登上去看看有没有打折，打折到预算再买。

@111qqz Arch 也不是需要水平多高，只是需要基础扎实，我之前用了两年多没出过问题，一方面是靠使用习惯，另一方面是看硬件兼容性。
表示用了 Arch 的滚动升级和 AUR 之后就不想用其他发行版了。但说回来所有发行版都是基于 Linux Kernel 的，绝大多软件包也都是基于源码的，懂配置的话其实什么发行版都一样用。

基础扎实用 Arch，小白用 Ubuntu，逞强肯定折腾。

深度学习开发没玩过，不过既然都是 Linux 平台就无所谓发行版，看自己的喜好和习惯。

我们服务端用新版 Node 而不用 Babel 等工具的原因：
1. 服务器环境是确定的，不会有兼容性问题。
2. 所写即所得，运行和调试的就是自己写的代码。
3. 用原生提供的特性，避免被引入的库坑。
4. Current 版本的 Node 的可靠性足够好。
5. 0 配置，拉代码装包即可运行。
6. 修复架构相关问题，而不是靠补丁掩盖。
7. 已有特性的性能被进一步优化。

当然不同项目的情况不同，要根据实际情况选型。

平时服务端用 require，前端用 import，对比各自都没有绝对优势，只是不同的写法罢了，或者说 import 只是 ES 标准收录而已。

写 Node 程序用 Node ES 最直接简单，虽然 Node ES 比其他 ES 实现经常要落后一些，但也用不了多久就能追回来，而且其他 ES 实现最终也都是要转化成 Node ES 才能被 Node 执行。

Babel ES 可能更贴近于 ES 标准，但其实也就只有几个不疼不痒的特性而已。

TypeScript 在 V8 没有原生支持 ES6 的时候有优势，但是 ES6 出来之后好像也就没啥特别强大的吸引力要转，除非依赖哪个重要的包是基于 TypeScript。

现在众多的 ES 实现，都差不多，选择哪个主要是习惯使然，很少有因为某个硬性的技术需求而刻意选型的情况。

其实造成这种现象也和 ES 标准的制定流程有关，新特性会由各自 ES 实现者出草案，然后加入到自己的 ES 实现当中，开发者用起来，当某一特性被使用到一定程度的时候才会有资格接受评审，接受了社区的广泛试用才能正式进入 ES 标准，而各自 ES 实现者在实现新特性草案的时候基本上也都是互相交流、互抄方案的，所以殊途同归也是必然的。

@4ever911 其实对移动性没有需求的话，我之前的方案还是非常给力的，Win10 台式机，每天上班时间全屏虚拟机 Linux，下班快速休眠玩游戏，体验非常棒。

其实也幻想过，在网络情况理想的情况下，用超薄本远程桌面到工作站上办公，TeamViewer 之类的商业软件做得体验也挺不错的。

三年前一直在心痒攒钱买 x1 装 Arch，但分辨率、厚度和续航都不及 Mac，价钱相当，于是攒了个台式机。。。

目前公司送给我了一台 MBP 2016，基本上开一套 WebStorm+Chrome 的话，上午 10 点打开，下午 7 点还有 20%的电，拿着去各种开会非常方便。

x1、XPS 一直不断在优化续航，但好像目前还是达不到 MBP 的程度。

Mac 对程序开发工作逐渐不那么友好了，尤其是键盘，感觉重心偏向了视觉设计工作，系统对自由软件的支持也不完美。键盘手感好烂~~

感觉原 IBM 的用于高效生产的硬件设计+MBP 的分辨率和电源优化+完美的 Linux 兼容性会非常有市场。

企业是要赚钱的，性价比最重要，不同应用场景下不同操作系统的性价比表现不同。

我接触到的绝大多互联网应用都是基于 Java、Node、Python、PHP 的，可能用 Win 的话性价比优势不足，安全性、硬件利用率等都没有赢得市场的高度认可。
不过如果全用是微软的互联网技术，从语言框架到 IDE 到 Server 到 OS 买一整套的话可能能节省相当多的开发和运维时间，毕竟是商业产品，就看微软的技术是否适用于企业的产品，企业是否值得花大价钱购买商业产品换取开发和运维时间。

另一方面，现在互联网创业公司越来越多，大多数都是从小规模逐渐发展，企业营收目标要与融资余额赛跑，在免费的 Linux 与 800 多刀的 Win 之间选择的话大多还是屈服于省钱，这时候不用 Linux 的就显得有些特别了。

楼主受到鄙视的原因可能是，作为一个优秀的商业产品，win 的卖点是使用门槛尽可能低（不然这个商品做得未免太失败了，产品设计行业中有一种思维是“任何需要用户配置的产品都是失败的产品”），Linux 使用起来对技术人员的要求很高，所以思维定势地就变成用 Linux 的技术人员要比用 Win 的技术人员更厉害，就如同会心算的人比用计算器的人厉害。建议楼主在告诉别人自己的技术栈的时候突出自己的受益，比如受益于 Win 的产品设计，一个人可以高效管理上百台业务不同的服务器，这一点用 Linux 的话是很难做到的。

双方的锅。

拨打电话的员工搞不清楚紧急联系人存在的意义，放肆使用，是一种自私的表现。个人认为只有在员工犯法、重病、失踪等严重事件的时候才应该通知紧急联系人。
下班就切断联系，不留任何余地，把自己工作上存在的问题抛给其他人，未免有些不负责任。
公司员工没有建立关于非工作时间电话联系的原则，楼主遇到了问题也没有从公司和个人的双重角度，积极反思和沟通解决问题，此类问题无论是在这家公司还是在楼主身上肯定还会发生。

双方都有问题，才导致了最终的结果。

有些机制预防非工作时间沟通的情况，如：
1. 周五不上线。否则要求上线的人向 CEO 申请批准周末加班保障，当然加班费和加班福利要由公司承担。
2. 下午五点后慎重上线。主要是下午五点后是晚高峰，一方面会对服务性能有影响，另一方面如果有上线后出问题的风险的话，影响面太大。通常如果不是时令相关的话（如双十一或 618 之类的）建议第二天上午上线。
3. 写清注释、文档等必要信息，便与协作。
4. 建立异步工作机制。

非工作时间电话联系的情况，个人遇到最多的是上线后出问题的情况，有一些机制可以有效降低上线后出问题的风险：
1. 必须经过测试团队认证测试通过才能上线。
2. 灰度发布。
3. 上线后要有全面的回归测试。
虽然不能 100%避免，但绝大多数手癌或脑残问题都能有效避免。

以上只是想说明，没有解决不了的问题，只有不想解决的问题。

一言不合就离职或者开人的做法也并不明智，因为很可能大家一起商定原则、指定奖惩措施就可以解决和避免遇到的问题。毕竟没有哪家公司的管理机制是完美的，都要靠所有员工参与不断优化的。大家一起工作一起协作本身就应该是不断生产公有知识并转化成公共知识的过程。

另外个人认为工作生活分开是非常有助于工作和生活双方面可持续发展的，但并不意味着下班就完全切断和公司的联系，而是从自己的角度上不要认为工作比生活重要，从他人的角度上也不要认为非工作时间工作是理所应当。

我经常唠叨一句话：雇佣和受雇本身是双向选择的，也是遵循市场经济原理制约的，这是个良性过程，只是时间的问题。

如果不认同我的观点也没关系，因为既然发到 V2 上面，就给予了大家各抒己见的权利，当然人身攻击除外，总之一句话：如果双方都不想改善各自的问题，这样的公司我肯定不去，这样的员工我肯定不要。

组装机，8000 可以上一台高性价比的游戏 PC。
慢不慢一方面是硬件，一定要把 SSD 用起来；
另一方面是系统清理，父母用经常会被流氓软件安装很多用不到的程序，定期清理。

Pixel 原生 Android N 表示还好，半天时间支付宝只用了 1%的电量。。。

使用 MacOS 或 Linux 应聘微软会被拒嘛？

新版本可以发布修改的开源协议，禁止特定公司使用。
但是已发布的未修改协议的开源软件好像就不受限制了。
毕竟开源协议也是协议的一种，双方遵守。