我想到几种方案：
1. 单臂路由方案，弱电箱换装 VLAN 交换机，软路由迁移至其他散热良好的端点作主路由，缺点是主路由必须用 openwrt 实现 VLAN 和拨号，且出站流量理论上限(1000/2)Mbps
2. 主路由换用 DMZ/UPnP 支持良好的硬路由，买一个蒲公英 X1 盒子负责 DDNS 和转发等任务。

Android 原生不是有多用户功能吗？ MIUI 的双开就是用多用户包装出来的。
128G 还嫌臃肿这事跟系统没太大关系，只是你用太久了，手动备份数据后恢复出厂设置就是了。

自己组装几台放办公室里好了，维护也不用看别人眼色，我这边不少组就是这么干了。让教授出点经费搞几台组装机还是容易些的吧?放异地机房又没远程管理和可用性保障的话那没啥优势。
管理的话组内专用不给 root 问题也不会很大，或者就弄个 portainer CE 。

没有，S3 的定义就是关 CPU ，外设低功耗，仅保留可以 offload 的必须功能，或者直接关闭，例如网卡 offload 在 S3 负责 NS 和 ARP 响应。剩下的都是要 CPU 参与的当然就没法用了。
S0ix(Modern Standby Connected)是替代方案，如果硬解不支持那就用节能的电源配置吧，新硬件也没有特别费电的。

路由器软硬件和硬盘有问题的可能性很大。

@mutalisk
我这里说得不太严谨，应该是打不过 NIST 曲线。
SM2 跟已经广泛部署的 P256 没显著差别+生得晚，就是输了。
跟 TLS 密钥交换可以使用自定义群（因为有被攻击的可能，还没什么人用，在 1.3 被删除）不一样，X.509 的 ECC 公钥好像只能用具名曲线(用 OID 标识)，所以不更新软件就不能用。

搜到了个关于 SM2 的测评。
https://developer.aliyun.com/article/785339
看文章说法，问题蛮多的，SM4 速度打不过 AES ，SM2 打不过 EdDSA 。
而且以前国标还强推客户端证书和双证书体系，换句话说，除非你有脱裤子给上面看的需求，否则强行适应这种标准都是负收益的事，而且现在上面也不喜欢用这种方法了。

SM2 、SM3 、SM4 都是有在 IANA 注册的，由 RFC8998 定义，也就是说在特定系统上使用这些算法是没有障碍的。
包括 TLS1.3 密码套件（ TLS_SM4_GCM_SM3 ，TLS_SM4_CCM_SM3 ），签名模式 sm2sig_sm3 ，群 curveSM2 。
至少 openssl 支持这个是无压力的，实际上一些银行 U 盾也有用这个。

但民用市场得考虑软件兼容性，你没有靠谱的办法让 XP 上的 Schannel SSP （ Windows 上的默认 SSL/TLS 实现）支持 TLS1.3 和 SM 系列，要知道 TLS 可以自动协商用什么密码套件，但证书种类可没法协商，客户端不支持就直接终止连接了。这也是为啥现在那么多网站证书还用 RSA2048 而不是 ECC 一样。

考虑到 SM2 也是一种 ECC ，在兼容性差于 ECDSA P256/P384/P521 （换句话说就是既生瑜何生亮），曲线参数同样有来源不明的问题，就算要换代，EdDSA(Curve25519)是设计透明度、安全性、性能上更好的选择，SM2 都可以直接跳过了，如果不是政策要求都没必要特意折腾这个。

不敢认同。
这些 ssh 客户端一般是先下载到本地临时目录，然后用编辑器打开，检测到变化后自动上传。如果不是覆盖上传而是别名上传后 rename 的话不应该出现你说的问题。
干这行的谁不是标配一个高级编辑器，除了高亮还能做做自动检查和格式化；除非是编辑空文件，大部分编辑器都不会主动修改编码和换行符。
至于 sudo 问题，那只适用于直接在 ssh terminal 跑远程编辑器的场景，想用本地编辑器就得先 copy ，改完上传再 copy 回去，如果是反复改的情况会很烦。而且一般远程编辑器功能有限又缺乏配置，如果网不好的话响应还慢，不顺手。

如果不在意 X540 是十年前的型号，那有条件（ Cat6 UTP/光纤）时上 10GbE 更划算，这些老产品已经收回成本，有白菜价的条件。另外这些老卡普遍只有 pcie2.1 ，在 MSDT 上用比较容易遇上通道不足的问题。
I350 个人觉得没必要，家用不如直接怼 4 个 RTL8111 大力出奇迹；数据中心直接上 10GbE 方案，I350 搞不好已经成了坑中小企采购的玩意。

不过有些时候换不了线是一个没得商量的问题，那 2.5GbE 靠线路兼容性享受一点溢价也不是不能理解，现在的 SATA SSD 偏贵也是这种情况。

先考虑找邻居共享宽带吧，买新卡你也拿不到。
要么就看看什么小米一元流量和华为天际通什么的。
如果运气好家里有小米通信的白卡应该也能线上开卡。

2.5G 的目标用途是在不能更换布线的前提下以较小代价提高带宽。跟那些全新 10GE 网卡（ UTP/光纤，还要算上收发器）是很便宜了。拿全新跟全新比，不要将洋垃圾拿出来比。

我觉得是微信本身已经没啥必须通过包体更新才能实现的**用户可见**的新特性了，甚至需要的组件老早就存在于包体里了，反正热更云控什么的都是基本操作，上不上特性跟包体版本没太大关系。
至于用户不可见的部分，说了也没用。
另外国外渠道相对单一且完善，像 GMS 的自动更新应用也是默认打开的，频繁发版也不怎么打扰用户。

没有审查能力的话确实是这样。
如果有简单的审查能力，尽量用功能单一的脚本，同时只允许引用知名的库脚本。这类脚本不会很长，功能也比较明确，比较容易检查。

8100 不算是坑吧。一台手机 SoC 不是全部，你还得看周边配置，例如拍照充电电池之类的。
考虑到 K40(870)换代是 K50(8100)，后者不至于比前者差，除非你就是不信任联发科。
我很心水 K50 ，但没有无线充电让我觉得很难受。

可能的原因，依据不太充足
1. 欠电保存导致电池损坏，影响放电能力，机器需要降频避免电压不稳
2. GMS 是强制更新的，不存在旧版本不影响性能的情况，因为压根没法用旧版本
3. GMS 的更新是静默进行的，可能会后台拖慢响应速度
4. 闪存数据挥发，需要更多的读取和纠错来恢复数据

一般不更新也不影响使用吧。
我的经验是去设置页主动点一下检查更新，如果用了分应用代理，要把“android 系统”也拉进去。
从米 6 用到米 9 都没出现过更新不了的情况。
现在 play 商店有 minimumapi21 arm64 版本，下的时候优先找这个版本。
https://gitlab.opengapps.org/opengapps/arm64/-/tree/master/priv-app/com.android.vending/21/nodpi