现在写代码本质上就是开发速度和质量方面的平衡，对一方面有要求就得另一方面有所妥协。

所以才会有软件测试工程学的存在，可以使用各种方法论来保障一定程度的质量的基础上尽可能提升速度。

老北京的东西，一种是过去食物匮乏，普通人吃不起肉什么的，只能吃些廉价的东西，在能吃到的东西里面算好吃的；然后到了现在人们消费得起更好的食材了，所以觉得那些不怎么好吃，仅仅是有一些老北京的味道而已。
另一种是，随着社会节奏越来越快，成本控制越来越狠，现在很多打着老北京旗号的店实际上没有严格按照过去的工艺使用正宗的食材做（也有的是不允许那么做了），就好比是在国外吃中餐，有那个意思，但不是那个味。

比如炸酱面，一方面属于是可以做得很好吃也可以做得很难吃，另一方面是每个人都有自己偏好的口味和做法，导致不少北京餐馆的炸酱面的都是唬弄外地人的，本地人也不爱吃。如果随机找北京人问哪里的炸酱面好吃，大概率会说老百姓自己家里做的最好吃。

往前倒几十年，物流和农业不像现在这么发达的时候，北方很多地区的食物种类都极其有限，比如过去北京冬天蔬菜基本只有屯的大白菜一种，鱼只有淡水鱼，想吃海鲜都不容易。南方很多全年食材丰富甚至临海的地区对这些北方地区算是降维打击，所以饮食文化相对发达一些，人们对食物的要求也更高。

@Puteulanus #26 @Puteulanus 打卤面一般来说都是家里自己做的最好吃 https://i.imgur.com/krir4IG.png

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 还是升级依赖还是升级系统环境都是一样的。

我 18 年配的 NAS 用的普通内存，跑到现在没有因为内存出过问题。

另一台服务器 Win10 基本每周都会出现莫名其妙问题，但重启可以解决，所以怀疑是系统内存 Bug 。后来换了 Debian ，就稳定很多了。

之前看到一个资深做定制 NAS 的商家说过，普通家用负载一年可能都不会出一次内存错误，所以一般也不会给客户推荐 ECC 内存。即便出了问题，大不了程序闪退，重新启动就好了。除非是那种出内存错误会导致其他严重连带问题的情况，比如文件系统。

看到有人提到了 DDR5 的 ECC ，这个也让我困惑了一阵子，后来才知道因为 DDR5 硬件本身技术难度，导致错误没法降到可以让人接受的程度，所以内置了某种 ECC 机制来拉高可靠性的，但这个顶多了是提升到了 DDR4 的可靠性，追求更高可靠性可能还是需要企业级 ECC 。

问题 1：

setTimeout 是 JS 里比较特殊的 API ，它本身是异步执行的，放到 Promise 回调函数里执行会马上返回一个计时器对象，Promise 也只能自主看到这个返回，而 setTimeout 回调函数内的代码是在倒计时结束后才会执行的，你不调用 resolve 或 reject 的话 Promise 就压根不知道执行完了（始终是 pending 状态）。

倒计时设置为 0 也是要进行倒计时，而不是说倒计时为 0 就将异步代码转成同步代码了。

建议看看 Event Loop 机制，然后搞明白 setTimeout 是在哪个阶段执行的，这块是 JS 异步的核心，搞不明白的话以后还是会有很多问题整不明白。



问题 2：

第一段代码同问题 1 。错误被 setTimeout 拐到异步过程里了，第一个 then 的回调函数没有捕捉到这个错误，然后就相当于是一个没有 return 的函数，默认返回了 undefined ，下一级 catch 没有捕捉到异常被忽略，再往下 then 接收到一个 undefined 值。

第二段代码第一个 then 的回调函数捕捉到了错误，将其作为一个 Promise.reject 传给下一级，下一级 catch 接收到这个 reject ，执行里面的代码输出了 err 的信息，同时这个回调函数没有写 return ，本身也没有返回一个 Promise 对象，所以默认返回了 undefined 给下一级，下一级 then 接收到了这个 undefined 值，然后运行内部代码将其输出了出来。

https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Promise/then
仔细看一下“返回值”部分，看看 then 是怎么工作的。

Manjaro 发行版，目前自在用 AUR 里的这个版本 https://aur.archlinux.org/packages/com.qq.weixin.deepin
除了现在有个强制始终最前面显示的问题以外，没有其他问题，分配个独立工作区用着还行。
其他发行版的话，你可以参考一下这个包的 PKGBUILD 脚本，应该都能装，就只是看依赖包的版本兼容性如何了。

我现在系统盘和重要资料都是 btrfs 快照增量备份到其他盘，其他资料是加了 snapraid 奇偶校验。

用驼峰的话，大写只是为了断词所以可以统一规定缩写也一律按照首字母大写其他字母小写的规则。

看语言、数据库等兼容性，比如有的语言核心库都是遵照某种风格的，或者有的数据库只支持某种风格，就尽量追求统一。

之前一种说法是，驼峰能少按键。

但归根结底还是看喜好。

我之前写 JS ，一种风格是变量用小驼峰，常量全大写+下划线，类型大驼峰。不同风格代表不同信息。