我用 ChatGPT 用 Bash 做了一个，还可以接受 Post 参数作为命令参数。

但是本站不欢迎 ChatGPT 回复，所以就不贴了。

建议开发自主可控操作系统，如果俄罗斯没有开发能力，可以购买强大的鸿蒙，彻底解决卡脖子问题。

@arfaWong US or UK

- 低空飞行时容易被击落

其实无人机的发现难度高于有人飞机，低慢小普通雷达很难发现。目前主要是靠红外雷达。

- 小型无人坦克

小坦克的通过性太差，仅用于某些特种作战。巷战更是别想，你怎么上台阶？

小公司直接 git ops 就完了，至于 pipeline 用什么都可以。gitlab ci ，jenkins 等等，没啥大的区别。

搜了下之前的邮件，没有代发。

正常来说不应该代发。

iOS 很有意思，默认配置下，取景框里是镜像的，但是拍出来是不镜像的。符合当镜子用的需求和拍照的需求。

iOS：设置-相机-构图-镜像前置镜头

这个在 iOS 上默认应该是关闭的，也就是默认不镜像。

7 楼是对的，正确的视觉设计就是手机分左右侧，大屏幕（电脑等）放同侧。

好奇什么样的小本买卖不想让人看到名字中的某个字。

交通费不在保险公司范围内，你只能和全责方协商。

他不给你只能起诉他，有发票的情况下，假设一天两百，四天八百。但是法院一般都会给你打个折扣。能要回来两三百就不错了。

如果没有发票，只给你公共交通费，一天二十？

地铁系统的问题，坐标北京，印象里没有失败过～

@uiosun 集群版本不能指定 db

但是我不同意 db 无意义。虽然是设计失误，但是既然有这个功能，下游还是得开放配置。

go-zero 就是被国内开发环境吊打的太少，老板或者客户说，你的 db 就是 3 ，要么搞定要么滚蛋。你怎么办？

这个分为两个安全问题：

1. AES 密钥放到板子上行不行？
答：不建议，AES 没有 Public Key ，是对称加密。安全角度上，将对称密钥放到板子上风险较大，意味着一旦你一个板子被人读到了密钥，那么所有的通讯的加密都无效了

优化方案 为每个板子生成单独的 Key ，如果不便于烧录，可以采用首次连接通过固定 bootstrap key 签发单独的 key 的方案，这样哪怕 bootstrap key 泄漏，获得 key 也不能用于之前的设备。

这个方案进化后就是签客户端证书，不过都证书了，那用 https mtls 是最简单的。


2. 传输层手搓 HTTP + AES ，行不行？
答：一般安全需求下（防脚本小子），可行。高安全需求（涉及到金钱、个人关键隐私信息等等），不可行。


成本可以接受的高安全需求环境下，建议使用 ATECC608 之类的安全芯片，可以自带客户端证书或者私钥，无法通过技术手段读取。而且加解密都是通过安全芯片进行的，也减轻了 MCU 的计算负担。

@lesismal

1. 即使是内网环境，所有的流量也应该加密，哪怕是 TCP 也应该套 SSL 。不搞这个你连等保都过不了。

2. 线头阻塞是个啥玩意，说的是 HOL blocking ？这个一般不是翻译为队头阻塞么。

这里有点矛盾，因为 TCP 的队头阻塞是在丢包率比较高的网络中才有较大的影响，如果不丢包也就没什么阻塞一说了，而你之前论证不需要 SSL 说是内网环境，内网的丢包率通常是非常低的。

另外 TCP 的问题和 gRPC 有啥关系，你换其他 TCP 上的 RPC 实现不是一样的问题么。连解决方法，比如 multiplexing 都是一样的，别的 RPC 能用，gRPC 也能用。

当然你可以换基于 UDP 的 RPC 实现，gRPC 社区我看也在做基于 QUIC 也就是 HTTP3 作为传输层的工作。

如果是 1/3 首付然后共同还贷，加名字是很合理的。因为共同还贷用的是夫妻共同财产。

如果是全款的房子，就不太合理了。

@lakehylia 嗯，这几年可以了。以前代位追偿也要算一次出险，现在无责代位追偿不算出险。

总的来说，不算性别歧视，还是男司机比较好伺候，处理过自己和别人的几次事故，有无责有全责。
男司机一般比较冷静，责任定了，就报保险修就完了，也不去主张什么交通费、折旧费这这那那的。

乐鑫确实不错，esp32 开始越来越流行。

但是芯片好不好和用不用是两码事，和你能不能入场也是两码事。