想起看过的一个论文，以前 HTTPS 少的时候，墙内的人访问一个含敏感词的页面过一会儿以后会收到一个从运营商核心网 IP 来的重放。论文作者猜测是触发之前墙并没有保存已经处理过的数据包的内容，触发以后想看看完整的页面是什么。

让我想到十几年前的 Google Wave ，既可以当邮件又可以当 IM ，还可以当协作文档和游戏平台，它发布的时候大家是多么激动，可惜当时 JS 引擎的性能太差了，界面非常卡顿。

当然对于普通用户最大的困惑是不会用，不理解为什么自己的话没打完别人已经开始打回复了。

还建议你看一下你那个 NUC 的电源能不能带动 3 个设备，因为 67W 以上需要加入 PFC 电路，很多小电脑的电源是 65W 。

盒子都在 PCDN 吧，还能怎么弄呢？

如果是 ARM 版的 OneNote 那 x86/64 的插件估计是无法兼容，以前装 64 位 Office 的时候它还会问你真的要用 64 位吗，32 位兼容性更好。。。。你可以试试装个 x86 版的 OneNote

缩写可不可以当场单词发音是约定俗成的，有一些不成文的规律，但主要还是靠记忆。

外国人 CLI 都是一个一个字母读的。
GUI 读 gooey 的比较多，但是 G U I 的也有（通常是外行）。
再比如，DAO 做 Data Access Object 的时候一个一个字读，数字合约那个当成一个词发音居多。

如果你周围没有英语母语的人来问的话，可以试试用 Google Translate 的发音功能，它后面的 TTS 引擎里面有这些不规则的数据。

如果当时数据库还在运行，不要关机那 file handle 应该还在，从 procfs 可以找到。

（真）云服务器可以把文件系统 trim 关掉也不会影响性能，这样可以大幅提升恢复的概率。离线修复的话应该先把磁盘镜像做好 snapshot ，以防止修复失误造成更大的损失，如果云支持运行内存也能 snapshot 那更好。

3-2-1 备份必不可少，不要把全部鸡蛋都放在云上。

我在的公司是个大型供应链外企，在用 CrowdStrike Falcon ，我自己机器就触发过它好几次，最搞笑的是它对 Visual Studio 刚升级以后编译出来的二进制特别敏感，经常是我 exe 才出来就被它删了或者禁止访问，而且它也不告诉你，VS 报错信息也差劲，第一次遇到花了好久才发现为什么。我最后发现空白项目或者 Hello world 也能触发，我估摸是写病毒的才配用最最新版的编译器？

现在为了防止 exe 在生产环境被它删掉我们就只能用旧版 VS ，开发部门的同事都挺反感它的，不过对于非技术用户来说确实可以防住他们中勒索病毒。

不要说政府，就是大公司证书如果没有自动化，全部换起来也是要花很长时间，因为证书没有更新搞死的 K8s 集群的事情很多大公司都遇到过，开自己 CA 的很大一个动机就是可以签发长一点的证书，节省更新的人工。

台湾这个政府 CA 老实说已经很配合了，Google 和 Mozilla 如果敢吊销美国政府的根 CA 的话，相关负责人可以直接被以危害国家安全名义起诉。换成国内的话就是请安装这个 12306 根证书再用我们网站。。。。

想出这么一个新策略，免费帮攻击者刷上传，加速他们被封：

识别出攻击以后，把 TCP send window 降为 1 ，并且延迟发包，这样攻击者要反复重发一个几十字节的 ACK 包才能下到一个字节，上传要高于下载了。

@laminux29 删库自爆一个医院的系统？这可不是一般的可刑，是非常刑。要是这个医院正巧在这个期间死人了，还可以栽赃，删库的人判刑不说，估计家里还会变成病人的灵堂。

@FreddyLiu
> 是不是我的电脑端也要有两个网口，才能通过 SMB 多通道实现速度提升？现在只有一根网线的话，即便是 2.5G 口也是千兆口的速度？

不需要的，本地是一个口也会同时尝试往 NAS 的两个 IP 发 TCP 连接，这样 NAS 两张网卡都可以利用上。


如果你交换机和 NAS 都支持的话，@shuax 说的 balance-rr 模式其实是最理想的，就是实现了你本来设想的 1+1=2 的带宽，也不需要特殊协议的支持。但这个模式一定要交换机里面配置一下才行。

人家拼多多那个是多个 0day ，现在一个 0day 值很多钱的，最差也可以报告给 Google 拿个 bug bounty 的钱。如果不报告然后自己写一个扫描器反而可能会被 Google Play 下架并 ban 掉开发账户。

终端用户能做的就是检查 Android 安全更新是不是最新版的+祈祷厂商没有在魔改的时候造成新的漏洞。

首先除非你有被国家级单位盯上的可能，那 TPM 旁路攻击根本不需要考虑，因为能把自己挂到 LPC 总线上的攻击者完全可以通过其他的方法攻击，反正读出你的密钥是没有问题。唯一的解决方案是把 TPM 和内存直接集成进 CPU ，比如苹果的处理器。

至于雷电 DMA 漏洞是老黄历，Windows 系统中安装 Intel 的雷电驱动以后，插入新的雷电设备需要管理员权限才能允许 DMA 。同时最近版本的 Windows 10 和所有版本的 Windows 11 都可以启用 BitLocker Core Isolation ，之后 DMA 也会被限制住，再没有权限读取内存里面的密钥。

最后我个人的观点是凡是软件实现的东西都比硬件更容易有漏洞。几乎所有在固件里实现的 TPM 都出现过泄露 key 的终极漏洞，而我知道的最严重的硬件 TPM 问题只是生成的随机数不够随机而已。

另外如果你不相信你机器上的 TPM 的话，那也不用相信 Secure boot 了，那一切在那台电脑上的操作都是不可信的，无论你是如何输入密码。比如你被一个特工盯上了，而你电脑上没有启用 TPM ，那他可以很容易的在你电脑上装个 rootkit ，你下次启动的时候只要输入了密码就会被通过网络发送出去，他就可以解密之前做的硬盘镜像。

我很久前做的项目，数据库是跑在机械硬盘的 SAN 上面，达不到响应速度要求，于是软件会在启动的时候把数据复制进一个 in-memory 数据库，再定期同步回 SAN 数据库。但其实如果我本地调试的话，没有多线程的情况下，直接用 SAN 数据库那个性能也是可以的。

所以其实内存级别的随机 IO 速度对于绝大多数应用并没有必要，SSD 在个人用的场景下绝对绰绰有余。