不同公司情况不一样，而且很可能完全不一样，你可以问问公司老员工你们公司是啥情况。
家里是 2K 显示器和 4K 电视，公司里给配的是三星贴牌 23 寸 1080p 破显示器，没觉得不适应，处理文书还凑活。
这东西比较玄学，如果家里的看着舒服，就买同款就好了。
社会问题还得用社会学解决，技术是解决不了的。
跟管理小孩是一样的，首相要摸清楚到底为什么那些视频能吸引他，然后在用同样他能够接受的方式传达正确的信息，比如找一些相同风格但揭露智商税产品的视频。
多培养培养其他爱好。
有的行业是地区性的，比如程序员就那几个城市能选，回老家可能根本没有这个产业还不如转行做别的。
另外就是跟生涯规划有关，就是考虑 OP 提到的第 3 点，但不同时期考虑的问题不一样。
在用 R4S ，千兆宽带，跑透明代理、VPN 、DDNS ，网络内设备没有 PT 等高负载需要，就普通家庭应用场景，性能完全够用。如果满足于公网 500 兆其实 R2S 就够用。
一开始我是用的 All-in-one 方案，NAS 、服务器、软路由（旁路网关）在同一台机器上，但发现这三者的可靠性要求是不一样的，网络设备的可靠性要远高于 NAS 和服务器，在几次折腾 NAS 和服务器导致网络不可用之后，我就决定把网络设备分离出来了，专门的工作让专门的设备去干。而且当你想把各种用途全体现在一个设备上的时候，往往会发现可选择的产品很少，很可能找不到完全匹配需求的产品，而且价格也很难便宜。
其实在网络用途这个范畴里，软路由存在的意义基本也就是透明代理、VPN 、DNS 、DDNS 和各种网络分流需求，其他的基本都是 NAS 和服务器的范畴，不一定非要放在路由器上。上述需求中除了透明代理其实很多品牌硬路由也能胜任，比如我之前用的华硕路由就是自带 VPN 和 DDNS ，甚至可以插硬盘盒当轻度 NAS 用。如果只用于网络用途的话，软路由其实也并不需要多么强的硬件，除非你带宽很高或网络设备很多或网络拓扑很复杂。
软路由设备通常网口都比较少，网口多的价格也相对较贵，而且多口交换的性能也可能不如硬交换机。其实如果软路由是作为唯一网关的话，只需要一个 WAN 口和一个 LAN 口，内网流量完全不需要走网关路由，公网只需要网口和处理性能能支撑住你的公网带宽就行。两口软路由加若干便宜、可靠、速度快的硬交换，可能是大多情况下玩软路由的正解。我现在就是把原来用的华硕路由调成了交换模式，兼任 AC 和 AP ；还把另一个运营商送的还比较不错的路由关闭 WiFi 、调成交换模式当硬交换机用。
看 OP 可能只是对路由的性能有要求，对功能要求并不多；那么首选考虑的方向应该是提高硬路由硬件配置，软路由只能效率更差需要更多预算买配置更高的。可以考虑看看二手企业级路由。
现在写代码本质上就是开发速度和质量方面的平衡，对一方面有要求就得另一方面有所妥协。
所以才会有软件测试工程学的存在，可以使用各种方法论来保障一定程度的质量的基础上尽可能提升速度。
老北京的东西，一种是过去食物匮乏，普通人吃不起肉什么的，只能吃些廉价的东西，在能吃到的东西里面算好吃的；然后到了现在人们消费得起更好的食材了，所以觉得那些不怎么好吃，仅仅是有一些老北京的味道而已。
另一种是，随着社会节奏越来越快，成本控制越来越狠，现在很多打着老北京旗号的店实际上没有严格按照过去的工艺使用正宗的食材做（也有的是不允许那么做了），就好比是在国外吃中餐，有那个意思，但不是那个味。
比如炸酱面，一方面属于是可以做得很好吃也可以做得很难吃，另一方面是每个人都有自己偏好的口味和做法，导致不少北京餐馆的炸酱面的都是唬弄外地人的，本地人也不爱吃。如果随机找北京人问哪里的炸酱面好吃，大概率会说老百姓自己家里做的最好吃。
往前倒几十年，物流和农业不像现在这么发达的时候，北方很多地区的食物种类都极其有限，比如过去北京冬天蔬菜基本只有屯的大白菜一种，鱼只有淡水鱼，想吃海鲜都不容易。南方很多全年食材丰富甚至临海的地区对这些北方地区算是降维打击，所以饮食文化相对发达一些，人们对食物的要求也更高。
Manjaro 在我这的战绩有 2 个：
一个是 Intel 平台上装的系统，系统盘直接插到 AMD Ryzen 平台上可以正常使用；
另一个是超过半年没更新，更新后可以正常使用。
现在在用的 2018 年的雷蛇笔记本，Manjaro 装上触控板、蓝牙、wifi 、盒盖休眠、唤醒都可以正常使用，唯独接上多显示器的情况下休眠再唤醒会有显示问题，但我只需要在休眠之前把接显示器的扩展坞拔掉就行了。
之前用过很多年 Arch ，对比之下感觉 Manjaro 非常稳定。
我个人认为软路由在交换方面不如硬交换机性价比高，而如果软路由是作为唯一网关的话，1WAN 口+1LAN 口能满足公网带宽需要就够了，内部网络交换靠便宜、性能好、可靠的硬交换机就行了。
当然看你的“软路由”是不是只网络相关工作。出于吃多了 All-in-boom 的苦，我现在基本都是专门的设备干专门的工作了，硬件选择会更多，成本也更低，可用性还更高。
理论上是的，只不过 smb 本身性能损耗比较大，换个其他性能好的协议就好。
虽然不是打游戏的场景，但我目前就是一台高性能服务器用 NFS 挂载另一台 NAS 的存储空间，然后服务器上的服务都会经过这个 NFS 通道直接读写 NAS 上的存储空间。当前瓶颈在存储阵列的速度上。
include 存的是头文件吧，有的你只装预编译的内核不装头文件包也就不会有这一部分。
不管是库还是应用程序，都看是不是调用内核的特定版本才有的 API ，如果你换了一个 API 不兼容的内核，这些库和应用程序就会因为调用不到相应的 API 而无法正常工作。不过貌似这方面比较少见，绝大多数还是使用比较稳定的 API 的，很长时间里的内核版本都是兼容的。
如果遇到现有库和应用程序与新内核 API 不兼容的情况，就要看可不可以使用兼容版本的库和应用程序，或者看是不是编译过程支持按照新内核的特性来选择 API 编译。
现在很多发行版都支持同时安装多个内核，重启的时候可以在启动界面切换内核版本，如果一个版本的内核不能让系统正常工作，可以重启选择旧内核。
该投诉投诉，该退钱退钱，运营商让步空间挺大的，就看你能不能闹，等补偿好了，再找个靠谱的套餐换上。
对 NAS 来说，功耗大头实际上是硬盘，一块机械硬盘功率在 10W 左右，一块 SSD 功率在 4W-10W 左右，随便拿几块盘组个阵列就超过其他硬件的功耗了。
你这个功耗已经很低了，我的服务器 CPU+硬盘+显卡空载还 60W ，再优化估计就得停机了，能休眠的都休眠，用的时候再唤醒，但这样又会降低使用体验。
感觉这时候最理想的是大小核架构，低负载的时候大核心休眠，负载上来了又能抗很高的性能需求。
不知道分布式能不能这么搞，比如低负载的时候将 pod 部署在低功耗机器上，负载增加了自动调度唤醒高功耗机器干活，干完了负载降下去了再释放。
patch 版本通常都会修复 bug 和安全漏洞的，所以一般能升就升。
minor 版本通常会引入新特性，或积累比较多的更新，出了一个 minor 之后就不会出上一个 minor 的 patch ，所以一般能升就升。
major 版本通常有支持周期的，如果过了周期也就不会有修复 bug 或安全更新了，所以最好随时保证 major 版本仍有更新支持。其他的就是看依赖包是不是兼容，像 gyp 包就有可能跟 major 版本强相关，node 过新可能编译失败。
当然不管什么时候给项目升级，都要做好测试，最好能灰度发布看一看；这个不论是升级 node 还是升级依赖还是升级系统环境都是一样的。
Select Language