@rojer12 x86 的电视盒子，有什么好一点的方案吗？大概查了一下，Android TV 已经没有 x86 支持了

自己写个 python 脚本，定义好分组逻辑，然后用这个脚本生成最终的 yml 不就好了，估计简单需求逻辑代码 100 行以内就可以搞定

累了，IPv4 赶紧毁灭，全面普及 IPv6 吧

@AlexaETF 这种模式应该是比较好的，不过对于大部分人来说坚持记账很有挑战

华三的易用性怎么样？最近也是在纠结用 ubnt 还是用华三

FTTR 就是多此一举，真实情况是，对家庭网络没需求的人，在现有 5G 的覆盖下，连宽带都用不着拉，回家也继续手机用 wifi ，对家庭网络有需求，自己搞 nas 之类设备的人，谁会用你的 PON 设备放到房间？以太网的路由器交换机多成熟，丰俭由人，就算想上光纤网络，也是基于以太网的光纤网络，而且没人会给每个房间都拉光纤

车是好车，不过我所在小区鸡贼开发商地下车位宽度只画了 2.4 米，停不下宽两米的车，只能告辞

用啥 finder ，直接开 iTerm2 搞

@ren2881971 话说为啥大家都在提 SM 算法，之前貌似大量使用的是 RSA/AES/3DES ，SM 已经作为规范被强制使用了吗？

@cnbattle 我说的方案对付一般的中间人攻击是没问题的。同意你的观点，在安全问题上没有完美方案，只是增加门槛（大力出奇迹各种加密算法也不是不能破解，更别说不安全的软件硬件环境，哈哈）

@litchinn 正解，能采用加密保证安全的前提是浏览器运行环境（包括浏览器、操作系统、甚至硬件）安全，一般在根证书可信的情况下，https 加密可以满足绝大多数场景

@hhjswf 客户端不配置私钥，只有公钥，所以不存在私钥泄露问题

先使用非对称加密算法完成密钥交换，然后再使用对称算法用密钥对业务数据进行加密，简单过程大概这样：
1. 客户端（ js ）内置非对称加密公钥，在握手阶段，客户端随机生成密钥的配置，将这个配置用公钥加密后发给服务端。这样即使加密后的内容被截获也无法破解，因为私钥在服务端存储。
2. 服务端用私钥解出密钥配置后，用对称加密算法和服务器端提供的密钥加密响应。
3. 客户端对响应进行解密，确认服务器端已经成功配置，后续使用对称加密进行通信。
之所以搞这么麻烦，是因为一般来说非对称加密只用来处理小数据段，加密大量数据时效率很低而且也不容易解决双向加密需求。

@520discuz 我理解大佬的意思是接下来一段时间钱确实会更值钱，可是由于经济不好，大多数人并没有能力判断什么时候经济会变好，也就没有魄力在值钱时把钱有效地花出去，最终还是会持币迎来新一波货币贬值。就像炒股一样，侥幸在低位买进的股民，在股价上升期往往舍不得卖，结果还是持股做了一回过山车。

@reallynyn 听君一席话，胜读十本书。关于口罩那部分，用来比喻经济萧条期间的通缩太形象了！

@KnightYui 做网关何必 Surge 呢，随便用 docker 运行个 clash 不就搞定了

家用的话，ER-X 就够了，200 多块钱可以买到二手，基本都是个人卖家，出二手的原因一般是不会用