用户多就是可以为所欲为的.jpg
国行 ROM 想要真正杀掉微信还不容易，得进设置里结束运行才行。
我甚至好奇为啥微信不给其他 app 做推送服务，优势巨大啊，不过可能这生意不赚钱。

好像 facebook 也是这么叼自己做推送的。

userscript 解决
https://greasyfork.org/zh-CN/scripts/423001-twitter-media-downloader

如果乐观点说，饿了么为了构建竞争壁垒，不会因为你开了这个会员就无条件把数据都透露给合作方的，肯定是有限度有脱敏的。如果真到要倒闭了卖数据捞最后一波，或者意外泄漏啥的，那你有没有同意这个协议无关紧要。

就算你不用这个，各家连锁餐饮基本都有搞点餐 wx 小程序啥的，地理位置+openid 都成标配了，条款跟这里列的差不多。

我觉得多装个浏览器挺好的，例如 Chrome Stable 带拓展日用，Chrome Dev 做开发，还能顺便测试新版本兼容性。

你那是隔一睹墙哦，无线信号没法穿透水泥墙的，只有衍射。

mmc 是有类似 trim 的低级指令的。理论上 pcie/SoC 内建读卡器（ win 下分类为内存技术设备，linux 下识别为 mmcblock ）支持这种指令。
可以考虑插到 linux 的机器上处理，反正也不需要天天做的事情。
另外还有个要注意的，第一次格式化用 sdcard.org 的 SD Formatter 来格式化，然后原地更换文件系统，好像能缓解性能下降迹象，但我不确定这个工具是不是只是在分区前面留了点空闲空间而已。

如果用户量不大，可以先用发邮件-激活码的模式。

先排查一下是不是 pmtu 问题 /t/800024

我曾经用过所谓的 passthrough 配置，就是 WAN 侧只有 /64 SLAAC RA 然后 LAN 侧用 odhcpd RA relay 模式，会有长时间无 IPv6 流量会导致默认路由丢失和同 /64 子网不互通的问题，不知道怎么修。我看你的抓包记录 ICMPv6 只有 NS 没有 RS 和 RA ，不知道会不会是类似问题。

1. 先用传统方法（ dhcp 提供的 dns 服务器）查询 doh 服务器的 ip 。这样设计的好处是自动感知纯 ipv4/ipv6 网络
2. 配置 doh 服务器时会一并配置回落 ip 地址，大部分 doh 客户端都支持这个功能

查了下 ffmpeg 文档，最通用的 mp4 容器支持 128 位密钥的 cenc-aes-ctr 加密，不过基本没 GUI 视频播放器支持解密这个。
主流的流媒体 DRM 加密都是非通用实现，没啥参考价值。
直接用 zip 打包加密就好了，注意最好用 Store 算法（就是不压缩）

2 开头的都是公网地址（ GUA ）。
通常防火墙规则是将 /64 的子网当做内网，或者根据 RA 通告的前缀长度决定，使用 SLAAC 的前缀长度不超过 /64
如果内网的路由器 RA 有广播 ULA 前缀（ fc00::/7,用途类似 ipv4 的私有地址）,也可以用这个。
链路本地地址 fe80::/10 只能在链路上用。
连不上多数自己路由器配置问题，有些路由器 WAN 侧和 LAN 侧使用相同前缀的话路由会有问题。

我从 win10 20H1 就开始不定时遇上这个问题，之后就换成 win11 insider dev 了，出现概率要低很多，也没查出原因。

@wxf666 @lslqtz 视频的话通常继续用 AAC-LC 或者 opus 就够了，带宽没紧张到那种地步。
AAC 本身有一个 HE-AAC 的版本，但仅在低码率有优势，FFmpeg 指南建议只在低于 32kbps/ch 的时候考虑使用。
aptx 和 LDAC 估计也是这个问题，不是低码率就没优势，运算更复杂，兼容性肯定打不过 AAC-LC 。

估计是预装的 windows （可能还有 office ），至少先进去一下都激活了，不然日后重装就恢复不了正版了。
出厂就有 bitlocker 的估计是支持现代待机（ S0ix/Low Power S0 Idle ）的机子，Linux 对这个的支持好像不太好，你可以看看能不能换回 S3 睡眠，也不要用太久的内核。

早期的 SM 密码体系（ SM1 ）是不公开实现+双证书体系，就是 @jeesk 的那种情况。当然不出意外地没人用。
目前公开标准化并可以在 TLS 系统中使用的是 SM2 和 SM4 ，推这玩意近 IETF 标准的好像还是蚂蚁金服的团队的功劳。
SM2 其实也就是一个自己选的椭圆曲线，跟目前常用的 NSA Suite B 一样存在参数来源不明的问题，但又没人证明这里有什么缺陷，论设计透明度都不如 Curve25519 。

这种密码算法一般就是本着自己设计的只要设计水平不落伍，就算出问题自己更有可能早一步发现而已。

200 台，你这是公司内网吗？别乱搞啊，真要搞也应该是防火墙+堡垒机解决方案的。

音频这边的压缩改进主要不是用在网络流媒体上了，我知道这类技术用在蓝牙上还是有需求的，保持质量极限压低码率好在低带宽的 BLE 链路上传输。

@jim9606 我好像搞错了一部分，.netstandard2.0 能覆盖大部分受支持的.NET 实现，通常如果希望库在大部分.NET Framework 和所有未来.NET 版本兼容会选这个作为目标。
通常可以认为平台 Win32 API 功能最齐全，不过想要易用性我就不在行了，看有没有搞这行的大佬了。

.NET 库兼容性和可移植性上，netstandard2.0 是最佳选择，这个目标被所有 netframework 、netcore 、net5+支持。
我见过的几个需要访问 Win32 API 的.NET 应用，通常是拿到非托管 DLL （系统 DLL 或者 SDK 提取的），然后根据 C 接口用 C#自己写一个 P/Invoke wrapper 来调 DLL 的方法。这样你的主应用想用什么版本的.NET 都行。如果担心 WinUI3 没成熟的可以考虑.NET6/7+WinUI2 。
这个 wrapper 可能有现成库可以用，nuget 包通常会捆绑相应的非托管 DLL 。