哈哈哈，一年前我一同学的客户就提出过这奇葩要求，我有幸帮他解决过，记得是用了 nginx 的一个不是默认自带的模块，需要自己编译安装。

摆烂到不至于，员工只会按照规矩死板办事，airpods pro 的召回计划，有机子用来专门检测，能检测出来就给你换，检测不出就不给。

看过一个段子：你非要人家说你丑?

同一个固件也会变差，我用了一年多，感觉降噪差了很多，大家都说是固件升级原因，我也就接受了这种说法。

因为首批用户有召回计划，我去免费换新了，新耳机的固件和我旧耳机的一样，都是当时的最新版。我再次到车站带上新耳机时，哇，那种第一次带上时的感觉又回来了。

现在新耳机又用了一年半了，感觉又回到原来那种鬼样了。我觉得，新固件降噪可能确实削弱了一点，但主要原因还是硬件老化造成。

@moremoney

1. IEE 754 标准中，根本就无法精确表示 -0.02 这个数，所以 -0.02 是你舍入得到的，还是软件舍入得到的

2. 问题中”这个数“，到底是指 65532 还是 -0.02 ，不明白你的意思

3 ”FloatToSignedWord“，按字面意思是 float 的 32 位的二进制，转换成 16 位有符号数 ，16 位有符号数表示的范围在 -32768~32767 ，你又是如何的到 65532 这个值的

所以根本没人能解决你的问题，大家全靠猜

float 有 -0.02 这个数？

@xiaojiang68 之前也差点因为这个问题弃用，把文件管理协议切成 scp 后，就再也没掉线了

自找苦吃

PDF 翻译 加 1 ，能做出来绝对有市场

@nomagick SSH 三种登录模式：密码，公钥密钥，证书，我没有搞混，是你不了解技术进步了。

@nomagick SSH 推荐的安全登录方式是证书登录，怎么就没 CA 了，密码模式确实没 CA ，但它就是这么的不堪，随时被中间人工具，你能用不代表它安全，只是没人攻击你罢了。

@nomagick 你不会天真认为 DH 算法能防止中间人攻击吧，中间人可以两端都骗，算出两端的密钥，最终解决方案就是和 TLS 一样，引入 CA 才能解决。

为什么不用现成的软件，dexpot 虽然不更新，但依然好用

@bowser1701 已经开放很久了, 上次和 B 站某 Up 有点误会

session cookies 傻傻分不清

xxx 管理平台可破

后端服务之间远程调用目前两大主流分别是 rpc(远程过程调用) 和 RESTful 风格的 http，rpc 一般工作在应用层以下，而 http 是应用层协议，RESTful 只是 http 调用的一种风格和 rpc 没关系，你前后端交互 API 设计也可以用 RESTful 风格，前后端分离是一种软件设计模式和 RESTful 或 rpc 都没关系

都 root 了，直接官网下 frp 不就好了，配合 scrcpy 体验很好